| Internet-Draft | EVPN EAD Multipath | July 2026 |
| Li, et al. | Expires 5 January 2027 | [Page] |
In EVPN multi-homing deployments, multiple PE devices attached to the same Ethernet Segment each originate Ethernet Auto-Discovery (EAD) routes. Standard BGP best-path selection retains only one route per NLRI key, which can suppress reachability information needed for EVPN aliasing, fast convergence, and split-horizon filtering.¶
This document specifies that BGP speakers MUST treat EAD routes as multipath and MUST advertise and install all valid EAD routes for a given Ethernet Segment, rather than selecting a single best path.¶
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 January 2027.¶
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.¶
BGP MPLS-Based Ethernet VPN (EVPN) [RFC7432] defines Ethernet Auto-Discovery (EAD) routes (Route Type 1) for multi-homing functions including fast convergence (Section 8.2), split-horizon filtering (Section 8.3), and aliasing (Section 8.4). In a multi-homing deployment, multiple Provider Edge (PE) devices attached to the same Ethernet Segment (ES) each originate EAD routes that share the same Ethernet Segment Identifier (ESI).¶
Per [RFC7432] Section 7.1, the BGP route key for an EAD route comprises the Route Distinguisher (RD), the ESI, and the Ethernet Tag ID. The originating PE's IP address is not part of the route key. When multiple PEs originate EAD routes with the same RD and ESI, standard BGP [RFC4271] best-path selection treats them as competing paths for the same prefix and retains only one.¶
While [RFC7432] recommends that each PE use a unique RD to distinguish its routes, this recommendation is not always followed in practice. Additionally, even with unique RDs, Route Reflector (RR) topologies may reflect only a subset of paths to their clients. In either case, retaining a single best path for EAD routes can result in:¶
This document specifies the multipath requirements for EAD routes to address these issues.¶
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.¶
The requirements in this section apply to EVPN Route Type 1 (Ethernet Auto-Discovery) routes with a non-zero ESI. Routes with ESI set to zero and all other EVPN route types are subject to standard BGP best-path selection per [RFC4271] Section 9.1.2 without modification.¶
A BGP speaker MUST advertise all valid EAD routes for a given ESI to its BGP peers, regardless of the outcome of best-path selection. This applies to both locally originated and received EAD routes.¶
This requirement applies to Route Reflectors, which MUST reflect all valid EAD routes for a given ESI to their clients, rather than reflecting only the best path.¶
This behavior is functionally equivalent to BGP Add-Paths [RFC7911] for the specific case of EAD routes, without requiring Add-Paths capability negotiation.¶
A BGP speaker MUST install forwarding state for all valid EAD routes for a given ESI, not only the best path. Specifically:¶
The resulting forwarding state maps the ESI and EVI to the set of originating PE addresses and their associated labels.¶
The multipath requirements in this document do not remove the recommendation in [RFC7432] to assign unique RDs per PE. Unique RDs remain useful for operational troubleshooting and route identification. The requirements specified here apply regardless of whether RDs are unique or shared.¶
A BGP speaker implementing this specification advertises additional EAD routes that a non-implementing peer would not. The additional routes are valid BGP UPDATE messages and are processed normally by the receiving peer. A non-implementing peer may apply standard best-path selection to these routes; this does not cause protocol errors, but may result in the peer not utilizing all available paths.¶
Treating EAD routes as multipath increases the number of routes in the BGP Loc-RIB and the forwarding plane. A misconfigured or malicious peer could originate a large number of EAD routes for the same ESI. Implementations MUST support a configurable limit on the number of paths accepted per ESI. When this limit is reached, additional routes SHOULD be discarded.¶
BGP session authentication using TCP-AO [RFC5925] is RECOMMENDED to protect against unauthorized route injection.¶
This document has no IANA actions.¶
The multi-homing procedures in RFC 7432 and the ongoing work on its revision informed the requirements in this document.¶