SPRING Abhishek Chakraborty Internet-Draft Jayant Kumar Agarwal Vishnu Pavan Beeram Intended status: Informational HPE Expires: 7 January 2027 6 July 2026 SRv6 for Multipath Traffic Engineering draft-ajp-spring-srv6-mpte-00 Abstract A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that enables weighted load balancing of unicast traffic across a constrained set of paths optimized for an objective. This document is informational and describes one realization approach for applying SRv6 semantics to MPTE, based on the Multipath Traffic Engineering Internet-Draft (draft-kompella-teas-mpte). It summarizes associated procedures, lifecycle, management, and forwarding behavior. This document applies existing SRv6 architecture and semantics to MPTE without defining new SRv6 endpoint behaviors or signaling protocols. It focuses on data-plane realization using existing forwarding instructions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Abhishek & Jayant Expires 7 January 2027 [Page 1] Internet-Draft SRv6 for MPTE July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope and Design Principles . . . . . . . . . . . . . . . . . 4 3. Overview of MPTET-SRv6 Functional Entities . . . . . . . . . 4 3.1. Allocation Function . . . . . . . . . . . . . . . . . . . 4 3.2. MPTE-DAG Block . . . . . . . . . . . . . . . . . . . . . 4 3.3. DAG Locator and DAG SID . . . . . . . . . . . . . . . . . 5 3.4. Support for MC Roles . . . . . . . . . . . . . . . . . . 5 3.5. Support for Signaling Protocols . . . . . . . . . . . . . 6 4. Working Principles . . . . . . . . . . . . . . . . . . . . . 6 4.1. MPTED Computer . . . . . . . . . . . . . . . . . . . . . 6 4.2. Allocation Function . . . . . . . . . . . . . . . . . . . 7 4.3. Signaling Source . . . . . . . . . . . . . . . . . . . . 7 4.4. Ingress Programming . . . . . . . . . . . . . . . . . . . 7 4.5. Transit Junction Programming . . . . . . . . . . . . . . 8 4.6. Penultimate Junction Programming . . . . . . . . . . . . 8 4.7. Egress Programming . . . . . . . . . . . . . . . . . . . 8 4.8. Versioning and Operational Behavior . . . . . . . . . . . 8 4.9. Optimization and Deployment Simplification Approaches . . 8 5. Forwarding Semantics . . . . . . . . . . . . . . . . . . . . 8 5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . 9 5.2. Transit Junction Behavior . . . . . . . . . . . . . . . . 9 5.3. Penultimate Junction Behavior . . . . . . . . . . . . . . 9 5.4. Egress Behavior . . . . . . . . . . . . . . . . . . . . . 9 5.5. MTU Considerations . . . . . . . . . . . . . . . . . . . 9 6. Service Mapping Considerations . . . . . . . . . . . . . . . 10 7. Inter-AS Considerations . . . . . . . . . . . . . . . . . . . 10 8. Interoperability Considerations . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Deployment Example . . . . . . . . . . . . . . . . . 13 A.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 13 A.2. Example DAG Computation . . . . . . . . . . . . . . . . . 13 A.3. Example Junction Signaling Intent . . . . . . . . . . . . 14 A.3.1. SID Structure Example . . . . . . . . . . . . . . . . . 14 A.4. Example Route Programming . . . . . . . . . . . . . . . . 14 A.5. Packet Walk Example . . . . . . . . . . . . . . . . . . . 15 A.6. Update Behavior Example . . . . . . . . . . . . . . . . . 15 A.7. Inter-AS Example . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Abhishek & Jayant Expires 7 January 2027 [Page 2] Internet-Draft SRv6 for MPTE July 2026 1. Introduction The notions of Multipath Traffic Engineering (MPTE) and an MPTE Directed Acyclic Graph (MPTED) tunnel are introduced in [I-D.kompella-teas-mpte]. MPTE SRv6 extension points are described in companion documents and aligned here for realization context. This document describes an approach in which each MPTED uses a unique DAG Locator and a unique DAG SID as SRv6 forwarding context to program and operate MPTE junction state. In this approach, transit junctions (non-penultimate hops) forward traffic using IPv6 forwarding with weighted ECMP next hops, penultimate-hop junctions terminate the DAG SID, ingress nodes encapsulate traffic with DAG SID and Service SID, and egress nodes perform service handling. The approach ensures there are not two SRv6 SID terminations at a single node. The forwarding semantics in this approach do not require additional SRv6 encapsulation at transit junctions. This approach does not change or redefine existing SRv6 semantics and does not define new SRv6 forwarding instructions. It uses existing SRv6 architecture in an MPTE context. This approach also considers inter-domain use cases. 1.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. Lowercase uses of these words are not to be interpreted as BCP 14 normative requirements. 1.2. Terminology This document reuses terminology from [I-D.kompella-teas-mpte], [RFC8754], [RFC8986], and [RFC9800]. DAG Locator: A unique SRv6 locator allocated for a specific MPTED within a domain. This locator represents the per-DAG transport context used by transit junctions (non-penultimate hops) for IPv6 forwarding with weighted ECMP next hops according to the DAG's signaled junction state. Abhishek & Jayant Expires 7 January 2027 [Page 3] Internet-Draft SRv6 for MPTE July 2026 DAG SID: A unique SRv6 SID allocated for a specific MPTED, used for DAG termination semantics at penultimate-hop junctions. In this realization, DAG SID behavior is equivalent to END.X with Next-C-SID, PSP & USD processing semantics where applicable [RFC8986] [RFC9800], with weighted ECMP next hops according to the DAG's signaled junction state. Domain: A network administrative domain within which DAG Locators and DAG SIDs are unique and privately scoped, consistent with [RFC8402] Segment Routing Architecture concepts. Allocation Function: A logical function that owns SRv6 block space for MPTED use and allocates unique DAG Locator and DAG SID values on request from the MC. 2. Scope and Design Principles This document describes one realization approach for applying SRv6 semantics to MPTE and summarizes associated procedures, lifecycle, management, and forwarding behavior. This document does not define: * a new SRv6 Endpoint Behavior, * signaling protocol specific encodings for RSVP-TE, PCEP, BGP, or other signaling families, * MPTE control-plane role behavior, DAG computation procedures, or signaling procedures defined by [I-D.kompella-teas-mpte] and companion drafts. 3. Overview of MPTET-SRv6 Functional Entities 3.1. Allocation Function The allocation function is a logical entity that allocates and manages the DAG Locator and DAG SID. It is usually co-located with the MC for operational simplicity, or MAY be implementation-specific and located elsewhere. The MC requests dynamic allocation of unique DAG Locator and DAG SID values for each DAG and, optionally, each DAG version. The mechanisms used for communication between MC and Allocation Function are out of scope. 3.2. MPTE-DAG Block Each Allocation Function is assigned one or more unique SRv6 block(s), referred to in this document as DAG Block(s). Abhishek & Jayant Expires 7 January 2027 [Page 4] Internet-Draft SRv6 for MPTE July 2026 It is RECOMMENDED to assign separate SRv6 blocks to each allocation function for operational simplicity, and to use those blocks only for MPTED purposes. Using best-effort or Flex-Algo SRv6 blocks for DAG Locator/SID allocation MAY create loops and MAY raise security concerns if stale or inconsistent state is not cleaned up properly. DAG blocks are private to a domain and MUST NOT be advertised to other domains by any means. The same DAG Block can be reused by another domain. If every ingress behaves as MC and each MC is accompanied by an Allocation Function, two deployment options are common: (1) each MC SHOULD have its own unique DAG Block, or (2) multiple MCs MAY share a common DAG Block with coordinated allocations. The choice depends on operational and scaling requirements. 3.3. DAG Locator and DAG SID For each MPTED, the implementation MUST associate one DAG Locator and one DAG SID that are unique within the domain. Section 3.2 describes one approach to allocation and Section 4 describes the corresponding programming workflow. An implementation MAY allocate a new DAG Locator and DAG SID per DAG version, or MAY reuse the same values across versions when safe update behavior is preserved. A unique DAG Locator and DAG SID per DAG provides clear DAG identification inside a domain and improves operational debugging and tracing. DAG locators and DAG SIDs in this realization are private transport identifiers and MUST NOT be advertised in IGP or other routing protocols. These identifiers MAY be carried only by the signaling protocol used to program junction nodes for the DAG. 3.4. Support for MC Roles As described in [I-D.kompella-teas-mpte], the MPTED computer (MC) is the entity that computes the MPTED. The MC can be either: * an ingress node, or * a Path Computation Element (PCE). This realization supports both MC models and does not constrain its functional placement. TO, MC, and SS may co-reside on one node or be distributed across multiple nodes, consistent with the base MPTE architecture. The residence and placement model of the MC influences the operational choice of signaling protocol family (Section 3.5) used to program DAG junctions. Abhishek & Jayant Expires 7 January 2027 [Page 5] Internet-Draft SRv6 for MPTE July 2026 3.5. Support for Signaling Protocols This document aligns with the signaling protocol direction of [I-D.kompella-teas-mpte] and supports mapping SRv6 MPTE signaling to the same companion protocol families: * RSVP-TE extensions, * PCEP extensions, * BGP-based signaling, * other MPTE-compatible signaling specifications. Protocol-specific details for these signaling families are specified in [I-D.beeram-pce-pcep-mpted], [I-D.kbr-teas-mptersvp], and [I-D.zzhang-idr-mpte-signaling]. Independently of the chosen signaling protocol, the signaling exchange is expected to carry SRv6 context (for example DAG Locator/SID context) required by this realization. This document does not define protocol-specific signaling procedures. 4. Working Principles 4.1. MPTED Computer The MPTED Computer (MC) computes the MPTED and its per-junction PHOP/NHOP state according to [I-D.kompella-teas-mpte]. For each DAG (and optionally each DAG version), the MC requests the Allocation Function to provide a unique DAG Locator and DAG SID. The SRv6 realization programming intent derived from the DAG result is as follows: * DAG Locator context is used for non-penultimate transit junction programming, * DAG SID context is used for penultimate-hop termination programming, * no DAG transport Locator/SID programming is required at egress, * ingress tunnel Encapsulation's destination is set to DAG SID with service SID stacking in SRH. The resulting junction programming intent is provided to the Signaling Source for distribution. Detailed MPTE computation workflow and signaling procedures are out of scope in this document. These procedures and workflows are specified in companion MPTE documents. Abhishek & Jayant Expires 7 January 2027 [Page 6] Internet-Draft SRv6 for MPTE July 2026 4.2. Allocation Function The Allocation Function allocates and manages DAG Locator and DAG SID values from assigned DAG block space. The Allocation Function MAY be placed on any node or controller entity. For operational simplicity, co-location with the MC is RECOMMENDED. The Allocation Function returns the DAG Locator/DAG SID context needed for signaling and forwarding realization. The mechanisms used for communication between MC and Allocation Function are out of scope. 4.3. Signaling Source The Signaling Source distributes the MC-provided per-junction intent using signaling procedures defined by [I-D.kompella-teas-mpte], [I-D.beeram-pce-pcep-mpted], [I-D.kbr-teas-mptersvp], and [I-D.zzhang-idr-mpte-signaling]. For SRv6 realization, the signaling payload carries DAG identity/version and SRv6 context (DAG Locator and DAG SID), together with PHOP/NHOP relationships needed by receiving junction nodes. The base signaling workflow remains as defined in [I-D.kompella-teas-mpte]; this realization only identifies SRv6- specific context used by programmed nodes. Protocol-specific signaling procedures remain out of scope in this document. 4.4. Ingress Programming Ingress programming installs tunnel encapsulation context for the selected MPTED: * Outer Encapsulation's destination is set to the DAG SID, * SRH carries service SID context, * forwarding next hops are programmed per MPTE DAG intent. Ingress does not require DAG-specific transit SID stacking for in- domain transport beyond the DAG Locator/SID realization described in this document. Abhishek & Jayant Expires 7 January 2027 [Page 7] Internet-Draft SRv6 for MPTE July 2026 4.5. Transit Junction Programming Transit junctions (non-penultimate hops) are programmed with DAG Locator route state toward MPTE-programmed NHOPs. Transit junctions perform IPv6 forwarding for this transport context with weighted ECMP next hops. They do not perform DAG SID termination in this realization. 4.6. Penultimate Junction Programming Penultimate-hop junction programming installs DAG SID termination state with MPTE-programmed NHOPs toward egress. Upon match of the terminating DAG SID context, the node applies signaled SRv6 endpoint behavior and forwards toward egress according to DAG NHOP intent. 4.7. Egress Programming Egress programming does not require DAG transport-route state in this realization. Egress performs service handling based on service SID context and local service forwarding behavior. 4.8. Versioning and Operational Behavior Implementations MAY either: * update PHOP/NHOP state while reusing an existing DAG Locator/SID, or * allocate new DAG Locator/SID values for a new DAG version and perform make-before-break. In all cases, signaling and forwarding state MUST remain consistent for DAG identity, version, and DAG Locator/SID context. 4.9. Optimization and Deployment Simplification Approaches Deployments MAY simplify operations while preserving the working principles described in this section. Two approaches are common: * Shared DAG Block architecture, where multiple logical Allocation Functions share a common DAG Block with coordinated allocations. * Minimal DAG Block with per-allocation function locator ownership, where a minimal set of DAG Blocks is shared across all logical Allocation Functions, each logical Allocation Function is assigned a unique locator, and each logical Allocation Function allocates function codes from the shared DAG Block in its local scope. For the second approach, additional programming semantics will be clarified in a future version of this draft. 5. Forwarding Semantics Section 4 defines functional roles and programming intent. This section defines the resulting packet-forwarding behavior at each node type. Abhishek & Jayant Expires 7 January 2027 [Page 8] Internet-Draft SRv6 for MPTE July 2026 5.1. Ingress Behavior Ingress encapsulates packets into the SRv6 transport context associated with the selected MPTED. The outer IPv6 Header destination is the DAG SID, and SRH carries service SID context. Ingress forwarding uses MPTE-programmed next hops for the DAG. 5.2. Transit Junction Behavior Transit junctions (non-penultimate hops) forward packets by IPv6 lookup on DAG Locator route context, performing IPv6 forwarding with weighted ECMP next hops. No DAG SID termination is performed at these transit nodes. Forwarding follows MPTE-programmed NHOP sets. 5.3. Penultimate Junction Behavior Penultimate-hop junctions match the DAG SID termination route, apply the signaled endpoint behavior, and forward packets toward egress NHOPs programmed by MPTE. This model keeps DAG SID termination at penultimate context and avoids requiring additional in-domain DAG-specific SID stacking. This model also avoids 2 terminations at any node in a domain. 5.4. Egress Behavior Egress receives traffic after DAG transport realization and performs service SID handling. Service SID semantics follow [RFC8986] SRv6 Network Programming including DT4, DT6, End.X behaviors and [RFC9800] Compressed SRv6 Segment List processing. Egress does not require per-DAG transport-route programming for this realization model. 5.5. MTU Considerations Implementations SHOULD account for SRv6 encapsulation overhead (outer IPv6 header, SRH, and service SID context) when programming ingress encapsulation and service transport. Path-MTU validation SHOULD ensure that realized MPTED forwarding does not introduce unintended fragmentation behavior. This realization does not require additional SRv6 encapsulation insertion at transit and penultimate nodes beyond ingress encapsulation behavior. Abhishek & Jayant Expires 7 January 2027 [Page 9] Internet-Draft SRv6 for MPTE July 2026 6. Service Mapping Considerations Service mapping can be implemented in different ways and is outside the strict scope of this document. One possible model is to map services onto an SRv6 TE policy [RFC9256] that triggers intent-based MPTED computation and signaling. Other mapping approaches are equally valid. 7. Inter-AS Considerations For inter-AS or inter-domain end-to-end MPTET realization, the next- domain transport SID can be placed in the SRH to steer traffic across domain boundaries. Each domain maintains private DAG locator/SID spaces. Inter-domain exchange SHOULD use explicitly intended interconnect SIDs or transport SIDs without leaking private DAG locator blocks. Note: Full inter-domain forwarding mechanics and state synchronization requirements are subject to further clarification and will be detailed in the future revision of this document. 8. Interoperability Considerations Interoperable behavior requires consistent interpretation of DAG identity/version and DAG Locator/SID context by all participating nodes. Interoperability of SRv6 forwarding behavior follows [RFC8754], [RFC8986], and [RFC9800]. 9. IANA Considerations This document has no IANA actions. 10. Security Considerations Security considerations from [I-D.kompella-teas-mpte] apply. SRv6 and SRH security considerations in [RFC8754], [RFC8986], and [RFC8402] apply. Because DAG locator/SID spaces are private and signaling-scoped, implementations SHOULD enforce strict authorization and policy checks on junction-programming messages and SHOULD validate stale- state cleanup for safety. 11. Contributors TBD Abhishek & Jayant Expires 7 January 2027 [Page 10] Internet-Draft SRv6 for MPTE July 2026 12. Acknowledgements TBD 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, . [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, . [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, . [RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding in IPv6", RFC 9800, DOI 10.17487/RFC9800, March 2025, . [I-D.kompella-teas-mpte] Kompella, K., et al., "Multipath Traffic Engineering", Work in Progress, Internet-Draft, draft-kompella-teas-mpte, 2026, . Abhishek & Jayant Expires 7 January 2027 [Page 11] Internet-Draft SRv6 for MPTE July 2026 [I-D.beeram-pce-pcep-mpted] Beeram, V., et al., "PCEP Extensions for MPTED Tunnels", Work in Progress, Internet-Draft, draft-beeram-pce-pcep-mpted-01, 2026, . [I-D.kbr-teas-mptersvp] Kompella, K., et al., "RSVP-TE Extensions for MPTE", Work in Progress, Internet-Draft, draft-kbr-teas-mptersvp-03, 2026, . [I-D.zzhang-idr-mpte-signaling] Zhang, Z., et al., "BGP Signaling for MPTE Junction States", Work in Progress, Internet-Draft, draft-zzhang-idr-mpte-signaling-00, 2026, . 13.2. Informative References [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . Abhishek & Jayant Expires 7 January 2027 [Page 12] Internet-Draft SRv6 for MPTE July 2026 Appendix A. Deployment Example (Provisioning, Signaling, and Forwarding) This appendix illustrates one deployment realization aligned with the approach in this document. A.1. Topology |-- T3 -- PHP1 -- Egress1 Ingress1 (MC1) --\ | | / +-- T1 -- T2 | | |------/ Ingress2 (MC2) --/ | | | |-- T4 -- PHP2 ------Egress2 For simplicity, each ingress acts as MC and TO/SS for DAGs sourced from that ingress. A.2. Example DAG Computation For a request sourced at Ingress1 and destined to Egress1, MC1 computes: * JCT Ingress1: PHOPs = none, NHOPs = {T1} * JCT T1: PHOPs = {Ingress1}, NHOPs = {T2} * JCT T2: PHOPs = {T1}, NHOPs = {T3, T4} * JCT T3: PHOPs = {T2}, NHOPs = {PHP1} * JCT T4: PHOPs = {T2}, NHOPs = {PHP2} * JCT PHP1: PHOPs = {T3}, NHOPs = {Egress1} * JCT PHP2: PHOPs = {T4}, NHOPs = {Egress1} * JCT Egress1: PHOPs = {T3, T4}, NHOPs = none MC1 requests allocation and receives, for example: * DAG Locator: 2001:db8:1::/48 * DAG SID: 2001:db8:1:e001:: * SID structure metadata: BL 32, LNL 16, LFL 16, AL 64 * Endpoint behavior: END.X with Next-C-SID, PSP & USD Abhishek & Jayant Expires 7 January 2027 [Page 13] Internet-Draft SRv6 for MPTE July 2026 A.3. Example Junction Signaling Intent For DAG1 version 1: * Ingress1: install encapsulation context with destination address 2001:db8:1:e001:: and service SID context in SRH (Section 5.1). * T1/T2/T3/T4: install DAG Locator route 2001:db8:1::/48 with signaled NHOP sets for forwarding at transit junctions (non-penultimate hops) (Section 5.2). * PHP1/PHP2: install terminating route 2001:db8:1:e001::/80 with END.X with Next-C-SID, PSP & USD and NHOP to Egress1 for penultimate behavior (Section 5.3). This /80 route performs DAG SID termination with SRH operation if required. The same route with 2001:db8:1:e001::/64 prefix is also installed to handle termination with END.X with Next-C-SID, PSP & USD and no SRH operation. * Egress1: no per-DAG transport-route programming is required; service SID handling is applied (Section 5.4). A.3.1. SID Structure Example In this deployment example, Compressed SRv6 SID is used with: Locator Block Length (LBL): 32 Locator Node Length (LNL): 16 Locator Function Length (LFL): 16 Argument Length: 128 - (LBL + LNL + LFL) The same approach works with Traditional SRv6 SIDs. In that case, the route prefixes and prefix-length follow Traditional SID requirements. A.4. Example Route Programming Ingress1 tunnel route example: * destination: Egress1 loopback prefix * tunnel encapsulation DA: 2001:db8:1:e001:: * outgoing next hop: toward T1 Transit route example: * 2001:db8:1::/48 -> NHOP set per DAG signaling (IPv6 forwarding with weighted ECMP at transit junctions (non-penultimate hops)) Penultimate route examples: * 2001:db8:1:e001::/80 -> NHOP Egress1, endpoint behavior END.X with Next-C-SID, PSP & USD (DAG SID termination at penultimate nodes, SRH operation, Forward on DAG programmed NHOPs) * 2001:db8:1:e001::/64 -> NHOP Egress1, endpoint behavior END.X with Next-C-SID, PSP & USD (DAG SID termination at penultimate nodes, Forward on DAG programmed NHOPs) Abhishek & Jayant Expires 7 January 2027 [Page 14] Internet-Draft SRv6 for MPTE July 2026 A.5. Packet Walk Example Ingress1 transmits: [SA: Ingress1-lo0, DA: 2001:db8:1:e001:: Next-Header: 43 TTL=64] [SRH: SL=1, s[0]:2001:db8:1:9000:e111::] [payload] T1/T2/T3/T4 perform IPv6 forwarding with weighted ECMP and TTL decrement without DAG SID termination. PHP1/PHP2 match 2001:db8:1:e001::/80, execute termination behavior, update SRH state, and forward: [SA: Ingress1-lo0, DA: 2001:db8:1:9000:e111:: Next-Header: Payload TTL=60] [payload] Egress1 applies service SID processing (for example DT4 behavior) and forwards to service table. No additional in-domain DAG-specific SRv6 SID stacking is required. A.6. Update Behavior Example If T2-T4 fails, implementation may temporarily steer only via T3 while DAG1 version2 is signaled. If a better T2-T4 path appears, DAG1 version3 may include additional T4 adjacency entries; updated junction state is signaled and applied with implementation-specific make-before-break behavior. A.7. Inter-AS Example For end-to-end multi-domain realization, ingress may include a next- domain transport SID in SRH. [SA: Ingress1-lo0, DA: 2001:db8:1:e001:: Next-Header: 43 TTL=64] [SRH: SL=2, s[0]:2001:db8:1:9000:e111::, s[1]:] [payload] Private DAG locators are not leaked between domains. Abhishek & Jayant Expires 7 January 2027 [Page 15] Internet-Draft SRv6 for MPTE July 2026 Authors' Addresses Abhishek Chakraborty HPE Sy. No. 192, Whitefield Road Mahadevapura, Bengaluru Karnataka 560048 India Email: abhishek.chakraborty.ietf@gmail.com Jayant Kumar Agarwal HPE Sy. No. 192, Whitefield Road Mahadevapura, Bengaluru Karnataka 560048 India Email: jayant.agarwal.ietf@gmail.com Vishnu Pavan Beeram HPE 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: vishnupavan.ietf@gmail.com Abhishek & Jayant Expires 7 January 2027 [Page 16]