]> Nokia

520 Almanor Avenue Sunnyvale CA 94085 United States of America jorge.rabadan@nokia.com

Nokia

520 Almanor Avenue Sunnyvale CA 94085 United States of America senthil.sathappan@nokia.com

Ribbon Communications

Alexander.Vainshtein@rbbn.com

HPE

wen.lin@hpe.com

Routing BGP Enabled ServiceS EVPN SRv6 Assisted Replication Optimized Ingress Replication BUM Multicast OISM 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the BGP Enabled ServiceS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Ethernet VPN (EVPN) 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) 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 , the AR procedures apply to BM traffic only; unknown unicast follows the regular unicast forwarding procedures. 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. EVPN services can be deployed over an SRv6 data plane, as specified in . Over SRv6, EVPN BUM traffic is carried using ingress replication: the IMET route advertises an End.DT2M SRv6 Service Segment Identifier (SID) 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.

Problem Statement Although both AR and EVPN-over-SRv6 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 is, by construction, bound to IP tunnels. 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 .
  • The optional single-IP fallback (Section 8 of ) selects the forwarding mode based on a VXLAN Virtual Network Identifier (VNI) (an AR-VNI versus an IR-VNI), which is specific to VXLAN.
• 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 ) 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) 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.

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 .
• 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 . Because SRv6 SIDs are readily available, the two-SID model also removes the need for the single-IP/VNI fallback of Section 8 of . See .
• The forwarding mode and the loop-avoidance signaling that 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 .
• Split-horizon filtering for multihoming MAY use the SRv6 Arg.FE2 argument of the End.DT2M SID, signaled as specified in and . The multihoming procedures of apply over SRv6 with the clarifications in .

The control-plane role discovery of , including the PMSI Tunnel attribute 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 ) and Segment Routing (SR) Point-to-Multipoint trees for Ethernet VPN (EVPN) and Multicast VPN (MVPN) , which are out of scope of this document.

Terminology and Conventions This document uses the terminology of , , , , and . The following terms are used frequently:

AR:

Assisted Replication, as defined in .

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 .

AR-LEAF:

Assisted Replication Leaf, an NVE/PE that sends all its BM traffic to an AR-REPLICATOR for further replication, as defined in .

RNVE:

Regular Network Virtualization Edge (RNVE), an NVE that supports but not the AR procedures of .

BD:

Broadcast Domain.

BUM:

Broadcast, unknown unicast, and Multicast traffic. As in , 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 .

End.DT2M:

The SRv6 Endpoint behavior "Endpoint with decapsulation and L2 table flooding" defined in Section 4.12 of .

End.DT2M.AR:

The SRv6 Endpoint behavior "End.DT2M with Assisted Replication" defined in this document () 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.

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 and signaled per and .

SBD:

Supplementary Broadcast Domain, as defined in .

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 when, and only when, they appear in all capitals, as shown here.

Assisted Replication over SRv6: Control Plane The control-plane roles, discovery, and replication modes of 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 : 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 and the IP-address-specific Route Target (RT) derived from the AR-REPLICATOR address, are reused as specified in .

SRv6 SID Advertisement for the AR Roles Over an SRv6 data plane, the roles that 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 :

• Regular-IR IMET route: an AR-LEAF, an AR-REPLICATOR, and an RNVE advertise a Regular-IR IMET route as defined in , 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 .
• 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 . 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 (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 , except that the AR-SID is taken from the SRv6 L2 Service TLV rather than from the Next Hop / Originating Router's IP address.

Non-Selective and Selective Assisted Replication The non-selective and selective replication modes are used as defined in Sections 5 and 6 of , respectively. For selective AR, the AR-LEAF sends a Leaf A-D route in response to a Replicator-AR route with the "L" flag set, as specified in . 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 .

Assisted Replication over SRv6: Data Plane

AR-LEAF Encapsulation When an AR-LEAF has selected an AR-REPLICATOR for a given BD (per the procedures of ), 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 , 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 . An AR-LEAF that is multihomed to one or more Ethernet Segments (ESs) follows the additional procedures in for the peers with which it shares an ES.

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 ). 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 and EVPN Ethernet Tree (E-Tree) 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 except for the Upper-Layer header processing, which is as follows: 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 .
• For selective AR, when a two-hop replication tree is used between AR-REPLICATORs of different AR-LEAF-sets (Section 6 of ), 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 , 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 and described in and . A new Endpoint behavior is defined, rather than reusing End.DT2M with an additional argument, for two reasons. First, the End.DT2M definition in 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 for ESI-based split-horizon filtering (Arg.FE2) and for EVPN E-Tree .

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 . 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 and , 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 (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 : 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 . 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 remain applicable, and the direct-copy procedures of are not required for split-horizon filtering. Loop avoidance follows the same principle as in : 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.

Multihoming The multihoming procedures for Assisted Replication defined in 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 .
• 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 . 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 is advertised and interpreted unchanged; it is independent of the underlay encapsulation.

The Designated Forwarder (DF) election procedures of and are not modified by this document.

OISM and IP Multicast over SRv6 with Assisted Replication EVPN Optimized Inter-Subnet Multicast (OISM) forwards IP multicast traffic within a Tenant Domain, building on EVPN inter-subnet forwarding , 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 . OISM already defines the AR roles for IP multicast (Section 3.2.3 of ): 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 and , 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 . 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 . The PTA flags of those routes are set as specified in Section 3.2.3 of and .
• 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 . 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 .

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 ). 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 . Selective forwarding based on SMET routes is unchanged. As noted in Section 3.2.6 of , 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.

