Skip to main content

Usage and Applicability of BGP Link-State Shortest Path Routing (BGP-SPF) in Data Centers
draft-ietf-lsvr-applicability-22

Yes

Jim Guichard

No Objection

Deb Cooley
Gunter Van de Velde
Murray Kucherawy
Paul Wouters
Zaheduzzaman Sarker

Note: This ballot was opened for revision 15 and is now closed.

Jim Guichard
Yes
Deb Cooley
No Objection
Erik Kline
No Objection
Comment (2025-01-04 for -16) Sent
# Internet AD comments for draft-ietf-lsvr-applicability-16
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4

* I'm kind of surprised that there's no mention of nor comparison with
  draft-ietf-rift-rift, which I thought was aimed at Clos/Fat-Tree
  deployments.

### S5.5.1

* For IPv6 link-local -only network design, see if RFC 7404 is a useful
  reference for this document.

## Nits

### S5.4

* "BGP sessions with a ToR device could have parameters than BGP
   sessions between..."

   ->

  "BGP sessions with a ToR device could have different parameters than BGP
   sessions between..."

  I suspect.
Gunter Van de Velde
No Objection
John Scudder
(was Discuss) No Objection
Comment (2025-01-22 for -21) Sent
Thanks for addressing my DISCUSS points. One nit that arose in the new version, "received by leave nodes” should be “received by leaf nodes”.
Murray Kucherawy
No Objection
Paul Wouters
No Objection
Roman Danyliw
No Objection
Comment (2025-01-08 for -20) Not sent
Thank you to Mallory Knodel for the GENART review.
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2025-01-06 for -19) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-lsvr-applicability-19
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Ketan Talaulikar for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)


### Section 1

Please re-expand `BGP-SPF` (as the abstract is not really part of the document).

### Sections 2 & 5

Please use OSPFv3 RFC rather than RFC 2328 for OSPFv2 ;-)

### Section 3

It took me some seconds to realize that the figure is rotated 90° as the more common setting with North = Tier 1 (e.g., as in figure 2). Is it on purpose ?

### Section 4

Suggest moving `Additional motivation for deploying BGP-SPF is included in [I-D.ietf-lsvr-bgp-spf].` at the end of this section and as a paragraph (currently, it seems out of the flow).

Should `SPF` be expanded ?

### Section 5.1

Should `SAFI` be expanded ?

### Section 5.2.1

Is it about LAG in `they are often aggregated at the link layer rather than the IP layer` if so, then why not writing it ?

Is it `each leaf switch` or "each leaf router" ?

### Section 5.4

As IPv6 RAs announce the link-local IPv6 address, is it a problem ? (normally not, but perhaps worth mentioning ? or adding a reference to section 5.5.1)

### Section 5.5.1

It is quite unusual to have a subsection adding a reference to its parent section as in `as described in Section 5.5, ``

Thanks for suggesting RFC 7404 ;-)

### Section 6

`One potential deployment would be the underlay for a Service Provider (SP) backbone` looks weird in a document whose title is `Usage and Applicability of BGP-SPF in Data Centers`... Suggest removing this section.

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)