Applicability of EVPN Assisted Replication to SRv6 Tunnels

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.¶

• 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.¶

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.¶

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].¶

• 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.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:¶

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).¶

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-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.¶

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.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.¶

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.¶

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>.

[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>.

[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>.

[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>.