SPRING V. P. Beeram Internet-Draft C. Barth Intended status: Standards Track HPE Expires: 6 January 2027 A. Smith Arrcus, Inc. 5 July 2026 Signaling RSVP-TE Tunnels on an SR-MPLS Forwarding Plane Using Adjacency Segment Identifiers draft-beeram-spring-rsvp-sr-mpls-00 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 to use SR-MPLS Adjacency SIDs that are advertised by the IGP as the forwarding-plane labels for RSVP-TE tunnels. It restricts scope to per-link Adj-SIDs and defines the signaling procedures and protocol extensions required to couple the RSVP-TE control plane with the native SR-MPLS forwarding 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 6 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Beeram, et al. Expires 6 January 2027 [Page 1] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 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. IGP Advertisement . . . . . . . . . . . . . . . . . . . . 6 4. RSVP-TE Tunnel Setup Using Adj-SIDs . . . . . . . . . . . . . 6 4.1. Adj-SID Discovery . . . . . . . . . . . . . . . . . . . . 6 4.2. Path Message Processing . . . . . . . . . . . . . . . . . 6 4.3. Resv Message Processing . . . . . . . . . . . . . . . . . 7 4.4. Label Stack Construction at Ingress . . . . . . . . . . . 8 5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 8 5.1. Binding SIDs as Delegation Labels . . . . . . . . . . . . 8 5.2. ETLD Computation . . . . . . . . . . . . . . . . . . . . 9 6. Protection Mechanisms . . . . . . . . . . . . . . . . . . . . 9 6.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 9 7. Bandwidth Admission Control . . . . . . . . . . . . . . . . . 10 8. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 10 8.1. Attribute Flags: SR Forwarding Plane . . . . . . . . . . 11 8.2. RRO Label Sub-object Flag: SR Adj-SID . . . . . . . . . . 11 8.3. Constraining Adj-SID Selection via ERO . . . . . . . . . 12 9. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . 13 10.2. Record Route Label Sub-object Flags . . . . . . . . . . 13 10.3. Error Codes and Error Values . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Beeram, et al. Expires 6 January 2027 [Page 2] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 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]. 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 to use IGP-advertised SR Adj-SIDs as the forwarding-plane labels for RSVP-TE tunnels. This unifies the forwarding plane: 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, explicit path management, and fast-reroute signaling on top of the shared SR-MPLS forwarding plane. This document restricts its scope to: * Per-link Adj-SIDs: One Adj-SID per physical or logical TE link (not per-neighbor aggregate SIDs). Benefits of this approach over RFC 8577: * Single label allocation system: Eliminates dual allocation (TE link labels + Adj-SIDs) and potential label space fragmentation. Beeram, et al. Expires 6 January 2027 [Page 3] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 * 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 forwarding-plane conflicts. 2. Terminology The following terms are used in this document: Adj-SID: Adjacency Segment Identifier. A label allocated by a node for a specific adjacency (TE link) and advertised via IGP. When present at the top of the label stack, the node pops the label and forwards the packet over the associated adjacency. Per-link Adj-SID: An Adj-SID that identifies a specific TE link (interface) rather than a neighbor (set of parallel links). Corresponds to an Adj-SID advertisement without the B-flag (Backup) and without the S-flag (Set). Binding SID (BSID): A local label that, when matched, triggers the imposition of a predetermined label stack. Used at delegation hops to represent a downstream path segment. SR-MPLS Forwarding Plane: The MPLS data plane where forwarding decisions at each hop are driven by Adj-SIDs (pop and forward) rather than per-LSP swap labels. PLR: Point of Local Repair. The node that detects a failure and initiates fast-reroute. SRLB: Segment Routing Local Block. The range of local labels from which Adj-SIDs are allocated. 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 defines the properties of Adj-SIDs used as the forwarding-plane labels for RSVP-TE tunnels. Beeram, et al. Expires 6 January 2027 [Page 4] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 3.1. Adj-SID Persistence An Adj-SID used for RSVP-TE forwarding 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 for RSVP-TE forwarding MUST be per-link (per- interface). That is, a unique Adj-SID is allocated for each TE link, even if multiple parallel links exist to the same neighbor. This corresponds to an Adj-SID advertisement without the S-flag (Set) in the IGP. Per-neighbor (Set) SIDs, which aggregate multiple parallel links under a single SID with ECMP semantics, MUST NOT be used for RSVP-TE forwarding under this specification. Rationale: RSVP-TE requires per-link granularity for: * Bandwidth admission control on individual links. Beeram, et al. Expires 6 January 2027 [Page 5] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 * Explicit path routing over specific interfaces. * Per-link protection (detecting which specific link failed). 3.3. IGP Advertisement Each node participating in the SR-MPLS forwarding plane for RSVP-TE MUST advertise its per-link Adj-SIDs via the IGP using the extensions defined in [RFC8667] (IS-IS) or [RFC8665] (OSPF). The V-flag (Value) and L-flag (Local) MUST be set, indicating that the advertised SID value is an absolute MPLS label from the SRLB. A controller or ingress LER uses these IGP advertisements to pre- compute the label stack for an RSVP-TE tunnel prior to signaling. 4. RSVP-TE Tunnel Setup Using Adj-SIDs This section describes the signaling procedures for establishing an RSVP-TE tunnel that uses IGP-advertised Adj-SIDs for its forwarding 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 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: Beeram, et al. Expires 6 January 2027 [Page 6] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 * 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. When a transit node receives the Path message: * It MUST verify that it has a per-link Adj-SID configured 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 its locally configured Adj-SID 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 its locally configured per-link Adj-SID 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 per-link 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). Beeram, et al. Expires 6 January 2027 [Page 7] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 * No new label allocation occurs. The node simply references its pre-existing, IGP-advertised Adj-SID. 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, pre- programmed in the forwarding plane, and advertised via 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. * Every label marked with the "SR Adj-SID" flag is a pop-and- forward label. The next hop's label MUST also be pushed onto the stack. * 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 from the first hop to the penultimate hop -- 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). 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: * A local label from the SRLB (or dynamic label range). Beeram, et al. Expires 6 January 2027 [Page 8] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 * Programmed in the forwarding plane with an action to pop the BSID and push the label stack representing the path from this node to the next delegation hop (or egress). * 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. 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 facility backup link protection is active, the PLR needs to push the bypass tunnel's label(s). The ETLD SHOULD be decremented to account for the bypass tunnel label at protected hops. 6. Protection Mechanisms This document uses the facility backup link protection procedures defined in [RFC8577] Section 8.1 and [RFC4090]. Node protection and non-signaled protection paths are outside the scope of this document. 6.1. Link Protection Link protection operates as defined in [RFC8577] Section 8.1. To provide link protection at a PLR, the LSR MUST allocate a separate Adj-SID for the TE link that will be used for RSVP-TE tunnels requesting link protection from the ingress. This link-protected Adj-SID is analogous to the link-protected TE link label defined in [RFC8577]. A facility backup bypass tunnel is pre-established to protect the TE link. The bypass tunnel terminates at the next hop (the merge point). The bypass tunnel is signaled via RSVP-TE. Beeram, et al. Expires 6 January 2027 [Page 9] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 When the protected TE link is operational, the PLR pops the link- protected Adj-SID and forwards the packet over the TE link to the next hop. When the TE link fails, the PLR pops the link-protected Adj-SID and redirects the packet via the facility backup bypass tunnel to the next hop. Since the facility backup terminates at the next hop (merge point), the incoming label on the packet at the merge point will be the Adj- SID that the merge point expects -- the same label it would have received had the protected link been operational. No additional signaling extensions are required to support link protection beyond those already defined in [RFC8577] and [RFC4090]. 7. Bandwidth Admission Control Bandwidth admission control operates per standard RSVP-TE procedures. The fact that the forwarding-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]. Beeram, et al. Expires 6 January 2027 [Page 10] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 8.1. Attribute Flags: SR Forwarding Plane Bit Number (TBD2): SR Forwarding Plane The presence of this flag in the LSP_REQUIRED_ATTRIBUTES object [RFC5420] of a Path message mandates the use of IGP-advertised per- link SR Adj-SIDs 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 IGP-advertised SR 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 per-link Adj-SID configured 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 IGP-advertised SR Adjacency SID. This flag MUST be set by a transit node when recording its per-link Adj-SID in the RRO. The TE Link Label flag (0x02) from [RFC8577] SHOULD NOT be used when the label is a native SR Adj-SID. The SR Adj-SID flag (TBD4) provides equivalent pop-and-forward semantics with the additional indication that the label is IGP-originated. 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. Beeram, et al. Expires 6 January 2027 [Page 11] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 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 per-link Adj-SIDs exist for the same TE link), it MAY include an ERO Label sub-object [RFC3473] following the hop-identifying sub-object (IPv4/IPv6 prefix or Unnumbered Interface ID). 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 per-link 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 its locally configured per-link Adj-SID 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 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. Beeram, et al. Expires 6 January 2027 [Page 12] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 * 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. 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 Path Flags Resv TBD2 SR Forwarding Plane Yes No No No [ThisDoc], Section 8.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 [ThisDoc], Section 8.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: Beeram, et al. Expires 6 January 2027 [Page 13] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 24 Routing Problem [RFC3209] This Error Code has the following globally defined Error Value sub-codes: TBD1 = Adj-SID mismatch [ThisDoc], Section 8.3 TBD3 = SR Adj-SID unavailable [ThisDoc], Section 8.1 11. Security Considerations This document does not introduce fundamentally new security issues beyond those in [RFC8577], [RFC3209], and [RFC8402]. The use of IGP-advertised Adj-SIDs introduces a dependency on IGP security. If an attacker can inject false IGP advertisements with spoofed Adj-SIDs, traffic could be misdirected. Deployments SHOULD use IGP authentication [RFC5304] [RFC5310] to protect against such attacks. The Adj-SIDs used for RSVP-TE forwarding are local labels visible in IGP advertisements. An off-path attacker with knowledge of these labels could craft packets that traverse specific paths. This is an inherent property of SR-MPLS and is not worsened by this specification. Deployments MAY use ACLs at domain boundaries to filter externally sourced packets with SR label stacks. 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. 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 6 January 2027 [Page 14] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 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, . [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, . [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, . Beeram, et al. Expires 6 January 2027 [Page 15] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 13.2. Informative References [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, . [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, . [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, . 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 Beeram, et al. Expires 6 January 2027 [Page 16] Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026 Abhishek Chakraborty HPE Email: abhishek.chakraborty@hpe.com Jayant Agarwal HPE Email: jayant.agarwal@hpe.com Authors' Addresses 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 6 January 2027 [Page 17]