Last Call Review of draft-ietf-spring-mpls-path-segment-16
review-ietf-spring-mpls-path-segment-16-rtgdir-lc-bocci-2023-11-15-00

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