Applicability of EVPN Assisted Replication to SRv6 Tunnels
draft-rabadan-bess-evpn-srv6-ar-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 | Jorge Rabadan , Senthil Sathappan , Sasha Vainshtein , W. Lin | ||
| Last updated | 2026-08-01 | ||
| 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-rabadan-bess-evpn-srv6-ar-00
BGP Enabled ServiceS J. Rabadan, Ed.
Internet-Draft S. Sathappan
Intended status: Standards Track Nokia
Expires: 2 February 2027 A. Vainshtein
Ribbon Communications
W. Lin
HPE
1 August 2026
Applicability of EVPN Assisted Replication to SRv6 Tunnels
draft-rabadan-bess-evpn-srv6-ar-00
Abstract
Assisted Replication (AR) is an optimized ingress replication
solution for Ethernet VPN (EVPN) Broadcast and Multicast (BM)
traffic. AR offloads the replication effort from ingress Network
Virtualization Edge (NVE) devices onto Assisted Replication
Replicators (AR-REPLICATORs). The base AR specification is focused
on Network Virtualization Overlay (NVO) networks that use IP tunnels,
and it is typically deployed for Virtual eXtensible Local Area
Network (VXLAN). EVPN services can also be instantiated over Segment
Routing over IPv6 (SRv6); however, the SRv6 EVPN transport
specification supports only ingress replication for BUM traffic, and
the AR procedures rely on IP-tunnel semantics (such as the tunnel
source and destination IP addresses) that do not map exactly to an
SRv6 data plane. As a result, AR cannot be readily deployed over
SRv6 tunnels.
This document specifies the applicability of Assisted Replication to
SRv6 tunnels, for EVPN BM traffic, for selective multicast based on
Internet Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) proxy, and for EVPN IP multicast traffic based on
Optimized Inter-Subnet Multicast (OISM). It defines a new SRv6
Endpoint behavior for the AR-REPLICATOR role and the associated
control-plane procedures, so that the AR solution can be used with an
SRv6 underlay.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://jorabada.github.io/draft-evpn-srv6-ar/draft-rabadan-bess-
evpn-srv6-ar.html. Status information for this document may be found
at https://datatracker.ietf.org/doc/draft-rabadan-bess-evpn-srv6-ar/.
Rabadan, et al. Expires 2 February 2027 [Page 1]
Internet-Draft EVPN AR for SRv6 August 2026
Discussion of this document takes place on the BGP Enabled ServiceS
Working Group mailing list (mailto:bess@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/bess/. Subscribe at
https://www.ietf.org/mailman/listinfo/bess/.
Source for this draft and an issue tracker can be found at
https://github.com/jorabada/draft-evpn-srv6-ar.
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 2 February 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
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
3. Assisted Replication over SRv6: Control Plane . . . . . . . . 7
3.1. SRv6 SID Advertisement for the AR Roles . . . . . . . . . 7
3.2. Non-Selective and Selective Assisted Replication . . . . 8
Rabadan, et al. Expires 2 February 2027 [Page 2]
Internet-Draft EVPN AR for SRv6 August 2026
4. Assisted Replication over SRv6: Data Plane . . . . . . . . . 8
4.1. AR-LEAF Encapsulation . . . . . . . . . . . . . . . . . . 9
4.2. The End.DT2M.AR SRv6 Endpoint Behavior . . . . . . . . . 9
4.3. Split-Horizon Filtering and Loop Avoidance . . . . . . . 11
5. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. OISM and IP Multicast over SRv6 with Assisted Replication . . 13
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Data Center . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Wide Area and Inter-Data-Center . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. SRv6 Endpoint Behavior . . . . . . . . . . . . . . . . . 14
8.2. PMSI Tunnel Types and Flags . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Ethernet VPN (EVPN) [RFC7432] distributes BUM traffic within a
Broadcast Domain (BD) by means of a set of Provider Multicast Service
Interface (PMSI) tunnels that are advertised in the Inclusive
Multicast Ethernet Tag (IMET) route (EVPN route type 3). When
ingress replication (IR) is used, the ingress Network Virtualization
Edge (NVE) or Provider Edge (PE) device sends a separate copy of each
BUM packet to every remote PE that advertised an IMET route for the
BD. IR places the entire replication load on the ingress PE, which
often means that multiple copies of the same BUM packet are sent over
the same link.
Assisted Replication (AR) [RFC9574] optimizes ingress replication by
allowing an Assisted Replication Leaf (AR-LEAF) to send a single copy
of each BM packet to an AR-REPLICATOR, which then replicates the
traffic on the AR-LEAF's behalf to the remaining PEs of the BD, as
well as to its own local Attachment Circuits (ACs). As in [RFC9574],
the AR procedures apply to BM traffic only; unknown unicast follows
the regular unicast forwarding procedures. [RFC9574] defines two AR
replication modes, non-selective and selective, and the control-plane
extensions required to discover the AR roles and to build the
associated replication trees.
Rabadan, et al. Expires 2 February 2027 [Page 3]
Internet-Draft EVPN AR for SRv6 August 2026
EVPN services can be deployed over an SRv6 [RFC8986] data plane, as
specified in [RFC9252]. Over SRv6, EVPN BUM traffic is carried using
ingress replication: the IMET route advertises an End.DT2M SRv6
Service Segment Identifier (SID) [RFC8986] in the SRv6 Layer 2 (L2)
Service Type-Length-Value (TLV) of the Border Gateway Protocol (BGP)
Prefix-SID attribute, and the ingress PE replicates a copy of each
BUM packet towards the End.DT2M SID of every remote PE.
1.1. Problem Statement
Although both AR [RFC9574] and EVPN-over-SRv6 [RFC9252] are widely
applicable, an implementor cannot deploy AR over an SRv6 underlay
today because of a number of gaps in the referenced specifications:
* The AR solution in [RFC9574] is, by construction, bound to IP
tunnels. [RFC9574] states that the solution is "focused on NVO
networks (hence its use of IP tunnels)" and that it is independent
of the data-plane encapsulation "as long as the tunnel is IP
based". The procedures rely on IP-tunnel semantics that have no
direct SRv6 equivalent:
- The AR-REPLICATOR is identified by two IP addresses, an Ingress
Replication IP address (IR-IP) (for regular ingress
replication) and an Assisted Replication IP address (AR-IP)
(for AR replication), and the forwarding mode is selected by
the receiving node based on the outer IP Destination Address
(DA) of the packet (AR-IP versus IR-IP), see Section 5 of
[RFC9574].
- The optional single-IP fallback (Section 8 of [RFC9574])
selects the forwarding mode based on a VXLAN Virtual Network
Identifier (VNI) (an AR-VNI versus an IR-VNI), which is
specific to VXLAN.
* [RFC9252] specifies how EVPN BUM traffic is carried over SRv6 by
signaling an End.DT2M Segment Identifier (SID) in the IMET route,
but it does not define Assisted Replication roles or an AR-
specific SRv6 endpoint behavior.
* The End.DT2M behavior (Section 4.12 of [RFC8986]) decapsulates the
received packet and floods the exposed Ethernet frame to the local
L2 Output Interfaces (OIFs) of the associated L2 table, excluding
the OIFs identified by the Arg.FE2 argument (for split-horizon
filtering). End.DT2M does not include any step that re-
encapsulates and re-replicates the frame back into the overlay
towards remote PEs. An AR-REPLICATOR needs precisely that
additional capability.
Rabadan, et al. Expires 2 February 2027 [Page 4]
Internet-Draft EVPN AR for SRv6 August 2026
* EVPN Optimized Inter-Subnet Multicast (OISM) [RFC9625] already
accommodates the AR roles at the control plane (an AR-REPLICATOR
is provisioned with the Supplementary Broadcast Domain (SBD)), but
OISM identifies the "apparent source BD" of a received packet from
a Multiprotocol Label Switching (MPLS) label or a VXLAN VNI. No
SRv6 encoding is specified.
1.2. Solution Overview
This document specifies the applicability of Assisted Replication to
SRv6 tunnels for EVPN BM traffic and for EVPN IP multicast traffic
(OISM), by making the following changes and clarifications:
* A new SRv6 Endpoint behavior, "End.DT2M with Assisted Replication"
(End.DT2M.AR for short), is defined for the AR-REPLICATOR role.
It is a variant of the End.DT2M behavior: it performs the End.DT2M
local L2 flooding and, in addition, re-replicates the decapsulated
BM frame towards the remote PEs of the BD. See Section 4.
* An AR-REPLICATOR advertises an SRv6 SID associated with the
End.DT2M.AR behavior (referred to as the Assisted Replication
Segment Identifier (AR-SID)) in its Replicator-AR IMET route, and
a regular End.DT2M SID in its Regular-IR IMET route. This two-SID
model is the SRv6 analog of the AR-IP versus IR-IP model of
[RFC9574]. Because SRv6 SIDs are readily available, the two-SID
model also removes the need for the single-IP/VNI fallback of
Section 8 of [RFC9574]. See Section 3.
* The forwarding mode and the loop-avoidance signaling that
[RFC9574] encodes in the outer IP DA are, over SRv6, encoded in
the choice of destination SID: an AR-LEAF sends BM traffic to a
replicator's AR-SID (End.DT2M.AR), whereas an AR-REPLICATOR re-
replicates towards each remote PE's regular End.DT2M SID, so that
the receiving PE floods locally and does not re-replicate. See
Section 4.
* Split-horizon filtering for multihoming MAY use the SRv6 Arg.FE2
argument of the End.DT2M SID, signaled as specified in [RFC9252]
and [RFC9819]. The multihoming procedures of
[I-D.ietf-bess-extended-evpn-optimized-ir] apply over SRv6 with
the clarifications in Section 5.
The control-plane role discovery of [RFC9574], including the PMSI
Tunnel attribute [RFC6514] Assisted-Replication tunnel type and its
flags, and the selective-AR Leaf Auto-Discovery (A-D) route
procedures, are reused unchanged. Only the tunnel identification (an
SRv6 SID instead of an IP address or VNI) and the data-plane behavior
are modified.
Rabadan, et al. Expires 2 February 2027 [Page 5]
Internet-Draft EVPN AR for SRv6 August 2026
Assisted Replication is an optimization of ingress replication. It
is distinct from, and complementary to, tree-based replication
approaches such as SRv6 replication segments (the End.Replicate
behavior [RFC9524]) and Segment Routing (SR) Point-to-Multipoint
trees for Ethernet VPN (EVPN) and Multicast VPN (MVPN)
[I-D.ietf-bess-mvpn-evpn-sr-p2mp], which are out of scope of this
document.
2. Terminology and Conventions
This document uses the terminology of [RFC7432], [RFC9574],
[RFC9252], [RFC8986], and [RFC9625]. The following terms are used
frequently:
AR: Assisted Replication, as defined in [RFC9574].
AR-REPLICATOR: Assisted Replication Replicator, an NVE/PE that
replicates BM traffic received on overlay tunnels to other overlay
tunnels and to local ACs, on behalf of AR-LEAF nodes, as defined
in [RFC9574].
AR-LEAF: Assisted Replication Leaf, an NVE/PE that sends all its BM
traffic to an AR-REPLICATOR for further replication, as defined in
[RFC9574].
RNVE: Regular Network Virtualization Edge (RNVE), an NVE that
supports [RFC8365] but not the AR procedures of [RFC9574].
BD: Broadcast Domain.
BUM: Broadcast, unknown unicast, and Multicast traffic. As in
[RFC9574], the AR procedures apply to Broadcast and Multicast (BM)
traffic; unknown unicast follows the regular unicast forwarding
procedures.
BM: Broadcast and Multicast traffic, excluding unknown unicast
frames, as defined in [RFC9574].
End.DT2M: The SRv6 Endpoint behavior "Endpoint with decapsulation
and L2 table flooding" defined in Section 4.12 of [RFC8986].
End.DT2M.AR: The SRv6 Endpoint behavior "End.DT2M with Assisted
Replication" defined in this document (Section 4) for the AR-
REPLICATOR role.
AR-SID: Assisted Replication Segment Identifier (AR-SID), an SRv6
Service SID instantiated with the End.DT2M.AR behavior and
advertised by an AR-REPLICATOR.
Rabadan, et al. Expires 2 February 2027 [Page 6]
Internet-Draft EVPN AR for SRv6 August 2026
Arg.FE2: The argument of the End.DT2M (and End.DT2M.AR) SID that
provides a local mapping to an Ethernet Segment Identifier (ESI)
for split-horizon filtering, as defined in Section 4.12 of
[RFC8986] and signaled per [RFC9252] and [RFC9819].
SBD: Supplementary Broadcast Domain, as defined in [RFC9625].
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.
3. Assisted Replication over SRv6: Control Plane
The control-plane roles, discovery, and replication modes of
[RFC9574] are reused for SRv6, with the changes described in this
section. In particular:
* The IMET route Network Layer Reachability Information (NLRI) is
not modified.
* The PMSI Tunnel attribute is used as defined in [RFC9574]: the
Assisted-Replication tunnel type (value 0x0A) and the flags (the
Assisted-Replication Type "T" field, the BM and U Pruned-Flood-
List flags, and the "L" Leaf Information Required flag) are used
unchanged.
* The selective-AR procedures, including the use of the Leaf A-D
route [RFC9572] and the IP-address-specific Route Target (RT)
derived from the AR-REPLICATOR address, are reused as specified in
[RFC9574].
3.1. SRv6 SID Advertisement for the AR Roles
Over an SRv6 data plane, the roles that [RFC9574] assigns to the IR-
IP and the AR-IP are played by two distinct SRv6 Service SIDs
advertised in the SRv6 L2 Service TLV of the BGP Prefix-SID attribute
[RFC9252]:
* Regular-IR IMET route: an AR-LEAF, an AR-REPLICATOR, and an RNVE
advertise a Regular-IR IMET route as defined in [RFC9252],
carrying an SRv6 Service SID with the End.DT2M Endpoint behavior.
This SID is the SRv6 analog of the IR-IP. An AR-LEAF sets the "T"
field of the PMSI Tunnel attribute of this route to AR-LEAF, as
specified in [RFC9574].
Rabadan, et al. Expires 2 February 2027 [Page 7]
Internet-Draft EVPN AR for SRv6 August 2026
* Replicator-AR IMET route: an AR-REPLICATOR advertises, in
addition, a Replicator-AR IMET route with the Assisted-Replication
tunnel type (0x0A) in the PMSI Tunnel attribute, the "T" field set
to AR-REPLICATOR, and the "L" flag set according to the
replication mode (0 for non-selective, 1 for selective). This
route carries an SRv6 Service SID with the End.DT2M.AR Endpoint
behavior. This SID is referred to as the AR-SID and is the SRv6
analog of the AR-IP.
For these EVPN routes, the BGP Next Hop MUST be set to the IPv6
address of the advertising PE that is used as the Source Address of
the outer IPv6 header when encapsulating BM traffic, as specified in
[RFC9252].
The AR-SID advertised in the Replicator-AR route MUST be different
from the End.DT2M SID advertised by the same AR-REPLICATOR in its
Regular-IR route, and MUST be associated with the End.DT2M.AR
Endpoint behavior. Because the two roles are distinguished by two
distinct SIDs and Endpoint behaviors, the single-IP AR-REPLICATOR
procedures of Section 8 of [RFC9574] (which distinguish the roles by
an AR-VNI versus an IR-VNI) are not needed and are not used over
SRv6.
An AR-LEAF discovers the AR-REPLICATORs of a BD, and the AR-SID to
use, from the received Replicator-AR IMET routes, exactly as in
[RFC9574], except that the AR-SID is taken from the SRv6 L2 Service
TLV rather than from the Next Hop / Originating Router's IP address.
3.2. Non-Selective and Selective Assisted Replication
The non-selective and selective replication modes are used as defined
in Sections 5 and 6 of [RFC9574], respectively. For selective AR,
the AR-LEAF sends a Leaf A-D route [RFC9572] in response to a
Replicator-AR route with the "L" flag set, as specified in [RFC9574].
When the Leaf A-D route is used over SRv6, it carries the AR-LEAF's
SRv6 Service SID (End.DT2M behavior) in the SRv6 L2 Service TLV that
the selective AR-REPLICATOR uses to replicate towards that AR-LEAF,
instead of a downstream-assigned MPLS label or VNI.
For the Leaf A-D route, the BGP Next Hop MUST be set to the IPv6
address of the advertising AR-LEAF that is used as the Source Address
of the outer IPv6 header when encapsulating BM traffic, as specified
in [RFC9252].
4. Assisted Replication over SRv6: Data Plane
Rabadan, et al. Expires 2 February 2027 [Page 8]
Internet-Draft EVPN AR for SRv6 August 2026
4.1. AR-LEAF Encapsulation
When an AR-LEAF has selected an AR-REPLICATOR for a given BD (per the
procedures of [RFC9574]), it sends a single copy of each BM packet to
that AR-REPLICATOR. The AR-LEAF encapsulates the customer Ethernet
frame using the H.Encaps.L2 or H.Encaps.L2.Red behavior [RFC8986],
with the destination address set to the AR-SID (End.DT2M.AR)
advertised by the selected AR-REPLICATOR, as it would for a regular
End.DT2M SID in [RFC9252].
An AR-LEAF that is multihomed to one or more Ethernet Segments (ESs)
follows the additional procedures in Section 5 for the peers with
which it shares an ES.
4.2. The End.DT2M.AR SRv6 Endpoint Behavior
The "End.DT2M with Assisted Replication" behavior (End.DT2M.AR for
short) is a variant of the End.DT2M behavior (Section 4.12 of
[RFC8986]). As with End.DT2M, any SID instance of this behavior is
associated with an L2 table T and takes the Arg.FE2 argument for
split-horizon filtering; the End.DT2M applications of EVPN BUM
bridging with ESI filtering [RFC7432] and EVPN Ethernet Tree (E-Tree)
[RFC8317] also apply to End.DT2M.AR.
An End.DT2M.AR SID is instantiated only on an AR-REPLICATOR. In
addition to the End.DT2M local L2 flooding, the behavior re-
replicates the decapsulated BM frame towards the set of remote PEs of
the BD (the BM flood list of table T), so that replication is
performed on behalf of the AR-LEAF that sent the packet.
When N receives a packet whose IPv6 DA is S and S is a local
End.DT2M.AR SID, the processing is identical to the End.DX2 behavior
in [RFC8986] except for the Upper-Layer header processing, which is
as follows:
Rabadan, et al. Expires 2 February 2027 [Page 9]
Internet-Draft EVPN AR for SRv6 August 2026
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Let SA be the IPv6 Source Address of the outer IPv6 header
S03. Remove the outer IPv6 header with all its extension headers
S04. Forward via all local L2 OIFs excluding those associated
with the identifier Arg.FE2
S05. For each remote PE P in the BM flood list of table T {
S06. If (P is the PE from which the packet was received) continue
S07. Let D be the destination SID to use for P (see below)
S08. Encapsulate a copy of the exposed frame via H.Encaps.L2
(or H.Encaps.L2.Red) with IPv6 DA = D
S09. Forward the copy towards D
S10. }
S11. } Else {
S12. Process as per Section 4.1.1 of RFC 8986
S13. }
The destination SID D used in step S07 is determined as follows:
* For non-selective AR, and for the AR-LEAF nodes and RNVE nodes
that a selective AR-REPLICATOR replicates to directly, D is the
remote PE's End.DT2M SID (as advertised in that PE's Regular-IR
IMET route). Because that SID is associated with the End.DT2M
behavior (not End.DT2M.AR), the receiving PE floods the frame to
its local L2 OIFs only and does not re-replicate it, which
prevents loops and duplicate delivery. This is the SRv6
equivalent of an AR-REPLICATOR setting the outer IP DA to a remote
node's IR-IP in [RFC9574].
* For selective AR, when a two-hop replication tree is used between
AR-REPLICATORs of different AR-LEAF-sets (Section 6 of [RFC9574]),
D is the other AR-REPLICATOR's AR-SID (End.DT2M.AR), so that the
second AR-REPLICATOR further replicates to the AR-LEAFs of its
set. As in [RFC9574], a given BM packet traverses at most two AR-
REPLICATORs.
An AR-LEAF that advertises both a Regular-IR IMET route and a Leaf
A-D route for selective AR MUST carry the same SRv6 L2 Service SID
with the End.DT2M behavior in both routes. A selective AR-REPLICATOR
uses the SID from the received Leaf A-D route as D when re-
replicating towards that AR-LEAF; that SID MUST match the End.DT2M
SID advertised in the AR-LEAF's Regular-IR IMET route.
Step S06 enforces that an AR-REPLICATOR MUST NOT replicate a BM
packet back towards the PE from which it was received. That source
PE is identified by the AR-REPLICATOR using the incoming information
available for the received packet (for example, the IPv6 Source
Address SA saved in step S02, together with the control-plane state
that associates that IPv6 address with the originating PE).
Rabadan, et al. Expires 2 February 2027 [Page 10]
Internet-Draft EVPN AR for SRv6 August 2026
When re-replicating, the AR-REPLICATOR MAY preserve, in the outer
IPv6 Source Address of each copy, the IPv6 Source Address of the
originating AR-LEAF; otherwise it uses one of its own IPv6 addresses.
Split-horizon filtering for multihoming relies on that source address
when local-bias filtering is used, and on the Arg.FE2 argument
otherwise, as specified in [RFC9746] and described in Section 4.3 and
Section 5.
A new Endpoint behavior is defined, rather than reusing End.DT2M with
an additional argument, for two reasons. First, the End.DT2M
definition in [RFC8986] performs only local L2 flooding after
decapsulation and does not contemplate re-encapsulating the frame
into SRv6 towards remote PEs. Second, encoding the AR role in an
argument would not be compatible with the existing End.DT2M arguments
already used by [RFC9252] for ESI-based split-horizon filtering
(Arg.FE2) and for EVPN E-Tree [RFC8317].
4.3. Split-Horizon Filtering and Loop Avoidance
Over SRv6, split-horizon filtering for EVPN BM traffic may use either
local-bias filtering or ESI filtering based on the Arg.FE2 argument
of the End.DT2M SID, as selected per [RFC9746]. The choice affects
how a multihomed AR-LEAF and an AR-REPLICATOR handle BM traffic, as
follows.
When Arg.FE2-based ESI filtering is used, as specified in Section 6.3
of [RFC9252] and [RFC9819], a multihomed egress PE advertises the
Arg.FE2 value associated with a shared ES, and the ingress PE encodes
that argument into the egress PE's End.DT2M SID at the ARG offset
indicated by the SID structure before encapsulating, so that the
egress PE prunes the OIF(s) of that ES from the L2 flooding. In that
case, split-horizon filtering is independent of the tunnel source IP
address, and the source-IP-based restrictions of Section 9.1 of
[RFC9574] (including the recommendation to preserve the tunnel source
IP address and to disable unicast Reverse Path Forwarding (uRPF)) do
not apply. With Assisted Replication, however, the AR-REPLICATOR
would need to encode the Arg.FE2 that corresponds to the originating
AR-LEAF's shared ES(es) on each re-replicated copy. To avoid
requiring the AR-REPLICATOR to track that ES membership per flow, a
multihomed AR-LEAF uses the procedures of Section 5: it sends copies
directly (via regular ingress replication, applying the appropriate
Arg.FE2) to the PEs with which it shares an ES, and uses the AR-
REPLICATOR only for the remaining PEs, with which no ES is shared and
for which split-horizon filtering is therefore not required.
When local-bias filtering is used instead, split-horizon filtering
relies on the outer IPv6 Source Address as specified in [RFC9746]. A
multihomed AR-LEAF MAY still send its BM traffic to the AR-
Rabadan, et al. Expires 2 February 2027 [Page 11]
Internet-Draft EVPN AR for SRv6 August 2026
REPLICATOR, and the AR-REPLICATOR MAY preserve the originating AR-
LEAF's IPv6 Source Address when re-replicating, as described above,
so that egress PEs can apply local-bias filtering. In that case, the
source-IP-based considerations of Section 9.1 of [RFC9574] remain
applicable, and the direct-copy procedures of Section 5 are not
required for split-horizon filtering.
Loop avoidance follows the same principle as in [RFC9574]: a
receiving node re-replicates only when the traffic is received on an
End.DT2M.AR SID; when it is received on an End.DT2M SID it is flooded
locally only. An AR-REPLICATOR never sends a copy back to the PE
from which the packet was received.
5. Multihoming
The multihoming procedures for Assisted Replication defined in
[I-D.ietf-bess-extended-evpn-optimized-ir] apply to SRv6 tunnels.
That specification addresses the case in which an AR-REPLICATOR
cannot retain the source identity required for EVPN split-horizon
filtering when it replicates on behalf of a multihomed AR-LEAF, by
having the multihomed AR-LEAF deliver a copy, via regular ingress
replication, to each remote PE with which it shares a multihomed ES,
while the AR-REPLICATOR skips those PEs.
Over SRv6, this procedure applies with the following clarifications:
* The direct copies that the multihomed AR-LEAF sends to the PEs
with which it shares an ES are encapsulated towards those PEs'
End.DT2M SIDs, with the appropriate Arg.FE2 encoded as described
in Section 4.3.
* The AR-REPLICATOR, when re-replicating on behalf of that AR-LEAF,
skips the PEs that are in the shared-ES list of the AR-LEAF, as
specified in [I-D.ietf-bess-extended-evpn-optimized-ir]. For the
remaining PEs (with which the AR-LEAF shares no ES), no Arg.FE2
needs to be applied.
* The Extended Multihoming Assisted Replication (Extended-MH-AR)
capability flag defined in
[I-D.ietf-bess-extended-evpn-optimized-ir] is advertised and
interpreted unchanged; it is independent of the underlay
encapsulation.
The Designated Forwarder (DF) election procedures of [RFC7432] and
[RFC8365] are not modified by this document.
Rabadan, et al. Expires 2 February 2027 [Page 12]
Internet-Draft EVPN AR for SRv6 August 2026
6. OISM and IP Multicast over SRv6 with Assisted Replication
EVPN Optimized Inter-Subnet Multicast (OISM) [RFC9625] forwards IP
multicast traffic within a Tenant Domain, building on EVPN inter-
subnet forwarding [RFC9135], using the same IMET-advertised tunnels
used for BUM traffic, augmented with the Supplementary Broadcast
Domain (SBD) and the Selective Multicast Ethernet Tag (SMET) route
[RFC9251]. OISM already defines the AR roles for IP multicast
(Section 3.2.3 of [RFC9625]): each PE (including the AR-REPLICATOR)
attached to the Tenant Domain originates an SBD-IMET route and IMET
routes for its attached BDs, and the AR-REPLICATOR is provisioned
with the SBD.
When the underlay is SRv6, OISM IP multicast with Assisted
Replication uses the procedures of Section 3 and Section 4, applied
to both the regular BD IMET routes and the SBD-IMET routes:
* An AR-REPLICATOR originates a Replicator-AR IMET route for each BD
to which it is attached, and an SBD-IMET route for the Tenant
Domain, each carrying an AR-SID (End.DT2M.AR) as described in
Section 3. An AR-LEAF (and any other PE) originates Regular-IR
IMET routes for its attached BDs and an SBD-IMET route, each
carrying an End.DT2M SID as in [RFC9252]. The PTA flags of those
routes are set as specified in Section 3.2.3 of [RFC9625] and
[RFC9574].
* When an ingress AR-LEAF needs to send an IP multicast frame from a
particular source BD, it selects an AR-REPLICATOR that originated
an IMET route for that BD and sends a single copy of the frame to
that AR-REPLICATOR's AR-SID from the selected BD IMET route. The
AR-REPLICATOR re-replicates to the egress PEs using each egress
PE's End.DT2M SID for either the source BD or the SBD, as
determined by the OISM procedures of Section 3.2.3 of [RFC9625].
If the ingress AR-LEAF has not received any IMET route for that BD
from an AR-REPLICATOR, it follows the IR procedures of
Section 3.2.2 of [RFC9625].
In OISM, an egress PE derives the "apparent source BD" of a received
packet from the tunnel demultiplexer of the route that advertised the
tunnel (an MPLS label or a VXLAN VNI in [RFC9625]). Over SRv6, this
demultiplexer is the End.DT2M (or End.DT2M.AR) Service SID itself:
the SID on which the packet is received identifies the L2 table T and
thus the source BD or the SBD. Accordingly, an AR-REPLICATOR
selects, for each egress PE, the End.DT2M SID that the egress PE
advertised for the source BD when the egress PE is attached to that
BD, and the End.DT2M SID advertised for the SBD otherwise, mirroring
the label selection in Section 3.2.3 of [RFC9625].
Rabadan, et al. Expires 2 February 2027 [Page 13]
Internet-Draft EVPN AR for SRv6 August 2026
Selective forwarding based on SMET routes [RFC9251] is unchanged. As
noted in Section 3.2.6 of [RFC9625], when IR or AR is used there is
no need for Selective Provider Multicast Service Interface (S-PMSI)
A-D routes to provide selectivity; the SMET routes, together with the
IMET/SBD-IMET SIDs, provide it. The SMET route carries no tunnel
information and therefore requires no SRv6-specific encoding.
7. Use Cases
7.1. Data Center
In a Clos (leaf-and-spine) data center fabric running EVPN over SRv6,
Assisted Replication can be used when leaf PEs have limited BM
replication capabilities, and to avoid sending multiple BM copies of
the same packet over the same physical link. A spine (or a subset of
spines) can act as an AR-REPLICATOR, offloading BM and OISM IP
multicast replication from the leaves. Non-selective AR is typically
sufficient in 3-stage Clos fabrics; if desired, selective AR can be
used in 5-stage Clos fabrics. This is the SRv6 analog of the VXLAN
deployment described in [RFC9574].
7.2. Wide Area and Inter-Data-Center
In Wide Area Network (WAN) and inter-Data Center (inter-DC)
deployments where EVPN is carried natively over SRv6, selective AR
(Section 6 of [RFC9574]) can be used to build two-hop replication
trees between AR-REPLICATORs of different replication domains (AR-
LEAF-sets), limiting the replication fan-out at any single node. The
control-plane and data-plane procedures are those of Section 3 and
Section 4.
8. IANA Considerations
8.1. SRv6 Endpoint Behavior
This document requests IANA to allocate a new code point in the "SRv6
Endpoint Behaviors" registry, under the "Segment Routing" registry
group, for the End.DT2M.AR behavior defined in Section 4. The
allocation is requested from the range managed under the "First Come
First Served" policy.
+=======+=====+===================+===============+
| Value | Hex | Endpoint Behavior | Reference |
+=======+=====+===================+===============+
| TBD | TBD | End.DT2M.AR | This document |
+-------+-----+-------------------+---------------+
Table 1: Requested SRv6 Endpoint Behavior
Rabadan, et al. Expires 2 February 2027 [Page 14]
Internet-Draft EVPN AR for SRv6 August 2026
8.2. PMSI Tunnel Types and Flags
This document does not request any new PMSI Tunnel type or PMSI
Tunnel attribute flag. The Assisted-Replication tunnel type (value
0x0A) and the associated flags allocated by [RFC9574] are reused
unchanged.
9. Security Considerations
The security considerations of [RFC7432], [RFC9574], [RFC9252],
[RFC8986], [RFC9625], and [RFC9251] apply to this document.
The End.DT2M.AR behavior causes an AR-REPLICATOR to re-replicate BM
and IP multicast traffic into the SRv6 overlay. A node MUST
instantiate an End.DT2M.AR SID only for the AR-REPLICATOR role, and
SRv6 SIDs associated with this behavior MUST be reachable only from
within the trusted SRv6 domain. As with other SRv6 Service SIDs,
packets destined to an End.DT2M.AR SID SHOULD be filtered at the
domain boundary, as described in the security considerations of
[RFC8986] and [RFC8754], so that an off-domain attacker cannot inject
traffic that triggers replication. Failure to do so could allow an
attacker to cause traffic amplification by directing traffic to an
AR-REPLICATOR's AR-SID.
The loop-avoidance rules in Section 4 (re-replicate only for traffic
received on an End.DT2M.AR SID, never send a copy back to the source
PE, and use at most two AR-REPLICATOR hops) bound the replication so
that a single BM packet cannot be replicated indefinitely within the
domain.
Because split-horizon filtering over SRv6 relies on the Arg.FE2
argument rather than on the tunnel source IP address, the uRPF
considerations of Section 9.1 of [RFC9574] do not apply; an operator
can keep uRPF enabled in the SRv6 underlay independently of the AR
procedures.
10. References
10.1. Normative References
[I-D.ietf-bess-extended-evpn-optimized-ir]
Lin, W., Sivaraj, S., Garg, V., and J. Rabadan, "Extended
Procedures for EVPN Optimized Ingress Replication", Work
in Progress, Internet-Draft, draft-ietf-bess-extended-
evpn-optimized-ir-09, 29 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
extended-evpn-optimized-ir-09>.
Rabadan, et al. Expires 2 February 2027 [Page 15]
Internet-Draft EVPN AR for SRv6 August 2026
[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/rfc/rfc2119>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/rfc/rfc7432>.
[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/rfc/rfc8174>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/rfc/rfc8365>.
[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/rfc/rfc8986>.
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
and W. Lin, "Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Proxies for Ethernet
VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
<https://www.rfc-editor.org/rfc/rfc9251>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/rfc/rfc9252>.
[RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or
Multicast (BUM) Procedures", RFC 9572,
DOI 10.17487/RFC9572, May 2024,
<https://www.rfc-editor.org/rfc/rfc9572>.
[RFC9574] Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and
A. Sajassi, "Optimized Ingress Replication Solution for
Ethernet VPNs (EVPNs)", RFC 9574, DOI 10.17487/RFC9574,
May 2024, <https://www.rfc-editor.org/rfc/rfc9574>.
Rabadan, et al. Expires 2 February 2027 [Page 16]
Internet-Draft EVPN AR for SRv6 August 2026
[RFC9625] Lin, W., Zhang, Z., Drake, J., Rosen, E., Ed., Rabadan,
J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast
(OISM) Forwarding", RFC 9625, DOI 10.17487/RFC9625, August
2024, <https://www.rfc-editor.org/rfc/rfc9625>.
[RFC9746] Rabadan, J., Nagaraj, K., Lin, W., and A. Sajassi, "BGP
EVPN Multihoming Extensions for Split-Horizon Filtering",
RFC 9746, DOI 10.17487/RFC9746, March 2025,
<https://www.rfc-editor.org/rfc/rfc9746>.
[RFC9819] Talaulikar, K., Raza, K., Rabadan, J., and W. Lin,
"Argument Signaling for BGP Services in Segment Routing
over IPv6 (SRv6)", RFC 9819, DOI 10.17487/RFC9819, July
2025, <https://www.rfc-editor.org/rfc/rfc9819>.
10.2. Informative References
[I-D.ietf-bess-mvpn-evpn-sr-p2mp]
Parekh, R., Voyer, D., Filsfils, C., Bidgoli, H., and Z.
J. Zhang, "Multicast and Ethernet VPN with Segment Routing
P2MP and Ingress Replication", Work in Progress, Internet-
Draft, draft-ietf-bess-mvpn-evpn-sr-p2mp-18, 21 January
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
bess-mvpn-evpn-sr-p2mp-18>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/rfc/rfc6514>.
[RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J.,
Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree)
Support in Ethernet VPN (EVPN) and Provider Backbone
Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317,
January 2018, <https://www.rfc-editor.org/rfc/rfc8317>.
[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/rfc/rfc8754>.
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/rfc/rfc9135>.
Rabadan, et al. Expires 2 February 2027 [Page 17]
Internet-Draft EVPN AR for SRv6 August 2026
[RFC9524] Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
Z. Zhang, "Segment Routing Replication for Multipoint
Service Delivery", RFC 9524, DOI 10.17487/RFC9524,
February 2024, <https://www.rfc-editor.org/rfc/rfc9524>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Jorge Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Senthil Sathappan
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: senthil.sathappan@nokia.com
Alexander Vainshtein
Ribbon Communications
Email: Alexander.Vainshtein@rbbn.com
Wen Lin
HPE
Email: wen.lin@hpe.com
Rabadan, et al. Expires 2 February 2027 [Page 18]