Re: [spring] draft-ietf-spring-mpls-path-segment

[Cheng Li <[e-mail]>]

Hi Bruno,

Many thanks for your work! I am addressing the comments received from the WG, so it is fine/good to me that address your comments in the same time 😊
Please see my reply inline. The diff is generated by comparing with 09. The proposed update tries to address the comments from you, Ketan and Stewart.

If you like to use Github, the link is here: https://github.com/muzixing/SR-MPLS-Path-Segment/commit/3ace59b1e87859950dfac8a967ee560128843b6b

Respect and thanks,
Cheng


From: [e-mail] <[e-mail]>
Sent: Wednesday, July 12, 2023 10:41 PM
To: [e-mail]; SPRING WG <[e-mail]>
Cc: James Guichard <[e-mail]>
Subject: draft-ietf-spring-mpls-path-segment

Hi authors,

Since Jim is now the responsible AD, the shepherd for this document has been changed from Jim to myself.
As a result you/this document benefit/suffer from another review.

Please find below my comments/questions.

On a side note, I have two questions for you (for the shepherd writeup):
Are there existing implementations of the protocol?
Have a significant number of vendors indicated their plan to implement the specification?

[Cheng]Weiqiang has replied to you on these two questions. Path Segment has been implemented by a significant number of vendors for several years, and it has been used in large scale networks.
---

Abstract
"This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path in an SR-MPLS network."

Given that the path segment may be allocated from a local label of the egress node, (e.g. SRLB, dynamic pool), I believe that only the egress node may use that label to identify an SR-path. (not any node on the path/in the network).
If so I believe the following change would be more accurate:
OLD; to identify an SR path in an SR-MPLS network.
NEW: to identify an SR path on the egress LER

[Cheng] I tend to agree with you. However, the controller/Ingress may know the meaning of the Path Segment as well, so use ‘in an SR-MPLS network’ may be better than ‘on the egress LER’ ? But it looks ok to me to modify the text.

Same comment for the §1 Introduction. ("A Path Segment is defined to uniquely identify an SR path in an SR-MPLS network.")
[Cheng] Same above. Addressed.

-------
Abstract:
"A Segment Routing (SR) path is identified by an SR segment list. Only the complete segment list can identify the end-to-end SR path, and a sub-set of segments from the segment list cannot distinguish one SR path from another as they may be partially congruent. SR path identification is a pre-requisite for various use-cases such as Performance Measurement (PM), bidirectional paths correlation, and end-to-end 1+1 path protection."

This seems to be saying that "Performance Measurement (PM), bidirectional paths correlation, and end-to-end 1+1 path protection" is not possible without MPLS Path Segment. I don't feel that this is correct. Eventually you mean that "a form of path identification/discrimination", which is different as this identification may be performed at a different layer than the SR-path. (e.g. different egresss loopbacl/prefix SID, any form of ID below that MPLS stack (e.g. different IP address, L4 source/destination port, application specific ID (e.g. My Miscriminator?)...
May be consider rephrasing.

[Cheng] How about this?

_____NEW_____
A Segment Routing (SR) path is identified by an SR segment list. A
sub-set of segments from the segment list cannot distinguish one SR path
from another as they may be partially congruent. SR path identification
is a pre-requisite for various use-cases such as Performance Measurement
(PM), and end-to-end 1+1 path protection.

In SR for MPLS data plane (SR-MPLS), an Egress node can not determine on which SR path a packet traversed the network from the label stack because the segment identifiers are stripped from the label stack as the packet transits the network.

This document defines Path Segment to identify an SR path on the egress node of the path.
_____NEW_____


Same text/comment in the §1 Introduction.

-------

§1 Introduction
"or IPv6 data plane using an SRH header via SRv6 [RFC8986]"
Since this document is specific to SR-MPLS, I don't think that this text and reference are needed.
[Cheng]Agree, deleted.

-------
§1.2
"SRv6: Instantiation of SR on the IPv6 data plane."
Since this document is specific to SR-MPLS, I don't think that this text is needed.
[Cheng] Agree, deleted.

-----
§1 Introduction
"Thus, the egress node cannot determine along which SR path the packet came."

