Reviewer: Matthew Bocci Review result: Has Nits I have been selected as the Routing Area Directorate reviewer for draft-ietf-spring-mpls-path-segment-16. Summary ------- The draft is mostly ready to progress subject to fixing a few minor comments/nits as listed below. Major Comments -------------- None Minor Comments/Nits ------------------- Section 2: Path Segment ... Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks. As per [RFC5586], when GAL is used, the ACH appears immediately after the bottom of the label stack. MB> GAL stands for "Generic Associated Channel Header Label". Please correct the expansion above. MB> Are there any considerations as to where GAL and PSID are in a stack where they are both present? Is PSID always bottom of stack even when a GAL is present, or is GAL bottom of stack? ... Signaling of the PSID between the egress, ingress and possibly a centralized controller is out of the scope of this document. ... MB> Add 'LER' to ingress and egress MB> In my previous review I made the a comment about how you allocate the PSID. I mean, is it from a label space local to the egress LER, or is it global, or is the label block it is allocated from application specific? Please can you clarify in the draft. If it is application specific, then please say so and I would suggest stating that the label block it is allocated from is out of scope of the draft. Section 3: Use Cases MB> These use cases seem rather underspecified for a standards track document, particularly Path Segment for 1+1 End to end protection. To my knowledge, this mode of protection where you duplicate traffic over working and protect paths is only formally defined for GMPLS networks or for MPLS-TP. I would suggest either splitting this section into a separate informational document, or deleting the use case for 1+1 protection unless a reference can be added to a detailed specification of how it could work in segment routing. Section 3.1: Path Segment for Performance Measurement MB> 1st paragraph: s/Since Path Segment/Since a Path Segment MB> Can you add a reference for iOAM. Section 3.3: Path Segment for End-to-end Path Protection MB> I found the last paragraph a little hard to parse. I suggest making the following changes to make it more readable: s/binding this SR path identifiers/these SR path identifiers s/This equivalence group/An equivalence group s/an controller/a controller Regards Matthew -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
