TEAS V. P. Beeram Internet-Draft C. Barth Intended status: Standards Track HPE Expires: 6 May 2027 A. Smith Arrcus, Inc. S. Maduschke Verizon 2 November 2026 Signaling RSVP-TE Tunnels on an SRv6 Forwarding Plane Using End.X Segment Identifiers draft-beeram-teas-rsvp-srv6-01 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 that are advertised in the IGP serve as TE link SIDs, defines new RSVP signaling extensions for carrying SRv6 SIDs and for influencing the endpoint behavior flavors of the SIDs, describes TE path segment-list construction procedures at the ingress (including NEXT-CSID compressed segment lists), adapts the delegation mechanisms of RFC 8577 to use SRv6 Binding SIDs, and describes the termination of the tunnel at the egress. 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." Beeram, et al. Expires 6 May 2027 [Page 1] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 This Internet-Draft will expire on 6 May 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Acronyms and Definitions . . . . . . . . . . . . . . . . 5 3. SRv6 TE Link SIDs . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Allocation and IGP Advertisement . . . . . . . . . . . . 6 3.2. Forwarding Behavior . . . . . . . . . . . . . . . . . . . 7 3.3. Sharing and Bandwidth Admission Control . . . . . . . . . 8 3.4. Compressed SID Considerations . . . . . . . . . . . . . . 8 3.5. SID Persistence . . . . . . . . . . . . . . . . . . . . . 10 3.6. Per-Link SIDs . . . . . . . . . . . . . . . . . . . . . . 10 3.7. SID Selection . . . . . . . . . . . . . . . . . . . . . . 11 4. Tunnel Setup . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Signaling Overview . . . . . . . . . . . . . . . . . . . 11 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Egress Modes . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Baseline Implementation and Optional Extensions . . . . . 15 5. Signaling Extensions . . . . . . . . . . . . . . . . . . . . 16 5.1. Generalized Label Request . . . . . . . . . . . . . . . . 16 5.2. Generalized Label (Resv) . . . . . . . . . . . . . . . . 17 5.3. RRO SRv6 SID Sub-object . . . . . . . . . . . . . . . . . 18 5.4. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 20 5.4.1. SSI-D . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4.2. SRv6 NEXT-CSID . . . . . . . . . . . . . . . . . . . 20 5.4.3. SRv6 PSP and SRv6 USD . . . . . . . . . . . . . . . . 21 5.4.4. SRv6 Egress SID . . . . . . . . . . . . . . . . . . . 22 5.5. Constraining SRv6 SID Selection via ERO . . . . . . . . . 23 6. TE Path Segment-List Construction . . . . . . . . . . . . . . 25 6.1. Procedures at the Ingress . . . . . . . . . . . . . . . . 25 6.2. Reduced SRH . . . . . . . . . . . . . . . . . . . . . . . 27 Beeram, et al. Expires 6 May 2027 [Page 2] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 6.3. SID Validation . . . . . . . . . . . . . . . . . . . . . 28 6.4. First-Hop Steering . . . . . . . . . . . . . . . . . . . 31 7. Delegation with SRv6 Binding SIDs . . . . . . . . . . . . . . 31 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 31 7.2. Sub-segment Re-encapsulation . . . . . . . . . . . . . . 32 7.3. Effective SRv6 Segment-List Depth (ESLD) . . . . . . . . 34 8. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. Scope and Architecture . . . . . . . . . . . . . . . . . 36 8.2. RSVP-TE-Signaled Facility Backup for Protected End.X SIDs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.3. TI-LFA Link Protection . . . . . . . . . . . . . . . . . 37 9. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 38 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 10.1. SRv6 Switching Types . . . . . . . . . . . . . . . . . . 38 10.2. Attribute Flags . . . . . . . . . . . . . . . . . . . . 38 10.3. RRO Sub-object Types . . . . . . . . . . . . . . . . . . 39 10.4. ERO Sub-object Types . . . . . . . . . . . . . . . . . . 39 10.5. RRO SRv6 SID Sub-object Flags . . . . . . . . . . . . . 39 10.6. ERO SRv6 SID Sub-object Flags . . . . . . . . . . . . . 40 10.7. Attribute TLVs . . . . . . . . . . . . . . . . . . . . . 40 10.8. Error Codes and Error Values . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 13.1. Normative References . . . . . . . . . . . . . . . . . . 41 13.2. Informative References . . . . . . . . . . . . . . . . . 43 Appendix A. ESLD Computation and Delegation Procedure . . . . . 44 A.1. Computing the ESLD . . . . . . . . . . . . . . . . . . . 45 A.2. Delegation Decision Procedure . . . . . . . . . . . . . . 46 A.3. ESLD Reset at Delegation Hops . . . . . . . . . . . . . . 47 A.4. Compressed SID Interaction . . . . . . . . . . . . . . . 47 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 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 Beeram, et al. Expires 6 May 2027 [Page 3] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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. SRv6 can steer traffic along an explicit path using a segment list selected at the headend, but it has no mechanism for the network to admit and reserve resources for that path, or to share the work of imposing a long segment list without a controller. A signaling plane provides both. RSVP-TE gives hop-by-hop bandwidth admission control, priorities and preemption for LSPs that share the same End.X SIDs, so no per-LSP forwarding state is needed. Hops along the path can be selected automatically as delegation hops, based on the segment-list depth they signal, so that a long segment list can be imposed without a controller instantiating Binding SIDs. RSVP-TE also provides coordinated link protection, with the PLR reporting whether protection is in place. In addition, each hop reports the SID it actually selected, which lets the ingress build and verify the segment list, and the ingress can state requirements on the SIDs (such as compressed SIDs, PSP and USD flavors, and how the tunnel terminates at the egress) without knowing the SIDs in advance. As a result, operators can use the RSVP-TE feature set, including bandwidth admission control, LSP priorities, preemption, and auto- bandwidth, together with the native IPv6 forwarding of SRv6. This document extends the work of RFC 8577 to the SRv6 data plane. It defines: * How SRv6 End.X SIDs that are advertised in the IGP 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. * 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 models for RSVP-TE tunnels over the SRv6 forwarding plane (Section 8). * 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. Beeram, et al. Expires 6 May 2027 [Page 4] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 * Attribute flags that let the ingress mandate the endpoint behavior flavors (PSP, USD) of the SIDs used along the path and select how the tunnel terminates at the egress. * Support for compressed SRv6 segment lists using the NEXT-CSID flavor [RFC9800], enabling reduced SRH overhead. Other compression flavors (e.g., REPLACE-CSID) are outside the scope of this document. This revision of the document specifies SRv6 RSVP-TE tunnels over point-to-point TE links, with an ERO in which every transit hop is a strict hop. The following are outside its scope: Point-to-Multipoint (P2MP) RSVP-TE tunnels; LAN adjacencies (Section 3.6); loose hops (Section 4.1); and node protection (Section 8.1). The SR-MPLS counterpart of this document is [I-D.beeram-mpls-rsvp-sr]. 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], [RFC4090], [RFC8402], [RFC8754], [RFC8986], [RFC8577], and [RFC9800]. SRv6 TE Link SID: An SRv6 End.X SID allocated at a node for a specific TE link and advertised in the IGP. 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. NEXT-CSID, CSID, CSID container, SID Structure: As defined in [RFC9800] and [RFC9352]. Compressed SID: A SID whose Endpoint Behavior is a NEXT-CSID flavor (Section 3.4). Beeram, et al. Expires 6 May 2027 [Page 5] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 PLR, merge point: As defined in [RFC4090]. 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 Segment List entries (full-length SIDs or CSID containers) 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 and IGP Advertisement 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. The SRv6 TE Link SID MUST be an End.X SID that is advertised in the IGP for the corresponding adjacency, using the SRv6 extensions of IS- IS [RFC9352] or OSPFv3 [RFC9513]. A node MUST NOT use an End.X SID as a TE Link SID for an SRv6 RSVP-TE tunnel unless it is so advertised. This document defines no new IGP extensions for this purpose. Mandating IGP advertisement has the following consequences: * Every SID used in the SRH is routable and verifiable against the IGP link-state database. * The ingress validation procedures (Section 6.3) use the IGP to confirm that each SID belongs to the correct node and adjacency and has the expected Endpoint Behavior. * If a node fails, its IGP advertisements are withdrawn, and the neighbors detect the failure through the usual RSVP-TE mechanisms (IGP adjacency loss, RSVP Hello or refresh timeout) and report it Beeram, et al. Expires 6 May 2027 [Page 6] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 toward the ingress, which tears down or re-signals the LSP. SID validation at setup ensures that every SID belongs to the intended node and adjacency, and the unicast-locator requirement below prevents the SID of a failed node from being reachable through another node. The locator from which a SRv6 TE Link SID is allocated MUST be a unicast locator that is advertised by exactly one node; anycast locators MUST NOT be used. In addition, if a SID Structure [RFC9352] is advertised for the SID, its Locator Node length MUST be non-zero, so that the SID identifies a single node. This requirement is stricter than the validity conditions of [RFC9800], and is intended to prevent mis-routing when the SID of a failed node would otherwise be reachable via another node. The procedures in this document assume that the ingress (or a controller computing the path) has the link-state information (the TED) for all hops of the LSP, so that the SIDs can be verified against the IGP (Section 6.3). The TED may be populated from the IGP, or from BGP-LS [RFC9514] for hops in other domains. Paths that contain hops for which the ingress or controller has no link-state information are outside the scope of this document. 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, for example SIDs with different flavors (Section 5.4.3), compressed and full-length SIDs (Section 3.4), or SIDs that are eligible for 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. 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. Beeram, et al. Expires 6 May 2027 [Page 7] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 * 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 and Bandwidth Admission Control 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 that have the same SID requirements (Section 3.7). * 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. Bandwidth admission control operates per standard RSVP-TE procedures. Each transit node maintains per-link bandwidth accounting, performs admission control on LSP setup and bandwidth modification requests, and advertises available bandwidth via the IGP. Because the SRv6 TE Link SID is shared, a transit node enforces bandwidth in the control plane only and cannot police per LSP. The ingress imposes the encapsulation per tunnel, and MAY meter and police the traffic of each LSP. 3.4. Compressed SID Considerations This document supports compressed SRv6 segment lists that use the NEXT-CSID flavor of [RFC9800]. A CSID container is a 128-bit value that holds the Locator-Block common to its CSIDs, a first CSID, and further CSIDs in its Argument bits. A CSID is the Locator-Node and Function portion of a SID. Consequently an End.X hop consumes one CSID. If all CSIDs have the same length LNFL, a container holds 1 + floor(AL / LNFL) CSIDs, where AL = 128 - LBL - LNL - FL is the Argument length of the SID Structure. For example, with a 32-bit Locator-Block and 16-bit CSIDs, a container holds six CSIDs. Beeram, et al. Expires 6 May 2027 [Page 8] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 The use of compressed SIDs is applicable to SRv6 RSVP-TE tunnels and offers the following advantages in this context: * Reduced SRH overhead: A path of N hops that would require N x 16 bytes with full SIDs may require significantly fewer bytes with compressed SIDs. When the entire segment list fits in a single container, no SRH is needed (Section 6.1), and the overhead approaches 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 compressed 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 compressed SIDs or full-length SIDs are in use. 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. A compact encoding of compressed SIDs in these objects is a possible future optimization and is outside the scope of this document. A SID is a compressed SID if and only if its Endpoint Behavior (Section 5.3) is one of the following NEXT-CSID codepoints of the IANA "SRv6 Endpoint Behaviors" registry: End.X with NEXT-CSID and its PSP, USP and USD flavor combinations (52 through 59), End with NEXT- CSID and its flavor combinations (43 through 50), End.B6.Encaps with NEXT-CSID (93) and End.B6.Encaps.Red with NEXT-CSID (94). No other field of the signaling carries this information. The list is closed on purpose: it covers only the NEXT-CSID flavor that this document supports. The flavor tests for PSP, USP and USD elsewhere in this document are made on the flavors of the registry entry, not on a list. If the ingress does not mandate compressed SIDs (Section 5.4.2), a transit node that has both a compressed and a full-length End.X SID for the outgoing TE link, and is not constrained by the ERO (Section 5.5), selects between them according to local policy. Operators are RECOMMENDED to configure a preference for compressed SIDs in a network whose ingress nodes implement compression. If the ingress desires to mandate the use of compressed SIDs at all hops, it sets the SRv6 NEXT-CSID attribute flag (Section 5.4.2) in the LSP_REQUIRED_ATTRIBUTES object. Hops that cannot provide a compressed End.X SID MUST reject the Path message. Beeram, et al. Expires 6 May 2027 [Page 9] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 The TE path segment-list construction procedures at the ingress (Section 6.1) describe how an ingress that implements compression applies the NEXT-CSID container packing rules of [RFC9800] when the RRO contains compressed SIDs. The ingress obtains the SID Structure of each SID from the IGP (Section 6.3). A SID without a valid SID Structure is not compressible and occupies a Segment List entry of its own. Compression flavors other than NEXT-CSID are not supported by this document. A transit node that implements this document SHOULD NOT return a SID with any other compression flavor in the Generalized Label or the RRO. An ingress or delegation hop MUST treat an RRO SRv6 SID sub-object whose Endpoint Behavior is a compression flavor other than NEXT-CSID as a validation failure (Section 6.3). 3.5. SID Persistence An SRv6 TE Link SID is RECOMMENDED to be persistent, i.e., advertised with the P-flag set in the IS-IS SRv6 End.X SID sub-TLV [RFC9352] or the corresponding OSPFv3 sub-TLV [RFC9513]. Persistence is not required. A persistent SID keeps its value when the adjacency transitions between UP and DOWN and across restarts, and the ingress segment list remains valid across adjacency flaps. When SIDs are not persistent, a node that restarts may allocate new values. RSVP-TE signaling adapts to such changes: the refreshed or re-signaled Resv message carries the new SIDs in the Generalized Label and the RRO, and the ingress updates its segment list accordingly. 3.6. Per-Link SIDs An SRv6 TE Link SID MUST be attached to a single unidirectional adjacency. A unique SID is used for each TE link, even if multiple parallel links exist to the same neighbor, because RSVP-TE needs per- link granularity for bandwidth admission control on individual links, for explicit routing over specific interfaces, and for per-link protection. An End.X SID that is advertised for a set of adjacencies (S-flag set) MUST NOT be used. The TE links of an SRv6 RSVP-TE tunnel are point-to-point adjacencies. LAN adjacencies (broadcast and other multi-access links) are out of scope of this document, and LAN End.X SIDs are not used as SRv6 TE Link SIDs. When the adjacency is realized over a bundle of Layer 2 member links, the TE link is the Layer 3 adjacency, and SIDs advertised for individual Layer 2 members are not applicable. Beeram, et al. Expires 6 May 2027 [Page 10] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 3.7. SID Selection A TE link can have more than one eligible SRv6 TE Link SID, for example SIDs that differ in compression (Section 3.4), in the PSP/USD flavors (Section 5.4.3), or in eligibility for protection (Section 8). The following rules apply: * A transit node MUST select a SID that satisfies the attribute flags (Section 5.4) and the ERO SRv6 SID sub-object (Section 5.5), if any, of the Path message. * Absent such constraints, the transit node selects among its eligible SIDs according to local policy. * The ingress or controller MAY constrain the selection using the ERO SRv6 SID sub-object (Section 5.5). The attribute flags of Section 5.4 constrain the compression and the flavors of the SID without pinning it. A pinned SID that is not persistent (Section 3.5) can become stale after an adjacency flap, and the next Path message that carries it then fails. * Local protection is requested with the existing procedures of [RFC4090], i.e., the "local protection desired" flag of the SESSION_ATTRIBUTE object (Section 8.1). This document adds no attribute flag or other signaling for it. The ingress uses the RRO as the authoritative source for segment-list construction (Section 6.1), so a segment list that was pre-computed from the IGP link-state database (the TED) is replaced by the one built from the RRO if the two differ. The IGP and the TED are used for pre-computation and validation (Section 6.3). 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_IPv4 or 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). The ingress MAY include the attribute flags of Section 5.4 in the LSP_REQUIRED_ATTRIBUTES object to mandate compressed SIDs, the PSP and USD flavors, and an egress SID. Beeram, et al. Expires 6 May 2027 [Page 11] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 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. This document specifies EROs in which each transit hop is a strict hop. The ERO sub-object of a strict hop MUST identify the TE link of that hop, using an IPv4 or IPv6 interface address [RFC3209] or an Unnumbered Interface ID [RFC3477] sub-object; a sub-object that identifies only a node is not sufficient. Procedures for loose hops, where each hop selects the TE link toward the next hop, will be added in a future revision. 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, advertised in the IGP (Section 3.1), for the outgoing TE link that satisfies the attribute flags and the ERO. If an ERO SRv6 SID sub-object (Section 5.5) is present for this hop, the node verifies that the indicated SID and Endpoint Behavior match 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. If the SRv6 Egress SID flag (Section 5.4.4) is set, the egress provides a terminating SID; otherwise it indicates that it provides no SID (Section 4.3). 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 validates the recorded SIDs (Section 6.3) and 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). Beeram, et al. Expires 6 May 2027 [Page 12] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 +---+ +---+ +---+ +---+ +---+ | 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) 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: Beeram, et al. Expires 6 May 2027 [Page 13] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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. Node A forwards the packet over the A-B TE link as required by Section 6.4. 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). This example uses a service SID. Section 4.3 describes the other ways in which a tunnel can terminate at the egress. 4.3. Egress Modes The ingress selects how the tunnel terminates at the egress. The egress is the end of the SRv6 RSVP-TE LSP and has no downstream TE link, so it does not provide an End.X SID. The following modes are defined: 1. Service SID: The ingress appends a service SID (Section 6.1) as the last segment of the segment list and does not set the SRv6 Egress SID flag (Section 5.4.4). The egress processes the service SID. 2. Termination at the last transit hop: The ingress appends no service SID, does not set the SRv6 Egress SID flag, and MUST set the SRv6 USD flag (Section 5.4.3). The segment list ends with the End.X SID of the last transit node. That node, whose End.X SID has the USD flavor, removes the outer IPv6 header and forwards the inner packet to the egress. This is analogous to penultimate hop popping in MPLS. It is achieved with the USD flavor, not with the PSP flavor. 3. Termination at the egress: The ingress sets the SRv6 Egress SID flag. The egress provides a terminating SID in the Resv message, and the segment list ends with this SID. The egress removes the outer IPv6 header and forwards the inner packet. This is analogous to ultimate hop popping in MPLS, and is useful when the Beeram, et al. Expires 6 May 2027 [Page 14] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 egress must observe the outer header, e.g., for QoS, TTL handling or OAM. It is achieved with the USD flavor of the egress End SID. In mode 1 and mode 2 the egress does not provide an SID. It places the unspecified address (::), i.e., all 128 bits set to zero [RFC4291], in the Generalized Label (Section 5.2) and does not add an RRO SRv6 SID sub-object. The ingress determines from the RRO whether the egress provided a terminating SID: an RRO SRv6 SID sub-object recorded by the egress means that it did, and its absence means that it did not. An RRO SRv6 SID sub-object that carries the unspecified address MUST be treated as an error. 4.4. Baseline Implementation and Optional Extensions An implementation that learns the SRv6 SIDs from the RRO and uses none of the optional extensions listed below is a conformant baseline implementation. Baseline implementations interoperate with each other and with implementations of the optional extensions, as described here. The following is mandatory to implement: * All nodes: the SRv6-Segment switching type (TBD1) in the Generalized Label Request, the 128-bit Generalized Label (Section 5.2), the RRO SRv6 SID sub-object (Section 5.3), label recording, and the PathErr 'SRv6 SID usage failure' (TBD4). * Transit node: selecting an End.X SID for the outgoing TE link that is advertised in the IGP (Section 3.1), by local policy (Section 3.7); returning the SID in the Generalized Label, and the SID with its Endpoint Behavior in the RRO; processing ERO hops; and bandwidth admission control. * Egress: placing the unspecified address (::) in the Generalized Label and adding no RRO SRv6 SID sub-object (egress mode 1, Section 4.3). * Ingress: having the link-state information (the TED) for all hops of the LSP; sending an ERO; building the segment list from the RRO SIDs and the service SID (Section 6.1); the validation procedures (Section 6.3); first-hop steering (Section 6.4); and accepting any End.X flavor (any combination of PSP, USP and USD, determined from the IANA registry), including the NEXT-CSID End.X variants, which a transit node may return according to local policy when the SRv6 NEXT-CSID flag is absent. An ingress that does not implement compression places each compressed SID in a Segment List entry of its own (Section 6.1). Beeram, et al. Expires 6 May 2027 [Page 15] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 The following are optional to implement. An ingress uses an extension only toward nodes that support it. The ingress learns this by configuration, or when a node rejects the Path message: * The SRv6 NEXT-CSID, SRv6 PSP, SRv6 USD and SRv6 Egress SID attribute flags (Section 5.4), and egress modes 2 and 3 (Section 4.3). A node that does not implement a flag rejects a Path message that carries it. * The ERO SRv6 SID sub-object (Section 5.5). A node that does not implement it rejects a Path message that carries it, as for any unrecognized ERO sub-object. * Delegation (Section 7): the SSI-D flag, the ESLD attribute TLV, and Delegation SIDs. A baseline ingress that cannot fit the segment list in the MTU rejects the tunnel (Section 6.3). * NEXT-CSID packing at the ingress (Section 6.1) and the use of the PSP flavor for a reduced SRH (Section 6.2). * Protection (Section 8). 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 select an SRv6 End.X SID, advertised in Beeram, et al. Expires 6 May 2027 [Page 16] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 the IGP (Section 3.1), 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 provide a suitable End.X SID MUST send a PathErr with error code 'Routing Problem (24)' and error value 'SRv6 SID usage failure (TBD4)'. The egress behaves as described in Section 4.3. The Switching Type determines that the label is an SRv6 SID, which is a 128-bit IPv6 address. This is independent of the session type and of the IPv4, IPv6 or Unnumbered Interface ID sub-objects that identify the hops in the ERO and the RRO. 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 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 selected for the downstream TE link. At the egress, the field carries the terminating SID if the SRv6 Egress SID flag (Section 5.4.4) was set, and the unspecified address (::), i.e., all 128 bits set to zero [RFC4291], otherwise. 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. The value :: (all 128 bits set to zero) means that the egress provides no SID (Section 4.3). The unspecified address is defined in [RFC4291]; its use here as an indication that no SID is provided is Beeram, et al. Expires 6 May 2027 [Page 17] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 defined by this document. Because the Generalized Label object is required in the Resv message, a value is needed when the egress has no SID to provide. 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 flag is defined: * 0x01 - Delegation SID: Indicates that the recorded SID is a Delegation SID (End.B6.Encaps or End.B6.Encaps.Red, or the NEXT-CSID variants). When this flag is not set, the recorded SID is an SRv6 TE Link SID (End.X) or, at the egress, a terminating SID (Section 5.4.4). All other bits MUST be set to zero on transmission and ignored on receipt. 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 value MUST be the behavior that is bound to the SID at the recording node, and MUST match the behavior advertised for that SID in the IGP. The field is the Beeram, et al. Expires 6 May 2027 [Page 18] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 only indication of whether the SID is a compressed SID (Section 3.4). A receiver determines this from the field alone. A receiver determines the flavors (PSP, USP, USD) of the recorded behavior from the entry of the codepoint in the IANA "SRv6 Endpoint Behaviors" registry, and MUST NOT rely on a fixed list of codepoints. The RRO SRv6 SID sub-object is carried in the Resv message to communicate the SRv6 SIDs selected at each hop back to the ingress LER. A node records it in addition to, and immediately after, the IPv4 or IPv6 address or Unnumbered Interface ID sub-object that it records per [RFC3209] or [RFC3477]; that sub-object identifies the hop to which the SID belongs. When the "label recording desired" flag is set in the SESSION_ATTRIBUTE object, a node that supports the SRv6-Segment switching type records the SRv6 SID sub-object in place of the RRO Label sub-object defined in [RFC3209] and [RFC3473], and MUST NOT also record a Label sub-object for the same SID. A new sub-object is defined because the Label sub-object has no field for the Endpoint Behavior of the SID. 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 USD = 32, End.X with PSP and USD = 33, or the NEXT-CSID variants 52 through 59). 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), End.B6.Encaps.Red (27), or the NEXT-CSID variants (93, 94). It records the Delegation SID in place of the sub-object that would record its End.X SID; it does not also record an End.X SID. The egress includes an RRO SRv6 SID sub-object only if it provides a terminating SID (Section 5.4.4). The cross-validation of the RRO against the ERO and the IGP is described in Section 6.3. Beeram, et al. Expires 6 May 2027 [Page 19] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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 implements a flag processes it as specified. A node that does not implement a flag rejects a Path message that carries it in the LSP_REQUIRED_ATTRIBUTES object, per [RFC5420]. The support of these flags is optional (Section 4.4). 5.4.1. SSI-D Bit Number TBD3: SRv6 Segment-list Imposition - Delegation (SSI-D) 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 ERO 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 NEXT-CSID Bit Number TBD8: SRv6 NEXT-CSID The presence of this flag in the LSP_REQUIRED_ATTRIBUTES object of a Path message mandates that the SID used at each transit hop is a compressed SID (Section 3.4), i.e., a NEXT-CSID flavor SID [RFC9800]. When the flag is absent, a transit node selects the SID according to local policy (Section 3.4), subject to the ERO. A transit node that recognizes this flag processes it as follows: * If the ERO contains no SRv6 SID sub-object for this hop, the node MUST select a compressed End.X SID for the outgoing TE link. A delegation hop that provides a Delegation SID MUST select a NEXT- CSID Binding SID (End.B6.Encaps with NEXT-CSID or End.B6.Encaps.Red with NEXT-CSID). * If the ERO contains an SRv6 SID sub-object for this hop and its Endpoint Behavior is not a compressed-SID codepoint, the node MUST reject the request. Beeram, et al. Expires 6 May 2027 [Page 20] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 * If the node cannot comply, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'SRv6 SID usage failure (TBD4)'. A hop that does not recognize this flag rejects the Path message per [RFC5420]. The flag requires every hop to provide a compressed SID. It does not require that the resulting segment list fit in a single container. 5.4.3. SRv6 PSP and SRv6 USD Bit Number TBD9: SRv6 PSP Bit Number TBD10: SRv6 USD The presence of either flag in the LSP_REQUIRED_ATTRIBUTES object of a Path message mandates that the End.X SID selected at every transit hop includes the corresponding flavor of [RFC8986]: Penultimate Segment Pop (PSP) or Ultimate Segment Decapsulation (USD). When both flags are present, the SID includes both flavors. The flags apply to End.X SIDs only. A delegation hop that provides a Delegation SID (a Binding SID) is not subject to them. A node that does not recognize a flag rejects the Path message per [RFC5420]. A transit node selects an End.X SID whose Endpoint Behavior includes at least the mandated flavors. The minimal Endpoint Behavior, depending on the SRv6 NEXT-CSID flag (Section 5.4.2), is: +=============+===================+=================+ | Flags set | Full-length End.X | NEXT-CSID End.X | +=============+===================+=================+ | none | 5 | 52 | +-------------+-------------------+-----------------+ | PSP | 6 | 53 | +-------------+-------------------+-----------------+ | USD | 32 | 56 | +-------------+-------------------+-----------------+ | PSP and USD | 33 | 57 | +-------------+-------------------+-----------------+ Table 1: Minimal Endpoint Behavior Satisfying the Flavor Flags Beeram, et al. Expires 6 May 2027 [Page 21] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 A SID whose behavior includes additional flavors (e.g., USP) also satisfies the mandate. If an ERO SRv6 SID sub-object pins a SID for a hop (Section 5.5), its Endpoint Behavior MUST include the mandated flavors; otherwise the node MUST reject the request. A node that cannot comply MUST send a PathErr with error code 'Routing Problem (24)' and error value 'SRv6 SID usage failure (TBD4)'. The USD flavor acts only when Segments Left is zero, in the Upper- Layer header processing of the End and End.X behaviors (Section 4.16.3 of [RFC8986]), whether or not an SRH is present. Requesting it at every hop therefore does not change the processing at hops where Segments Left is non-zero. This allows the ingress to request it before it knows where delegation boundaries will be placed. An ingress MUST set the SRv6 USD flag when it sets the SSI-D flag (Section 5.4.1) or requests explicit delegation, because the last hop of a sub-segment must remove the outer IPv6 header (Section 7.2). An ingress that signals a bypass tunnel (Section 8.2) SHOULD set the SRv6 USD flag. A node applies these flags in the same way regardless of its position on the path. It does not need to determine whether it is the last transit hop or the node that processes the penultimate segment; the position of a SID in the segment list is determined by the ingress, and the action of the PSP or USD flavor depends only on Segments Left when the packet arrives (Section 6.2). 5.4.4. SRv6 Egress SID Bit Number TBD11: SRv6 Egress SID The presence of this flag in the LSP_REQUIRED_ATTRIBUTES object of a Path message requests that the egress provide a terminating SID (Section 4.3, mode 3). The egress MUST provide an End SID with the USD flavor, i.e., an End variant that includes USD (for example, Endpoint Behavior 28 through 31), or the NEXT-CSID counterpart (for example, 47 through 50) when the SRv6 NEXT-CSID flag is set. The SRv6 PSP flag has no effect at the egress. The egress records the SID in the Generalized Label (Section 5.2) and in an RRO SRv6 SID sub-object (Section 5.3) with the Delegation SID flag clear. The SID MUST be advertised in the IGP. If the egress cannot comply, it MUST send a PathErr with error code 'Routing Problem (24)' and error value 'SRv6 SID usage failure (TBD4)'. When the flag is absent, the egress provides no SID (Section 4.3, modes 1 and 2). Beeram, et al. Expires 6 May 2027 [Page 22] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 The SRv6 PSP and SRv6 USD flags require no action at the egress. The SRv6 NEXT-CSID flag affects the egress only by selecting the variant of the egress SID when the SRv6 Egress SID flag is set. As for any other node on the path, an egress that does not recognize a flag in the LSP_REQUIRED_ATTRIBUTES object rejects the Path message that carries it ([RFC5420]). 5.5. Constraining SRv6 SID Selection via ERO A node MAY have multiple SRv6 End.X SIDs for the same TE link (e.g., SIDs that are eligible for protection and SIDs that are not, SIDs with different PSP/USP/USD flavors, or compressed and full-length SIDs). When the ingress (or a controller computing the path) needs to constrain a transit node to use a specific SID, it MAY include the SRv6 SID in the ERO. For an End.X SID, the ingress selects it from the IGP. A Delegation SID is allocated dynamically and is not advertised in the IGP (Section 7.1); the ingress or controller learns it by other means, e.g., configuration, a controller, or an earlier signaling of the same LSP. This is achieved by placing an ERO SRv6 SID sub-object following the sub-object (IPv4 or IPv6 interface address, or Unnumbered Interface ID) that identifies the TE link of the corresponding transit hop. The ERO SRv6 SID sub-object has the following format: 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) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Endpoint Behavior | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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: 24 (octets). Flags: An 8-bit field. The following flag is defined: Beeram, et al. Expires 6 May 2027 [Page 23] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 * 0x01 - Delegation SID: Indicates that the specified SID is a Delegation SID (End.B6.Encaps or End.B6.Encaps.Red, or the NEXT-CSID variants). When this flag is not set, the specified SID is an SRv6 TE Link SID (End.X). All other bits MUST be set to zero on transmission and ignored on receipt. 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 at the delegation hop. SRv6 Endpoint Behavior (16 bits): The SRv6 Endpoint Behavior codepoint of the SID from the IANA "SRv6 Endpoint Behaviors" registry. The value MUST be non-zero. When the Delegation SID flag is set, the value MUST be a Binding SID behavior (End.B6.Encaps, End.B6.Encaps.Red, or a NEXT-CSID variant). The field is the only indication of whether the specified SID is a compressed SID (Section 3.4). When a transit node that implements this sub-object (Section 4.4) 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, and that the Endpoint Behavior of the sub-object equals the behavior bound to that SID at the node. * If the Delegation SID flag (0x01) is set, it MUST verify that the SRv6 SID matches one of its locally allocated Binding SIDs and that the Endpoint Behavior of the sub-object equals the behavior bound to that SID. * If the Delegation SID flag (0x01) is clear, it MUST verify that the Endpoint Behavior satisfies the attribute flags of Section 5.4.2 and Section 5.4.3, if present. If the Delegation SID flag is set, it MUST verify that the Endpoint Behavior satisfies the attribute flag of Section 5.4.2, if present; the flags of Section 5.4.3 do not apply to a Delegation SID. * 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. Beeram, et al. Expires 6 May 2027 [Page 24] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 * 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 SID autonomously, subject to Section 3.7. 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, subject to step 4. This includes transit hop End.X SIDs and, if the SRv6 Egress SID flag (Section 5.4.4) was set, the egress terminating SID. 3. For each sub-object with the Delegation SID flag (0x01) set, add the Delegation SID to the TE path segment list. 4. Omit from the TE path segment list the SIDs that are covered by a delegation hop. The SIDs covered by a delegation hop are those recorded by the hops downstream of it, up to but not including the Delegation SID of the next delegation hop. For the last delegation hop, they are the SIDs up to but not including the final entry of the list. The final entry is the service SID in egress mode 1, the End.X SID of the last transit hop in egress mode 2, and the terminating SID of the egress in egress mode 3. The final entry is retained because a Delegation SID MUST NOT be the last SID in the list (Section 7.1). A delegation hop covers at least one SID. The ingress does not impose the covered SIDs; the delegation hop imposes them (Section 7.2). 5. If any SID in the list is a compressed SID (Section 3.4), an ingress that implements compression SHOULD construct the segment list using the NEXT-CSID compression rules of [RFC9800], applied as follows. The ingress uses the SID Structure of each SID obtained from the IGP (Section 6.3); for a Delegation SID, the structure is that of the End.X SIDs advertised from the same locator (Section 7.2). An ingress that does not implement Beeram, et al. Expires 6 May 2027 [Page 25] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 compression instead places each compressed SID in a Segment List entry of its own, as a SID that is not compressible, as described in [RFC9800]; the MTU validation (Section 6.3) then counts one entry per SID. a. Walk the SIDs in order. A compressed SID is compressible if its SID Structure is valid for compression per [RFC9800] (Locator-Block length and Locator-Node plus Function length non- zero, and Argument length equal to 128 minus the sum of the other lengths) and its Argument value is zero. A SID that is not compressible occupies a Segment List entry of its own. b. Start a container with the first compressible SID of a run. Append the Locator-Node and Function bits of each following compressible SID to the container's Argument bits while the SID has the same Locator-Block and the bits fit in the remaining capacity. Set the unused trailing bits to zero. c. Otherwise start a new container. A full-length SID and a compressed SID from a different Locator-Block each start a new Segment List entry. d. If the service SID (see below) is a NEXT-CSID SID with the same Locator-Block and a known SID Structure, and the remaining capacity of the last container suffices, the ingress MAY copy it into that container as described in Section 6.2 of [RFC9800]. 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 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. How the segment list ends depends on the egress mode (Section 4.3): * Mode 1 (service SID): 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). * Mode 2 (termination at the last transit hop): the segment list ends with the End.X SID of the last transit node, which has the USD flavor. No service SID is appended. * Mode 3 (termination at the egress): the segment list ends with the terminating SID of the egress. Beeram, et al. Expires 6 May 2027 [Page 26] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 The ingress then sets the IPv6 Destination Address of the outer header to the first entry of the resulting Segment List and sets the Segments Left field to (number of entries in the Segment List - 1). If the Segment List consists of a single entry (a single full-length SID or a single container), the ingress MAY omit the SRH and use H.Encaps.Red, as described in [RFC8986]; the outer IPv6 Destination Address is then that entry. When the whole path is encoded in a single container, the packet carries no SRH. A delegation hop applies these procedures to the portion of the RRO that it is responsible for when it constructs its sub-segment segment list (Section 7.2). The ingress forwards the encapsulated packet as required by Section 6.4. If the segment list is empty (egress mode 2 and the egress is the direct neighbor of the ingress over the first TE link), the ingress forwards the packet over that TE link without SRv6 encapsulation. 6.2. Reduced SRH When the SRH is present and the SRv6 PSP flag (Section 5.4.3) is set or the ingress pins a PSP-flavored SID, the node that processes the penultimate segment removes the SRH from the packet before forwarding, reducing the overhead at the next hop. The terms "penultimate segment" and "last transit hop" describe the segment list that the ingress builds. The PSP or USD behavior of a node is determined only by the flavor of the SID that the node advertised. The ingress determines PSP support by examining the SRv6 Endpoint Behavior field in the RRO SRv6 SID sub-object from the hop that processes the penultimate segment. If the recorded behavior is an End.X variant that includes the PSP flavor, the ingress MAY use the PSP-flavored SID. For example, the full-length End.X codepoints 6 (PSP), 8 (PSP and USP), 33 (PSP and USD) and 35 (PSP, USP and USD) include the PSP flavor, as do the NEXT-CSID codepoints 53, 55, 57 and 59. This list is illustrative. Implementations MUST determine the flavors of a recorded behavior from its entry in the IANA "SRv6 Endpoint Behaviors" registry rather than from a fixed list of codepoints, so that the behavior remains correct as the registry grows. In particular, an ingress that does not recognize the PSP flavor in a combined codepoint such as 33 would wrongly conclude that the hop does not support PSP and would not use the reduced SRH. Beeram, et al. Expires 6 May 2027 [Page 27] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 When the whole path is encoded in a single container and the SRH is omitted (Section 6.1), PSP does not apply. An ingress that needs the SRH to reach the egress (for example, to carry SRH TLVs, or for OAM) does not set the SRv6 PSP flag, and pins a SID without the PSP flavor at the hop where it matters (Section 5.5); a pinned SID without the PSP flavor conflicts with the SRv6 PSP flag (Section 5.4.3). 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 segment list will correctly forward packets along the intended path. The following validation checks MUST be performed: 1. ERO/RRO/IGP Cross-Validation: In base RSVP-TE, the label that a node provides is tied to the forwarding of the outgoing link on which the bandwidth is admitted. With SRv6, the End.X SIDs are pre-installed and shared. If a transit node provides an End.X SID that corresponds to a different TE link than the one on which the bandwidth was admitted (for example, due to misconfiguration or a race), bandwidth is reserved on one link while traffic is forwarded on another. Because SRv6 SIDs are routable IPv6 addresses, a stale or incorrect SID is also not simply dropped as an unknown MPLS label would be. The cross-validation maintains the coupling between the reservation and the forwarding. 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, and, for each sub-object that records an End.X SID, the ingress MUST verify against the IGP that: a. the SID is advertised as an End.X SID by the node identified for that hop in the ERO; b. the SID is advertised for the adjacency that corresponds to the TE link identified in the ERO for that hop; and c. the Endpoint Behavior recorded in the RRO equals the behavior advertised for the SID in the IGP. Beeram, et al. Expires 6 May 2027 [Page 28] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 A Delegation SID is not advertised in the IGP. For a sub-object that records a Delegation SID, the ingress applies the checks of Section 7.2 instead: the SID falls within a locator advertised by the recording node, and its structure is valid for compression. 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. The ingress MUST also verify that the node advertising the first SID in the TE path segment list is the neighbor reached over the first TE link of the ERO. 3. MTU Validation: The ingress MUST verify that the total size of the SRv6 encapsulation does not cause the encapsulated packet to exceed the Path MTU. The encapsulation consists of the outer IPv6 header (40 bytes) and, unless the SRH is omitted (Section 6.1), the SRH fixed header (8 bytes) and 16 bytes per Segment List entry. A container counts as one entry; a SID that is not compressible counts as one entry. If the encapsulation 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 other than delegation hops have recorded an End.X variant appropriate for TE link forwarding, i.e., an End.X behavior with any combination of the PSP, USP and USD flavors, or its NEXT-CSID counterpart (for example, codepoints 5-8 and 32-35 for full-length SIDs, and 52-59 for NEXT-CSID SIDs). b. Delegation hops (if any) have recorded an End.B6.Encaps or End.B6.Encaps.Red variant (codepoints 14, 27, 93 or 94). Beeram, et al. Expires 6 May 2027 [Page 29] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 c. If the SRv6 PSP or SRv6 USD flag (Section 5.4.3) was set, the Endpoint Behavior of every RRO sub-object that records an End.X SID includes the corresponding flavor. If the SRv6 Egress SID flag (Section 5.4.4) was set, the RRO contains a final SRv6 SID sub-object from the egress whose Endpoint Behavior is an End variant that includes the USD flavor (a NEXT-CSID End variant if the SRv6 NEXT-CSID flag was set), and the SID matches what the IGP advertises for the egress. If the flag was clear and the egress recorded an RRO SRv6 SID sub-object, the ingress ignores it and MAY log the event. d. If the SRv6 NEXT-CSID attribute flag (Section 5.4.2) was set in the LSP_REQUIRED_ATTRIBUTES, every transit hop has recorded a NEXT-CSID End.X variant (for example, codepoints 52-59), and every delegation hop has recorded a NEXT-CSID Binding SID (codepoint 93 or 94). e. A recorded Endpoint Behavior that is a compression flavor other than NEXT-CSID is a validation failure (Section 3.4). f. In egress mode 2 (Section 4.3), the Endpoint Behavior of the last transit hop includes USD. If an unexpected behavior is recorded, the ingress SHOULD log the event and MAY reject the tunnel setup. 5. SID Structure: For each compressed SID, the ingress obtains the SID Structure from the IGP. If the ingress cannot obtain a valid SID Structure for a SID, it MUST treat that SID as not compressible per [RFC9800] and place it in a Segment List entry of its own. The ingress SHOULD log the event. This affects the MTU validation (check 3). An implementation MAY provide a local option to fail the tunnel in this case. 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)'. Beeram, et al. Expires 6 May 2027 [Page 30] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 6.4. First-Hop Steering A node that imposes a segment list for an SRv6 RSVP-TE LSP (the ingress, a delegation hop, or a PLR that encapsulates onto a bypass path) MUST forward the resulting packet over the TE link on which the LSP's resources were admitted for that segment, and MUST NOT rely on the IGP route to the locator of the first SID. Subsequent transit hops are not affected, since End.X forwards the packet over its adjacency. How a node does this is a local implementation choice. For example, it can forward the encapsulated packet over that TE link with the neighbor on that link as the explicit next hop, or it can list its own End.X SID for that TE link as the first SID and forward over the adjacency that SID identifies; in that case the node MAY omit the SID from the packet. 7. Delegation with SRv6 Binding SIDs 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 the constraint is often the MTU, because each full-length SID in the SRH is 128 bits (16 bytes), compared to 4 bytes per MPLS label. For full-length SIDs, a 10-hop path requires 160 bytes of SRH versus 40 bytes of MPLS label stack. This comparison applies to full-length SIDs only. With compressed SIDs (Section 3.4), the gap narrows substantially: when the whole path is encoded in a single container no SRH is needed, and longer paths use one 16-byte entry per container (see also Appendix A.4). The delegation mechanism remains necessary for full-length SIDs and for paths that exceed the capacity of the available containers. In SRv6, delegation is achieved using Binding SIDs. A delegation hop allocates an SRv6 Binding SID (End.B6.Encaps or End.B6.Encaps.Red, or their NEXT-CSID variants) that represents a sub-segment-list covering the downstream portion of the path. Unlike TE Link SIDs, a Delegation SID is allocated dynamically and is not advertised in the IGP. 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. Beeram, et al. Expires 6 May 2027 [Page 31] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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. The sub-segment-list is made of the SIDs that the delegation hop covers, as determined by the procedure in Section 6.1 (step 4). The delegation hop constructs it from the portion of the RRO that it is responsible for. Example with the following topology: +---+ +---+ +---+ +---+ +---+ +---+ | 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 Beeram, et al. Expires 6 May 2027 [Page 32] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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. The End.X SID K::100 has the USD flavor, so K removes the outer IPv6 header and forwards the inner packet on the K-L TE link. The egress L receives the inner packet. Note: This example omits the service SID at the egress for brevity and terminates in egress mode 2 (Section 4.3). Accordingly the End.X SIDs at the last hop of each sub-segment (H::100 and J::100) and the final End.X SID (K::100) have the USD flavor; the ingress sets the SRv6 USD flag (Section 5.4.3) because delegation is requested. In practice, the ingress would append a service SID (e.g., L::46 for End.DT46) to the segment list, as described in Section 6.1. 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. A Delegation SID is allocated from a locator of the delegation hop that is advertised in the IGP, and MUST use the same SID Structure (Locator-Block, Locator-Node, Function and Argument lengths) as the End.X SIDs advertised from that locator. The ingress derives the SID Structure of a Delegation SID from that locator's IGP-advertised structure. The ingress MUST verify that the Delegation SID falls within a locator advertised by the recording node, by matching the Locator-Block and Locator-Node bits of the SID, and that the structure is valid for compression per [RFC9800]. If the structure is not valid, the Delegation SID is not compressible (Section 6.3). Beeram, et al. Expires 6 May 2027 [Page 33] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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, and the outer IPv6 header that the delegation hop pushed must be removed there. The last End.X SID of each sub-segment MUST therefore have the USD flavor (an End.X variant that includes USD, e.g., Endpoint Behavior 32 through 35 for full-length SIDs, or 56 through 59 for NEXT-CSID SIDs), which decapsulates the outer IPv6 header when Segments Left is zero and forwards the inner packet. The PSP flavor alone is not sufficient, because it removes only the SRH. Setting the SRv6 USD flag (Section 5.4.3) in the LSP_REQUIRED_ATTRIBUTES object satisfies this requirement at every hop. Delegation hops constructing sub-segment SRHs MAY additionally use PSP-flavored End.X SIDs at the penultimate hop of the sub-segment. The delegation hop forwards the re- encapsulated packet as required by Section 6.4. 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 Segment List entries (128-bit SIDs or CSID containers) 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. Beeram, et al. Expires 6 May 2027 [Page 34] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 In MPLS, the ETLD is typically constrained by platform label-stack depth limits. In SRv6, the primary constraint is MTU: each Segment List entry 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. 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. * In egress mode 1 (Section 4.3), 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 unless it is packed into an existing container (Section 6.1). * 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 (Section 8.2). * A node that carries its own End.X SID in the packet to satisfy first-hop steering (Section 6.4) includes it in its ESLD. * When compressed SID encoding (Appendix A.4) is in use, the ESLD counts 128-bit Segment List entries (containers), not individual CSIDs. A SID that is not compressible counts as one entry. Appendix A provides a detailed reference procedure for computing the ESLD and making delegation placement decisions. Beeram, et al. Expires 6 May 2027 [Page 35] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 8. Protection 8.1. Scope and Architecture This section discusses link protection of the SRv6 TE Link SIDs that are used by SRv6 RSVP-TE tunnels. Node protection is outside the scope of this document. The SR architecture does not mandate a mechanism to protect an End.X SID. The B-flag in the IS-IS SRv6 End.X SID sub-TLV [RFC9352] indicates that the SID is eligible for protection, not which mechanism protects it. An SRv6 RSVP-TE tunnel that requests link protection [RFC4090] therefore cannot assume that a protected End.X SID is protected by an RSVP-TE-signaled facility backup tunnel. The approach of [RFC8577] of allocating a separate TE link label, not advertised in the IGP, for tunnels that request link protection is not applicable, because an SRv6 TE Link SID MUST be advertised in the IGP (Section 3.1). Protection signaling follows [RFC4090]. The ingress requests protection with the "local protection desired" flag in the SESSION_ATTRIBUTE object. A PLR reports "local protection available" and "local protection in use" in the flags of the RRO IPv4, IPv6 or Unnumbered Interface ID sub-object that identifies the hop. The request is not mandatory: a transit node that has no suitable protected End.X SID for the outgoing TE link uses an unprotected End.X SID and does not set "local protection available". The following subsections describe the models that have been identified for link protection of RSVP-TE tunnels in a network that uses SRv6 End.X SIDs, and the aspects that each of them needs to address. 8.2. RSVP-TE-Signaled Facility Backup for Protected End.X SIDs With this model, the PLR protects an End.X SID using a facility backup bypass tunnel [RFC4090] that is signaled via RSVP-TE. This model requires the IGP to identify an End.X SID as protected by an RSVP-TE-signaled bypass tunnel. That identification will be covered in a separate draft and is a dependency of this subsection. A transit node that receives a request for protection selects such an End.X SID for the outgoing TE link, if one exists. When the protected TE link fails, the PLR performs the following: Beeram, et al. Expires 6 May 2027 [Page 36] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 1. Receives the packet with the protected End.X SID as the active segment, and executes the End.X behavior (decrements Segments Left and updates the IPv6 DA with the next SID). 2. Instead of forwarding on the failed TE link, it encapsulates the packet toward the merge point over the bypass path, applying Section 6.4. The bypass tunnel is an SRv6 RSVP-TE tunnel that is signaled as described in this document. Its ingress SHOULD set the SRv6 USD flag (Section 5.4.3) and uses termination at the last transit hop (Section 4.3, mode 2). The last segment of the bypass segment list is the USD-flavored End.X SID of the node immediately upstream of the merge point, as recorded in the RRO of the bypass tunnel. That node removes the outer encapsulation and forwards the original packet to the merge point. The merge point therefore performs no decapsulation, receives the packet as if it had arrived on the protected TE link, and continues processing the original segment list. Targeting a SID at the merge point itself can instead cause a double decapsulation in some cases, e.g., when the PLR is the penultimate hop or coincides with PSP processing. If the bypass path is a single alternate link to the merge point, the PLR forwards over that link without encapsulation (Section 6.4). The PLR maps the protected End.X SID to its bypass tunnel from local state. Bandwidth protection, bypass selection, and the behavior at the merge point follow [RFC4090]. The ESLD at a protected hop MUST account for the bypass encapsulation overhead (Appendix A.1). 8.3. TI-LFA Link Protection With this model, a protected End.X SID is protected by TI-LFA [RFC9855], i.e., by a non-signaled repair path. This model requires the following procedures to be specified: * 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 End.X 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 cause the primary RSVP-TE state to be torn down. This section will be elaborated in a later revision of this document. Beeram, et al. Expires 6 May 2027 [Page 37] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 9. OAM Considerations SRv6 OAM mechanisms based on ICMPv6 and the mechanisms of [RFC9259] are applicable to SRv6 RSVP-TE tunnels. When an SRH is used, the SRH in OAM probe packets can be constructed using the same procedures as data packets (Section 6). When the whole path is encoded in a single container and no SRH is present (Section 6.1), there is no SRH to carry the O-flag [RFC9259] or SRH TLVs [RFC8754]. Traceroute-style probing then relies on the Hop Limit of the outer IPv6 header. The PSP flavor [RFC8986] removes the SRH at the penultimate segment (Section 6.2); an ingress that needs the SRH to reach the egress does not set the SRv6 PSP flag, and pins a SID without the PSP flavor at the relevant hop (Section 5.5). The segment list that a delegation hop imposes (Section 7.2) is not visible to the ingress. Discovering it requires OAM support at the delegation hop, which is not defined by this document. The specific OAM procedures for these tunnels will be described in a future revision of this document. A mechanism by which a delegation hop reports the segment list that it imposes would be an extension to SRv6 OAM and is expected to be described separately. 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: 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 five new Attribute Flags: Beeram, et al. Expires 6 May 2027 [Page 38] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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 NEXT-CSID Yes No No No [This doc], Section 5.4.2 TBD9 SRv6 PSP Yes No No No [This doc], Section 5.4.3 TBD10 SRv6 USD Yes No No No [This doc], Section 5.4.3 TBD11 SRv6 Egress SID Yes No No No [This doc], Section 5.4.4 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: Flag Name Reference ---- ----------- --------- 0x01 Delegation SID [This document], Section 5.3 Beeram, et al. Expires 6 May 2027 [Page 39] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 Bits 0x02 through 0x80 are unassigned. 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 Bits 0x02 through 0x80 are unassigned. 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.4.2, 5.4.3, 5.4.4, 5.5 TBD5 SRv6 segment list imposition [This document], failure Section 6.3 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]. Beeram, et al. Expires 6 May 2027 [Page 40] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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. The ingress builds the segment list from the SIDs recorded in the RRO. A transit node can therefore influence the path of the traffic by recording an arbitrary SID. The validation procedures of Section 6.3 mitigate this: the ingress verifies each SID and its Endpoint Behavior against the IGP-advertised information. The security of this validation depends on the security of the IGP, and deployments SHOULD use IGP authentication [RFC5304] [RFC5310]. 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, . Beeram, et al. Expires 6 May 2027 [Page 41] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 [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, . [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, February 2003, . [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, . [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, . [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, . Beeram, et al. Expires 6 May 2027 [Page 42] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 [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, . [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, . [RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", RFC 9513, DOI 10.17487/RFC9513, December 2023, . [RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding", RFC 9800, DOI 10.17487/RFC9800, June 2025, . 13.2. Informative References [I-D.beeram-mpls-rsvp-sr] Beeram, V. P., Barth, C., and A. Smith, "Signaling RSVP-TE Tunnels on an SR-MPLS Forwarding Plane Using Adjacency Segment Identifiers", Work in Progress, Internet-Draft, draft-beeram-mpls-rsvp-sr-01, 26 October 2026, . [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, . Beeram, et al. Expires 6 May 2027 [Page 43] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 [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, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, 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, . [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, . [RFC9259] Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. Chen, "Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)", RFC 9259, DOI 10.17487/RFC9259, June 2022, . [RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., Bernier, D., and B. Decraene, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December 2023, . [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, . 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. Beeram, et al. Expires 6 May 2027 [Page 44] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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. It applies when an SRH is present. * 16: The per-entry overhead (bytes) for each 128-bit Segment List entry (a full-length SID, a CSID container, or a SID that is not compressible). 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. The ESLD counts Segment List entries. A path whose segment list fits in a single entry (for example, a single CSID container) needs no SRH, and its encapsulation overhead is 40 bytes only (Section 6.1). 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: an outer IPv6 header of 40 bytes, plus an SRH if the bypass segment list does not fit in a single entry. The ESLD at a protected hop SHOULD be computed using an effective Link_MTU reduced by the bypass tunnel overhead. Beeram, et al. Expires 6 May 2027 [Page 45] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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. For an ingress that implements compression: if compressed SIDs are present (Endpoint Behavior is a NEXT-CSID codepoint in the RRO SRv6 SID sub-objects), apply the NEXT-CSID packing rules of [RFC9800] as described in Section 6.1, using the SID Structure from the IGP: compressible SIDs that share a Locator-Block are packed into shared 128-bit containers; full-length SIDs, SIDs that are not compressible, and compressed SIDs from a different Locator-Block each occupy a separate entry. An ingress that does not implement compression counts each compressed SID as one entry. c. In egress mode 1, add one entry for the service SID (e.g., End.DT46) that the ingress will append to the segment list, unless it is packed into the last container (Section 6.1). In egress mode 3, the egress terminating SID is part of the TE path SIDs. In egress mode 2, nothing is added. 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. 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). Beeram, et al. Expires 6 May 2027 [Page 46] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 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. Compressed SID Interaction When compressed SID (NEXT-CSID) encoding is in use, the ESLD counts 128-bit Segment List entries (containers), not individual CSIDs. A CSID is the Locator-Node and Function portion of a SID, of length LNFL (Section 3.4). If all CSIDs in a container share the same LNFL, a container holds P = 1 + floor(AL / LNFL) CSIDs, where AL = 128 - LBL - LNL - FL is the Argument length of the SID Structure. For example, with a 32-bit Locator-Block and 16-bit CSIDs, AL = 80 and P = 6. The effective hop capacity depends on the mix of SID types along the downstream path: * All full-length SIDs: each SID consumes one container. Effective capacity = ESLD hops. Beeram, et al. Expires 6 May 2027 [Page 47] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 * All compressible SIDs from the same Locator-Block with the same LNFL: up to P SIDs per container. Effective capacity = ESLD x P hops. When the whole path fits in one container, no SRH is needed. * Mixed: full-length SIDs, SIDs that are not compressible, and compressed SIDs from different Locator-Blocks each consume a separate entry; consecutive compressible SIDs from the same Locator-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 Endpoint Behavior in each RRO SRv6 SID sub-object to identify the compressed SIDs and the SID Structure from the IGP to pack them. 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 Bharath RadhaKrishna Bhat HPE Email: bharath.bhat@hpe.com Beeram, et al. Expires 6 May 2027 [Page 48] Internet-Draft RSVP-TE with SRv6 End.X SIDs November 2026 Minjie Dai HPE Email: minjie.dai@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 Sven Maduschke Verizon Email: sven.maduschke@de.verizon.com Beeram, et al. Expires 6 May 2027 [Page 49]