SRv6 for Multipath Traffic Engineering
draft-ajp-spring-srv6-mpte-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Abhishek Chakraborty , Jayant Kumar Agarwal , Vishnu Pavan Beeram | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ajp-spring-srv6-mpte-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8402>.
[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,
<https://www.rfc-editor.org/info/rfc8754>.
[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,
<https://www.rfc-editor.org/info/rfc8986>.
[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, <https://www.rfc-editor.org/info/rfc9800>.
[I-D.kompella-teas-mpte]
Kompella, K., et al., "Multipath Traffic Engineering",
Work in Progress, Internet-Draft,
draft-kompella-teas-mpte, 2026,
<https://datatracker.ietf.org/doc/html/
draft-kompella-teas-mpte>.
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,
<https://datatracker.ietf.org/doc/html/
draft-beeram-pce-pcep-mpted-01>.
[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,
<https://datatracker.ietf.org/doc/html/
draft-kbr-teas-mptersvp-03>.
[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,
<https://datatracker.ietf.org/doc/html/
draft-zzhang-idr-mpte-signaling-00>.
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,
<https://www.rfc-editor.org/info/rfc9256>.
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]:<next-domain-transport-sid>]
[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]