Stefano, Thanks for the updated document. -04 address my comments.
Thanks. -- Bruno From: spring [mailto:spring-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com Sent: Tuesday, February 14, 2017 5:57 PM To: draft-ietf-spring-segment-routing-central-...@tools.ietf.org Cc: spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe Hi Authors, As the document shepherd, please find below a set of comments. Thank you, Regards, Bruno ====================================== Major comment: ====================================== Name and descriptors' content are not aligned between draft-ietf-spring-segment-routing-central-epe and draft-ietf-idr-bgpls-segment-routing-epe. Change seems to come from draft-previdi-idr-bgpls-segment-routing-epe-01.txt October 25, 2014. e.g. BGP Egress Peer Engineering or BGP Peer Engineering; PeerNode SID vs Peer-Node-SID; Node Descriptors vs Local Node Descriptors; Peer Descriptors vs Remote Node Descriptors; Remote Node Descriptors containing a Router ID vs not ... Note that this is also not aligned with draft-ietf-spring-segment-routing-10. ---- Security section is empty. ---- Manageability section is empty. ====================================== Minor Comment: ====================================== Terminology: This document uses the term BGP-PE for "Peer Engineering" while the BGP document (draft-ietf-idr-bgpls-segment-routing-epe-07) use the terme BGP-EPE "Egress Peer Engineering". A consistent name would be useful. Note also that PE is already a very popular term for BGP VPNs and stands for Provider Edge. Given that both functions may be used on the same network/node, using a different TLA would seem more user friendly. Note that even this doc use the term PE to sometimes refers to "Peer Engineering" and sometimes for "Provider Edge" (e.g. §1.2). This is confusing. Note that RFC 7855 and draft-ietf-spring-segment-routing-10 use the term "egress peer engineering" and "Egress Peer Engineering (EPE)" ---- Proposed: OLD: For editorial reasons, the solution is described for IPv4. A later section describes how the same solution is applicable to IPv6. NEW: For editorial reasons, the solution is described for IPv4 and MPLS SID. This solution is equally applicable to IPv6 with either MPLS-SR or IPv6 SR. Given this, section 6 seems useless. --- Abstract "This document is on the informational track." This sentence is probably not required as this is already indicated in the "Intended Status" of this same page. --- "The solution MUST be applicable to iBGP as well as eBGP peerings." I'm not sure to understand what is meant by "iBGP peering", and how does this solution apply to this case. --- OLD: A PeerSet segment to the set of peers (E and F). NEW: A PeerSet segment to the set of peers (E and F) belonging to the same AS. --- Names of sections 3.1 to 3.5 are very long and not easy to quickly parse. May be they could be shorten. e.g. OLD: BGP-PE Router advertising the Peer D and its PeerNode SID NEW: Peer-Node-SID to D --- In sections 3.x, in order to avoid being to IPv4 specific, may be OLD: IPv4 interface address NEW: IPv4/IPv6 interface address or may be NEW: IP interface address --- Somewhere in the doc (e.g. section 1), may be saying that the solution only allow TE for outbound traffic, not inbound traffic. This is probably obvious for the authors, but may not be to some readers. --- The solution allows advertising a single set of Descriptors with both Peer-Node-SID and Peer-Set-SID at the same time. (Which is good IMHO). But for Peer-Adj-SID, it seems to require to advertise another set of Descriptors dedicated to the Peer-Adj-SID. Why? And it's not clear to me whether this would be allowed to advertise the 3 types of EPE SIDs (Peer-Node-SID, Peer-Set-SID and Peer-Adj-SID) at the same time (with a unique set of Descriptors) --- Section 2 would seem a good place to define what is a PeerNode Segment, PeerAdj Segment, PeerSet Segment. --- 3.6. Fast Reroute (FRR) "An BGP-PE enabled border router should allocate a FRR backup entry on a per BGP Peering SID basis:" What do you mean by "should"? Is this "SHOULD"? "If multi-hop, backup via the remaining PeerADJ SIDs to the same peer." This is mandating FRR Link protection. What if people want node protection? "1. If multi-hop, backup via the remaining PeerADJ SIDs to the same peer." Do you mean _local_ PeerADJ SID? or may be :s/same peer/same Peer-Node-SID (as in "2.", it seem restricted to local SID) "2. Else backup via local PeerNode SID to the same AS." Don't you mean backup via the local remaining PeerSet? (Otherwise, what's the purpose of PeerSet?) "3. Else pop the PeerNode SID and perform an IP lookup." This node is known to support BGP-EPE. It could possibly learn EPE SID from other nodes. Why forbidding the use of an EPE SID advertised by another EPE node? --- §4.1 "The BGP-PE controller should collect all the paths advertised by all the engineered peers." A reader could understand "paths" as EPE paths, while I think you are refering to IP unicast external routes. BTW, this document never states it's applicability with regards to BGP AFI/SAFI. A priori, it looks to me that this document is only application to IP unicast route, i.e. AFI/SAFI 1/1 and 2/1. An possibly to IP labelled routes assuming the labels are those from the external peer. (AFI/SAFI 1/4 and 2/4) Could this be indicated somewhere in section 1? --- "Alternatively, Extended Metrics, as defined in [I-D.ietf-isis-te-metric-extensions] could also be advertised using new BGP-LS attributes." What do you mean by "new"? "To be defined"? or "defined in draft-ietf-idr-te-pm-bgp"? or else? --- Terminology is not consistent. e.g. "BGP Peering Segments" vs "BGP Peer Segments" Which is the right term? --- "A static IP/MPLS route can be programmed at the host H. The static route would define a destination prefix, a next-hop and a label stack to push. The global property of the IGP Prefix SID is particularly convenient: the same policy could be programmed across hosts connected to different routers." Labels (value) are local, not global, so the last sentence is debatable. Same comment for §7: " o Ability to deploy the same input policy across hosts connected to different routers (avail the global property of IGP prefix SIDs)." --- "This RFC3107 policy route "overwrites" an equivalent or less-specific "best path". As the best-path is changed, this EPE input policy option influences the path propagated to the upstream peer/customers." Regarding the last sentence, unfortunately the exact behavior is implementation specific. cf https://tools.ietf.org/html/draft-ietf-mpls-rfc3107bis-00#section-5 May be OLD: As the best-path is changed, this EPE input policy option influences the path propagated to the upstream peer/customers. NEW: As the best-path is changed, this EPE input policy option may influence the path propagated to the upstream peer/customers. Indeed, implementations treating the SAFI-1 and SAFI-4 routes for a given prefix as comparable would trigger a BGP WITHDRAW of the SAFI-1 route to them BGP upstream peers. ====================================== Nits: ====================================== OLD: set of peers (198.51.100.6 and 192.0.2.2) NEW: set of peers (198.51.100.6 for E and 192.0.2.2 for F) (Motivation: to ease the understanding as most people would not remember all IP addresses and they are also not indicated in the figure 1.) --- From: spring [mailto:spring-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Sent: Monday, February 13, 2017 11:08 AM To: spring@ietf.org<mailto:spring@ietf.org> Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-central-epe-03 [1]. Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *27th of February*. Note that this is *not only* a call for comments on the document; it is also a call for support (or not) to publish this document as an Informational RFC. We have already polled for IPR knowledge on this document and all Authors have replied. Two IPR have been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-03 [2] https://datatracker.ietf.org/ipr/search/?id=draft-ietf-spring-segment-routing-central-epe&submit=draft _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
