]> Cisco Systems

venggovi@cisco.com

Cisco Systems

aswkuppu@cisco.com

Cisco Systems

sajassi@cisco.com

Routing Internet Engineering Task Force keyword This document specifies the procedures for achieving faster Layer-3 convergence from link/ node failures when all-active multi-homing is used with EVPN/ MVPN seamless interop [draft-ietf-bess-evpn-mvpn-seamless-interop]. Specifically, these improvements apply when L3 routed multicast services are deployed by BGP/ EVPN PEs using the procedures defined by the above draft.

Introduction This document specifies procedures for improving the L3 convergence from link/ node failures when deploying routed multicast services. These routed multicast services can be deployed through all-active multi-homing (MH) procedures defined for EVPN/ MVPN seamless interop as defined in .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology All of the terminology used in this document comes from and . A new term is introduced in this document:

• Single Forwarder Mode: In this mode, only one of the EVPN PEs hosting the all-active Ethernet Segment forwards multicast packets into the Multicast Distribution Tunnel of the EVPN fabric. This tunnel is formed by using the I-PMSI and/or S-PMSI procedures of .

Scope of this document This document covers the following aspects:

• EVPN PEs that provide Layer-3 routed multicast services based on the procedures of .
• EVPN PEs that have multicast sources and receivers connected to all-active Ethernet segments.
• This document does not cover

Background of the all-active MH solution for EVPN/ MVPN and Problem Statement Figure-1 below depicts a scenario where a tenant's multicast VPN spans across both EVPN and MVPN PEs; where all EVPN PEs have multicast IRB capability. An EVPN PE (with multicast IRB capability) can be modeled as an MVPN PE where the virtual IRB interface of an EVPN PE (virtual interface between a Bridge Table and IP-VRF) can be considered a routed interface for the MVPN PE.

EVPN & MVPN PEs Seamless Interop with all-active MH hosts | / | | | +--------+ | Rcvr2 +---|(MAC-VRF2) | | | | +------------+ | | +--+--+ | MPLS/ | | Src2| EVPN PE2 | IP | +--+--+ +------------+ | | | Rcvr3 +---|(MAC-VRF1) | | | MVPN PE4 | | \ | | | +--------+ +-------------->| (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr6 | / | +---------+ +--------+ Rcvr4 +---|(MAC-VRF3) | | | +------------+ | | | | EVPN PE3 | | +------------+ | | |(MAC-VRF3) | | | | \ | | | | (IP-VRF)|-----+ | +-------------->| / | | | Rcvr7 +---|(MAC-VRF3) | | | +------------+ | +--+--+ | |Rcvr8| EVPN PE4 | +--+--+ +------------+ | | Rcvr9 +---|(MAC-VRF4) | | | | \ | | +-------------->| (IP-VRF)|----------+ | / | |(MAC-VRF4) | +------------+ ]]>

To support multicast sources and/ or receivers that are connected to multiple EVPN PEs via an all-active multihomed ES, the following design constructs specified in apply:

1. When multicast sources are present on multi-homed hosts, the remote PEs (Egress) having receivers could join any of the EVPN PEs hosting the all-active Ethernet Segment. This is acheived by creating the intra-ES tunnel between the EVPN PEs hosting the ES.
2. When the multicast receivers are present on multi-homed hosts, only one PE must forward packets received from the remote PE via the EVPN fabric towards the all-active multihomed host on the ES. This is achieved through DF election.

Problem Statement When multicast source(s) are connected to EVPN PEs via all-active ESI-MH segments, we have the I-PMSI/ S-PMSI MDT tunnel rooted at one of the EVPN PEs hosting the ESI-MH. When there is a node/ AC link failure at the PE node that receives multicast packets from the host, it causes the multicast source to switch traffic to another PE via other active links of the ES. The EVPN PE now receiving the multicast packets is not yet ready to route those packets to remote receivers because the MDT rooted at that EVPN PE may not yet be setup. This causes a transient period during which the remote receivers across the EVPN/ MVPN to not receive traffic until the MDT is setup. Because multicast interest is signaled from the egress PEs hosting receiver(s), the solution to reconverge the MDT due to a AC link/ node failure at the PE hosting the multicast source, needs to be independent of any retransmission of receiver interest from the egress PEs. The solution must also avoid causing any duplication of data packets to the receiver(s) at the tenant hosts.

Procedures for improving convergence when multicast source is behind All-Active MH A key requirement of improving convergence for L3 routed multicast flows is to keep the multicast state, both (*, G) and (S, G) synchronized on all of the EVPN PEs hosting the ES prior to the node/ link failure. This can be acheieved by using the same BGP/ MVPN Route target advertised for the corresponding MVPN RT-6/7 and importing them to all the EVPN PEs hosting the ES. At the egress PE the RT value to be added to a MVPN RT-6/7 is imported from the EVPN RT-2/5 advertised for that prefix. In the ESI-LAG scenario, this RT-2/5 may be advertised from two or more EVPN PEs. In order to have the RT-6/7 imported to all the EVPN PEs hosting the ES, we can

1. have the same RT value provisioned on all the EVPN PEs.
2. have the egress EVPN PE join the MDT using MVPN route type 6/7 populated with a list of route targets, each corresponding to an EVPN PE hosting the ES.
3. All other methods like out-of-band synchronization are outside the scope of this specification.

Single Forwarder Mode Operation The following procedures apply when deploying multicast routed services on EVPN PEs supporting all-active ESI-MH:

1. We need to retain the freedom of the Egress EVPN PE to choose the Upstream Multicast NH PE, when sending the MVPN Join C-Route (Type-6 or Type-7) at the same time meeting the requirement of synchronizing the incoming join across all EVPN PEs hosting the source on the ES.
2. The synchronization of the Join C-Route state amongst the EVPN PEs hosting the ES is achieved by forming a list of route-target values that are advertised by each of the PEs hosting the ES.
3. Sec 5.3 of defines the procedures based to construct the VRF Route Import Extended Community used by the egress PE when sending the join back to the ingress PE.

Intra-ES Tunnel Subnet tunnel for Single Forwarder mode In the Single Fowarder mode the intra-ES tunnel MUST be done with the following design:

1. Packets received on the intra-ES tunnel MUST be forwarded only to local receivers connected to a PE. This includes both receivers in the same VLAN as that of the source or other VLANs in the IP VRF.
2. Packets received on the intra-ES tunnel MUST NOT be forwarded to remote PEs via the P-tunnel.

IANA Considerations This memo includes no request to IANA.

Security Considerations This document uses protocols and procedures defined in the normative references and inherits the security considerations of those references.

References Normative References Informative References

Acknowledgements TBD

Contributors Cisco Systems

kethiruv@cisco.com

Cisco Systems

jefchian@cisco.com