L3 fast convergence for all-active multi-homing for EVPN/ MVPN Seamless interoperation

Internet-Draft	L3 Fast Convergence for EVPN/ MVPN MH	November 2026
Govindan, et al.	Expires 5 May 2027	[Page]

Abstract

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

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 5 May 2027.¶

Copyright Notice

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

1. 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 [I-D.ietf-bess-evpn-mvpn-seamless-interop].¶

1.1. Requirements Language

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

1.2. Terminology

All of the terminology used in this document comes from [RFC8365] and [I-D.ietf-bess-evpn-mvpn-seamless-interop].¶

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 [RFC6513] [RFC6514].¶

1.3. Scope of this document

This document covers the following aspects:¶

EVPN PEs that provide Layer-3 routed multicast services based on the procedures of [I-D.ietf-bess-evpn-mvpn-seamless-interop].¶
EVPN PEs that have multicast sources and receivers connected to all-active Ethernet segments.¶
This document does not cover [RFC9625]¶

2. 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 PE1
                     +------------+
           Src1 +----|(MAC-VRF1)  |                   MVPN PE3
          Rcvr1 +----|      \     |    +---------+   +--------+
                     |    (IP-VRF)|----|         |---|(IP-VRF)|--- Rcvr5
     +-------------->|      /     |    |         |   +--------+
     |     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)  |
                      +------------+

Figure 1: EVPN & MVPN PEs Seamless Interop with all-active MH hosts

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 [I-D.ietf-bess-evpn-mvpn-seamless-interop] apply:¶

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

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

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

have the same RT value provisioned on all the EVPN PEs.¶
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.¶
All other methods like out-of-band synchronization are outside the scope of this specification.¶

3.1. Single Forwarder Mode Operation

The following procedures apply when deploying multicast routed services on EVPN PEs supporting all-active ESI-MH:¶

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) [RFC6513] [RFC6514] at the same time meeting the requirement of synchronizing the incoming join across all EVPN PEs hosting the source on the ES.¶
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.¶
Sec 5.3 of [I-D.ietf-bess-evpn-mvpn-seamless-interop] defines the procedures based [RFC6514] to construct the VRF Route Import Extended Community used by the egress PE when sending the join back to the ingress PE.¶

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

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.¶
Packets received on the intra-ES tunnel MUST NOT be forwarded to remote PEs via the P-tunnel[RFC6513][RFC6514].¶

6. References

6.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC6513]: Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.
[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/info/rfc6514>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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/info/rfc8365>.
[I-D.ietf-bess-evpn-mvpn-seamless-interop]: Sajassi, A., Thiruvenkatasamy, K., Thoria, S., Gupta, A., and L. Jalil, "Seamless Multicast Interoperability between EVPN and MVPN PEs", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-mvpn-seamless-interop-12, 3 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mvpn-seamless-interop-12>.

6.2. Informative References

[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/info/rfc9625>.