MPLS V. P. Beeram Internet-Draft C. Barth Intended status: Standards Track HPE Expires: 29 April 2027 A. Smith Arrcus, Inc. 26 October 2026 Signaling RSVP-TE Tunnels on an SR-MPLS Forwarding Plane Using Adjacency Segment Identifiers draft-beeram-mpls-rsvp-sr-01 Abstract RFC 8577 introduced the concept of signaling RSVP-TE tunnels on a shared MPLS forwarding plane using preinstalled "TE link labels". Those labels are functionally equivalent to Segment Routing (SR) Adjacency Segment Identifiers (Adj-SIDs) but are allocated and distributed solely via RSVP-TE signaling. This document extends RFC 8577 so that RSVP-TE tunnels can use Segment Routing over MPLS (SR-MPLS) Adj-SIDs, as specified in RFC 8402 and RFC 8660, in place of TE link labels. It restricts scope to Adj-SIDs attached to a single unidirectional adjacency and defines the signaling procedures and protocol extensions required to couple the RSVP-TE control plane with the SR-MPLS data plane. 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/. 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 29 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Beeram, et al. Expires 29 April 2027 [Page 1] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. Adjacency SID Requirements . . . . . . . . . . . . . . . . . 4 3.1. Adj-SID Persistence . . . . . . . . . . . . . . . . . . . 5 3.2. Per-Link Adj-SIDs . . . . . . . . . . . . . . . . . . . . 5 3.3. Adj-SID Selection . . . . . . . . . . . . . . . . . . . . 6 4. RSVP-TE Tunnel Setup Using Adj-SIDs . . . . . . . . . . . . . 7 4.1. Adj-SID Discovery . . . . . . . . . . . . . . . . . . . . 7 4.2. Path Message Processing . . . . . . . . . . . . . . . . . 7 4.3. Resv Message Processing . . . . . . . . . . . . . . . . . 8 4.4. Label Stack Construction at Ingress . . . . . . . . . . . 8 5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 9 5.1. Binding SIDs as Delegation Labels . . . . . . . . . . . . 9 5.2. ETLD Computation . . . . . . . . . . . . . . . . . . . . 10 6. Protection Mechanisms . . . . . . . . . . . . . . . . . . . . 10 6.1. RFC 8577 Link Protection Procedure . . . . . . . . . . . 11 6.2. RSVP-TE-Signaled Facility Backup for Protected Adj-SIDs . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. TI-LFA Link Protection . . . . . . . . . . . . . . . . . 11 7. Bandwidth Admission Control . . . . . . . . . . . . . . . . . 12 8. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 12 8.1. Attribute Flags: SR Forwarding Plane . . . . . . . . . . 12 8.2. RRO Label Sub-object Flag: SR Adj-SID . . . . . . . . . . 13 8.3. Constraining Adj-SID Selection via ERO . . . . . . . . . 13 9. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . 15 10.2. Record Route Label Sub-object Flags . . . . . . . . . . 15 10.3. Error Codes and Error Values . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 18 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Beeram, et al. Expires 29 April 2027 [Page 2] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 1. Introduction RFC 8577 [RFC8577] defines a mechanism to signal Resource Reservation Protocol - Traffic Engineering (RSVP-TE) tunnels using a shared Multiprotocol Label Switching (MPLS) forwarding plane. It introduces "Traffic Engineering (TE) link labels" -- preinstalled, per-TE-link labels that are allocated locally by each Label Switching Router (LSR) and communicated to upstream neighbors via RSVP-TE Resv messages. These labels have "pop and forward" semantics and can be shared across all RSVP-TE Label Switched Paths (LSPs) traversing the same TE link. The Segment Routing (SR) architecture [RFC8402] independently defines Adjacency Segments (Adj-SIDs) with identical forwarding-plane semantics: an Adj-SID is a locally significant label that, when present at the top of the stack, instructs the node to pop the label and forward the packet over the associated adjacency. Adj-SIDs are advertised via Interior Gateway Protocol (IGP) extensions [RFC8667] [RFC8665] and are used in the MPLS data plane as specified in [RFC8660]. While RFC 8577 TE link labels and SR Adj-SIDs have the same data- plane behavior, they differ in their control-plane lifecycle: * TE link labels are typically allocated by a technology-agnostic TE component and discovered via Resv processing. * Adj-SIDs are typically allocated by the SR component and discovered via IGP. This document extends RFC 8577 so that RSVP-TE tunnels can use Segment Routing over MPLS (SR-MPLS) Adj-SIDs [RFC8660] in place of TE link labels. This document uses Adj-SIDs as allocated and advertised by SR-MPLS, so a single set of Adj-SID labels serves both SR-native and RSVP-TE-signaled traffic. The RSVP-TE control plane continues to provide bandwidth admission control and explicit path management on top of the SR-MPLS data plane. The protection of Adj-SIDs is discussed in Section 6. This document restricts its scope to: * Adj-SIDs attached to a single unidirectional adjacency: one Adj- SID per TE link (not Adj-SIDs attached to a set of adjacencies). * Link protection, as discussed in Section 6. Node protection is outside the scope of this document. Benefits of this approach over RFC 8577: Beeram, et al. Expires 29 April 2027 [Page 3] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 * Single label allocation system: Eliminates dual allocation (TE link labels + Adj-SIDs) and potential label space fragmentation for tunnels that use SR-MPLS Adj-SIDs. A node that also supports the RFC 8577 link protection procedure (Section 6.1) retains a separate TE link label allocation for the tunnels that use it. * IGP-native discovery: The ingress or controller can pre-compute the label stack from the IGP topology database without waiting for Resv processing to discover labels hop by hop. * Interoperability: The same Adj-SIDs serve SR-only nodes, RSVP-TE nodes, and hybrid deployments without data-plane conflicts. 2. Terminology This document uses the terminology defined in the Segment Routing architecture [RFC8402] and in SR-MPLS [RFC8660], including Adj-SID, Binding SID (BSID) and Maximum SID Depth (MSD). Readers are expected to be familiar with both documents. Those terms are not redefined here. The terms "Point of Local Repair" (PLR) and "merge point" are used as defined in [RFC4090]. The terms "TE link label", "delegation label" and "Effective Transport Label-Stack Depth" (ETLD) are used as defined in [RFC8577]. The following term is specific to this document: SR-MPLS RSVP-TE tunnel: An RSVP-TE tunnel that is signaled by the RSVP-TE control plane and whose LSPs are forwarded using SR-MPLS Adj-SIDs, as described in this document. 2.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. 3. Adjacency SID Requirements This section describes the properties of the Adj-SIDs that are used by SR-MPLS RSVP-TE tunnels. The Adj-SIDs themselves are allocated and advertised as specified in [RFC8402], [RFC8660], [RFC8667] and [RFC8665]. Beeram, et al. Expires 29 April 2027 [Page 4] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 3.1. Adj-SID Persistence An Adj-SID used by an SR-MPLS RSVP-TE tunnel is RECOMMENDED to be persistent (i.e., advertised with the P-flag set in the IS-IS Adj-SID sub-TLV [RFC8667] or the OSPF Adj-SID sub-TLV [RFC8665]). However, persistence is not required. Persistent Adj-SIDs have the following properties: * The label value is preserved when the associated adjacency transitions from UP to DOWN and back to UP. * The label value is preserved across process restarts and router reboots. * The label is pre-programmed in the forwarding plane upon configuration, even if the adjacency is not yet operational. In this state, packets arriving with the Adj-SID are dropped (the forwarding entry exists but points to a down adjacency). When persistent Adj-SIDs are used, the label stack at the ingress remains valid across adjacency flaps; only the data-plane reachability of the adjacency changes, which is handled by protection mechanisms (Section 6). When non-persistent Adj-SIDs are used, a node that restarts may allocate new Adj-SID label values. RSVP-TE signaling inherently adapts to such changes: the refreshed or re-signaled Resv message will carry the new Adj-SID values in the Label object and RRO, and the ingress LER will update its label stack accordingly. The transient disruption during the restart is comparable to what occurs with any RSVP-TE label change. 3.2. Per-Link Adj-SIDs An Adj-SID used by an SR-MPLS RSVP-TE tunnel MUST be attached to a single unidirectional adjacency [RFC8402]. That is, a unique Adj-SID is used for each TE link, even if multiple parallel links exist to the same neighbor. In the IGP, this corresponds to an Adj-SID advertised without the S-flag (Set) [RFC8667] [RFC8665]. Adj-SIDs attached to a set of unidirectional adjacencies (e.g., Adj- SIDs advertised with the S-flag set, which aggregate multiple parallel links under a single SID with ECMP semantics) MUST NOT be used by SR-MPLS RSVP-TE tunnels under this specification. Rationale: RSVP-TE requires per-link granularity for: Beeram, et al. Expires 29 April 2027 [Page 5] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 * Bandwidth admission control on individual links. * Explicit path routing over specific interfaces. * Per-link protection (detecting which specific link failed). The IS-IS Adj-SID sub-TLV [RFC8667] advertises an Adj-SID for a Layer 3 adjacency. When the Layer 3 adjacency is realized over a bundle of Layer 2 member links, the TE link is the Layer 3 adjacency; the individual Layer 2 members are not TE links. The Adj-SID used by an SR-MPLS RSVP-TE tunnel is therefore the Adj-SID of the Layer 3 adjacency. The Adj-SIDs that [RFC8668] allows to be advertised for the individual Layer 2 members of a bundle are not applicable to this specification. 3.3. Adj-SID Selection A TE link can have more than one Adj-SID attached to its adjacency, for example one per address family, or one that is eligible for protection and one that is not (B-flag, see Section 6). The following rules apply to the selection of the Adj-SID: * Address family: For a hop identified by an IPv4 (IPv6) prefix sub- object, the Adj-SID MUST be an IPv4 (IPv6) Adj-SID, i.e., one advertised for the IPv4 (IPv6) address family of the adjacency [RFC8667] [RFC8665]. For a hop identified by an Unnumbered Interface ID sub-object [RFC3477], which carries no address family, the node selects the Adj-SID according to local policy, unless the selection is constrained by an ERO Label sub-object (see Section 8.3). * Protection: Which of several eligible Adj-SIDs is used for a TE link, including whether it is eligible for protection (B-flag), is subject to the considerations in Section 6. Absent an ERO Label sub-object (Section 8.3), the transit node selects among them according to local policy. * Predictability: To maximize the chance that a label stack pre- computed from the IGP/TED by the ingress or controller matches the stack built from the RRO (Section 4.4), the ingress or controller SHOULD constrain the Adj-SID selection using the ERO Label sub- object (Section 8.3) whenever more than one eligible Adj-SID exists for a TE link. Otherwise, the transit node selects the Adj-SID according to local policy and the RRO remains the authoritative source (Section 4.1). Beeram, et al. Expires 29 April 2027 [Page 6] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 4. RSVP-TE Tunnel Setup Using Adj-SIDs This section describes the signaling procedures for establishing an RSVP-TE tunnel that uses SR-MPLS Adj-SIDs in the data plane. 4.1. Adj-SID Discovery Prior to signaling, the path computation engine (on the ingress LER or an external controller) determines the Adj-SID for each TE link along the explicit path by consulting the Traffic Engineering Database (TED). Each link in the TED carries the Adj-SID value(s) from the node that owns the link (the node whose IGP advertisement defined the SID). The path computation engine MAY pre-compute the full label stack from the TED. However, the ingress MUST still use the labels recorded in the RRO of the Resv message as the authoritative source for label stack construction. The TED-based pre-computation serves as a validation mechanism and enables faster setup. If a link's Adj-SID is not present in the TED at the time of path computation, the path computation engine SHOULD exclude that link from consideration when computing the explicit path. 4.2. Path Message Processing The ingress LER initiates RSVP-TE signaling by sending a Path message with the following attributes: * The LSP_REQUIRED_ATTRIBUTES object MUST carry the "SR Forwarding Plane" flag (Section 8.1) to mandate the use of Adj-SIDs at all transit hops. * The ERO MUST contain the explicit path as a sequence of sub- objects identifying each transit hop (IPv4/IPv6 prefix sub-objects or Unnumbered Interface ID sub-objects). * The ERO MAY additionally contain Label sub-objects [RFC3473] to constrain the Adj-SID selection at specific transit hops (see Section 8.3). This is OPTIONAL; when present, the transit node MUST use the indicated label or reject the request. * If delegation is requested, the LSP_ATTRIBUTES object carries the LSI-D flag as defined in [RFC8577] Section 9.4. * The "label recording desired" flag [RFC3209] MUST be set in the SESSION_ATTRIBUTE object. Beeram, et al. Expires 29 April 2027 [Page 7] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 When a transit node receives the Path message: * It MUST verify that it has an Adj-SID satisfying Section 3.2 and Section 3.3 (including the address family) for the outgoing TE link toward the next hop. * If an ERO Label sub-object [RFC3473] is present for this hop, the node MUST verify that the indicated label matches one of its locally configured Adj-SIDs for the relevant TE link. If there is a mismatch, the node MUST send a PathErr with error code 'Routing Problem (24)' and a new error value 'Adj-SID mismatch (TBD1)'. * If no ERO Label sub-object is present for this hop, the node selects one of its locally configured Adj-SIDs for the outgoing TE link. * The node performs bandwidth admission control on the outgoing TE link per standard RSVP-TE procedures. 4.3. Resv Message Processing When a node generates or forwards a Resv message: * It MUST place its Adj-SID for the outgoing TE link (the link over which it forwards traffic for this LSP) in the Label object of the Resv message. * It MUST record the same Adj-SID in the RRO Label sub-object with the "SR Adj-SID" flag set (Section 8.2). * No new label allocation occurs. The node simply references its pre-existing Adj-SID, which is already programmed in the forwarding plane and advertised via the IGP. The key difference from RFC 8577: in RFC 8577, the node allocates a TE link label from its local label space. Here, the node references an Adj-SID that is already allocated, programmed in the forwarding plane, and advertised via the IGP. The RSVP-TE signaling is purely a control-plane exercise -- no forwarding-plane programming occurs at tunnel setup or teardown. 4.4. Label Stack Construction at Ingress Upon receiving the Resv message, the ingress LER constructs the label stack using the same rules defined in [RFC8577] Section 7: * Process RRO Label sub-objects starting from the first downstream hop. Beeram, et al. Expires 29 April 2027 [Page 8] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 * Every label marked with the "SR Adj-SID" flag is an Adj-SID and is pushed onto the stack. As an Adj-SID is a pop-and-forward label, the label recorded in the RRO by the next downstream hop MUST also be pushed onto the stack, so that it is exposed when the Adj-SID is popped. * Delegation labels (Binding SIDs) are handled per the stacking approach (Section 5). Since all transit hops use Adj-SIDs (pop-and-forward), the resulting label stack is the ordered sequence of Adj-SIDs of the links along the path -- identical to what an SR headend would impose for the same path. 5. Delegating Label Stack Imposition The delegation mechanism from [RFC8577] Section 5 is preserved with one refinement: delegation labels are mapped to SR Binding SIDs (BSIDs) [RFC8402]. 5.1. Binding SIDs as Delegation Labels When a transit node is selected as a delegation hop (either explicitly or via automatic delegation using ETLD), it MUST allocate a Binding SID to represent the downstream path segment. The Binding SID is allocated and instantiated as specified for SR-MPLS [RFC8402] [RFC8660]. In the context of this document: * The segment list associated with the Binding SID is the label stack that represents the path from this node to the next delegation hop (or egress). * The Binding SID is recorded in the RRO with the "Delegation Label" flag (0x04) as defined in [RFC8577] Section 9.5. Sharing semantics: A Binding SID representing a specific downstream Adj-SID sequence can be shared across multiple RSVP-TE LSPs that traverse the same downstream path segment. This mirrors the delegation label sharing in [RFC8577] Section 5.1.1. When the downstream path changes (e.g., due to MBB or reoptimization), the old BSID MUST be updated or a new BSID allocated for the new path segment. Beeram, et al. Expires 29 April 2027 [Page 9] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 5.2. ETLD Computation The ETLD (Effective Transport Label-Stack Depth) mechanism from [RFC8577] Section 5.3 operates unchanged. The computation accounts for: * The Maximum SID Depth (MSD) advertised by each node via IGP [RFC8491] or signaled via other mechanisms. * Protection overhead: If a protection mechanism that requires the PLR to push additional label(s) is active (see Section 6), the ETLD SHOULD be decremented to account for those labels at protected hops. 6. Protection Mechanisms This section discusses the protection of the Adj-SIDs that are used by SR-MPLS RSVP-TE tunnels. Node protection is outside the scope of this document. The SR architecture does not mandate a specific mechanism to protect an Adj-SID. [RFC8402] Section 3.4 describes the protection of an Adj-SID as policy-based, with IP Fast Reroute (IPFRR) and MPLS Fast Reroute (MPLS-FRR) as examples, and [RFC8667] Section 2.2.1 defines the B-flag as an indication that the Adj-SID is eligible for protection, not of the protection mechanism. The existing Adj-SID advertisements do not identify the protection mechanism that is associated with a protected Adj-SID. In particular, an SR-MPLS RSVP- TE tunnel that requests link protection [RFC4090] cannot assume that a protected Adj-SID is protected by an RSVP-TE-signaled facility backup path. Using a backup path other than a TI-LFA [RFC9855] path (whether an RSVP-TE-signaled facility backup path or a non-signaled, controller-managed SR-TE backup path) with a protected Adj-SID requires extensions to SR-MPLS (see Section 6.2). The following subsections describe the models that have been identified for link protection of RSVP-TE tunnels in a network that uses SR-MPLS Adj-SIDs, and the aspects that each of them needs to address. The first model does not use SR Adj-SIDs for the tunnels that request link protection; the other two do. Beeram, et al. Expires 29 April 2027 [Page 10] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 6.1. RFC 8577 Link Protection Procedure With this model, the link protection procedure of [RFC8577] Section 8.1 and [RFC4090] is used unchanged: the PLR allocates a separate TE link label for the TE link that will be used by tunnels that request link protection from the ingress, and a facility backup bypass tunnel that terminates at the next hop (the merge point) is pre-established to protect the TE link. The bypass tunnel is signaled via RSVP-TE, uses regular labels, and can be computed using any relevant constraints and optimization objective. Since the bypass tunnel terminates at the merge point, the incoming label on the packet at the merge point is the label that it expects. This model does not use protected SR Adj-SIDs, either with their current semantics or with enhanced semantics. A tunnel that uses this model signals the TE Link Label flag (Bit 16) of [RFC8577] and uses TE link labels at all hops; it does not use SR Adj-SIDs (see Section 8.1). The model also retains a separate TE link label allocation, which reduces the benefit of a single label allocation system described in Section 1. Because the existing Adj-SID advertisements cannot distinguish an Adj-SID that is protected by RSVP-TE from one that is protected by another mechanism, a label allocated for this purpose is not advertised in the IGP as an SR-MPLS Adj-SID unless the extension described in Section 6.2 is available. 6.2. RSVP-TE-Signaled Facility Backup for Protected Adj-SIDs With this model, the PLR protects a protected Adj-SID using a facility backup bypass tunnel [RFC4090] that is signaled via RSVP-TE. When the protected link is operational, the PLR pops the Adj-SID and forwards the packet over the link; when the link fails, the PLR pops the Adj-SID and redirects the packet via the bypass tunnel to the next hop. This model requires an extension to the Adj-SID advertisement that identifies the protection behavior that is associated with the Adj- SID and defines how it is realized, and that is backward compatible with existing SR-MPLS deployments (in particular, SR nodes that use TI-LFA to protect Adj-SIDs). The same extension would be needed for non-signaled, controller-managed SR-TE backup paths. Such extensions are expected to be discussed separately. This section will be elaborated in a later revision of this document. 6.3. TI-LFA Link Protection With this model, a protected Adj-SID is protected by TI-LFA [RFC9855], i.e., by a non-signaled repair path. It requires the following procedures to be specified: Beeram, et al. Expires 29 April 2027 [Page 11] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 * How an RSVP-TE LSP that requests link protection is considered protected by a non-signaled TI-LFA repair path that always merges at the next hop. * How the RSVP-TE signaling state of the primary LSP, and the forwarding state of the Adj-SIDs that it uses, are maintained after local repair, during the failure interval, and after the primary path is restored. The TI-LFA repair must not inadvertently cause the primary RSVP-TE state to be torn down. This section will be elaborated in a later revision of this document. 7. Bandwidth Admission Control Bandwidth admission control operates per standard RSVP-TE procedures. The fact that the data-plane label (Adj-SID) is shared across LSPs does not affect admission control, which is maintained in the control plane per-LSP. Each transit node: * Maintains per-link bandwidth accounting (reserved bandwidth as the sum of all admitted RSVP-TE LSPs on the link). * Performs admission control on new LSP setup or bandwidth modification requests. * Advertises available bandwidth via IGP TE extensions [RFC5305] [RFC3630]. The shared Adj-SID means that the forwarding plane does not distinguish between individual LSPs. Bandwidth enforcement is a control-plane property, not a forwarding-plane property. If hardware-based bandwidth policing per-LSP is required, this mechanism is not applicable. 8. Protocol Extensions This document introduces minimal signaling extensions: one new Attribute Flag and one new RRO Label sub-object flag. All other signaling uses existing RSVP-TE objects and sub-objects defined in [RFC3209], [RFC3473], and [RFC8577]. 8.1. Attribute Flags: SR Forwarding Plane Bit Number (TBD2): SR Forwarding Plane Beeram, et al. Expires 29 April 2027 [Page 12] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 The presence of this flag in the LSP_REQUIRED_ATTRIBUTES object [RFC5420] of a Path message mandates the use of SR-MPLS Adj-SIDs that satisfy Section 3 at all transit hops. Relationship to the TE Link Label flag (Bit 16 from [RFC8577]): * Bit 16 (TE Link Label) requests RSVP-TE-allocated TE link labels. * Bit TBD2 (SR Forwarding Plane) requests SR-MPLS Adj-SIDs. * These two flags are mutually exclusive. A node MUST NOT set both flags for the same LSP. When a node that recognizes this flag cannot comply (e.g., it does not have a suitable Adj-SID for the outgoing TE link), it MUST send a PathErr with error code 'Routing Problem (24)' and error value 'SR Adj-SID unavailable (TBD3)'. An ingress LER that sets this bit MUST also set the "label recording desired" flag [RFC3209] in the SESSION_ATTRIBUTE object. 8.2. RRO Label Sub-object Flag: SR Adj-SID Flag (TBD4): SR Adj-SID The presence of this flag in an RRO Label sub-object indicates that the recorded label is an SR-MPLS Adjacency SID. This flag MUST be set by a transit node when recording its Adj-SID in the RRO. The TE Link Label flag (0x02) from [RFC8577] SHOULD NOT be used when the label is an SR-MPLS Adj-SID. The SR Adj-SID flag (TBD4) provides equivalent pop-and-forward semantics with the additional indication that the label is an Adj-SID that is advertised by the IGP. The label value is carried in the standard 20-bit label field of the existing RRO Label sub-object. No new RRO sub-object type is defined. 8.3. Constraining Adj-SID Selection via ERO When the ingress needs to constrain a transit node to use a specific Adj-SID (e.g., when multiple Adj-SIDs exist for the same TE link, such as a protected and an unprotected one, see Section 3.3), it MAY include an ERO Label sub-object [RFC3473] following the hop- identifying sub-object (IPv4/IPv6 prefix or Unnumbered Interface ID). Beeram, et al. Expires 29 April 2027 [Page 13] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 The ERO Label sub-object carries the desired 20-bit Adj-SID label value using the existing encoding defined in [RFC3473] Section 4.1. No new ERO sub-object type is defined. When a transit node receives an ERO Label sub-object and the SR Forwarding Plane flag is set: * It MUST verify that the label in the ERO Label sub-object matches one of its locally configured Adj-SIDs for the outgoing TE link. * On match: it uses that Adj-SID. * On mismatch: it MUST send a PathErr with error code 'Routing Problem (24)' and error value 'Adj-SID mismatch (TBD1)'. When no ERO Label sub-object is present, the transit node selects one of its locally configured Adj-SIDs for the outgoing TE link autonomously. Note: Delegation labels (Binding SIDs) are recorded in the RRO using the existing Delegation Label flag (0x04) from [RFC8577] Section 9.5. No new signaling is required for delegation. 9. OAM Considerations MPLS LSP Ping and Traceroute [RFC8029] are applicable for RSVP-TE tunnels using SR-MPLS Adj-SIDs. The procedures in [RFC8287] (Label Switched Path Ping for Segment Routing) provide additional mechanisms for validating individual SIDs along the path. For an RSVP-TE tunnel using Adj-SIDs: * LSP Ping MAY use the RSVP-TE session-based FEC (as per standard RSVP-TE OAM) to validate end-to-end connectivity. * Traceroute SHOULD use the SR Segment List FEC [RFC8287] to validate each Adj-SID at every transit hop. * A delegation hop that expands a Binding SID into a label stack SHOULD report the expanded stack in the Label Stack Sub-TLV of the MPLS echo reply. 10. IANA Considerations This document requests the following IANA allocations. Beeram, et al. Expires 29 April 2027 [Page 14] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 10.1. Attribute Flags IANA manages the "Attribute Flags" subregistry as part of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry. This document introduces one new Attribute Flag: +======+============+===========+===========+===+=====+=============+ | Bit | Name | Attribute | Attribute |RRO| ERO | Reference | | No | | Flags | Flags | | | | | | | Path | Resv | | | | +======+============+===========+===========+===+=====+=============+ | TBD2 | SR | Yes | No |No | No | This | | | Forwarding | | | | | document, | | | Plane | | | | | Section | | | | | | | | 8.1 | +------+------------+-----------+-----------+---+-----+-------------+ Table 1 10.2. Record Route Label Sub-object Flags IANA manages the "Record Route Object Sub-object Flags" registry as part of the "Resource Reservation Protocol-Traffic Engineering (RSVP- TE) Parameters" registry. This document introduces one new Label Sub-object Flag: +======+============+============================+ | Flag | Name | Reference | +======+============+============================+ | TBD4 | SR Adj-SID | This document, Section 8.2 | +------+------------+----------------------------+ Table 2 10.3. Error Codes and Error Values IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes". Within this subregistry is a definition of the "Routing Problem" Error Code (24). IANA is requested to allocate further error values for use with this Error Code as follows: 24 Routing Problem [RFC3209] This Error Code has the following globally defined Error Value sub- codes: Beeram, et al. Expires 29 April 2027 [Page 15] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 +=======+========================+============================+ | Value | Meaning | Reference | +=======+========================+============================+ | TBD1 | Adj-SID mismatch | This document, Section 8.3 | +-------+------------------------+----------------------------+ | TBD3 | SR Adj-SID unavailable | This document, Section 8.1 | +-------+------------------------+----------------------------+ Table 3 11. Security Considerations This document does not introduce new security issues. The security considerations pertaining to RSVP [RFC2205], RSVP-TE [RFC3209], the MPLS and GMPLS security framework [RFC5920], and SR [RFC8402] [RFC8660] remain relevant. The IGP-advertised Adj-SIDs are used only for the optional pre- computation of the label stack and for path computation (Section 4.1); the ingress builds its label stack from the RRO (Section 4.4). Deployments SHOULD use IGP authentication [RFC5304] [RFC5310] to protect the information that is used for path computation. 12. Acknowledgements The authors would like to thank Harish Sitaraman, Tejal Parikh, and Tarek Saad for their contributions to RFC 8577, which forms the foundation for this work. The authors would also like to thank Bruno Decraene for his detailed review and comments. 13. References 13.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, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . Beeram, et al. Expires 29 April 2027 [Page 16] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, February 2003, . [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, . [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangar, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, . [RFC8577] Sitaraman, H., Beeram, V., Parikh, T., and T. Saad, "Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane", RFC 8577, DOI 10.17487/RFC8577, April 2019, . [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, . [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, . Beeram, et al. Expires 29 April 2027 [Page 17] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, . 13.2. Informative References [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, February 2003, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, October 2003, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, . Beeram, et al. Expires 29 April 2027 [Page 18] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, . [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, December 2019, . [RFC9855] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute Using Segment Routing", RFC 9855, DOI 10.17487/RFC9855, October 2025, . Contributors Chandra Ramachandran HPE Email: chandrasekar.ramachandran@hpe.com Sudharsana Venkatraman HPE Email: sudharsana.venkatraman@hpe.com Shraddha Hegde HPE Email: shraddha.hegde@hpe.com Abhishek Chakraborty HPE Email: abhishek.chakraborty@hpe.com Jayant Agarwal HPE Email: jayant.agarwal@hpe.com Authors' Addresses Beeram, et al. Expires 29 April 2027 [Page 19] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs October 2026 Vishnu Pavan Beeram HPE Email: vishnupavan.ietf@gmail.com Colby Barth HPE Email: jonathan.barth@hpe.com Andrew Smith Arrcus, Inc. Email: andy@arrcus.com Beeram, et al. Expires 29 April 2027 [Page 20]