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

From: "[email-masked]" <[email-masked]>
Date: Thu, 13 Jul 2023 10:10:10 +0800

Hi Bruno,

Thanks for your information. 

The authors also appreciate Jim's careful guidance.

I am trying to answer your two questions as below:

Is there an existing implementation of the protocol?

As far as I know, there are now multiple vendors who have implemented the protocol on their different productions, and several operators have deployed it in their field network. Taking China Mobile as an example, we have deployed more than 300,000 SPN(slicing packet network) Nodes for 5G backhaul, which already support this protocol. This protocol plays an important role in the performance monitoring and trouble shooting for the large-scale SR network.

Are there a large number of vendors that have indicated that they plan to implement the specification?

As our presentations, more than 10 vendors have implement it, such as ZTE, Fiberhome, Huawei. And more and more vendors are implementing it in their new productions. At the same time, based on the protocol, several new drafts have been post for new application scenarios, such as:
https://www.ietf.org/archive/id/draft-lin-bfd-path-consistency-over-sr-01.txt, in this draft, H3C proposed a BFD solution based on path segment to keep the forward path andreverse path consistent when using S-BFD or U-BFD.

Any comments are welcome.

B.R
Weiqiang Cheng

From: bruno.decraene
Date: 2023-07-12 22:41
To: [email-masked]; SPRING WG
CC: James Guichard
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?

---
 
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

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

-------
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.

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.
-------
§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.
 
-----
§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. 
 
------
§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)
 
-----------
§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.
 
-----
§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)
---
 §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 "
 ------
§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.
 -----
§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.
 ---
§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. 
 
 ----
§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.
 
---
§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.
 
-----
§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."
 
 ----
§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")
 --
§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.
 ---
§ 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.

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.