EVPN multi-homing support for L3 services
draft-ietf-bess-evpn-l3mh-proto-00
| Document | Type | Active Internet-Draft (bess WG) | |
|---|---|---|---|
| Authors | Patrice Brissette , Michael MacKenzie , Satoru Matsushima , Wen Lin , Jorge Rabadan | ||
| Last updated | 2026-02-23 | ||
| Replaces | draft-mackenzie-bess-evpn-l3mh-proto | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-bess-evpn-l3mh-proto-00
BESS Working Group P. Brissette, Ed.
Internet-Draft M. MacKenzie, Ed.
Intended status: Standards Track Cisco
Expires: 27 August 2026 S. Matsushima
Softbank
W. Lin
Juniper
J. Rabadan
Nokia
23 February 2026
EVPN multi-homing support for L3 services
draft-ietf-bess-evpn-l3mh-proto-00
Abstract
This document describes the use of EVPN Ethernet Segment Link
Aggregation Group (ES-LAG) technology to provide multi-homing
redundancy for Layer 3 services. The solution synchronizes ARP/ND,
multicast state, and IGP routes between redundant PEs without
requiring Layer 2 constructs or proprietary Inter-Chassis
Communication protocols.
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.
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 27 August 2026.
Brissette, et al. Expires 27 August 2026 [Page 1]
Internet-Draft EVPN L3MH February 2026
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. Problems with unicast load-balancing from core to CE . . 4
1.2. Problems with multicast from core to CE . . . . . . . . . 4
1.3. Problems with IGP adjacencies over the LAG port . . . . . 4
1.4. Problems with supporting multiple subnets on same ES in all
active mode . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8
3. Solution Details . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Example Topology . . . . . . . . . . . . . . . . . . . . 8
3.2. Route Target Usage . . . . . . . . . . . . . . . . . . . 10
3.3. EVPN Instance Usage . . . . . . . . . . . . . . . . . . . 11
3.4. Mapping for L3 Interface to ESI . . . . . . . . . . . . . 11
3.5. Mapping for L3 Sub-Interface to Ethernet Tag-id . . . . . 11
3.6. ARP/ND Synchronization . . . . . . . . . . . . . . . . . 12
3.6.1. Advertising ARP/ND Routes . . . . . . . . . . . . . . 12
3.6.2. Processing Received ARP/ND Routes . . . . . . . . . . 13
3.7. IGMP/MLD Synchronization . . . . . . . . . . . . . . . . 14
3.7.1. Advertising IGMP/MLD Routes . . . . . . . . . . . . . 14
3.7.2. Processing Received IGMP/MLD Routes . . . . . . . . . 14
3.8. IGP Route Synchronization . . . . . . . . . . . . . . . . 14
3.8.1. ESI-Based Approach . . . . . . . . . . . . . . . . . 15
3.8.2. IP Gateway-Based Approach . . . . . . . . . . . . . . 15
4. Convergence Considerations . . . . . . . . . . . . . . . . . 16
5. Overall Advantages . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Brissette, et al. Expires 27 August 2026 [Page 2]
Internet-Draft EVPN L3MH February 2026
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Resilient L3VPN service to a CE requires multiple service PEs to run
a Multi-Chassis Link Aggregation Group mechanism, which previously
required a proprietary ICL control plane link between them.
This document uses [RFC7432], [RFC9135] and [RFC9136] procedures to
bring EVPN based ES-LAG all-active multi-homing load-balancing to L3
services focusing on the L3VPN [RFC4364] use case to provide
examples.
EVPN ES-LAG is completely transparent to a CE device, and provides
link and node level redundancy with load-balancing using the existing
BGP control plane required by the L3 services.
For example, the L3VPN service can be MPLS, VxLAN or SRv6 based, and
does not require EVPN signaling to remote neighbors. The EVPN
signaling is limited to the redundant service PEs sharing a Ethernet
Segment Identifier (ESI). This is used to synchronize ARP/ND,
multicast Join/Leave, and IGP routes replacing need for ICL link.
+-----+
| PE3 |
+-----+
+-----------+
| MPLS/IP |
| CORE |
+-----------+
+-----+ +-----+
| PE1 | | PE2 |
+-----+ +-----+
| |
I1 I2
\ /
\ /
+---+
|CE1|
+---+
Figure 1: EVPN ES-LAG Topology
Figure 1 shows an ES-LAG multi-homing topology where PE1 and PE2 are
part of the same redundancy group providing multi-homing to CE1 via
interfaces I1 and I2. PE1, PE2 and PE3 are attached to the same
L3VPN thru the core (running [RFC4364] and/or [RFC9136] procedures).
Brissette, et al. Expires 27 August 2026 [Page 3]
Internet-Draft EVPN L3MH February 2026
Interfaces I1 and I2 are Bundle-Ethernet interfaces running LACP
protocol. The CE device can be a layer-2 or layer-3 device
connecting to the redundant PEs over a single LACP LAG port.
In the case of a layer-3 CE device, this document looks to solve the
case of an IGP adjacency between PEs and CE. Further study is needed
to support BGP PE to CE protocols. The core, shown as IP or MPLS
enabled, provides wide range of L3 services. ES-LAG multi-homing
functionality is decoupled from those services in the core and it
focuses on providing multi-homing to CE.
To deliver resilient layer-3 services and provide traffic load-
balancing towards the access, the two service PEs advertise layer-3
reachability towards the layer-3 core and both be eligible to receive
traffic and forward towards the Access.
1.1. Problems with unicast load-balancing from core to CE
The layer-2 hashing performed by CE over its LAG port means that only
one service PE may populate its ARP/ND cache. In Figure 1, if CE1
ARP/ND responses always hash to PE1, then PE2's ARP/ND table remains
empty. Traffic from remote PEs can be received by either service PE.
Traffic that reaches PE2 does not find an ARP entry and is dropped.
Solution: Synchronize ARP/ND entries using EVPN RT-2 routes as
described in Section 3.6.
1.2. Problems with multicast from core to CE
Multicast IGMP/MLD join messages from CE may always hash to a single
PE due to LAG hashing behavior. When PIM runs on both redundant PEs,
PIM hello messages from each PE are not visible to the other PE
because the CE cannot switch traffic between LAG members. Both PEs
become PIM Designated Router (DR). However, IGMP joins for a given
multicast group may hash to only one PE, so only that PE programs the
multicast route and sends PIM joins.
Solution: Synchronize IGMP/MLD state using EVPN RT-7/RT-8 routes as
described in Section 3.7.
1.3. Problems with IGP adjacencies over the LAG port
A layer-3 CE device connecting to redundant PEs may establish an IGP
adjacency on the bundle port. The adjacency forms to only one PE, so
IGP customer routes are only present on that PE. This prevents load-
balancing benefits as only one PE advertises customer routes to the
core.
Brissette, et al. Expires 27 August 2026 [Page 4]
Internet-Draft EVPN L3MH February 2026
<---------+
| IGP Adj
+-------+ |
| | 192.0.2.1/24 |
| PE1 +-----------+ |
| | | |
| | | +
+-------+ |
|
+ | +------+
RT5 | L | | CE1 +------>H1
Sync | A +->+ |
v G | | |
| | +------>R1
+-------+ | +------+
| | | 192.0.2.2/24
| PE2 +-----------+
| | 192.0.2.1/24
| |
+-------+
Figure 2: IGP Adjacency over LAG Port
Figure 2 provides an example of this use case, where CE1 forms an IGP
adjacency with PE1 (example: ISIS or OSPF), and advertises its H1 and
R1 routes into the IP-VRF of PE1. PE1 may then redistribute this IGP
route into the core as an L3 service. Any remote PEs are only aware
of the service from PE1, and cannot load balance through PE2 as well.
Solution: Synchronize IGP learned routes using EVPN RT-5 routes as
described in Section 3.8.
Note: BGP PE-CE protocols require further study.
1.4. Problems with supporting multiple subnets on same ES in all active
mode
When a CE supports multiple subnets using VLANs over a single LAG
interface, each VLAN maps to a separate L3 sub-interface on the PE.
When the PE synchronizes host reachability using EVPN RT-2 routes,
standard RT-2 advertisements do not indicate which sub-interface
(VLAN) the host belongs to. The peering PE cannot determine the
correct destination sub-interface when multiple sub-interfaces share
the same ESI.
The same problem occurs with IGMP/MLD route synchronization using
RT-7 and RT-8.
Brissette, et al. Expires 27 August 2026 [Page 5]
Internet-Draft EVPN L3MH February 2026
Solution: Use the Ethernet Tag-ID field to carry the VLAN ID in all
route sync messages (RT-2, RT-5, RT-7, RT-8) to identify the specific
sub-interface.
Note: This document focuses on L3 sub-interfaces. Mixed L2/L3 sub-
interfaces require further study.
1.5. Acronyms
BD: Broadcast Domain
BE: Bundle Ethernet Interface aka. L3 LAG interface
DF: Designated Forwarder
DR: Multicast Designated Router
EC: BGP Extended Community
ES: Ethernet Segment. When a customer site (device or network) is
connected to one or more PEs via a set of Ethernet links, then
that set of links is referred to as an 'Ethernet Segment'.
ESI: Ethernet Segment Identifier. A unique non-zero identifier that
identifies an Ethernet Segment is called an 'Ethernet Segment
Identifier'.
ES-LAG: This refers to multi-homing scenario where peering PEs,
connected to same CE, are two, three or more.
ETAG: Ethernet Tag. An Ethernet tag identifies a particular
broadcast domain, e.g., a VLAN. An EVPN instance consists of one
or more broadcast domains.
EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN. It is used to assist a L3 VRF for
route synchronization.
GRT: Global Routing Table
ICL: Inter Chassis Link
IGMP: Internet Group Management Protocol
IGP: Interior Gateway Protocol
IP-VRF: A VPN Routing and Forwarding table for IP routes on an PE.
Brissette, et al. Expires 27 August 2026 [Page 6]
Internet-Draft EVPN L3MH February 2026
The IP routes could be populated by EVPN and IP-VPN address
families. An IP-VRF is also an instantiation of a layer 3 VPN in
an PE.
MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE. A MAC-VRF is also an
instantiation of an EVI in a PE
MC-LAG: Multi-Chassis Link Aggregation Group (MC-LAG).
MLD: Multicast Listener Discovery.
PE: Provider Edge.
PIM: Protocol Independent Multicast.
RD: Route Distinguisher used in BGP.
RP: Multicast Rendezvous Point.
RT: Route-Targets used in BGP
RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as
defined in [RFC7432].
RT-5: EVPN route type 5, i.e., IP Prefix route, as defined in
Section 3 of [RFC9136].
RT-7: EVPN route type 7, i.e., Multicast Join Synch Route, as
defined in Section 9.2 of [RFC9251].
RT-8: EVPN route type 8, i.e., Multicast Leave Synch Route, as
defined in Section 9.3 of [RFC9251].
1.6. Requirements
The multi-homing solution described in this document satisfies the
following requirements:
1. MUST support Layer-3 access interfaces
2. MUST support Layer-3 access sub-interfaces
3. MUST support unicast and multicast VPN services
4. SHOULD support IGP route synchronization
5. SHOULD support global routing table (GRT) services
Brissette, et al. Expires 27 August 2026 [Page 7]
Internet-Draft EVPN L3MH February 2026
6. MUST support all-active load-balancing mode
7. MAY support single-active load-balancing mode
8. MUST support port-active load-balancing mode
9. SHOULD avoid Layer 2 constructs (EVI, MAC-VRF, BD, IRB) for L3
state synchronization
2. Solution Overview
This document defines EVPN-based route synchronization mechanisms to
enable all-active multi-homing for Layer 3 services. The solution
uses existing EVPN route types to synchronize state between PEs
sharing an Ethernet Segment:
* RT-2 (MAC/IP routes): Synchronize ARP/ND adjacencies
* RT-5 (IP Prefix routes): Synchronize IGP learned customer routes
* RT-7/RT-8 (Multicast Join/Leave): Synchronize IGMP/MLD state
Key design principles:
* ESI identifies the shared LAG interface between redundant PEs
* Ethernet Tag-ID identifies the sub-interface (VLAN) for AC-aware
scenarios
* IP-VRF Route Targets identify the VRF for route import/export
* ES-Import RT (optional) restricts distribution to ESI-attached PEs
The following sections describe detailed procedures for each
synchronization type.
3. Solution Details
3.1. Example Topology
Consider the Figure 3 topology, where two AC-aware bundling
interfaces are configured. Interface BE1 on PE1 and PE2 shares a LAG
with switch SW1 and supports two customer VRFs with overlapping
subnets on VLAN 1 and VLAN 2. Interface BE2 supports a single
customer VRF on native VLAN.
Brissette, et al. Expires 27 August 2026 [Page 8]
Internet-Draft EVPN L3MH February 2026
+------
| +-------+ BE1.1 (192.0.2.1/24)
| PE1 || BE1 +---------------------------------+
| || ESI-1| |
| || | BE1.2 (192.0.2.2/24) |
| || +-------------------------+ |
| +-------+ | |
| | | |
| +-------+ BE2 (198.51.100.1/24) | |
| || BE2 +------------------+ | |
| || ESI-2| | | |
| || | +v----+ | |
| || | |CE1 | | |
| +-------+ |.2 | | |
+------ |CUST1| | |
+^----+ | |
+------ | +v-----+-v----+
| +-------+ | |SW1 | +-->H1(.2)
| PE2 || BE2 +-----<-------------+ |CUST2 |CUST1 |
| || ESI-2| BE2 (198.51.100.1/24) +^-----+-^----+
| || | | |
| || | | |
| +-------+ | |
| | | |
| +-------+ BE1.2 (192.0.2.2/24) | |
| || BE1 +-------------------------+ |
| || ESI-1| |
| || | BE1.1 (192.0.2.1/24) |
| || +---------------------------------+
| +-------+
+------
PE(1,2):
CUST1-VRF (IP-VRF1)
CUST2-VRF (IP-VRF2)
SW1:
CUST1-Subnet1: (192.0.2.1/24) (VLAN 1)
CUST2-Subnet1: (192.0.2.1/24) (VLAN 2)
CE1:
CUST1-Subnet: (198.51.100.1/24)
Figure 3: ARP/ND synchronization over different VRF(s)
In this topology:
Brissette, et al. Expires 27 August 2026 [Page 9]
Internet-Draft EVPN L3MH February 2026
* BE1 (ESI-1): Shared by CUST1-VRF and CUST2-VRF with sub-interfaces
VLAN 1 and 2
* BE2 (ESI-2): Used only by CUST1-VRF on native VLAN
To synchronize state for CUST1-VRF, the solution uses:
Case 1 - Native interface (BE2 to CE1):
* IP-VRF RT(s): Identifies CUST1-VRF
* ESI-2: Identifies BE2 interface
* Ethernet Tag-ID 0: Indicates native VLAN
Case 2 - Sub-interface (BE1.1 to SW1):
* IP-VRF RT(s): Identifies CUST1-VRF
* ESI-1: Identifies BE1 interface
* Ethernet Tag-ID 1: Identifies VLAN 1 sub-interface
3.2. Route Target Usage
Route synchronization between peering PEs uses EVPN route types as
defined in [RFC7432] and [RFC9136].
Routes SHOULD be advertised with the ES-Import Route Target to
identify the Layer-3 interface for which the information must be
synchronized, and with the EVI-RT Extended Community [RFC9251] to
identify the routing context (IP-VRF or GRT) in which synchronization
occurs. This limits route distribution to PEs attached to the same
ESI and ensures that the routes are applied to the correct IP-VRF at
the receiving PE.
Alternatively, synchronization routes MAY be advertised using the IP-
VRF route Targets. However, this approach may cause the routes to be
distributed to all remote PEs in the IP-VRF, including those that do
not require the synchronization information.
In Figure 3, CUST1 routes carry IP-VRF1 RT(s) and CUST2 routes carry
IP-VRF2 RT(s). When using ES-Import RT optimization, routes also
carry EVI-RT Extended Community with the corresponding IP-VRF RT.
Brissette, et al. Expires 27 August 2026 [Page 10]
Internet-Draft EVPN L3MH February 2026
Note: When VRF Route Targets are used, routes are distributed to all
PEs importing that VRF RT, not just ESI-attached PEs. However, only
PEs with EVPN SAFI enabled will process these routes, effectively
limiting distribution to EVPN-capable PEs.
3.3. EVPN Instance Usage
Unlike [RFC7432] MAC-VRF deployments, EVI is not required for L3
multi-homing scenarios. The Route Distinguisher (RD) MAY be auto-
generated locally, and Route Targets are taken from the IP-VRF
configuration.
For Global Routing Table (GRT) services, an EVPN instance MAY be
assigned to provide Route Targets as required by [RFC7432].
Alternatively, users MAY explicitly configure Route Targets for GRT
synchronization.
The solution synchronizes the following state types:
* ARP/ND adjacencies (RT-2)
* IGMP/MLD join/leave (RT-7/RT-8)
* IGP learned routes (RT-5)
3.4. Mapping for L3 Interface to ESI
The ESI represents the L3 LAG interface between PE and CEs. This ESI
is signaled using RT-4 with the ES-Import Route Target as described
in Section 8.1.1 of [RFC7432] so that the service PE peers can
discover each other's common ES.
In the example Figure 3, route-syncs from interface BE1 have IP-VRF
RT(s) or ES-Import RT and EVI-RT EC with ESI 1 as an optimization.
3.5. Mapping for L3 Sub-Interface to Ethernet Tag-id
The Ethernet Tag-id represents the sub-interface subnet on the L3 LAG
interface between PE and CEs. This apply to all route-sync types
used for L3 multi-homing i.e., RT-2, RT-5, RT-7 and RT-8.
The Ethernet Tag ID encoded in synchronization routes is
automatically derived from the encapsulation VLAN tags of the Layer-3
interface, following the encoding rules for single and double
normalized VLAN identifiers defined in [RFC9744], as described below:
* Untagged Layer-3 LAG interfaces use an Ethernet Tag ID value of
zero.
Brissette, et al. Expires 27 August 2026 [Page 11]
Internet-Draft EVPN L3MH February 2026
* Singly tagged Layer-3 LAG interfaces encode a single normalized
VLAN identifier (VID) in the lower 12 bits of the Ethernet Tag ID
field.
* Doubly tagged Layer-3 LAG interfaces encode the outer normalized
VID in the upper 12 bits and the inner normalized VID in the lower
12 bits of the Ethernet Tag ID field.
For synchronization to operate correctly, PEs attached to the same
multi-homed CE MUST use consistent VLAN identifiers for the same
multihomed CE.
In the example Figure 3, route-syncs from sub-interface BE1.1 (VLAN1)
is represented by Ethernet Tag Identifier with ID 1.
3.6. ARP/ND Synchronization
This section describes procedures for synchronizing ARP/ND
adjacencies between PEs using EVPN RT-2 routes, as defined in
Section 10 of [RFC7432], with modifications for Layer 3 interfaces.
3.6.1. Advertising ARP/ND Routes
When a PE learns an ARP or ND adjacency on a Layer 3 interface or
sub-interface, it MUST advertise an EVPN RT-2 route with non-zero ESI
to synchronize the adjacency with peer PEs. Unlike Layer 2 EVPN
services, MAC-only RT-2 routes MUST NOT be advertised, and Layer 2
forwarding state MUST NOT be programmed.
The RT-2 advertisement MUST include:
* Non-zero ESI: Identifies the shared Ethernet Segment
* IP address and MAC address of the learned adjacency
* Ethernet Tag-ID: Set to VLAN ID for sub-interfaces, 0 for native
interfaces
The RT-2 advertisement SHOULD include a label-1 value of zero and
SHOULD NOT include a label-2. In addition, the RT-2 advertisement
SHOULD NOT include any BGP Encapsulation Extended Communities
[RFC9012].
The route MUST carry at least one of the following route target
options:
* ES-Import Route Target (instead of IP-VRF RT) to restrict
distribution to ESI-attached PEs
Brissette, et al. Expires 27 August 2026 [Page 12]
Internet-Draft EVPN L3MH February 2026
* EVI-RT Extended Community carrying the IP-VRF Route Target
(required when using ES-Import RT) as defined in Section 9.5 of
[RFC9251]
or
* IP-VRF Route Target(s) of the associated VRF
Note: If the same ARP/ND entry exists on different LAG interfaces but
uses the same subinterface normalized VLAN identifier (VID), the
entry cannot be synchronized across PEs.
3.6.2. Processing Received ARP/ND Routes
A PE receiving an RT-2 synchronization route MUST:
* Import the route only if both ES-Import RT and EVI-RT match the
local configuration. Alternatively, the route MAY be imported if
the IP-VRF RT matches the local IP-VRF import RT.
* Derive the local interface from the ESI
* Derive the sub-interface from the Ethernet Tag-ID (0 for native
interface)
* Install the adjacency in the appropriate IP-VRF and interface
* Ignore the label value and BGP Encapsulation Extended Community
value if present in the route.
A Route Reflector used to disseminate synchronization routes MUST
ignore the label value carried in those routes.
The treat-as-withdraw behavior defined in [RFC 7606] is applied to
EVPN MAC/IP Advertisement routes received with any of the following:
* an ES-Import Extended Community that identifies a non-local
Ethernet Segment;
* a non-local EVI-RT; or
* a reserved ESI, such as ESI-0 or ESI-MAC (all-FFs value).
In addition, a received RT-2 synchronization route MUST NOT trigger
the programming of an ARP/ND entry if the same entry has already been
learned locally on the PE.
Brissette, et al. Expires 27 August 2026 [Page 13]
Internet-Draft EVPN L3MH February 2026
3.7. IGMP/MLD Synchronization
This section describes procedures for synchronizing IGMP/MLD join and
leave messages between PEs using EVPN RT-7 and RT-8 routes as defined
in [RFC9251].
3.7.1. Advertising IGMP/MLD Routes
When a PE receives an IGMP Join or MLD Report on a Layer 3 interface
or sub-interface, it MUST advertise an EVPN RT-7 route. When it
receives an IGMP Leave or MLD Done, it MUST advertise an EVPN RT-8
route.
The RT-7/RT-8 advertisement MUST include:
* Non-zero ESI: Identifies the shared Ethernet Segment
* Multicast group and source information
* Ethernet Tag-ID: Set to VLAN ID for sub-interfaces, 0 for native
interfaces
As per Section 3.6.1, the route SHOULD carry ES-Import Route Target
and EVI-RT Extended Community. Alternatively, the route MAY carry
IP-VRF Route Target(s) of the associated VRF.
3.7.2. Processing Received IGMP/MLD Routes
A PE receiving an RT-7 or RT-8 synchronization route MUST:
* Import the route only if IP-VRF Route Target matches a local VRF,
OR both ES-Import RT and EVI-RT match local configuration
* Derive the local VRF from the matching Route Target or EVI-RT
* Derive the local interface from the ESI
* Derive the sub-interface from the Ethernet Tag-ID
* Install the multicast state in the appropriate VRF and interface
3.8. IGP Route Synchronization
This section describes procedures for synchronizing IGP learned
customer routes between PEs using EVPN RT-5 routes as defined in
Section 3 of [RFC9136].
Brissette, et al. Expires 27 August 2026 [Page 14]
Internet-Draft EVPN L3MH February 2026
When a CE forms an IGP adjacency on the LAG bundle, the adjacency may
form to only one PE. That PE learns customer routes via IGP and must
synchronize them to peer PEs so that all PEs can advertise the routes
to the core and provide load-balancing.
Two approaches are defined:
1. ESI-based approach
2. IP Gateway-based approach
3.8.1. ESI-Based Approach
With the ESI-based approach, the PE learning routes via IGP
advertises an RT-5 route with the ESI of the Ethernet Segment.
For [RFC4364] IP-VPN cores:
* PE1 advertises RT-5 with non-zero ESI and IP-VPN route for R1
* PE2 imports both routes, prefers the RT-5 due to non-zero ESI
* PE2 treats RT-5 as a local route and advertises new IP-VPN route
* Remote PEs receive IP-VPN routes from both PE1 and PE2 for load-
balancing
For [RFC9136] EVPN IP-VRF-to-IP-VRF cores:
* PE1 advertises RT-5 with non-zero ESI
* PE2 synchronizes per Section 4.2 of
[I-D.ietf-bess-evpn-ip-aliasing]
* Both PEs advertise IP A-D routes for the ESI
* Remote PEs load-balance per Section 4 of
[I-D.ietf-bess-evpn-ip-aliasing]
3.8.2. IP Gateway-Based Approach
With the IP Gateway-based approach, the PE learning routes via IGP
advertises an RT-5 route with the IP Gateway field set to the route's
next-hop address.
For [RFC4364] IP-VPN cores:
Brissette, et al. Expires 27 August 2026 [Page 15]
Internet-Draft EVPN L3MH February 2026
* PE1 advertises RT-5 with IP Gateway = nexthop and IP-VPN route for
R1
* PE2 imports both routes, prefers RT-5
* PE2 resolves R1 via IP Gateway using synchronized ARP/ND from RT-2
* PE2 advertises new IP-VPN route for load-balancing
For [RFC9136] EVPN IP-VRF-to-IP-VRF cores:
* PE1 advertises RT-5 with IP Gateway = nexthop (no IP-VPN route
needed)
* PE2 imports and resolves RT-5 via synchronized ARP/ND
* PE2 advertises RT-5 for R1
* Remote PEs load-balance to both PE1 and PE2
4. Convergence Considerations
Entries synchronized via EVPN routes MAY be configured with a
retention timer, allowing them to be retained during failure
scenarios, thereby improving convergence and minimizing network
churn.
The retention timer specifies how long a synchronized EVPN entry is
retained after the corresponding EVPN route is withdrawn by the
Layer-3 LAG ES peer. This mechanism is OPTIONAL, and the behavior
for a synchronized entry is as follows:
* When the EVPN route that originated the synchronized entry is
withdrawn, the retention timer is started and the entry is
retained until the timer expires.
* For ARP/ND entries, while the retention timer is running, the PE
attempts to refresh the entry by sending ARP Requests or Neighbor
Solicitation messages to the IP owner.
* For IGMP/MLD entries, while the retention timer is running, the PE
attempts to refresh the entry by sending group-specific Queries
for the corresponding multicast groups.
5. Overall Advantages
The use of EVPN ES-LAG all active multi-homing brings the following
benefits to L3 BGP services:
Brissette, et al. Expires 27 August 2026 [Page 16]
Internet-Draft EVPN L3MH February 2026
* Open standards based per interface all-active redundancy mechanism
that eliminates the need to run ICCP and LDP.
* Agnostic of underlay technology (MPLS, VXLAN, SRv6) and associated
services (L3, L3-VPN).
* Replaces legacy MC-LAG ICCP-based solution, and offers following
additional benefits:
- Fast convergence with mass-withdraw is possible with EVPN.
- Avoid the need of a dedicated ICCP channel between peering PEs.
* Removes the burden of having the need for ICL link and any
proprietary protocols.
6. Security Considerations
The same Security Considerations described in [RFC7432] are valid for
this document.
7. IANA Considerations
There are no IANA considerations.
8. Acknowledgments
The authors thank Ali Sajassi and Jeffrey Zhang for the discussions
on the use case and solution options.
9. References
9.1. Normative References
[I-D.ietf-bess-evpn-ip-aliasing]
Sajassi, A., Rabadan, J., Pasupula, S., Krattiger, L., and
J. Drake, "EVPN Support for L3 Fast Convergence and
Aliasing/Backup Path", Work in Progress, Internet-Draft,
draft-ietf-bess-evpn-ip-aliasing-03, 7 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-ip-aliasing-03>.
[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>.
Brissette, et al. Expires 27 August 2026 [Page 17]
Internet-Draft EVPN L3MH February 2026
[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>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[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/info/rfc9135>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>.
[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/info/rfc9251>.
[RFC9744] Sajassi, A., Ed., Brissette, P., Uttaro, J., Drake, J.,
Boutros, S., and J. Rabadan, "EVPN Virtual Private Wire
Service (VPWS) Flexible Cross-Connect (FXC) Service",
RFC 9744, DOI 10.17487/RFC9744, March 2025,
<https://www.rfc-editor.org/info/rfc9744>.
9.2. Informative References
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[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/info/rfc7432>.
Appendix A. Contributors
The following people has contributed substantially to this document:
Brissette, et al. Expires 27 August 2026 [Page 18]
Internet-Draft EVPN L3MH February 2026
Jiri Chaloupka
Cisco
Email: jichalou@cisco.com
Jayashree Subramanian
Cisco
Email: jays@cisco.com
Authors' Addresses
Patrice Brissette (editor)
Cisco Systems
Email: pbrisset@cisco.com
Michael MacKenzie (editor)
Cisco Systems
Email: mimacken@cisco.com
Satoru Matsushima
Softbank
Email: satoru.matsushima@g.softbank.co.jp
Wen Lin
Juniper
Email: wlin@juniper.com
Jorge Rabadan
Nokia
Email: jorge.rabadan@nokia.com
Brissette, et al. Expires 27 August 2026 [Page 19]