Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering
draft-ietf-idr-bgpls-segment-routing-epe-19
Yes
(Alvaro Retana)
No Objection
Roman Danyliw
(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
(Mirja Kühlewind)
(Suresh Krishnan)
Note: This ballot was opened for revision 18 and is now closed.
Roman Danyliw
No Objection
Warren Kumari
No Objection
Comment
(2019-05-15 for -18)
Not sent
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'
Alvaro Retana Former IESG member
Yes
Yes
(for -18)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2019-05-14 for -18)
Sent
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 IESG member
No Objection
No Objection
(for -18)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(for -18)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(2019-05-13 for -18)
Sent
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 IESG member
No Objection
No Objection
(for -18)
Not sent
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -18)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -18)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(2019-05-16 for -18)
Sent
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 IESG member
No Objection
No Objection
(for -18)
Not sent
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -18)
Not sent