BESS Working Group P. Brissette, Ed. Internet-Draft M. MacKenzie, Ed. Intended status: Standards Track Cisco Expires: 18 March 2027 S. Matsushima Softbank W. Lin Juniper J. Rabadan Nokia 14 September 2026 EVPN multi-homing support for L3 services draft-ietf-bess-evpn-l3mh-proto-01 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 18 March 2027. Brissette, et al. Expires 18 March 2027 [Page 1] Internet-Draft EVPN L3MH September 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 . . . . . . . . . . . . . . . . 15 3.7.1. Advertising IGMP/MLD Routes . . . . . . . . . . . . . 15 3.7.2. Processing Received IGMP/MLD Routes . . . . . . . . . 15 3.8. IGP Route Synchronization . . . . . . . . . . . . . . . . 16 3.8.1. ESI-Based Approach . . . . . . . . . . . . . . . . . 16 3.8.2. IP Gateway-Based Approach . . . . . . . . . . . . . . 17 4. Convergence Considerations . . . . . . . . . . . . . . . . . 17 5. Overall Advantages . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Brissette, et al. Expires 18 March 2027 [Page 2] Internet-Draft EVPN L3MH September 2026 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 an 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 through the core (running [RFC4364] and/or [RFC9136] Brissette, et al. Expires 18 March 2027 [Page 3] Internet-Draft EVPN L3MH September 2026 procedures). 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 18 March 2027 [Page 4] Internet-Draft EVPN L3MH September 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 18 March 2027 [Page 5] Internet-Draft EVPN L3MH September 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 a PE. Brissette, et al. Expires 18 March 2027 [Page 6] Internet-Draft EVPN L3MH September 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 a 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 18 March 2027 [Page 7] Internet-Draft EVPN L3MH September 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 18 March 2027 [Page 8] Internet-Draft EVPN L3MH September 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, 2001:db8:1::1/64) (VLAN 1) CUST2-Subnet1: (192.0.2.1/24, 2001:db8:2::1/64) (VLAN 2) CE1: CUST1-Subnet: (198.51.100.1/24, 2001:db8:3::1/64) Figure 3: ARP/ND synchronization over different VRF(s) The addresses above use the IPv4 and IPv6 documentation ranges from [RFC6890] and [RFC3849]. The procedures in this document are identical for IPv4 and IPv6: RT-2 routes synchronize ARP adjacencies Brissette, et al. Expires 18 March 2027 [Page 9] Internet-Draft EVPN L3MH September 2026 for IPv4 hosts and ND adjacencies for IPv6 hosts, and a dual-stack host is synchronized by a pair of RT-2 routes (one per address family). In this topology: * 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, which identifies the Ethernet Segment and restricts distribution to the PEs attached to that ES, together with the EVI-RT Extended Community [RFC9251], which identifies the routing context (IP-VRF or GRT) in which synchronization occurs. The specific Layer-3 (sub-)interface is identified by the ESI together with the Ethernet Tag-ID, not by the ES-Import Route Target alone. 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. Brissette, et al. Expires 18 March 2027 [Page 10] Internet-Draft EVPN L3MH September 2026 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. 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 applies to all route-sync types used for L3 multi-homing i.e., RT-2, RT-5, RT-7 and RT-8. Brissette, et al. Expires 18 March 2027 [Page 11] Internet-Draft EVPN L3MH September 2026 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. * 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 no EVPN Layer-2 bridging state (MAC-VRF/EVI, Inclusive Multicast (RT-3) flood state, or remote-MAC synchronization) is created for the advertised MAC. The MAC is carried solely to build the Layer-3 ARP/ND adjacency at the receiving PE. 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 Brissette, et al. Expires 18 March 2027 [Page 12] Internet-Draft EVPN L3MH September 2026 The RT-2 advertisement MUST carry exactly two MPLS labels: label-1 and label-2 as described below. A received route that does not carry exactly two labels MUST NOT be interpreted as an L3MH ARP/ND synchronization route (see the malformed-route handling in Section 3.6.2). The RT-2 advertisement MUST set label-1 to the MPLS Explicit NULL value (zero). label-1 has no forwarding meaning; it signals that this RT-2 is a Layer-3 neighbor-synchronization route and that the advertised MAC MUST NOT be used to program Layer-2 bridging or MAC- forwarding state. label-2 carries the associated IP-VRF's routing-context label or VNI for the encapsulation in use. For VXLAN symmetric IRB, this is the L3VNI. For MPLS or SRv6, this is the corresponding IP-VRF context identifier used by that encapsulation. label-2 does not, by itself, select the receiving IP-VRF; as in any EVPN/L3VPN deployment, VRF import is driven by Route Targets. 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 * 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. Brissette, et al. Expires 18 March 2027 [Page 13] Internet-Draft EVPN L3MH September 2026 * Derive the local interface from the ESI. If the ESI does not resolve to an Ethernet Segment that is local to this PE, the PE MUST NOT install any synced ARP/ND adjacency for the route. Because routes distributed using the IP-VRF Route Target reach every PE importing that VRF, a non-peering PE will receive such routes and MUST ignore them for adjacency programming (the route is retained per normal BGP procedures but no adjacency is installed). * Derive the sub-interface from the Ethernet Tag-ID (0 for native interface) * Select the receiving IP-VRF from the Route Targets, exactly as in any EVPN/L3VPN deployment (ES-Import RT + EVI-RT, or the IP-VRF RT). label-1 (Explicit NULL / zero) is used only as the Layer-3 neighbor-sync indicator and carries no forwarding meaning. label-2 carries the sender's routing-context label or VNI and MUST NOT be used by itself to select a different IP-VRF. * Install the ARP/ND adjacency in the selected IP-VRF and interface. Installing the adjacency resolves the synchronized MAC to the local Ethernet Segment so that routed traffic destined to the host egresses the correct LAG member rather than being flooded. Where the Layer-3 interface is a sub-interface of the LAG, this egress resolution is inherent to the adjacency. On bridge-based dataplanes, where the Layer-3 interface is an IRB/SVI over a bridge, the PE MAY install a local unicast MAC-to-Ethernet-Segment forwarding entry to achieve the same result. Such an entry is local forwarding state only: it MUST NOT create EVPN Layer-2 bridging state (no MAC-VRF/EVI, no RT-3/IMET flooding, no remote- MAC synchronization, and no MAC mobility signalling). * Ignore any BGP Encapsulation Extended Community present in the route. A Route Reflector used to disseminate synchronization routes does not install adjacencies from them and MUST propagate the label values unchanged. A received RT-2 synchronization route that is malformed MUST be handled with the treat-as-withdraw behavior defined in [RFC7606]. For the purposes of this document, such a route is malformed when any of the following holds: * it does not carry exactly two MPLS labels; * label-1 is not the MPLS Explicit NULL value (zero); Brissette, et al. Expires 18 March 2027 [Page 14] Internet-Draft EVPN L3MH September 2026 * label-2 is zero or does not encode a valid routing-context label/ VNI; or * the ESI is reserved or invalid, such as ESI-0 or ESI-MAC (all-FFs value). A route that is well-formed but does not apply to this PE is a policy non-match, not a malformed route, and MUST NOT be treated as withdraw. Such a route is retained per normal BGP procedures but does not program an adjacency. This includes a route whose ES-Import Extended Community identifies a non-local Ethernet Segment, a route carrying a non-local EVI-RT, and a well-formed route whose ESI does not resolve to a local Ethernet Segment on this PE. 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. 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: Brissette, et al. Expires 18 March 2027 [Page 15] Internet-Draft EVPN L3MH September 2026 * 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]. 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 Brissette, et al. Expires 18 March 2027 [Page 16] Internet-Draft EVPN L3MH September 2026 * 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: * 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: Brissette, et al. Expires 18 March 2027 [Page 17] Internet-Draft EVPN L3MH September 2026 * 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: * 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 Brissette, et al. Expires 18 March 2027 [Page 18] Internet-Draft EVPN L3MH September 2026 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-04, 2 March 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . [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, . Brissette, et al. Expires 18 March 2027 [Page 19] Internet-Draft EVPN L3MH September 2026 [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, . [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, . 9.2. Informative References [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, DOI 10.17487/RFC3849, July 2004, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . Appendix A. Contributors The following people has contributed substantially to this document: 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 Brissette, et al. Expires 18 March 2027 [Page 20] Internet-Draft EVPN L3MH September 2026 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 18 March 2027 [Page 21]