Last Call Review of draft-ietf-spring-mpls-path-segment-07
review-ietf-spring-mpls-path-segment-07-rtgdir-lc-bocci-2022-06-13-00

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.