As per a previous comment, may be restricting this statement to the SR-path.
e.g. NEW: Thus, the egress node cannot use the SR label stack to determine along which SR path the packet came.
[Cheng] Agree.

------
§2

"If the Path Segment is used by an intermediate node to identify an SR path, the SRGB MUST be used."

I don't think that the use of a label from the SRGB allows to identify the path on a intermediate node. e.g. this label may have been chosen by LDP/BGP LU/BGP VPN by a non SR compliant router. Also the MPLS WG is discussing MNA which allows inserting any number/thing in the stack (so including a value which is part of the SRGB).
I would propose to remove this sentence (alternatively define another technical solution for this, but any significant technical change may justify returning the document to the WG)
[Cheng] Agree,  deleted.

-----------
§2

"The term of SR path used in this document is a general term that can be used to describe an SR Policy, a Candidate-Path (CP), or a Segment-List (SL) [RFC9256]. Therefore, the PSID may be used to identify an SR Policy, its CP, or a SL terminating on an egress node depending on the use-case."

From a general standpoint, the PSID may probably be used to identify whatever you want _assuming_ a coordination between the ingress and the egress to specify the scope of the identification.
So IMO,
- either this document specify the scope of the identification, in which case no additional coordination is required, but this may limit the future use cases. I would suggest that a PSID identifies a Candidate-Path as this seems inline with RFC 9256.
- or this document defines how this scope/meaning is coordinated between the ingress and egress. ( section 3 says that this is out of scope). In which case this document can't say what this PSID identify. (it could be a SR Policy, or a Candidate-Path or just anything including application specific (e.g. Altnernate marking). To some extend the name of the ID (PSID) and even the name of the Segment type (Path Segment) is debatable as you may not be identifying a path. This looks like a bigger change.

(More generally MPLS is about making an association between a label value (any number) and a FEC/signification. In this document you propose to use a label value but you declare that assigning the FEC/signification is out of scope. To me this significantly reduce the interest of this document and the ability to have interoperability between two nodes implementing this document making it more a framework and than a STD track document.)

I think my suggestion would be to say that a PSID identifies a Candidate Path [RFC9256].  That way both the ingress and the egress knowns that using a different PSID means using a different candidate path. This still leave out of scope how the ingress knows about the PSID to use for each CP (let's say it's part of the SR policy configured/pushed) and what is the behavior on the receiver. And if one really needs to identify the SR Policy, one could achieve by either configuring, on the ingress, the same PSID for all the CP of the SR Policy.; or by configuring on the egress all the PSID used by the CP of a given SR Policy.

[Cheng] It is really weird that this question has been raised several times. But to me, this is quite clear. Your first sentence is totally correct  “From a general standpoint, the PSID may probably be used to identify whatever you want _assuming_ a coordination between the ingress and the egress to specify the scope of the identification.”

Let’s explain this in this way.

First of all, a PSID is associated with a SID list that identifies a forwarding path. This is the key use cases for the Path Segment.
When we use the same PSID to the SID lists in a Candidate path, then actually, we can say that this PSID is used to identify a CP.
When we use the same PSID to all the SID lists in a SR policy, we can say that this PSID is used to identify an SR policy.

But, now I think I know where the weird feeling comes. We may not say that a PSID is used for IDENTIFYING a CP or SR Policy. We should modify it in this way.

___OLD____
"The term of SR path used in this document is a general term that can be used to describe an SR Policy, a Candidate-Path (CP), or a Segment-List (SL) [RFC9256]. Therefore, the PSID may be used to identify an SR Policy, its CP, or a SL terminating on an egress node depending on the use-case."


___NEW___

The term of SR path used in this document is a path described by a Segment-List (SL). A PSID is used to identify a Segment List. However, one PSID can be used to identify multiple Segment Lists in some use cases if needed. For example, all the Segment lists in a Candidate path can use a single PSID, and all the Segment Lists in an SR policy can share the same PSID, if customers would like to aggregate the data among the Segment Lists. How to use the PSID to Segment Lists depends on the requirements of the use cases.


