Hey Alvaro, Thanks a lot again for your review. Have posted the next version. Please see response inline <Gaurav_1>.
Regards, Gaurav From: Alvaro Retana <aretana.i...@gmail.com> Date: Friday, November 3, 2017 at 7:33 AM To: Gaurav Dawra <gda...@cisco.com>, "draft-ietf-spring-segment-routing-central-...@ietf.org" <draft-ietf-spring-segment-routing-central-...@ietf.org> Cc: "spring@ietf.org" <spring@ietf.org>, "spring-cha...@ietf.org" <spring-cha...@ietf.org>, Bruno Decraene <bruno.decra...@orange.com> Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06 On October 30, 2017 at 1:53:07 AM, Gaurav Dawra (gdawra) (gda...@cisco.com<mailto:gda...@cisco.com>) wrote: Gaurav: Hi! Thanks for taking over this document! I have some remaining comments below, please take a look. I’m starting the IETF Last Call, which will be extended to account for the IETF meeting and the US Holidays. Thanks! Alvaro. ... M2.3. “The solution SHOULD minimize the need for new BGP capabilities at the ingress PEs.” What is the explicit requirement, that needs the “SHOULD”, from an interoperability point of view? <Gaurav> At Ingress PE, this requirement covers that there is need for some minimal configuration or protocol extension for Egress Engineering. Ok, but (1) the text doesn’t talk about configuration (just capabilities), and (2) I really think that Normative Language should not be used in this case because there’s really nothing that can be enforced: “SHOULD” means that “there may exist valid reasons in particular circumstances to ignore a particular item”, so there’s nothing that can be done if an extension or configuration is justified. Please s/SHOULD/should. <Gaurav_1> ACK Updated. Addressed in next version. M2.4. “The solution MUST accommodate an ingress BGP-EPE policy at an ingress PE or directly at a source host within the domain.” “MUST accommodate”?? What are you looking for? The ability to program at those points? The ability to instantiate any policy? <Gaurav> Solution MUST cover the ability to accommodate instantiation and programming of the BGP-EPE policy at Ingress. How about this: New> The solution MUST support the definition of an ingress BGP-EPE policy at either the ingress PE or at the source of the traffic. (I took “host” out because I assume that a PE in the other network is also a valid place.) <Gaurav_1> ACK Updated. Addressed in next version. ... P2. The examples in Sections 3.x seem incomplete and inaccurate to me. Also, the names used don’t match what is specified in draft-ietf-idr-bgpls-segment-routing-epe. In general, please be consistent with the names! For example: Section 3.1. (PeerNode SID to D): “ Descriptors: o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1 o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.4, AS2 o Link Descriptors (IP interface address, neighbor IP address): 2001:db8:cd::c, 2001:db8:cd::d Attributes: o PeerNode SID: 1012 “ Comments> - Section 5.1 in draft-ietf-idr-bgpls-segment-routing-epe uses “Local Node Descriptor” instead of simply “Node Descriptor”, and the BGP-LS ID is missing above. - s/Peer Descriptors/Remote Node Descriptor - The Link Descriptor uses the terms “IPv6 Interface Address” and “IPv6 Neighbor Address”… - s/Attributes/Link Attribute <Gaurav> ACK> Will compare and address in next update. 3.2-3.5 were not updated with the IPv6 names. <Gaurav_1> ACK Updated. Addressed in next version. ... P4. References: - Please add a reference for BMP and IPFIX. - Put the reference to BGP-LS on first mention (and not just way down in Section 9). - Replace the reference to RFC3107 with draft-ietf-mpls-rfc3107bis – and it can be made Informative. Not all the references were updated, and rfc3107bis is now rfc8277 anyway. <Gaurav_1> ACK Updated. Addressed in next version.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
