| Internet-Draft | SRv6 for MPTE | July 2026 |
| Chakraborty, et al. | Expires 21 January 2027 | [Page] |
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 as described in 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.¶
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 21 January 2027.¶
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.¶
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.¶
[I-D.stone-spring-mpte-sr] describes an approach for realizing MPTE in Segment Routing networks using SR Policy and Binding SID (BSID) constructs at each junction node, managed by a centralized controller. That approach is general to SR and applies to both SR-MPLS and SRv6 data planes. When a globally consistent BSID value is used across all junction nodes in [I-D.stone-spring-mpte-sr], this may appear structurally similar to the DAG Locator concept in this document, as both associate a single per-DAG identifier across junction nodes. However, the two constructs differ fundamentally in forwarding behavior: in [I-D.stone-spring-mpte-sr], each transit junction resolves the BSID to invoke a per-junction SR Policy, whereas in this document, transit junctions perform plain IPv6 forwarding on the DAG Locator prefix and do not execute any Endpoint Behavior at transit nodes.¶
[I-D.saad-teas-rsvpte-ip-tunnels] in Section 3.9, SRv6-Tunnel describes the Egress Address Block (EAB) approach which uses an EAB address from a dedicated non-IGP-advertised SRv6 Locator at the egress. Transit nodes forward packets toward the EAB using standard IPv6 forwarding on signaling-programmed routes, without performing any SRv6 Endpoint Behavior. The DAG Locator concept in this document shares a related characteristic: like the EAB, it uses a privately scoped Locator that is absent from the IGP, with transit nodes performing plain IPv6 forwarding on signaling-programmed routes.¶
This document contributes an SRv6-native realization path for MPTE that is intended to align with ongoing WG direction and operational needs. Each MPTED uses a unique DAG Locator and a unique DAG SID as SRv6 forwarding context to program and operate MPTE junction state. This realization leverages native IPv6 forwarding semantics at transit junctions to forward on a DAG Locator prefix with weighted ECMP and SRv6 semantics at penultimate-hop junctions to terminate a DAG SID. This approach natively supports multiple egress nodes within a single MPTED. No Binding SIDs or per-junction SR Policies are required, resulting in simpler per-node state and avoiding additional SRv6 encapsulation at transit junctions.¶
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.¶
This document reuses terminology from [I-D.kompella-teas-mpte], [RFC8754], [RFC8986], and [RFC9800].¶
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:¶
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.¶
Each Allocation Function is assigned one or more unique SRv6 block(s), referred to in this document as DAG Blocks.¶
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.¶
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.¶
As described in [I-D.kompella-teas-mpte], the MPTED Computer (MC) is the entity that computes the MPTED. The MC can be either:¶
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.¶
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:¶
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.¶
This section describes the end-to-end operational flow of the SRv6 MPTE realization defined in this document. The working principles are organized around the following functional roles.¶
This realization uses only existing SRv6 behaviors and does not define new SRv6 Endpoint Behaviors.¶
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:¶
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.¶
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.¶
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.¶
Ingress programming installs tunnel encapsulation context for the selected MPTED:¶
Ingress does not require DAG-specific transit SID stacking for in-domain transport beyond the DAG Locator/SID realization described in this document.¶
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.¶
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.¶
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.¶
Implementations MAY either:¶
In all cases, signaling and forwarding state MUST remain consistent for DAG identity, version, and DAG Locator/SID context.¶
Deployments MAY simplify operations while preserving the working principles described in this section. Two approaches are common:¶
For the second approach, additional programming semantics will be clarified in a future version of this draft.¶
Section 4 defines functional roles and programming intent. This section defines the resulting packet-forwarding behavior at each node type.¶
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.¶
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.¶
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 two terminations at any node in a domain.¶
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.¶
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.¶
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.¶
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.¶
Full inter-domain forwarding mechanics and state synchronization requirements are subject to further clarification and will be detailed in a future revision of this document.¶
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].¶
This document has no IANA actions.¶
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.¶
TBD¶
This appendix illustrates one deployment realization aligned with the approach in this document.¶
|-- 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.¶
For a request sourced at Ingress1 and destined to Egress1, MC1 computes:¶
MC1 requests allocation and receives, for example:¶
For DAG1 version 1:¶
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.¶
Ingress1 tunnel route example:¶
Transit route example:¶
Penultimate route examples:¶
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.¶
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.¶
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]:<next-domain-transport-sid>]
[payload]
¶
Private DAG Locators are not leaked between domains.¶
The authors would like to acknowledge Shraddha Hegde, Bharath R and Rajesh Shetty for their valuable inputs.¶