-----
§2
"The value of the TTL field in the MPLS label stack entry containing the PSID MUST be set to the same value as the TTL of the last label stack entry for the last segment in the SR path."
"MUST" is a pretty strong statement. What is the reason for this? What is the egress supposed to do if this is not the case?
Interestingly, RFC 6790 has a oppositive position with regards to the Entropy Label: "The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding." while the case seems similar (addition of a label "not used for forwarding")
https://datatracker.ietf.org/doc/html/rfc6790#section-4.2

Is there any rule for the TC field? (if not, please say so; if so, please specify the rule)
[Cheng] because we do not use Path Segment for forwarding, so IMHO, the TTL can be any, like 0, or same as the previous one.  How about the following modifications?
___OLD____
"The value of the TTL field in the MPLS label stack entry containing the PSID MUST be set to the same value as the TTL of the last label stack entry for the last segment in the SR path."

___NEW___
"The value of the TTL field in the MPLS label stack entry containing the PSID can be set to any value including 0, or the same value as the TTL of the last label stack entry for the last segment in the SR path."
---

§2
"Normally, an intermediate node will not process the PSID in the label stack because the PSID is inserted after the routing segment pointing to the egress node. But in some use cases, an intermediate node MAY process the PSID in the label stack by scanning the label stack or other means. In these cases, the PSID MUST be learned before processing. The detailed use cases and processing is out of the scope of this document."

I think that this text is about coordinating the semantic of the PSID between the node writing it (ingress) and the node(s) reading it (egrees or transit). Hence I think this point should rather be moved to section " 3. PSID Allocation and Distribution "
[Cheng] Let’s delete this paragraph of intermediate node processing. Stewart also suggested to do so.

------
§2

"A PSID can be used in the case of Penultimate Hop Popping (PHP), where some labels are be popped off at the penultimate hop of an SR path, but the PSID MUST NOT be popped off until it reaches at the egress node."

You cannot define a behavior, not to mention a "MUST" on a node which may not be compliant with this document.
I personally don't believe that you need to define a new behavior and I would propose:
OLD:
A PSID can be used in the case of Penultimate Hop Popping (PHP), where some labels are be popped off at the penultimate hop of an SR path, but the PSID MUST NOT be popped off until it reaches at the egress node.

NEW:
A PSID can be used in the case of Penultimate Hop Popping (PHP), where some labels are be popped off at the penultimate hop of an SR path. As per regular MPLS processing, the label below (including the PSID in this case) will not be popped by the penultimate node.
[Cheng] Agree. Thank you!

-----
§2

"In some deployments, service labels may be added after the Path Segment label in the MPLS label stack. In this case, the egress node MUST be capable of processing more than one label. The additional processing required, may have an impact on forwarding performance."
I belive that when the PSID is used, there is _always_ an extra processing work on the data plane (the processing of the PSID). So I don't think that this is specific to "some deployments" or "service label".
If so, please rephrase.


[Cheng]Well, to me, the sentence is trying to explain the cases that the egress node needs to support processing of multiple labels. But we do have some use cases that the only label is processed on the egress node is the PSID. For example, we only encode the labels of the LSP and PSID in the label stack while the last forwarding label is a PHP enable label. Therefore, when a packet arrives on the egress node, only one single label(The PSID) will be processed. In this case, multiple labels processing is not required.

In other words, this paragraph is only for info that it explains we may have differences with or without services label. If without services label, then the requirement of processing multiple labels MAY not changed. Indeed, the processing of PSID is new in any cases.

---
§2
"Entropy label and Entropy Label Indicator (ELI) as described in [RFC8662] for SR-MPLS path, can be placed before or after the PSID in the MPLS label stack."
You seem to be re-specifying the EL spec. From the perspetive of this egress node, the ELI, EL MUST be placed before the tunnel label (as per RFC6790) and the PSID MUST be placed after the tunnel label (as per this document).
So IMO this sentence is adding unnecessary confusion.
I would propose
OLD:
Entropy label and Entropy Label Indicator (ELI) as described in [RFC8662] for SR-MPLS path, can be placed before or after the PSID in the MPLS label stack.

NEW:
If Entropy Label is also used on this egress node, as per [RFC6790] the Entropy label Indicator (ELI) and Entropy Label (EL) would be placed before the tunnel label and hence does not interfere with the PSID which is placed below.
[Cheng] Agree, thank you. The key info is that ELI/EL is irrelevant with the PSID in using.

 ----
