Hi Matthew,
Many thanks for your review. Very helpful. Please see my reply inline.
Thanks,
Cheng
-----Original Message-----
From: Matthew Bocci via Datatracker <noreply@xxxxxxxx>
Sent: Wednesday, November 15, 2023 1:59 PM
To: rtg-dir@xxxxxxxx
Cc: draft-ietf-spring-mpls-path-segment.all@xxxxxxxx;
last-call@xxxxxxxx;
spring@xxxxxxxx
Subject: Rtgdir last call review of draft-ietf-spring-mpls-path-segment-16
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
MB> 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?
[Cheng]Ack. From
https://www.rfc-editor.org/rfc/rfc5586#section-1.3，we see the correct name is Generic Associated Channel Label, so we might update the name by this one.
Actually, this has been discussed before. The answer is no modification is introduced to GAL. Therefore GAL will be the last label in the label stack/bottom of the stack.
Please the text in section 2.
"
When a PSID is used, the PSID can be inserted at the ingress node and MUST immediately follow the last label of the SR path, in other words, inserted after the routing segment (adjacency/node/prefix segment) pointing to the egress node of the SR path.
"
MB2> OK
...
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.
[Cheng] In the draft, we are using 'node; instead of the LER. Is it ok for you to modify it like below
Signaling of the PSID between the egress node, the ingress node and possibly a
centralized controller is out of the scope of this document.
PSID is a local label, and allocated from the local label space of the egress LER/node. This has been clarified in the first paragraph of section 2.
"
A Path Segment is a Local Segment which uniquely identifies an SR path on the egress node. A Path Segment Identifier(PSID) is a single label that is assigned from the Segment Routing Local Block (SRLB) [RFC8402] of the egress node of an SR path.
"
MB2> Yes, that is fine fine me.
Section 3: Use Cases
MB> These use cases seem rather underspecified for a standards track
MB> 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.
[Cheng]The path segment is used for identify an SR path, and it introduces nothing excepting a PSID for identifying the path into 1+1 END TO END protection. Therefore, we think this text is only for informative. How about adding a sentence to state that the
detailed use case of 1+1 end-2-end protection is out of the scope of this document and will be described in other document?
MB2> Agreed
Section 3.1: Path Segment for Performance Measurement
MB> 1st paragraph: s/Since Path Segment/Since a Path Segment Can you add
MB> a reference for iOAM.
[Cheng] Ack, thanks! Is RFC9197 the right one?
MB2> I think so.
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
MB> 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
[Cheng]Thanks for the modifications. However, I may prefer to delete the last paragraph because it does not provide any new info actually. The first two paragraphs are enough for reader to know that the Path Segment is needed in this use case. We can also
add a simple sentence " The detailed solution of using Path Segment in end-to-end 1+1 path protection is out of the scope of this document." to complete the logic of this section. It also addresses the comment you mentioned above. Is it ok for you?
MB2> OK with me.
Regards
Matthew