Use Cases

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 .

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

IANA Considerations

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 . The allocation is requested from the range managed under the "First Come First Served" policy. Requested SRv6 Endpoint Behavior

Value	Hex	Endpoint Behavior	Reference
TBD	TBD	End.DT2M.AR	This document

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 are reused unchanged.

Security Considerations The security considerations of , , , , , and 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 and , 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 (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 do not apply; an operator can keep uRPF enabled in the SRv6 underlay independently of the AR procedures.

References Normative References This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices. Network Virtualization Overlay (NVO) networks using Ethernet VPNs (EVPNs) as their control plane may use trees based on ingress replication or Protocol Independent Multicast (PIM) to convey the overlay Broadcast, Unknown Unicast, or Multicast (BUM) traffic. PIM provides an efficient solution that prevents sending multiple copies of the same packet over the same physical link; however, it may not always be deployed in the NVO network core. Ingress replication avoids the dependency on PIM in the NVO network core. While ingress replication provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of ingress replication trees. This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432). The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. RFC 9252 defines procedures and messages for BGP overlay services for Segment Routing over IPv6 (SRv6), including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and global Internet routing. This document updates RFC 9252 and provides more detailed specifications for the signaling and processing of SRv6 Segment Identifier advertisements for BGP overlay service routes associated with SRv6 Endpoint Behaviors that support arguments. Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple segments. Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single tenant owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter-subnet multicast traffic and do not require any such traffic to egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined to be external to the EVPN domain. This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs). This document specifies updated procedures for handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs), including selective multicast and segmentation of provider tunnels. This document updates RFC 7432. An Ethernet Virtual Private Network (EVPN) is commonly used with Network Virtualization Overlay (NVO) tunnels as well as with MPLS and Segment Routing (SR) tunnels. The multihoming procedures in EVPN may vary based on the type of tunnel used within the EVPN Broadcast Domain. Specifically, there are two multihoming split-horizon procedures designed to prevent looped frames on multihomed Customer Edge (CE) devices: the Ethernet Segment Identifier (ESI) Label-based procedure and the local-bias procedure. The ESI Label-based split-horizon procedure is applied to MPLS-based tunnels such as MPLS over UDP (MPLSoUDP), while the local-bias procedure is used for other tunnels such as Virtual eXtensible Local Area Network (VXLAN) tunnels. Current specifications do not allow operators to choose which split-horizon procedure to use for tunnel encapsulations that support both methods. Examples of tunnels that may support both procedures include MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic Network Virtualization Encapsulation (Geneve), and Segment Routing over IPv6 (SRv6) tunnels. This document updates the EVPN multihoming procedures described in RFCs 7432 and 8365, enabling operators to select the split-horizon procedure that meets their specific requirements. HPE HPE HPE Nokia In the Virtualization Overlay (NVO) network with Ethernet VPN (EVPN), optimized ingress replication uses Assisted-Replication (AR) to achieve more efficient delivery of Broadcast and Multicast (BM) traffic. An AR-LEAF, which is a Network Virtualization Edge (NVE) device, forwards received BM traffic from its tenant system to an AR- REPLICATOR. The AR-REPLICATOR then replicates it to the remaining AR-LEAFs in the network. However, when replicating the packet on behalf of its multihomed AR-LEAF, an AR-REPLICATOR may face challenges in retaining the source IP address or including the expected Ethernet Segment Identifier (ESI) label that is required for EVPN split-horizon filtering. This document extends the optimized ingress replication procedures to address such limitations. The extended procedures specified in this document allow the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN NVO network. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK] The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly. Ethernet VPN (EVPN) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and end devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and end devices while maintaining the multihoming capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. This document describes the Segment Routing Replication segment for multipoint service delivery. A Replication segment allows a packet to be replicated from a replication node to downstream nodes. Arrcus Cisco Systems, Inc. Cisco Systems, Inc. Nokia Juniper Networks A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain.

Acknowledgments TODO acknowledge.