§2
"Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks [RFC5586]. When GAL is used, it MUST be added at the bottom of the label stack after the PSID."

Reading RFC 5586, that seems to be already the rule for GAL.  Hence I don't think that this needs to be defined as a new rule (MUST). Especially as this seems to indicate a variation (before BoS vs after BoS) hence this may add confusion.
I would propose:
OLD: Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks [RFC5586]. When GAL is used, it MUST be added at the bottom of the label stack after the PSID.
NEW: Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks. As per [RFC5586], when GAL is used, it the ACH appears immediately after the bottom of the label stack.
[Cheng] OK, thank you!
---
§2

"The MSD used for path computation MUST include the PSID."

MSD is already defined and you cannot redefine it with a new rule (MUST). Actually RC 8491 already states that the MSD include all labels that can be imposed ("the total number of MPLS labels that can be imposed, including all service/transport/special labels")
https://www.rfc-editor.org/rfc/rfc8491.html#section-5

I would propose
OLD: The MSD used for path computation MUST include the PSID.
NEW: As per RFC8491 the MSD signals the total number of MPLS labels that can be imposed. This includes the PSID.
[Cheng]Wonderful! I do like your working style of providing text directly, LOL. Professional indeed! Respect!

-----
§2
"In addition, adding a PSID to a label stack will increase the depth of the label stack, the PSID should be accounted when considering Maximum SID Depth (MSD)[RFC8992]."
The above last sentence of §2 seems to be duplicating some previous text (below) and hence seem not useful. I would propose to remove it.

"The SR path computation needs to know the Maximum SID Depth (MSD) that can be imposed at each node/link of a given SR path [RFC8664]. This ensures that the SID stack depth of a computed path does not exceed the number of SIDs the node is capable of imposing. The MSD used for path computation MUST include the PSID."

[Cheng] Removed already, thank you!
 ----
§3
"If an egress cannot support the use of the PSID, it MUST reject the attemption of configuration."

If a egress doest not support PSID, how would it support the above rule?
It would seem easier to put the rule/burden on one pushing the PSID (e.g. the 'centralized controller" although the latter is "out of scope of this document")
[Cheng]You are right. We might delete it directly, because it is obvious as well.


--
§7 (and also mostly §6)
To some extend, this whole section is about signaling the context and semantic of the PSID between the ingress and the egress. Personally I would rather move this section inside section 3.
[Cheng] Sorry I don’t really get this. To me, these two sections are about the use cases of how PSID can be used. We also leave the part of signaling of PSID to PCE/IDR drafts. So it will be ok to keep it as is?


---
§ 8. Security Considerations

 "no new security threats are introduced comparing to current SR-MPLS"
In general, such statement may be read by security guys as "we did not really bothered studying the security implications". IMO it's better to put more text to explain _why_ there is no impact on security.
As a matter of fact, I'm not sure to agree with this statement: the one (e.g. an attacket) having the ability to signal a PSID value to an ingress, would have the ability to signal any label including a label value used as a service (VPN) label. This would trigger a VPN breach (injecting packets in the VPN).
This may not be not specific to the PSID, but even an "old" RFC with "old" security considerations is doing an effort well beyond "nothing new". https://datatracker.ietf.org/doc/html/rfc5036#section-5
So please consider enhancing the security consideration.

[Cheng] I have to say sorry here, because I am not an expert of security. How about the following modifications?

___NEW___
A Path Segment in SR-MPLS is a label similar to other labels/Segment, such as a VPN label or a Prefix SID, defined in MPLS and SR-MPLS. The data plane processing of a PSID is a local implementation of an ingress node, or an egress node, which follows the same logic of existing MPLS dataplane.

A Path Segment is used within an SR-MPLS domain {{RFC8402}} and SHOULD not leak outside the domain, therefore no new security threats are introduced comparing to current SR-MPLS. The security consideration of SR-MPLS, such as boundary filtering described in {{Section 8.1 of RFC8402}} applies to this document.

A PSID is allocated by an egress node and distributed to an ingress. The distribution is performed within an SR trusted domain. However, the mechanism of distributing a PSID is out of the scope of this document, and its security consideration will be described in other documents.



Thanks,
BR
--Bruno

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.