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 SRv6 Forwarding Plane Using End.X Segment Identifiers draft-beeram-spring-rsvp-srv6-00 Abstract RFC 8577 defines mechanisms to signal RSVP-TE tunnels on a shared MPLS forwarding plane by introducing the notion of per-TE link labels that are functionally equivalent to SR-MPLS adjacency segments. This document extends that work to the SRv6 data plane, defining the signaling extensions and procedures necessary to establish RSVP-TE tunnels that utilize SRv6 Segment Identifiers (SIDs) for forwarding. This document specifies how SRv6 End.X SIDs serve as TE link SIDs, defines new RSVP signaling extensions for carrying SRv6 SIDs, describes TE path segment-list construction procedures at the ingress, and adapts the delegation mechanisms of RFC 8577 to use SRv6 Binding SIDs. The result couples the traffic engineering capabilities of the RSVP-TE control plane with the native IPv6 forwarding of SRv6. 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. Beeram, et al. Expires 6 January 2027 [Page 1] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Acronyms and Definitions . . . . . . . . . . . . . . . . 4 3. SRv6 TE Link SIDs . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Allocation . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Forwarding Behavior . . . . . . . . . . . . . . . . . . . 6 3.3. Sharing . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Micro-SID Considerations . . . . . . . . . . . . . . . . 6 4. Tunnel Setup . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Signaling Overview . . . . . . . . . . . . . . . . . . . 7 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Signaling Extensions . . . . . . . . . . . . . . . . . . . . 10 5.1. Generalized Label Request . . . . . . . . . . . . . . . . 10 5.2. Generalized Label (Resv) . . . . . . . . . . . . . . . . 10 5.3. RRO SRv6 SID Sub-object . . . . . . . . . . . . . . . . . 11 5.4. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 12 5.4.1. SSI-D . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4.2. SRv6 uSID . . . . . . . . . . . . . . . . . . . . . . 13 5.5. Constraining SRv6 SID Selection via ERO . . . . . . . . . 13 6. TE Path Segment-List Construction . . . . . . . . . . . . . . 15 6.1. Procedures at the Ingress . . . . . . . . . . . . . . . . 15 6.2. Reduced SRH . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. SID Validation . . . . . . . . . . . . . . . . . . . . . 16 7. Delegation with SRv6 Binding SIDs . . . . . . . . . . . . . . 17 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Sub-segment Re-encapsulation . . . . . . . . . . . . . . 18 7.3. Effective SRv6 Segment-List Depth (ESLD) . . . . . . . . 20 8. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 21 9. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 Beeram, et al. Expires 6 January 2027 [Page 2] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 10.1. SRv6 Switching Types . . . . . . . . . . . . . . . . . . 22 10.2. Attribute Flags . . . . . . . . . . . . . . . . . . . . 23 10.3. RRO Sub-object Types . . . . . . . . . . . . . . . . . . 23 10.4. ERO Sub-object Types . . . . . . . . . . . . . . . . . . 23 10.5. RRO SRv6 SID Sub-object Flags . . . . . . . . . . . . . 23 10.6. ERO SRv6 SID Sub-object Flags . . . . . . . . . . . . . 24 10.7. Attribute TLVs . . . . . . . . . . . . . . . . . . . . . 24 10.8. Error Codes and Error Values . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. ESLD Computation and Delegation Procedure . . . . . 27 A.1. Computing the ESLD . . . . . . . . . . . . . . . . . . . 27 A.2. Delegation Decision Procedure . . . . . . . . . . . . . . 28 A.3. ESLD Reset at Delegation Hops . . . . . . . . . . . . . . 29 A.4. Micro-SID Interaction . . . . . . . . . . . . . . . . . . 29 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction The scaling of RSVP-TE [RFC3209] control-plane implementations can be improved by adopting the guidelines and mechanisms described in [RFC2961] and [RFC8370]. RFC 8577 [RFC8577] further addressed forwarding-plane scalability by introducing the notion of preinstalled 'per-TE link labels' that are shared by MPLS RSVP-TE LSPs traversing those TE links. This approach couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane. SRv6 [RFC8402] brings the Segment Routing architecture to native IPv6 forwarding. SRv6 Segment Identifiers (SIDs) are 128-bit IPv6 addresses, and the ordered list of segments to be traversed is encoded in the Segment Routing Header (SRH) [RFC8754]. SRv6 Network Programming [RFC8986] defines a rich set of endpoint behaviors, including End.X (the SRv6 instantiation of an adjacency SID), which is functionally analogous to the TE link label concept of RFC 8577. This document extends the work of RFC 8577 to the SRv6 data plane. It defines: * How SRv6 End.X SIDs serve as TE link SIDs in the context of RSVP- TE signaling. * RSVP signaling extensions for carrying SRv6 SIDs in the Generalized Label, Record Route Object (RRO), and related objects. Beeram, et al. Expires 6 January 2027 [Page 3] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 * TE path segment-list construction procedures at the ingress Label Edge Router (LER) based on SRv6 SIDs recorded in the RRO. * Adaptation of the delegation mechanisms (delegation hops and delegation labels) of RFC 8577 to SRv6 Binding SIDs. * Link protection mechanisms for RSVP-TE tunnels over the SRv6 forwarding plane. * SID validation procedures at the ingress to verify the correctness of the constructed SRH before switching data traffic. * Optional ERO-based mechanisms for the ingress to constrain SID selection at transit hops. * Support for micro-SID (uSID) encoding, enabling compressed SRv6 segment lists with reduced SRH overhead. The combination of these extensions enables operators to leverage the rich feature set of the RSVP-TE control plane -- including bandwidth admission control, LSP priorities, preemption, and auto-bandwidth -- while utilizing the native IPv6 forwarding capabilities of SRv6. The signaling procedures and extensions discussed in this document do not apply to Point-to-Multipoint (P2MP) RSVP-TE tunnels. 2. Terminology 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. 2.2. Acronyms and Definitions The reader is assumed to be familiar with the terminology used in [RFC2205], [RFC3209], [RFC8402], [RFC8754], [RFC8986], and [RFC8577]. SRv6 TE Link SID: An SRv6 End.X SID allocated at a node for a specific TE link. When an IPv6 packet arrives with this SID as the IPv6 Destination Address, the node performs the End.X behavior: it decrements Segments Left, updates the IPv6 DA with the next SID in the SRH (if present), and forwards the packet over the TE link to the downstream neighbor. This is the SRv6 equivalent of the TE link label defined in RFC 8577. Beeram, et al. Expires 6 January 2027 [Page 4] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 SRv6 RSVP-TE tunnel: An RSVP-TE tunnel that requests the use of SRv6 TE Link SIDs at every hop of the LSP. This is the SRv6 equivalent of the Segment Routed RSVP-TE tunnel defined in RFC 8577. Delegation hop: A transit hop of an SRv6 RSVP-TE LSP that is selected to assist in the imposition of the segment list. The delegation hop allocates a Binding SID (End.B6.Encaps or End.B6.Encaps.Red) and performs re-encapsulation. There can be multiple delegation hops along the path. Delegation SID: An SRv6 Binding SID allocated at the delegation hop to represent a sub-segment-list that will be encapsulated at this hop. This is the SRv6 equivalent of the delegation label in RFC 8577. ESLD (Effective SRv6 Segment-List Depth): The effective number of SRv6 SIDs that a node (in relation to its position in the path) can potentially include in an SRH sent to its downstream hop. This is the SRv6 equivalent of the ETLD defined in RFC 8577. 3. SRv6 TE Link SIDs 3.1. Allocation A node that participates in an SRv6 RSVP-TE forwarding plane MUST allocate an SRv6 End.X SID for each TE link. These SIDs are allocated from the node's SRv6 locator prefix. Unlike MPLS TE link labels which are purely local and signaled only via RSVP, SRv6 End.X SIDs have an IPv6 address representation and are typically advertised via IGP extensions for SRv6 [RFC9352]. When an SRv6 End.X SID is allocated for RSVP-TE TE link purposes, it MAY be the same SID already advertised in the IGP for that adjacency, or a separate SID allocated specifically for RSVP-TE use. When an SRv6-capable node encounters an SRv6 TE Link SID as the IPv6 Destination Address, it MUST perform the End.X behavior as defined in Section 4.2 of [RFC8986]: decrement Segments Left, update the IPv6 DA with the next SID in the Segment List, and forward the packet over the corresponding TE link. Multiple SRv6 TE Link SIDs MAY be allocated for a given TE link to accommodate tunnels requesting protection (Section 8). An SRv6 SID is a 128-bit IPv6 address structured as LOC:FUNCT:ARG. For End.X SIDs used as TE Link SIDs, the LOC portion provides routability to the node, while the FUNCT identifies the specific adjacency. Beeram, et al. Expires 6 January 2027 [Page 5] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 3.2. Forwarding Behavior The forwarding behavior of an SRv6 TE Link SID at a transit node differs from the MPLS TE link label behavior in RFC 8577: * MPLS TE link label: The label is popped from the label stack, and the packet is forwarded on the TE link. * SRv6 TE Link SID: The End.X behavior is executed -- Segments Left is decremented, the IPv6 DA is updated with SegmentList[Segments Left], and the packet is forwarded on the TE link. The SID itself remains in the SRH Segment List but is no longer the active segment. This distinction is important for TE path segment-list construction (Section 6) and OAM (Section 9). 3.3. Sharing A key property of TE link labels in RFC 8577 is that they are shared among all RSVP-TE LSPs traversing the same TE link. SRv6 TE Link SIDs inherit this property naturally: * The same SRv6 End.X SID is returned in the Resv message for all RSVP-TE tunnels traversing the same TE link on a given node. * The End.X SID behavior is independent of the ingress or egress of the tunnel -- it simply forwards the packet on the TE link. * Implementations that maintain per-SID bandwidth accounting MUST aggregate the reservations made for all the LSPs using the shared SRv6 TE Link SID. 3.4. Micro-SID Considerations SRv6 micro-segment (uSID) [RFC9352] is a compressed SID format that allows multiple micro-SIDs to be packed into a single 128-bit SRH Segment List entry (referred to as a "container"). For example, with a 16-bit micro-SID format, up to six micro-SIDs can be encoded within one 128-bit container, dramatically reducing SRH overhead compared to full-length SRv6 SIDs. The micro-SID architecture is applicable to SRv6 RSVP-TE tunnels and offers the following advantages in this context: Beeram, et al. Expires 6 January 2027 [Page 6] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 * Reduced SRH overhead: A path of N hops that would require N x 16 bytes with full SIDs may require significantly fewer bytes with micro-SIDs, bringing the overhead closer to that of an MPLS label stack. * Reduced need for delegation: Because more segments fit within the MTU-constrained SRH, the delegation mechanism (Section 7) becomes necessary only for longer paths, simplifying network operation. * Impact on ESLD: The Effective SRv6 Segment-List Depth (Section 7.3) values increase substantially when micro-SIDs are in use, as more segments can be encoded per SRH. The same GENERALIZED_LABEL_REQUEST object (Section 5.1) is used regardless of whether micro-SIDs or full-length SIDs are in use. Transit nodes that support micro-SIDs SHOULD prefer allocating micro- SID End.X SIDs when available. The Generalized Label (Section 5.2) and RRO SRv6 SID sub-object (Section 5.3) carry the full 128-bit SID value in both cases; the distinction is transparent to the signaling. If the ingress desires to mandate the use of micro-SIDs at all hops, it MAY set the SRv6 uSID attribute flag (Section 5.4.2) in the LSP_REQUIRED_ATTRIBUTES object. Hops that cannot allocate a micro- SID End.X SID MUST reject the Path message. The TE path segment-list construction procedures at the ingress (Section 6) apply the micro-SID container packing rules defined in [RFC9352] when the RRO contains micro-SIDs. Consecutive micro-SIDs sharing the same block are packed into 128-bit containers, while full-length SIDs each occupy a separate Segment List entry. 4. Tunnel Setup 4.1. Signaling Overview To set up an SRv6 RSVP-TE tunnel, the following signaling sequence is used: 1. The ingress LER creates an RSVP Path message with a session type of LSP_TUNNEL_IPv6 and includes a Generalized Label Request object [RFC3471] with the Switching Type set to SRv6-Segment (TBD1), indicating that SRv6 TE Link SIDs are to be used at all hops (Section 5.1). Beeram, et al. Expires 6 January 2027 [Page 7] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 2. The ingress LER populates the EXPLICIT_ROUTE object with the explicit path and sets the "label recording desired" flag in the SESSION_ATTRIBUTE object. The ERO MAY contain SRv6 SID sub- objects (Section 5.5) to constrain the End.X SID selection at specific transit hops or to specify Delegation SIDs at delegation hops. 3. As the Path message traverses each hop, each transit node verifies that it has an SRv6 End.X SID for the outgoing TE link. If an ERO SRv6 SID sub-object (Section 5.5) is present for this hop, the node verifies the indicated SID matches a locally allocated End.X SID. The node also performs bandwidth admission control on the outgoing TE link per standard RSVP-TE procedures. 4. When the egress receives the Path message, it generates a Resv message. Each transit node provides its SRv6 End.X SID for the downstream TE link in the Generalized Label object and records it in the RRO using the SRv6 SID sub-object (Section 5.3). 5. When the Resv message reaches the ingress LER, it uses the SRv6 SIDs recorded in the RRO -- including transit End.X SIDs and any Delegation SIDs -- to construct the TE path segment list (Section 6). 4.2. Example Consider the following topology where each node has allocated SRv6 End.X SIDs for its TE links. SIDs are shown in abbreviated form (LOC:FUNCT). +---+ +---+ +---+ +---+ +---+ | A |--------| B |--------| C |--------| D |--------| E | +---+ +---+ +---+ +---+ +---+ End.X SIDs (for the downstream TE link toward the right): B: B::100 C: C::100 D: D::100 Service SID at egress E: E::46 (End.DT46) Figure 1: Sample Topology -- SRv6 TE Link SIDs Consider two tunnels: RSVP-TE tunnel T1: From A to E on path A-B-C-D-E RSVP-TE tunnel T2: From A to E on path A-B-C-D-E (different bandwidth reservation) Beeram, et al. Expires 6 January 2027 [Page 8] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 Both tunnels share the TE links A-B, B-C, C-D, and D-E. RSVP-TE is used to signal the setup of tunnel T1 (using the SRv6-Segment switching type in the Generalized Label Request). When node D receives the Resv message, it checks the next-hop TE link (D-E) and provides the SRv6 End.X SID (D::100) in the Generalized Label object. It also records this SID in the SRv6 SID sub-object in the RRO with the Delegation SID flag (0x01) clear. Similarly, node C provides its End.X SID (C::100) for TE link C-D, and node B provides its End.X SID (B::100) for TE link B-C. For tunnel T2, the transit nodes provide the same SRv6 End.X SIDs because all TE links (A-B, B-C, C-D, and D-E) are common between the two tunnels. The ingress LER A constructs the complete SRH for both T1 and T2 by combining the TE path SIDs signaled via RSVP-TE with the service SID (E::46, obtained out-of-band, e.g., via BGP): Segment List: The outer IPv6 header has: SA = A (source address of the ingress) DA = B::100 (first SID) The SRH contains: Segment List[0] = E::46 (service SID, bottom of list) Segment List[1] = D::100 (last TE hop) Segment List[2] = C::100 Segment List[3] = B::100 (first SID, top of list) Segments Left = 3 At each transit hop, the End.X behavior decrements Segments Left and updates the IPv6 DA. Unlike MPLS where a transit node swaps or pops a label, the SRH itself remains in the packet. At B: SL = 3 -> 2, DA = C::100, forward on B-C TE link At C: SL = 2 -> 1, DA = D::100, forward on C-D TE link At D: SL = 1 -> 0, DA = E::46, forward on D-E TE link At E, the packet arrives with DA = E::46 and SL = 0. E performs the End.DT46 service behavior (e.g., decapsulates the inner packet and forwards it in the appropriate routing table). Beeram, et al. Expires 6 January 2027 [Page 9] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 5. Signaling Extensions This section describes the RSVP signaling extensions required to establish SRv6 RSVP-TE tunnels. 5.1. Generalized Label Request The Generalized Label Request object [RFC3471] is carried in the RSVP Path message to indicate the type of forwarding plane requested for the tunnel. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To request an SRv6 forwarding plane for the RSVP-TE tunnel, the Generalized Label Request carries the following: 1. The LSP Encoding Type is set to Packet (1). 2. The Switching Type is set to "SRv6-Segment" (TBD1). This new switching type indicates that SRv6 SIDs are to be used for forwarding. Each transit node that receives a Path message with this switching type MUST allocate an SRv6 End.X SID for the outgoing TE link, provide it in the Generalized Label (Section 5.2), and record it in the RRO (Section 5.3). A transit node that does not recognize this switching type MUST reject the Path message per [RFC3471]. A transit node that recognizes this switching type but cannot allocate an End.X SID MUST send a PathErr with error code 'Routing Problem (24)' and error value 'SRv6 SID usage failure (TBD4)'. 3. The Generalized Payload Identifier (G-PID) MAY be set to All (0) or to a specific payload type if known, e.g., IPv4 (0x0800) or IPv6 (0x86DD). 5.2. Generalized Label (Resv) Each transit node provides its SRv6 TE Link SID in the Generalized Label object carried in the Resv message. The Generalized Label object [RFC3471] has the following format: LABEL class = 16, C_Type = 2 Beeram, et al. Expires 6 January 2027 [Page 10] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SID (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRv6 SID (128 bits): The 128-bit SRv6 End.X SID allocated for the downstream TE link. The interpretation of this field is determined by the Switching Type signaled in the Generalized Label Request (Section 5.1). When the Switching Type in the Generalized Label Request is set to SRv6-Segment (TBD1), a node receiving the Generalized Label in the Resv message MUST interpret the Label field as a 128-bit SRv6 SID. 5.3. RRO SRv6 SID Sub-object A new RRO sub-object is defined to record SRv6 SIDs along the path of an SRv6 RSVP-TE tunnel. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SID (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Endpoint Behavior | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD2 (to be assigned by IANA). Length: 24 (octets). Flags: An 8-bit field. The following flags are defined: * 0x01 - Delegation SID: Indicates that the recorded SID is a Delegation SID (End.B6.Encaps or End.B6.Encaps.Red). When this flag is not set, the recorded SID is an SRv6 TE Link SID (End.X). Beeram, et al. Expires 6 January 2027 [Page 11] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 * 0x02 - Micro-SID: Indicates that the recorded SID is a micro- SID [RFC9352]. When set, the ingress MUST apply micro-SID container packing rules during TE path segment-list construction (Section 6). A delegation hop MUST apply the same rules when constructing the sub-segment SRH (Section 7.2). Reserved: MUST be set to zero on transmission and ignored on receipt. SRv6 SID (128 bits): The SRv6 SID recorded at this hop. SRv6 Endpoint Behavior (16 bits): The SRv6 Endpoint Behavior codepoint from the IANA "SRv6 Endpoint Behaviors" registry. This field identifies the specific behavior bound to the SID (e.g., End.X = 5, End.B6.Encaps = 14). The RRO SRv6 SID sub-object is carried in the Resv message to communicate the SRv6 SIDs allocated at each hop back to the ingress LER. A transit node that provides an SRv6 TE Link SID MUST include the RRO SRv6 SID sub-object with the Delegation SID flag (0x01) clear and the SRv6 Endpoint Behavior field set to the appropriate End.X variant (e.g., End.X = 5, End.X with PSP = 6, End.X with PSP and USD = 32). The flavor information enables the ingress to determine PSP support for Reduced SRH (Section 6.2) and USD support for sub-segment decapsulation at delegation boundaries (Section 7.2). A delegation hop that provides a Delegation SID MUST include the RRO SRv6 SID sub-object with the Delegation SID flag (0x01) set and the SRv6 Endpoint Behavior field set to End.B6.Encaps (14) or End.B6.Encaps.Red (27). 5.4. Attribute Flags The following attribute flags are defined for use in the LSP_REQUIRED_ATTRIBUTES object [RFC5420] and/or the HOP_ATTRIBUTES sub-object [RFC7570] as specified in each subsection below. A transit node that recognizes the SRv6-Segment switching type (TBD1) in the Generalized Label Request MUST check for the presence of these flags and process them as specified. 5.4.1. SSI-D Bit Number TBD3: SRv6 Segment-list Imposition - Delegation (SSI-D) Beeram, et al. Expires 6 January 2027 [Page 12] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 Automatic Delegation: The presence of this flag in the LSP_REQUIRED_ATTRIBUTES object of a Path message indicates that the ingress has requested automatic delegation of segment-list imposition. If a transit hop does not support this flag, it MUST reject the Path message per the LSP_REQUIRED_ATTRIBUTES semantics of [RFC5420]. Explicit Delegation: The presence of this flag in the HOP_ATTRIBUTES sub-object [RFC7570] of an ERO in the Path message indicates that the hop identified by the preceding IPv6 sub-object has been picked as an explicit delegation hop. Processing follows the same procedures as Section 9.4 of [RFC8577], adapted for SRv6. 5.4.2. SRv6 uSID Bit Number TBD8: SRv6 uSID The presence of this flag in the LSP_REQUIRED_ATTRIBUTES object of a Path message mandates the use of micro-SID [RFC9352] encoding at all hops. This flag MUST be set in the LSP_REQUIRED_ATTRIBUTES object to ensure that hops that do not support micro-SIDs reject the Path message. A transit hop that cannot allocate a micro-SID End.X SID MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'SRv6 SID usage failure (TBD4)'. 5.5. Constraining SRv6 SID Selection via ERO A node MAY have multiple SRv6 End.X SIDs allocated for the same TE link (e.g., one for unprotected forwarding and one for link- protected forwarding, or SIDs with different PSP/USP/USD flavors). When the ingress (or a controller computing the path) needs to constrain a transit node to use a specific End.X SID, it MAY include the computed SRv6 SID in the ERO. This is achieved by placing an ERO SRv6 SID sub-object following the hop-identifying sub-object (IPv6 prefix or Unnumbered Interface ID) for the corresponding transit hop. The ERO SRv6 SID sub-object has the following format: Beeram, et al. Expires 6 January 2027 [Page 13] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SID (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L: The loose/strict concept does not apply to this sub-object. The L bit MUST be set to 0 and MUST be ignored on receipt. Type: TBD6 (to be assigned by IANA). Length: 20 (octets). Flags: An 8-bit field. The following flags are defined: * 0x01 - Delegation SID: Indicates that the specified SID is a Delegation SID (End.B6.Encaps or End.B6.Encaps.Red). When this flag is not set, the specified SID is an SRv6 TE Link SID (End.X). * 0x02 - Micro-SID: Indicates that the specified SID is a micro- SID [RFC9352]. Reserved: MUST be set to zero on transmission and ignored on receipt. SRv6 SID (128 bits): The desired SRv6 SID that the node should use. When the Delegation SID flag (0x01) is clear, this is an End.X SID for the outgoing TE link. When the Delegation SID flag is set, this is a Binding SID (End.B6.Encaps or End.B6.Encaps.Red) at the delegation hop. When a transit node receives a Path message with the SRv6-Segment switching type (TBD1) and an ERO SRv6 SID sub-object is present for this hop: * If the Delegation SID flag (0x01) is clear, it MUST verify that the SRv6 SID in the ERO sub-object matches one of its locally allocated End.X SIDs for the outgoing TE link. * If the Delegation SID flag (0x01) is set, it MUST verify that the SRv6 SID matches one of its locally allocated Binding SIDs (End.B6.Encaps or End.B6.Encaps.Red). Beeram, et al. Expires 6 January 2027 [Page 14] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 * On match: it MUST use that SID and record it in the RRO SRv6 SID sub-object and the Generalized Label in the Resv message. * On mismatch: it MUST send a PathErr with error code 'Routing Problem (24)' and error value 'SRv6 SID usage failure (TBD4)'. When no ERO SRv6 SID sub-object is present for a transit hop, the node selects a locally allocated SID autonomously. 6. TE Path Segment-List Construction 6.1. Procedures at the Ingress The ingress LER MUST inspect the SRv6 SIDs recorded in the RRO SRv6 SID sub-objects (Section 5.3) of the Resv message and construct the TE path segment list accordingly. The following logic is used by the ingress to build the TE path segment list: 1. Process RRO SRv6 SID sub-objects starting from the first downstream hop toward the egress. 2. For each sub-object with the Delegation SID flag (0x01) clear, add the SRv6 SID to the TE path segment list. This includes transit hop End.X SIDs. 3. For each sub-object with the Delegation SID flag (0x01) set, add the Delegation SID to the TE path segment list. 4. If any RRO SRv6 SID sub-object has the Micro-SID flag (0x02) set, the ingress MUST apply the micro-SID container packing rules defined in [RFC9352]. Consecutive micro-SIDs sharing the same block MUST be packed into 128-bit containers; full- length SIDs each occupy a separate Segment List entry. Unlike MPLS label stack construction in RFC 8577, where a regular (non-TE-link) label causes the next downstream label to NOT be pushed, all SRv6 TE Link SIDs from the RRO MUST be included in the SRH Segment List. This is because SRv6 forwarding uses the SRH Segment List as an ordered array indexed by Segments Left, rather than a push/pop stack. To construct the SRH, the ingress appends the service SID (e.g., End.DT46, End.DT4, End.DX6) to the TE path segment list. The service SID specifies the egress processing behavior and is obtained via mechanisms outside the scope of this document (e.g., BGP signaling, controller provisioning, or local configuration). The ingress then Beeram, et al. Expires 6 January 2027 [Page 15] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 sets the IPv6 Destination Address of the outer header to the first SID in the resulting Segment List and sets the Segments Left field to (number of SIDs in the Segment List - 1). 6.2. Reduced SRH When the penultimate transit node supports the PSP (Penultimate Segment Pop) flavor of End.X [RFC8986], the ingress MAY use a PSP- flavored End.X SID for the penultimate hop. This instructs the penultimate node to remove the SRH from the packet before forwarding, reducing overhead at the egress. The ingress determines PSP support by examining the SRv6 Endpoint Behavior field in the RRO SRv6 SID sub-object from the penultimate hop. If the behavior indicates an End.X with PSP variant (e.g., codepoint 6 or 8), the ingress MAY use the PSP-flavored SID. The SRH MAY be omitted entirely (H.Encaps.Red) when the Segment List contains only one SID, as described in [RFC8986]. 6.3. SID Validation Before switching data traffic onto an SRv6 RSVP-TE tunnel, the ingress LER (or delegation hop) MUST validate the SRv6 SIDs recorded in the RRO to ensure that the constructed SRH will correctly forward packets along the intended path. The following validation checks MUST be performed: 1. ERO/RRO Cross-Validation: The ingress MUST verify that the sequence of SRv6 SIDs recorded in the RRO SRv6 SID sub-objects corresponds to the hops specified in the EXPLICIT_ROUTE object. Specifically, for each transit hop identified in the ERO, there MUST be a corresponding RRO SRv6 SID sub-object. If a mismatch is detected, the ingress MUST treat the tunnel as failed and MAY initiate re-signaling. 2. Path Continuity: The ingress MUST verify that the recorded SRv6 SIDs form a contiguous forwarding path from the ingress to the egress (or to the next delegation hop). Each SRv6 TE Link SID in the sequence MUST correspond to a TE link that connects the node advertising the SID to the next hop in the path. 3. MTU Validation: Beeram, et al. Expires 6 January 2027 [Page 16] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 The ingress MUST verify that the total size of the SRv6 encapsulation -- comprising the outer IPv6 header (40 bytes), the SRH fixed header (8 bytes), and the Segment List (16 bytes per SID) -- does not cause the encapsulated packet to exceed the Path MTU. If the SRH size exceeds the MTU budget, the ingress MUST either invoke the delegation mechanism (Section 7) to split the segment list across multiple encapsulations, or reject the tunnel setup. 4. Endpoint Behavior Validation: The ingress MUST examine the SRv6 Endpoint Behavior codepoint in each RRO SRv6 SID sub-object and verify that: a. Transit hops have recorded an End.X variant (e.g., codepoints 5-8, 32-35) appropriate for TE link forwarding. b. Delegation hops (if any) have recorded an End.B6.Encaps or End.B6.Encaps.Red variant (codepoints 14 or 27). c. The behaviors are consistent with the tunnel's protection requirements (e.g., PSP-flavored SIDs at the penultimate hop if reduced SRH is desired). d. If the SRv6 uSID attribute flag (Section 5.4.2) was set in the LSP_REQUIRED_ATTRIBUTES, the ingress MUST verify that all RRO SRv6 SID sub-objects from transit hops have the Micro-SID flag (0x02) set. If an unexpected behavior is recorded, the ingress SHOULD log the event and MAY reject the tunnel setup. A delegation hop performing sub-segment re-encapsulation (Section 7.2) MUST apply the same validation checks to the portion of the RRO that it is responsible for. If a delegation hop fails to construct or impose the SRH for its sub-segment, it MUST send a ResvErr message with an error code of 'Routing Problem (24)' and an error value of 'SRv6 segment list imposition failure (TBD5)'. 7. Delegation with SRv6 Binding SIDs Beeram, et al. Expires 6 January 2027 [Page 17] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 7.1. Overview The delegation mechanism of RFC 8577 addresses the scenario where the ingress cannot impose the full label stack because of platform limitations. In SRv6, this constraint is even more significant because each SID in the SRH is 128 bits (16 bytes), compared to 4 bytes per MPLS label. A 10-hop path requires 160 bytes of SRH versus 40 bytes of MPLS label stack. In SRv6, delegation is achieved using Binding SIDs. A delegation hop allocates an SRv6 Binding SID (End.B6.Encaps or End.B6.Encaps.Red) that represents a sub-segment-list covering the downstream portion of the path. When a packet arrives at the delegation hop with the Delegation SID as the active SID, the node: 1. Performs the End.B6.Encaps behavior: pushes a new outer IPv6 header with its own SRH containing the sub-segment-list. 2. Sets the outer IPv6 DA to the first SID of the sub-segment-list. 3. Forwards the re-encapsulated packet. This is conceptually similar to the delegation label in RFC 8577, but the mechanism involves IPv6 re-encapsulation rather than MPLS label push. An important architectural constraint arises from the End.B6.Encaps pseudocode in Section 4.13 of [RFC8986]: the encapsulation action (steps S15-S19) is only reached when Segments Left > 0. When Segments Left equals zero, End.B6.Encaps stops processing the SRH (steps S02-S03) without performing encapsulation. This means a Delegation SID (End.B6.Encaps) MUST NOT be the last SID in the segment list. 7.2. Sub-segment Re-encapsulation The segment list imposed by the ingress contains Delegation SIDs interspersed with TE Link SIDs. The sub-segment-list represented by a Delegation SID does NOT include the next delegation hop's Delegation SID. Example with the following topology: Beeram, et al. Expires 6 January 2027 [Page 18] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 +---+ +---+ +---+ +---+ +---+ +---+ | A |------| B |------| C |------| D |------| E |------| F | +---+ +---+ +---+ +---+ +---+ +---+ | | D_SID1 | +---+ +---+ +---+ +---+ +---+ +---+ | L |------| K |------| J |------| I |------| H |------| G | +---+ +---+ +---+ +---+ +---+ +---+ | D_SID2 Figure 2: Delegation with SRv6 Binding SIDs Where D_SID1 is the Delegation SID at D and D_SID2 is the Delegation SID at I. End.X SIDs follow the same naming convention as Figure 1: each node X allocates X::100 for its downstream TE link. The ingress A imposes: SRH: DA = B::100, SL = 4 At node D, the End.B6.Encaps behavior is triggered for D_SID1 (SL = 2 > 0, so encapsulation proceeds per [RFC8986]): S13: SL is decremented (2 -> 1) S14: Inner DA is updated to D_SID2 S15: New outer IPv6 header + SRH is pushed New outer SRH: New outer DA = E::100, SL = 3 Inner packet: DA = D_SID2, SL = 1 At node I, the End.B6.Encaps behavior is triggered for D_SID2 (inner SL = 1 > 0, so encapsulation proceeds): S13: SL is decremented (1 -> 0) S14: Inner DA is updated to K::100 S15: New outer IPv6 header + SRH is pushed New outer SRH: New outer DA = J::100, SL = 0 Inner packet: DA = K::100, SL = 0 At node K, the packet arrives with DA = K::100 and SL = 0. K forwards the packet on the K-L TE link. At the egress L, the packet is decapsulated per normal SRv6 processing. Note: This example omits the service SID at the egress for brevity. In practice, the ingress would also append a service SID (e.g., L::46 for End.DT46) to the segment list, as described in Section 6. Beeram, et al. Expires 6 January 2027 [Page 19] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 Note that each Delegation SID has SL > 0 when processed, which is consistent with the End.B6.Encaps pseudocode in [RFC8986]. Delegation SIDs can be shared among all LSPs traversing the segment between two delegation hops, regardless of the egress. Note that the sub-segment SRHs pushed by delegation hops (e.g., ) follow the standard SRv6 forwarding model: the last End.X SID in each sub-segment has Segments Left = 0 when the packet arrives at that node. This is handled by using the PSP flavor at the penultimate hop of each sub-segment (which removes the outer SRH before the last hop), or alternatively by using the USD flavor at the ultimate hop (which decapsulates the outer IPv6 header when SL = 0). Delegation hops constructing sub-segment SRHs SHOULD use PSP-flavored End.X SIDs at the penultimate hop of the sub-segment to ensure clean removal of the outer SRH before the inner packet is exposed. 7.3. Effective SRv6 Segment-List Depth (ESLD) The ESLD mechanism is the SRv6 equivalent of the ETLD defined in Section 5.3.1 of [RFC8577]. It is used for automatic delegation. The ESLD is signaled as a per-hop recorded attribute (Type TBD7) in the Path message using the HOP_ATTRIBUTES sub-object [RFC7570]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | ESLD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESLD (8 bits): The effective number of SRv6 SIDs that this hop can potentially include in an SRH sent to its downstream hop. MUST be set to a non-zero value. The procedures for populating and processing the ESLD follow the same logic as the ETLD in Section 5.3.1 of [RFC8577], with adaptations for the SRv6 data plane. In MPLS, the ETLD is typically constrained by platform label-stack depth limits. In SRv6, the primary constraint is MTU: each SRv6 SID consumes 16 bytes in the SRH (versus 4 bytes per MPLS label), and the SRH must fit within the path MTU along with the outer IPv6 header (40 bytes), SRH fixed header (8 bytes), and the inner payload. Each node computes its ESLD based on the maximum number of 128-bit Segment List entries that can be accommodated on its outgoing TE link, considering both MTU constraints and any platform-imposed SRH depth limits. Beeram, et al. Expires 6 January 2027 [Page 20] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 The following principles govern the use of ESLD: * The delegation decision is made during Resv processing at the ingress LER (or at a previous delegation hop), when the RRO contains the actual SRv6 SIDs and the ESLD values from all nodes along the path are available. * The minimum ESLD among all nodes on a sub-path (from the ingress or previous delegation hop to the next delegation hop or egress) is the binding constraint. The SRH imposed at the head of the sub-path must be forwardable by all intermediate nodes. * The ingress MUST account for the service SID (e.g., End.DT46, End.DT4) when determining the required segment-list depth. The service SID is appended to the TE path segment list (Section 6) but is not signaled via RSVP-TE; it consumes one additional Segment List entry. * At each delegation hop, the ESLD is reset based on the node's capability to impose a new outer IPv6 header and SRH. The inner packet size (including the existing encapsulation from the previous imposition point) reduces the available MTU budget for the new SRH. * When facility backup protection is active, the ESLD MUST account for the additional encapsulation overhead of the bypass tunnel at protected hops. * When micro-SID encoding (Appendix A.4) is in use, the ESLD counts 128-bit Segment List entries (containers), not individual micro- SIDs. Micro-SID packing can significantly increase the effective hop capacity per container. Appendix A provides a detailed reference procedure for computing the ESLD and making delegation placement decisions. 8. Protection 8.1. Link Protection When the "local protection desired" flag [RFC4090] is set in the SESSION_ATTRIBUTE object, each transit node MUST use a link- protected SRv6 End.X SID for the outgoing TE link, if one is available. This is analogous to the use of protected TE link labels in [RFC8577]. Beeram, et al. Expires 6 January 2027 [Page 21] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 A node MAY allocate separate End.X SIDs for protected and unprotected forwarding on the same TE link. The link-protected End.X SID is associated with a pre-established bypass tunnel to the merge point (next-hop). The bypass tunnel may itself be an SRv6 path (using H.Encaps encapsulation). When the protected TE link fails, the PLR performs the following: 1. Receives the packet with the link-protected End.X SID as the active segment. 2. Instead of forwarding on the failed TE link, it encapsulates the packet in a new outer IPv6 header (+SRH if needed) directed toward the merge point via the bypass path. 3. At the merge point, the outer IPv6 header is removed, and the packet continues with the original SRH intact. Since the SRH of the protected LSP is preserved through the bypass tunnel, the merge point can continue processing the packet as if it arrived on the protected TE link. Node protection and non-signaled backup paths are outside the scope of this document. 9. OAM Considerations SRv6 OAM mechanisms based on ICMPv6 are applicable for SRv6 RSVP-TE tunnels. The SRH in the OAM probe packets can be constructed using the same procedures as data packets (Section 6). When delegation hops are present, the segment list imposed at each delegation hop can be discovered through traceroute-style probing, where each delegation hop reports the sub-segment-list it imposes. The specific OAM procedures and any necessary extensions will be described in a future revision of this document. 10. IANA Considerations 10.1. SRv6 Switching Types IANA maintains the "Switching Types" registry under the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry. This document requests the allocation of a new Switching Type: Beeram, et al. Expires 6 January 2027 [Page 22] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 Value Description Reference ----- ----------- --------- TBD1 SRv6-Segment [This document], Section 5.1 10.2. Attribute Flags IANA maintains the 'Attribute Flags' subregistry under the 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' registry. This document requests the allocation of two new Attribute Flags: Bit Name Attribute Attribute RRO ERO Reference No Flags Path Flags Resv TBD3 SSI-D Yes No No Yes [This doc], Section 5.4.1 TBD8 SRv6 uSID Yes No No No [This doc], Section 5.4.2 10.3. RRO Sub-object Types IANA maintains the "Record Route Object Sub-object Types" registry under the "Resource Reservation Protocol (RSVP) Parameters" registry. This document requests the allocation of a new sub- object type: Value Description Reference ----- ----------- --------- TBD2 SRv6 SID Sub-object [This document], Section 5.3 10.4. ERO Sub-object Types IANA maintains the "Explicit Route Object Sub-object Types" registry under the "Resource Reservation Protocol (RSVP) Parameters" registry. This document requests the allocation of a new sub- object type: Value Description Reference ----- ----------- --------- TBD6 SRv6 SID Sub-object [This document], Section 5.5 10.5. RRO SRv6 SID Sub-object Flags IANA is requested to create a new subregistry called "RRO SRv6 SID Sub-object Flags" under the "Resource Reservation Protocol (RSVP) Parameters" registry with the following initial values: Beeram, et al. Expires 6 January 2027 [Page 23] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 Flag Name Reference ---- ----------- --------- 0x01 Delegation SID [This document], Section 5.3 0x02 Micro-SID [This document], Section 5.3 10.6. ERO SRv6 SID Sub-object Flags IANA is requested to create a new subregistry called "ERO SRv6 SID Sub-object Flags" under the "Resource Reservation Protocol (RSVP) Parameters" registry with the following initial values: Flag Name Reference ---- ----------- --------- 0x01 Delegation SID [This document], Section 5.5 0x02 Micro-SID [This document], Section 5.5 10.7. Attribute TLVs IANA maintains the "Attribute TLV Space" registry under the 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' registry. This document requests the allocation of the following Attribute TLVs: Type Name Allowed on Allowed on Reference LSP_ATTRIBUTES LSP Hop Attributes TBD7 ESLD No Yes [This doc], Sec 7.3 10.8. Error Codes and Error Values IANA maintains the "Error Codes and Globally-Defined Error Value Sub- Codes" subregistry under the "Resource Reservation Protocol (RSVP) Parameters" registry. This document requests allocation of new error values under the "Routing Problem" Error Code (24): Value Description Reference ----- ----------- --------- TBD4 SRv6 SID usage failure [This document], Sections 5.1, 5.5 TBD5 SRv6 segment list imposition [This document], failure Section 6.3 Beeram, et al. Expires 6 January 2027 [Page 24] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 11. Security Considerations This document does not introduce fundamentally new security issues beyond those described in the base RSVP protocol [RFC2205], RSVP-TE [RFC3209], RFC 8577 [RFC8577], and the SRv6 security considerations in [RFC8402], [RFC8754], and [RFC8986]. The SRv6 SIDs carried in RSVP signaling messages (Generalized Label, RRO sub-objects) are 128-bit IPv6 addresses. The same considerations that apply to the protection of SRv6 SIDs in the data plane (Section 5 of [RFC8754]) and control plane also apply when these SIDs are exchanged via RSVP signaling. Operators SHOULD ensure that RSVP signaling messages carrying SRv6 SID information are protected using the authentication mechanisms defined in [RFC2747] (RSVP Cryptographic Authentication) or other applicable mechanisms. The SRv6 domain security model described in Section 5 of [RFC8754] MUST be applied. SRv6 SIDs allocated for RSVP-TE tunnels MUST be within the operator's SRv6 domain, and appropriate filtering MUST be applied at domain boundaries to prevent unauthorized use of these SIDs. 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, . [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, . [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 25] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, 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, . [RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, July 2015, . [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, . [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, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [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, . Beeram, et al. Expires 6 January 2027 [Page 26] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, February 2023, . 13.2. Informative References [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, . [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, . [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and T. Saad, "Techniques to Improve the Scalability of RSVP-TE Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, . Appendix A. ESLD Computation and Delegation Procedure This appendix provides a reference procedure for computing the ESLD and determining delegation hop placement. Implementations MAY use alternative approaches that achieve equivalent results. A.1. Computing the ESLD A node computes its ESLD as follows: ESLD = floor((Link_MTU - Tunnel_MTU - 40 - 8) / 16) Where: * Link_MTU: The MTU of the outgoing TE link. * Tunnel_MTU: The configured tunnel interface MTU (the maximum inner packet size the tunnel can carry). * 40: The outer IPv6 header size (bytes). * 8: The SRH fixed header size (bytes), comprising Next Header, Hdr Ext Len, Routing Type, Segments Left, Last Entry, Flags, and Tag fields. * 16: The per-SID overhead (bytes) for each 128-bit Segment List entry. Beeram, et al. Expires 6 January 2027 [Page 27] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 If the node has a platform-imposed limit on SRH depth (e.g., hardware can only process N Segment List entries), the ESLD MUST be set to the lesser of the MTU-derived value and the platform limit. Example 1: Link MTU = 9000, Tunnel MTU = 1500 ESLD = floor((9000 - 1500 - 40 - 8) / 16) = 465 Capped at 255 (8-bit field maximum). Example 2: Link MTU = 1500, Tunnel MTU = 1400 ESLD = floor((1500 - 1400 - 40 - 8) / 16) = 3 When facility backup protection is active at a node, the bypass tunnel adds encapsulation overhead (at minimum an outer IPv6 header of 40 bytes, plus an SRH if the bypass path has multiple hops). The ESLD at a protected hop SHOULD be computed using an effective Link_MTU reduced by the bypass tunnel overhead. A.2. Delegation Decision Procedure During Resv processing, the ingress LER (or previous delegation hop) determines whether delegation is needed using the following procedure: 1. Compute the required segment-list depth (D_required): a. Count the number of 128-bit Segment List entries needed to encode the TE path SIDs from the RRO. For full-length SIDs, each SID consumes one entry. b. If micro-SIDs are present (Micro-SID flag 0x02 set in the RRO SRv6 SID sub-objects), apply the micro-SID container packing rules of [RFC9352]: consecutive micro-SIDs sharing the same block are packed into shared 128-bit containers; full-length SIDs and micro-SIDs from different blocks each occupy a separate entry. c. Add one entry for the service SID (e.g., End.DT46) that the ingress will append to the segment list. 2. Determine the minimum ESLD (ESLD_min) among all nodes on the sub- path from this imposition point to the egress (or to the next delegation hop, if delegation has already been determined for downstream sub-paths). 3. If D_required <= ESLD_min, no delegation is needed. The imposition point can encode the full segment list. Beeram, et al. Expires 6 January 2027 [Page 28] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 4. If D_required > ESLD_min, delegation is needed. Select a delegation hop such that: a. The segment list from this imposition point to the delegation hop (including the Delegation SID) fits within ESLD_min for that sub-path. b. The delegation hop has sufficient ESLD capacity to encode the remaining downstream segment list (or to delegate further). c. The Delegation SID is NOT the last SID in the segment list at the imposition point (per the End.B6.Encaps constraint in Section 7). A.3. ESLD Reset at Delegation Hops When a delegation hop performs sub-segment re-encapsulation (Section 7.2), it pushes a new outer IPv6 header and SRH. The inner packet (including its existing IPv6 header and SRH) becomes the payload of the new encapsulation. The delegation hop computes its ESLD for the downstream sub-segment as: ESLD_deleg = floor((Link_MTU - Inner_Pkt_Size - 40 - 8) / 16) Where Inner_Pkt_Size is the expected maximum size of the packet arriving at the delegation hop, including the outer IPv6 header and remaining SRH from the previous imposition point, plus the inner payload up to the Tunnel MTU. In practice, the delegation hop can estimate the Inner_Pkt_Size from: * The Tunnel MTU (inner payload limit). * The SRH size from the previous imposition point: the number of remaining Segment List entries multiplied by 16, plus the SRH fixed header (8 bytes) and outer IPv6 header (40 bytes). A.4. Micro-SID Interaction When micro-SID encoding is in use, the ESLD counts 128-bit Segment List entries (containers), not individual micro-SIDs. Each container can hold multiple micro-SIDs (e.g., up to six 16-bit micro-SIDs per container). The effective hop capacity depends on the mix of SID types along the downstream path: Beeram, et al. Expires 6 January 2027 [Page 29] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 * All full-length SIDs: each SID consumes one container. Effective capacity = ESLD hops. * All micro-SIDs from the same block: up to P micro-SIDs per container (where P is the packing ratio, e.g., 6 for 16-bit micro- SIDs). Effective capacity = ESLD x P hops. * Mixed: full-length SIDs and micro-SIDs from different blocks each consume a separate container; consecutive micro-SIDs from the same block share containers. Effective capacity falls between ESLD and ESLD x P, depending on the path composition. The ingress or delegation hop determines the actual container count from the RRO during Resv processing, using the Micro-SID flag (0x02) in each RRO SRv6 SID sub-object to identify which SIDs can be packed. 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 Vishnu Pavan Beeram HPE Email: vishnupavan.ietf@gmail.com Beeram, et al. Expires 6 January 2027 [Page 30] Internet-Draft RSVP-TE with SRv6 End.X SIDs July 2026 Colby Barth HPE Email: jonathan.barth@hpe.com Andrew Smith Arrcus, Inc. Email: andy@arrcus.com Beeram, et al. Expires 6 January 2027 [Page 31]