Hi Stewart, Thank you so much for your thorough review! It is really helpful! Mach is quit busy recently, so he assigns me to address the comments. Sorry for a long delay. Please see inline for the detailed reply. You can review the proposed update in Github as well. [1] Authors, I converted the XML to markdown file for easier editing. Please review the proposed update from me. You can reply the email to cooperate or pull a request in Github as you like. Respect, Cheng [1]. https://github.com/muzixing/SR-MPLS-Path-Segment/commit/0951b5c0fa52c8c63a2dc3ab2975b67c8e5537f4?diff=split -----Original Message----- From: Stewart Bryant via Datatracker <noreply@xxxxxxxx> Sent: Monday, November 21, 2022 9:58 PM To: gen-art@xxxxxxxx Cc: draft-ietf-spring-mpls-path-segment.all@xxxxxxxx; last-call@xxxxxxxx; spring@xxxxxxxx; spring-chairs@xxxxxxxx Subject: Genart last call review of draft-ietf-spring-mpls-path-segment-08 Reviewer: Stewart Bryant Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-spring-mpls-path-segment-?? Reviewer: Stewart Bryant Review Date: 2022-11-21 IETF LC End Date: 2022-11-20 IESG Telechat date: Not scheduled for a telechat Summary: This document is not ready to progress. If it has not yet had one it could usefully be reviewed by the MPLS Review Teams as this is clearly MPLS technology that needs to validated by MPLS specialists. In my opinion the document really ought to go back to the Spring WG to have a number of issues resolved before the other review teams as asked to spend time on it. Major issues: A Path Segment is a single label that is assigned from the Segment SB> I think that should be a Path Segment Identifier, or a Path Segment SB> Label or a P-SID since a path segment is a subset of the path so the terms path segment without qualification is confusing and aliases with other use of the term, particularly in the transport network space. [Cheng]Ack, modified to Path Segment Identifier. ========= When a Path Segment is used, the Path Segment MUST 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. SB> What happens if the payload is not IP - is the PSL before the PW (or SB> other payload) label? [Cheng]In my understanding, the payload type is irrelevant with a Path Segment. So if any label is required to indicate the type of payload/processing of payload, then it should be after PSL/PSID. If a Path Segment Label is assigned to a LSP, then the Path Segment Label is inserted before the PW label. If a Path Segment Label is assigned to a PW, then the Path Segment Label is inserted after the PW label. However, do we have this use cases? It may be good to future discussion? ======= When Path Segment is allocated from the SRGB pool, an intermediate node MAY see the Path Segment label at the top of the label stack. SB> Just checking - is it carried as it native value? SB> If an intermediate node is looking at the PSL how does it know the SB> context of the label to know that it is a PSL and not some other label? SB> If the label is the base label how do you deal with the problem that some hardware is unable to process parts of the 20bit label space? SB> If we are going to provide this as an option the text needs to be specific on the elements of procedure [Cheng] Same as Adrian's comment, thank you Stewart. The proposed text is below, Normally, an intermediate node will not process the Path Segment label in the label stack. But in some use cases, an intermediate node MAY process the Path Segment label in the label stack. In these cases, the Path Segment label MUST be learned before processing. The detailed use cases and processing is out of the scope of this document. Hope it can address your comment. ====== A Path Segment 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 Path Segment MUST NOT be popped off until it reaches at the egress node. SB> What happens at the penultimate node - is it exposed there as a SB> result of PHP, and is it passed on as its native value or is the base added to it before it is passed across? [Cheng] Actually, Path Segment Label is like a VPN label, so no new requirement here. In this case, it should be the native value. Because the penultimate node should not read the path segment, so the label value should not be modified. The path segment will be used at the egress node. We can delete this paragraph if you don't like, nothing new. ========= Generic Associated Label (GAL) is used for Operations, Administration SB: I think that should be "(GAL) MAY be used". A PW running in an MPLS network can use the the CW first nibble 1, ACH mechanism. [Cheng] no problem. Thanks ======== SB> Section (3) is out of place WRT the rest of the text. Everything SB> else is data plane specific and control plane agnostic. I would suggest that the control plane is out of scope for the RFC and you should simply say that a method needs to be provided for the PSL imposition node to know what label to use and that this label MUST be unique on the node stripping and processing the PSL. I think information that belongs later in the text. [Cheng]Agree, the updated text is shown below " There are some ways to assign and distribute the Path Segment. The Path Segment can be configured locally or allocated by a centralized controller or by other means, this is out of the scope of this document. If an egress cannot support the use of the Path Segment Label, it MUST reject the attempt to configure the label. " ========= SB> The following text is very hard to read BSID and Path SID (PSID) can be combined to achieve both sub-path and end-to-end path monitoring. A reference model for such a combination in (Figure 2) shows an end-to-end path (A->D) that spans three domains (Access, Aggregation and Core domain) and consists of three sub-paths, one in each sub-domain (sub-path (A->B), sub-path (B->C) and sub-path (C->D)). Each sub-path is allocated a BSID. For nesting the sub-paths, each sub-path is allocated a PSID. Then, the SID list of the end-to-end path can be expressed as <BSID1, BSID2, ..., BSIDn, e-PSID>, where the e-PSID is the PSID of the end-to-end path. The SID list of a sub-path can be expressed as <SID1, SID2, ...SIDn, s-PSID>, where the s-PSID is the PSID of the sub-path. SB> Doesn't this require that the (single) PSL is unique at all BSID end points. I think that needs some discussion, such as whether you swap the PSL when you enter the new segment and whether the PSL is its native value of the locally resolved value and if the target locally resolved value how you know what to swap it to. [Cheng] Please advise, I make some modifications below BSID and PSID can be combined to achieve both sub-path and end-to-end path monitoring. A reference model for such a combination in (Figure 2) shows an end-to-end path (A->D) that spans three domains (Access, Aggregation and Core domain) and consists of three sub-paths, one in each sub-domain (sub-path (A->B), sub-path (B->C) and sub-path (C->D)). Each sub-path is associated with a BSID and a s-PSID. The SID list of the end-to-end path can be expressed as <BSID1, BSID2, ..., BSIDn, e-PSID>, where the e-PSID is the PSID of the end-to-end path. The SID list of a sub-path can be expressed as <SID1, SID2, ...SIDn, s-PSID>, where the s-PSID is the PSID of the sub-path. From the aspect of PSL, there is no difference comparing to normal mode without using BSID. So PSL is also a local label at each egress node of each sub-path or a global label which should be unique among the network. But again, it is the same with normal use case without BSID. The Path Segment will not be used in forwarding as well, so I do not think the value of Path Segment should be swapped. It is used to identify a path locally at the egress node. ======= Figure 2 shows the details of the label stacks when PSID and BSID are used to support both sub-path and end-to-end path monitoring in a multi-domain scenario. SB> I think that there needs to be some consolidation of the terminology between path segment and PSID since I think you are the term interchangeably. SB> I am also concerned about SR developing a parallel universe with SR specific approaches that apply to the general MPLS case, but using terms that are not easily back ported into MPLS. [Cheng]Ack. Please see modifications. =========== As defined in [RFC7799], performance measurement can be classified into Passive, Active, and Hybrid measurement. Since Path Segment is encoded in the SR-MPLS Label Stack as shown in Figure 1, existing implementation on the egress node can be leveraged for measuring packet counts using the incoming SID (the Path Segment). A different scheme such as carrying such identifier after the bottom of the label stack may require new implementation. SB> That statement lacks detail and is speculative. [Cheng]Sorry, about which part? This draft only focus on path segment itself. Regarding how to use path segment in measurement will be described in other draft I guess. I would suggest to delete the last sentence, because I cannot understand it as well ☹ ============ For Passive performance measurement, path identification at the measuring points is the pre-requisite. Path Segment can be used by the measuring points (e.g., the ingress and egress nodes of the SR path or a centralized controller) to correlate the packet counts and timestamps from the ingress and egress nodes for a specific SR path, then packet loss and delay can be calculated for the end-to-end path, respectively. SB> Did you discuss the effect of ECMP if not all packets contain a PSID SB> or you turn the instrumentation on and off? [Cheng]ECMP? Is it about entropy label? I think this is irrelevant with PSID? PSID is only used for identifying a path. ECMP can be used or not, it is independent. ========== Path Segment can also be used for Active performance measurement for an SR path in SR-MPLS networks for collecting packet counters and timestamps from the egress node using probe messages [I-D.ietf-mpls-rfc6374-sr] and [I-D.ietf-spring-stamp-srpm]. SB> Again out old friend ECMP needs a discussion [Cheng] Same as above. But we deleted the drafts because they will introduce dependencies. ============ Path Segment can also be used for In-band PM for SR-MPLS to identify the SR Path associated with the collected performance metrics [I-D.ietf-mpls-inband-pm-encapsulation]. SB> In a standards track document you cannot make a claim without SB> providing supporting text showing how this is done and what the issues might be. [Cheng] The logic is the same as Passive PM, the only thing this part would like to state is that the Path segment can be used for identifying a path, and this is required in PM. How about let’s modify them as below. ---OLD--- Path Segment can also be used for Active performance measurement for an SR path in SR-MPLS networks for collecting packet counters and timestamps from the egress node using probe messages. Path Segment can also be used for In-situ OAM for SR-MPLS to identify the SR Path associated with the in-situ data fields in the data packets on the egress node. Path Segment can also be used for In-band PM for SR-MPLS to identify the SR Path associated with the collected performance metrics. ---OLD--- ---NEW--- Path Segment can also be used for identifying path in active performance measurement, hybrid performance measurement, etc. The details of using Path Segment in these measurements are out of the scope of this document, and will be described in other drafts. ---NEW--- ========== In the current SR architecture, an SR path is a unidirectional path [RFC8402]. In order to support bidirectional SR paths, a straightforward way is to bind two unidirectional SR paths to a single bidirectional SR path. Path Segments can then be used to identify and correlate the traffic for the two unidirectional SR paths at both ends of the bidirectional path. SB> SR uses loose source routing and ECMP to minimise segments. Even SB> between a pair of adjacent nodes you cannot be sure of path reciprocity unless you you AdjSIDS. Is that the proposal? [Cheng]Yes. From the aspect of path segment, we do not care about it is really a true bidirectional path using Adj-SIDs or not. This is ensure by the operators. Even if a loose TE path is used in bidirectional path, this is not an error of Path Segment. It may be an error or a choice of operator. This is out of the scope of this document. ========= An attacker could exploit path segment to manipulate the accounting of SR traffic at the egress. Path segment could also be used to monitor traffic patterns for the E2E paths. The control protocols used to allocate path segments could also be exploited to disseminate incorrect path segment information. Note that, the path segment is imposed at the ingress and removed at the egress boundary and is not leaked out of the administered domain. SB> What are the mitigations for the increase in attack surface? [Cheng] It is the same with other labels/SIDs. Keeping it within the domain can help. Nothing new here I think. I will propose the delete this paragraph. ============ Minor issues: For SR-MPLS, this can be the Path Segment label allocated by the egress node. SB> Can be is not strict enough for standards track [Cheng] This only says that Path Segment is one of the options. There may be other options. So we are using 'can' ========= It is obvious that this equivalence group can be instantiated in the network by an SDN controller using the Path Segments of the SR paths. SB> Nothing is obvious until it is proven. [Cheng]Ack ---NEW--- This equivalence group can be instantiated in the network by an SDN controller using the Path Segments of the SR paths. ---NEW--- ======== Path Segment in SR-MPLS does not introduce any new behavior or any change in the way the MPLS data plane works. SB> If it does not change anything we do not need an ST RFC. [Cheng]Ack. I make some modifications as below. Please advise. ---NEW--- Path Segment in SR-MPLS is used within the SR domain, and no new security threats are introduced comparing to current SR-MPLS. The security consideration of SR-MPLS is described in {{Section 8.1 of RFC8402}} applies to this document. ---NEW--- ======== Path segment is additional metadata that is added to the packet consisting of the SR path. SB> I think you mean that the change is to add a new label. [Cheng]Deleted. ======== Nits/editorial comments: 6. Path Segment for Bidirectional SR Path In some scenarios, for example, mobile backhaul transport networks, there are requirements to support bidirectional paths, and the path is normally treated as a single entity. The both directions of the SB> "The both directions" is not good grammar [Cheng]Ack. s/The both directions/Forward and reverse directions Many thanks for your thorough review, it is really helpful! Respect!
SPRING Working Group W. Cheng
Internet-Draft H. Li
Intended status: Standards Track China Mobile
Expires: 1 December 2023 C. Li
Huawei Technologies Co., Ltd
R. Gandhi
Cisco Systems, Inc.
R. Zigler
Broadcom
30 May 2023
Path Segment in MPLS Based Segment Routing Network
draft-ietf-spring-mpls-path-segment-09
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.
In SR for MPLS data plane (SR-MPLS), the segment identifiers are
stripped from the packet through label popping as the packet transits
the network. This means that when a packet reaches the egress of the
SR path, it is not possible to determine on which SR path it
traversed the network.
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. When used, it is inserted by the ingress node of the SR
path and immediately follows the last segment identifier in the
segment list of the SR path. The Path Segment is preserved until it
reaches the egress node for SR path identification and correlation.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Cheng, et al. Expires 1 December 2023 [Page 1]
Internet-Draft Path Segment in SR-MPLS May 2023
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 December 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2. Path Segment . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PSID Allocation and Distribution . . . . . . . . . . . . . . 6
4. Nesting of Path Segments . . . . . . . . . . . . . . . . . . 7
5. Path Segment for Performance Measurement . . . . . . . . . . 8
6. Path Segment for Bidirectional SR Path . . . . . . . . . . . 8
7. Path Segment for End-to-end Path Protection . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Cheng, et al. Expires 1 December 2023 [Page 2]
Internet-Draft Path Segment in SR-MPLS May 2023
1. Introduction
Segment Routing (SR) [RFC8402] leverages the source-routing paradigm
to steer packets from a source node through a controlled set of
instructions, called segments, by prepending the packet with an SR
header in the MPLS data plane SR-MPLS [RFC8660] through a label stack
or IPv6 data plane using an SRH header via SRv6 [RFC8986] to
construct an SR path.
In an SR-MPLS network, when a packet is transmitted along an SR path,
the labels in the MPLS label stack will be swapped or popped. So
that no label or only the last label (e.g. Explicit-Null label) may
be left in the MPLS label stack when the packet reaches the egress
node. Thus, the egress node cannot determine along which SR path the
packet came.
However, to support various use-cases in SR-MPLS networks, like end-
to-end 1+1 path protection (Live-Live case) [RFC4426], bidirectional
path [RFC5654], or Performance Measurement (PM) [RFC7799], the
ability to implement path identification on the egress node is a pre-
requisite.
Therefore, this document introduces a new segment type that is
referred to as the Path Segment. A Path Segment is defined to
uniquely identify an SR path in an SR-MPLS network. It MAY be used
by the egress nodes for path identification hence to support various
use-cases including SR path PM, end-to-end 1+1 SR path protection,
and bidirectional SR paths correlation.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Abbreviations
DM: Delay Measurement.
LM: Loss Measurement.
MPLS: Multiprotocol Label Switching.
MSD: Maximum SID Depth.
PM: Performance Measurement.
Cheng, et al. Expires 1 December 2023 [Page 3]
Internet-Draft Path Segment in SR-MPLS May 2023
PSID: Path Segment ID.
SID: Segment ID.
SL: Segment List.
SR: Segment Routing.
SRLB: SR Local Block
SRGB: SR Global Block
SR-MPLS: Instantiation of SR on the MPLS data plane.
SRv6: Instantiation of SR on the IPv6 data plane.
2. Path Segment
A Path Segment Identifier(PSID) 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. Whether a PSID is allocated from the
SRLB, SRGB, or a dynamic range depends on specific use cases. If the
PSID is only used by the egress node to identify a SR path, the SRLB,
SRGB or dynamic MPLS label pool can be used. If the Path Segment is
used by an intermediate node to identify a SR path, the SRGB MUST be
used. Three use cases are introduced in Section 5, 6, and 7 of this
document.
When a PSID is used, the PSID MUST 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.
The term of SR path used in this document is a general term that can
be used to describe a 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.
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. If the Path Segment
is the bottom label, the S bit MUST be set.
Cheng, et al. Expires 1 December 2023 [Page 4]
Internet-Draft Path Segment in SR-MPLS May 2023
Normally, an intermediate node will not process the PSID in the label
stack. But in some use cases, an intermediate node MAY process the
PSID in the label stack. In these cases, the PSID MUST be learned
before processing. The detailed use cases and processing is out of
the scope of this document.
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.
The egress node MUST pop the PSID. The egress node MAY use the PSID
for further processing. For example, when performance measurement is
enabled on the SR path, it can trigger packet counting or
timestamping.
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.
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.
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.
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.
The label stack with Path Segment is shown in Figure 1:
Cheng, et al. Expires 1 December 2023 [Page 5]
Internet-Draft Path Segment in SR-MPLS May 2023
+--------------------+
| ... |
+--------------------+
| Label 1 |
+--------------------+
| Label 2 |
+--------------------+
| ... |
+--------------------+
| Label n |
+--------------------+
| PSID |
+--------------------+
| ... |
+--------------------+
~ Payload ~
+--------------------+
Figure 1: Label Stack with Path Segment
Where:
* The Labels 1 to n are the segment label stack used to direct how
to steer the packets along the SR path.
* The PSID identifies the SR path in the context of the egress node
of the SR path.
There may be multiple paths (or sub-path(s)) carried in the label
stack, for each path (or sub-path), there may be a corresponding Path
Segment carried. A use case can be found in Section 4.
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].
3. PSID Allocation and Distribution
There are some ways to assign and distribute the PSID. The PSID can
be configured locally or allocated by a centralized controller or by
other means, this is out of the scope of this document. If an egress
cannot support the use of the PSID, it MUST reject the attempt to
configure the label.
If an egress cannot support the use of the PSID, it MUST reject the
attemption of configuration.
Cheng, et al. Expires 1 December 2023 [Page 6]
Internet-Draft Path Segment in SR-MPLS May 2023
4. Nesting of Path Segments
Binding SID (BSID) [RFC8402] can be used for SID list compression.
With BSID, an end-to-end SR path can be split into several sub-paths,
each sub-path is identified by a BSID. Then an end-to-end SR path
can be identified by a list of BSIDs, therefore, it can provide
better scalability.
BSID and PSID can be combined to achieve both sub-path and end-to-end
path monitoring. A reference model for such a combination in
(Figure 2) shows an end-to-end path (A->D) that spans three domains
(Access, Aggregation and Core domain) and consists of three sub-
paths, one in each sub-domain (sub-path (A->B), sub-path (B->C) and
sub-path (C->D)). Each sub-path is associated with a BSID and a
s-PSID.
The SID list of the end-to-end path can be expressed as <BSID1,
BSID2, ..., BSIDn, e-PSID>, where the e-PSID is the PSID of the end-
to-end path. The SID list of a sub-path can be expressed as <SID1,
SID2, ...SIDn, s-PSID>, where the s-PSID is the PSID of the sub-path.
Figure 2 shows the details of the label stacks when PSID and BSID are
used to support both sub-path and end-to-end path monitoring in a
multi-domain scenario.
/--------\ /--------\ /--------\
/ \ / \ / \
A{ Access }B{ Aggregation }C{ Core }D
\ / \ / \ /
\--------/ \--------/ \--------/
Sub-path(A->B) Sub-path(B->C) Sub-path(C->D)
|<--------------->|<-------------->|<-------------->|
E2E Path(A->D)
|<------------------------------------------------->|
+------------+
~A->B SubPath~
+------------+ +------------+
|s-PSID(A->B)| ~B->C SubPath~
+------------+ +------------+
| BSID(B->C) | |s-PSID(B->C)|
+------------+ +------------+ +------------+
| BSID(C->D) | | BSID(C->D) | ~C->D SubPath~
+------------+ +------------+ +------------+ +------------+
|e-PSID(A->D)| |e-PSID(A->D)| |e-PSID(A->D)| |e-PSID(A->D)|
+------------+ +------------+ +------------+ +------------+
Figure 2: Nesting of Path Segments
Cheng, et al. Expires 1 December 2023 [Page 7]
Internet-Draft Path Segment in SR-MPLS May 2023
5. Path Segment for Performance Measurement
As defined in [RFC7799], performance measurement can be classified
into Passive, Active, and Hybrid measurement. Since Path Segment is
encoded in the SR-MPLS Label Stack as shown in Figure 1, existing
implementation on the egress node can be leveraged for measuring
packet counts using the incoming SID (the PSID).
For Passive performance measurement, path identification at the
measuring points is the pre-requisite. Path Segment can be used by
the measuring points (e.g., the ingress and egress nodes of the SR
path or a centralized controller) to correlate the packet counts and
timestamps from the ingress and egress nodes for a specific SR path,
then packet loss and delay can be calculated for the end-to-end path,
respectively.
Path Segment can also be used for Active performance measurement for
an SR path in SR-MPLS networks for collecting packet counters and
timestamps from the egress node using probe messages.
Path Segment can also be used for In-situ OAM for SR-MPLS to identify
the SR Path associated with the in-situ data fields in the data
packets on the egress node.
Path Segment can also be used for In-band PM for SR-MPLS to identify
the SR Path associated with the collected performance metrics.
6. Path Segment for Bidirectional SR Path
In some scenarios, for example, mobile backhaul transport networks,
there are requirements to support bidirectional paths, and the path
is normally treated as a single entity. Forward and reverse
directions of the path have the same fate, for example, failure in
one direction will result in switching traffic at both directions.
MPLS supports this by introducing the concepts of co-routed
bidirectional LSP and associated bidirectional LSP [RFC5654].
In the current SR architecture, an SR path is a unidirectional path
[RFC8402]. In order to support bidirectional SR paths, a
straightforward way is to bind two unidirectional SR paths to a
single bidirectional SR path. Path Segments can then be used to
identify and correlate the traffic for the two unidirectional SR
paths at both ends of the bidirectional path.
Cheng, et al. Expires 1 December 2023 [Page 8]
Internet-Draft Path Segment in SR-MPLS May 2023
7. Path Segment for End-to-end Path Protection
For end-to-end 1+1 path protection (i.e., Live-Live case), the egress
node of the path needs to know the set of paths that constitute the
primary and the secondaries, in order to select the primary path
packets for onward transmission, and to discard the packets from the
secondaries [RFC4426].
To do this in Segment Routing, each SR path needs a path identifier
that is unique at the egress node. For SR-MPLS, this can be the Path
Segment label allocated by the egress node.
There then needs to be a method of binding this SR path identifiers
into equivalence groups such that the egress node can determine for
example, the set of packets that represent a single primary path.
This equivalence group can be instantiated in the network by an SDN
controller using the Path Segments of the SR paths.
8. Security Considerations
Path Segment in SR-MPLS is used within the SR domain, and no new
security threats are introduced comparing to current SR-MPLS. The
security consideration of SR-MPLS is described in Section 8.1 of
[RFC8402] applies to this document.
9. IANA Considerations
This document does not require any IANA actions.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
Cheng, et al. Expires 1 December 2023 [Page 9]
Internet-Draft Path Segment in SR-MPLS May 2023
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/rfc/rfc8660>.
10.2. Informative References
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426,
DOI 10.17487/RFC4426, March 2006,
<https://www.rfc-editor.org/rfc/rfc4426>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/rfc/rfc5586>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/rfc/rfc5654>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/rfc/rfc7799>.
[RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
Shakir, R., and J. Tantsura, "Entropy Label for Source
Packet Routing in Networking (SPRING) Tunnels", RFC 8662,
DOI 10.17487/RFC8662, December 2019,
<https://www.rfc-editor.org/rfc/rfc8662>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/rfc/rfc8664>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
Cheng, et al. Expires 1 December 2023 [Page 10]
Internet-Draft Path Segment in SR-MPLS May 2023
[RFC8992] Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun,
"Autonomic IPv6 Edge Prefix Management in Large-Scale
Networks", RFC 8992, DOI 10.17487/RFC8992, May 2021,
<https://www.rfc-editor.org/rfc/rfc8992>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/rfc/rfc9256>.
Acknowledgements
The authors would like to thank Adrian Farrel, Stewart Bryant,
Shuangping Zhan, Alexander Vainshtein, Andrew G. Malis, Ketan
Talaulikar, Shraddha Hegde, and Loa Andersson for their review,
suggestions and comments to this document.
The authors would like to acknowledge the contribution from Alexander
Vainshtein on "Nesting of Path Segments".
Contributors
The following people have substantially contributed to this document:
Mach(Guoyi) Chen
Huawei Technologies Co., Ltd
Email: mach.chen@xxxxxxxxxx
Lei Wang
China Mobile
Email: wangleiyj@xxxxxxxxxxxxxxx
Aihua Liu
ZTE Corp
Email: liu.aihua@xxxxxxxxxx
Greg Mirsky
ZTE Corp
Email: gregimirsky@xxxxxxxxx
Gyan S. Mishra
Verizon Inc.
Email: gyan.s.mishra@xxxxxxxxxxx
Cheng, et al. Expires 1 December 2023 [Page 11]
Internet-Draft Path Segment in SR-MPLS May 2023
Authors' Addresses
Weiqiang Cheng
China Mobile
Email: chengweiqiang@xxxxxxxxxxxxxxx
Han Li
China Mobile
Email: lihan@xxxxxxxxxxxxxxx
Cheng Li
Huawei Technologies Co., Ltd
China
Email: c.l@xxxxxxxxxx
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@xxxxxxxxx
Royi Zigler
Broadcom
Email: royi.zigler@xxxxxxxxxxxx
Cheng, et al. Expires 1 December 2023 [Page 12]
Attachment:
draft-ietf-spring-mpls-path-segment-09-02.md
Description: draft-ietf-spring-mpls-path-segment-09-02.md
<<< text/html; name="draft-ietf-spring-mpls-path-segment-09-02.diff.html": Unrecognized >>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
