| Internet-Draft | SR MSDs | October 2026 |
| Ali, et al. | Expires 17 April 2027 | [Page] |
Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. An SR Policy can be instantiated SR-MPLS and SRv6 data planes.¶
Maximum SID Depth (MSD) is first introduced for SR-MPLS to indicate the number of SIDs supported by a node or a link on a node. This concept is further extended for SRv6 with more types of MSD. MSD may become one of the limitations that need to be considered when computing an SR-TE path for PCE.¶
This draft specifies some MSD considerations PCE needs to take into account when computing an SR-TE path.¶
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/.¶
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 17 April 2027.¶
Copyright (c) 2026 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.¶
Segment Routing (SR) [RFC8402] allows a node to steer a packet flow along any path. A Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of segments that represent a source-routed policy. The headend node is said to steer a flow into an SR Policy. The packets steered into an SR Policy have an ordered list of segments associated with that SR Policy written into them. Segment Routing Policy Architecture [RFC9256] updates [RFC8402] as it details the concepts of SR Policy and steering into an SR Policy. An SR Policy can be instantiated SR-MPLS and SRv6 data planes.¶
The concept of Maximum SID Depth (MSD) [RFC8491] is first introduced for SR-MPLS to express the number of SIDs supported by a node or a link on a node, and the Base MPLS Imposition MSD is defined to indicate the number of MPLS labels that can be imposed by a router. And the concept is further extended for SRv6 with more types of MSD defined in [RFC9352].¶
MSD may become one of the limitations that need to be considered when computing an SR-TE path for PCE.¶
For SR-MPLS, [RFC8664] defines the SR-PCE-CAPABILITY sub-TLV. PCEP speakers use this sub-TLV to exchange information about their SR capability, including MSD, which indicates that a PCC is capable of imposing on a packet. [RFC8664] also specifies MSD considerations PCE needs to take into account when computing the number of SIDs in an SR-TE path. Specifically, it mandates that once an SR-capable PCEP session is established with a non-zero MSD value, the corresponding PCE MUST NOT send SR-TE paths with a number of SIDs exceeding that MSD value.¶
Similarly, for SRv6, [RFC9603] specifies that a PCE MUST NOT send SRv6 paths that exceed the SRv6 MSD capabilities of the PCC.¶
However, the limitation of MSD could be loosened to allow one more SID in the SID list that is sent by the PCE in the following scenarios:¶
Moreover, not all of the SRv6 MSDs defined in [RFC9352] are about the limitation/capability of the head-end node (i.e, PCC), thus some of these SRv6 MSDs are not always necessary restrictions to be followed when sending an SRv6 path to the PCC.¶
This document specifies a procedure for optimizing the number of SIDs in an SR-TE path that PCE can compute when the first SID in the SR Policy SID list is not imposed on the packet in the above scenarios.¶
This document also analyzes the impact of different SRv6 MSDs when PCE sends SR-TE paths to the PCC.¶
The following terminology is used in this document:¶
MSD: Maximum SID Depth¶
PCC: Path Computation Client¶
PCE: Path Computation Element¶
PCEP: Path Computation Element Communication Protocol¶
SID: Segment Identifier¶
SR: Segment Routing¶
SR-TE: Segment Routing Traffic Engineering¶
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.¶
This section proposes a new A-flag (Adjacency SID exclusion for MSD consideration flag) in the SR-PCE-CAPABILITY sub-TLV defined in [RFC8664]. The bit position for the flag in the SR PCE Capability Flag Field registry is to be defined by IANA.¶
A (Adjacency SID exclusion for MSD consideration flag) - 1 bit (Bit Position TBD1):¶
[RFC8664] mandates that once an SR-capable PCEP session is established with a non-zero MSD value, the corresponding PCE MUST NOT send SR-TE paths with a number of SIDs exceeding that MSD value.¶
The following procedure MUST only be applied if both the PCE and PCC have advertised support for the capability by setting the A-flag in their respective SR-PCE-CAPABILITY sub-TLVs [RFC8664]. Under these conditions, if the first SID in an SR-MPLS TE path is an adjacency SID, the PCE MUST NOT send SR-TE paths with a number of SIDs exceeding that (MSD+1) value.¶
[RFC9603] defines the SRv6-PCE-CAPABILITY sub-TLV under the PATH- SETUP-TYPE-CAPABILITY TLV in the OPEN object. PCEP speakers use this sub-TLV to exchange information about their SRv6 capability. And the SRv6 MSD information advertised via SRv6-PCE-Capability sub-TLV conveys the SRv6 capabilities of the PCEP speaker.¶
As in [RFC9603] section 4.1.1, optional (MSD-Type,MSD-Value) pairs are carried in the SRv6-PCE-CAPABILITY sub-TLV, the SRv6 MSD types are as per [RFC9352], i.e, Maximum Segments Left MSD, Maximum End Pop MSD, Maximum H.Encaps MSD, Maximum End D MSD:¶
To conclude, when appears in the SRv6-PCE-CAPABILITY sub-TLV, the Maximum End Pop MSD and Maximum End D MSD only indicates the limitation when the PCC node acts as the penultimate or ultimate SR Segment Endpoint Node. So the Maximum End Pop MSD or Maximum End D MSD is not considered by PCE when sending the SRv6 path to PCC/ head- end node. The limitation of Maximum H.Encaps MSD could be loosened when the first SID is not in the SRH.¶
This section proposes a new A-flag (Adjacency SID exclusion for MSD consideration flag) in the SRv6-PCE-CAPABILITY sub-TLV defined in [RFC9603]. The bit position for the flag in the SRv6 Capability Flag Field registry is to be defined by IANA.¶
A (Adjacency SID exclusion for MSD consideration flag) - 1 bit (Bit Position TBD1):¶
This section proposes an R-Flag (Reduced SRH for MSD consideration flag) in the SRv6-PCE-CAPABILITY sub-TLV defined in [RFC9603]. The bit position for the flag in the SRv6 Capability Flag Field registry is to be defined by IANA.¶
R-flag (Reduced SRH for MSD consideration flag) - 1 bit (Bit Position TBD2):¶
[RFC9603] specifies that a PCE MUST NOT send SRv6 paths that exceed the SRv6 MSD capabilities of the PCC.¶
For the A-Flag, when both the PCE and PCC have advertised support for the capability by setting the A-flag in their respective SRv6-PCE- CAPABILITY sub-TLVs [RFC9603], under these conditions, if the first SID in an SRv6-TE path is an adjacency SID attached with the headend node, the PCE MUST NOT send SR-TE paths with a number of SIDs exceeding that (Maximum H.Encaps MSD+1) value.¶
For the R-Flag, when both the PCE and PCC have advertised support for the capability by setting the R-flag in their respective SRv6-PCE- CAPABILITY sub-TLVs [RFC9603], the PCE MUST NOT send SR-TE paths with a number of SIDs exceeding the (Maximum H.Encaps MSD+1) value.¶
(To be discussed) If both the A-Flag and R-Flag are set in the respective SRv6-PCE-CAPABILITY sub-TLVs [RFC9603] of PCE and PCC, the PCE MUST NOT send SR-TE paths with a number of SIDs exceeding the (Maximum H.Encaps MSD+1) value, since A-Flag and R-Flag are both about omitting the first SID in the SID list.¶
The proposed procedure is backward compatible with [RFC8664] and [RFC9603] as it requires both PCE and PCC to support the optimization capabilities during the PCEP initialization phase by setting the corresponding new flag in the SR-PCE-CAPABILITY or SRv6-PCE- CAPABILITY sub-TLV in the Open message. Specifically, if at least one PCEP peer is not capable of supporting the new flags, the PCE MUST NOT send SR-TE paths with a number of SIDs exceeding that MSD capability.¶
Security considerations in [RFC8664] and [RFC9603] apply to this document.¶
This document requests IANA to assign the following flags in the "SRv6 Capability Flag Field" registry.¶
Bit Description Reference
--------------------------------------------------------
TBD1 Adjacency SID exclusion for [this document]
MSD consideration (A-Flag)
TBD2 Reduced SRH for MSD
consideration (R-Flag) [this document]
¶