Dear authors: I just finished reading this document. Thanks for a clear and straight forward draft!
I have some comments (see below). The main one is about the inclusion of hosts as defining the source routed path, without them being explicitly called out in the draft-ietf-spring-segment-routing. Knowing that some of the authors overlap, please make sure there are no holes in the Architecture. I will start the IETF LC once this item is addressed, and a revised ID is produced do address the other comments, as needed. Thanks! Alvaro. Major: M1. As with draft-ietf-spring-segment-routing-central-epe, it worries me that hosts are called out as being able to define the source routed path. Please make sure that the Architecture document has some text about the use of hosts – maybe constrained to the case where the hosts can be programmed. Section 6 provides some good text for that. Minor: P1. “service chain”: please remove to avoid confusion with SFC (same comment as for all the SR documents). P2. References: - s/rfc3107/draft-ietf-mpls-rfc3107bis - The references to I-D.ietf-spring-segment-routing-central-epe and rfc7938 should be Normative. P3. There are 2 instances of using rfc2119 language, I don’t think that either is needed because you’re really paraphrasing other documents. IOW, I recommend you take the Normative language off. P3.1. Section 4.2.1. (Control Plane): “The implicit-null label in the NLRI tells Node10 that it is the penultimate hop and MUST pop the top label…” This is normal MPLS operation, so the MUST is really not introducing anything new, just paraphrasing the MPLS architecture. Instead of the MUST, a reference to MPLS would be more than enough. s/MUST/must P3.2. Section 11. (Manageability Considerations): “As recommended in [I-D.ietf-spring-segment-routing], the same SRGB SHOULD be allocated in all nodes…” The Architecture document doesn’t (yet) make that recommendation explicitly, but a pointer to it should be enough. s/SHOULD/should P4. Section 4.2.4. (Global BGP Prefix Segment through the fabric): “…a packet with top label 16011 received by any node in the fabric…and the label 16011 is penultimate-popped at Node10”, or at Node9, right? P5. Section 4.3: “…and with the BGP-Prefix-SID attribute extension defined in this document”; that was not defined in this document. P6. Section 4.3. (iBGP Labeled Unicast (RFC3107)) contains this text: “AIGP metric ([RFC7311]) is likely applied to the BGP-Prefix-SID as part of a large-scale multi-domain design such as Seamless MPLS [I-D.ietf-mpls-seamless-mpls].“ This paragraph sounds random to me as there is no further explanation of the use, impact, advantages, etc. Neither AIGP/Seamless MPLS is mentioned again in the document, nor in draft-ietf-idr-bgp-prefix-sid or rfc7938. Please either expand the concepts/use or delete this paragraph. P7. Section 5. (Applying Segment Routing in the DC with IPv6 dataplane): “Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID advertising the support of the Segment Routing extension header (SRH, [I-D.ietf-6man-segment-routing-header])…” draft-ietf-idr-bgp-prefix-sid says nothing explicitly about the BGP-Prefix-SID Attribute advertising support for the SRH – maybe it should, but it doesn’t. NEW> Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID for IPv6 packets destined to segment 2001:DB8::5 ([I-D.ietf-idr-bgp-prefix-sid]). Instead, put the reference later in the same section where it says “…sending IPv6 packets with a SRH extension header…”. Nits: N1. s/BGP4/BGP-4 N2. Section 3: “Further in this document…” A reference to Section 7 would be nice. N3. s/index11)/index11 N4. It would have been nice to illustrate the operation in 4.2.x using IPv6 addresses. N5. Throughout most of the document the nodes are referred to as Nodex, but there are a couple of places where Torx is used. Even though these nodes have been identified as ToRs, it would be nice to be consistent to avoid confusion. N6. Section 7: s/problems describe above/problems described above Also, putting a reference back to Section 3 would be nice. N7. The content in Section 7 is good, and the DC example helps in the illustration – but the applicability is not just constrained to it. It might be a good idea to add at note at the start mentioning the broader applicability. N8. Please avoid using “we”.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
