Reviewer: Matthew Bocci Review result: Has Issues The draft is generally clear and well written. Thanks! I have a few issues below that I think should be resolved before publication as an RFC. Minor Issues ------------ - Grammar and mis-placement of commas throughout, which makes the document hard to read in places. Please check through and correct. - Terminology. I suggest adding 'SRv6' since this is mentioned in the introduction. - Use of RFC2119 language. For a standards track document, I found there is a lack of clear usage of RFC2119 language. For example, in the last paragraph of the introduction, "It is normally used by the egress nodes for path identification". Do you mean it 'MAY' be used, or 'SHOULD' be used. What about intermediate LSRs? Can they ever use it? - Section 5 and 6. These are use cases for Path Segment. It would be clearer if they were discussed up-front in the draft to explain the drivers, requirements and uses of path segment before getting into the design. Major Issues ------------ My main issue is around label assignment/allocation. Section 2: Path Segment. This section states: "A Path Segment is a single label that is assigned from the Segment Routing Local Block (SRLB) [RFC8402] or Segment Routing Global Block (SRGB) [RFC8402] or dynamic MPLS label pool of the egress node of an SR path. It means that the Path Segment is unique in the context of the egress node of the SR path." If it is allocated from the SRGB then the scope of uniqueness can be much wider than just the egress LER. This leads me to ask how to choose whether to allocate it from the SRLB, SRGB, or dynamic range? Does this depend on the use case (for example MPLS-TP required a global identifier at the egress node for CV purposes). The use cases at the end of the document do not say whether the label needs to be only local to the egress LER or more widely scoped. I think they should make this clearer. Section 3: Path Segment Allocation This seems to mix label allocation with the control plane for distributing the label. This seems to be talking about local allocation at the egress node (the G-ACh case) vs. centralised allocation (using a controller). Please clarify. Also, the section discusses a hypothetical mechanism using signaling in the G-ACh. If this is not defined anywhere , I suggest removing this. If it is defined in a draft somewhere, then add an informative reference. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
