Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering
RFC 9086
Yes
No Objection
Note: This ballot was opened for revision 18 and is now closed.
Alvaro Retana Yes
Roman Danyliw No Objection
Warren Kumari No Objection
Thank you for writing this (and to Sheng for the OpsDir review).
I especially wanted to thank you / the WG for the "6. Manageability Considerations" section...
I have a few nits to offer:
"SR segments allows to enforce a flow through any topological"
This needs a subject ("SR segments allows the network to enforce a flow through any topological..."? or "SR segments allows steering a flow through any topological..." might be better) - actually, the sentence seems clumsy, but I cannot figure out how to reword it to be better.
"An ingress border router of an AS may compose a list of SIDs to steer a flow along a selected path within the AS, towards a selected egress border router C of the AS, and to a specific EBGP peer." - I'm not sure if this was copied from some earlier text / a diagram, but the 'C' is not needed / is confusing.
"3. BGP-LS NLRI Advertisement for BGP Protocol
his section describes ..."
Missing a 'T'
(Adam Roach; former steering group member) No Objection
Thanks for the work that everyone involved has put into this document. I have only two minor editorial comments. --------------------------------------------------------------------------- §1: > This > use-case comprises of a centralized controller that learns the BGP Nit: "This use case is composed of a centralized controller..." or "This use case comprises a centralized controller..." --------------------------------------------------------------------------- §3: > his section describes the BGP-LS NLRI encodings that describe the BGP > peering and link connectivity between BGP routers. Nit: "This section..."
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
Just editorial stuff... Throughout: “i.e.” needs a comma after it. So does “e.g.”. — Section 1 — SR can be directly applied to either an MPLS dataplane (SR/MPLS) with no change on the forwarding plane or to a modified IPv6 forwarding Make it “either to” so it’s parallel with the “or to” that comes later. centralized controller based BGP Egress Peer Engineering solution involving SR path computation using the BGP Peering Segments. This use-case comprises of a centralized controller that learns the BGP “Centralized-controller-based” is a compound adjective that needs to be hyphenated. “Use case” is a noun, and should not be hyphenated. And “comprises” should not have “of” after it (“consists of” would, though).
(Deborah Brungard; former steering group member) No Objection
(Ignas Bagdonas; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
Hi, thanks for this document. I only have a minor comment: Throughout the document, PeerNode SID, PeerAdj SID and PeerSet SID are used but the IANA section and existing registry use Peer-Node-SID, Peer-Adj-SID, Peer-Set-SID. Although there can't be any confusion, it might be worth having a single naming.
(Mirja Kühlewind; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection