Skip to main content

Multipath for EVPN Ethernet Auto-Discovery Routes
draft-li-bess-evpn-ead-multipath-00

Document Type Active Internet-Draft (individual)
Authors Zhiqiang Li , Zongpeng Du , Junjie Wang , Wei Cheng , Guoying Zhang , Xun Sun , Chunhao Zhao
Last updated 2026-07-04
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-li-bess-evpn-ead-multipath-00
BESS                                                               Z. Li
Internet-Draft                                                     Z. Du
Intended status: Standards Track                            China Mobile
Expires: 5 January 2027                                          J. Wang
                                                                W. Cheng
                                                                G. Zhang
                                                                  Centec
                                                                  X. Sun
                                                                   Inesa
                                                                 C. Zhao
                                                                    SAIA
                                                             4 July 2026

           Multipath for EVPN Ethernet Auto-Discovery Routes
                  draft-li-bess-evpn-ead-multipath-00

Abstract

   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.

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 January 2027.

Li, et al.               Expires 5 January 2027                 [Page 1]
Internet-Draft             EVPN EAD Multipath                  July 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  EAD Route Multipath Requirements  . . . . . . . . . . . . . .   3
     2.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Advertisement . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Forwarding State Installation . . . . . . . . . . . . . .   4
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   4
     3.1.  Route Distinguisher Allocation  . . . . . . . . . . . . .   4
     3.2.  Interoperability  . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   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.

Li, et al.               Expires 5 January 2027                 [Page 2]
Internet-Draft             EVPN EAD Multipath                  July 2026

   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:

   *  Remote PEs not receiving EAD routes from all PEs attached to an
      ES, preventing correct aliasing per [RFC7432] Section 8.4.

   *  Incomplete mass withdrawal, as the withdrawal of an EAD per-ES
      route from one PE is not received by all remote PEs.

   *  Incomplete forwarding state for ES and EVI labels, affecting
      split-horizon filtering for multi-homing groups with more than two
      PEs.

   This document specifies the multipath requirements for EAD routes to
   address these issues.

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.

2.  EAD Route Multipath Requirements

2.1.  Applicability

   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.

2.2.  Advertisement

   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.

Li, et al.               Expires 5 January 2027                 [Page 3]
Internet-Draft             EVPN EAD Multipath                  July 2026

   This behavior is functionally equivalent to BGP Add-Paths [RFC7911]
   for the specific case of EAD routes, without requiring Add-Paths
   capability negotiation.

2.3.  Forwarding State Installation

   A BGP speaker MUST install forwarding state for all valid EAD routes
   for a given ESI, not only the best path.  Specifically:

   *  For EAD per-ES routes, the ES label from each route originator
      MUST be installed.

   *  For EAD per-EVI routes, the EVI label from each route originator
      MUST be installed.

   The resulting forwarding state maps the ESI and EVI to the set of
   originating PE addresses and their associated labels.

3.  Operational Considerations

3.1.  Route Distinguisher Allocation

   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.

3.2.  Interoperability

   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.

4.  Security Considerations

   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.

Li, et al.               Expires 5 January 2027                 [Page 4]
Internet-Draft             EVPN EAD Multipath                  July 2026

5.  IANA Considerations

   This document has no IANA actions.

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

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271,
              January 2006, <https://www.rfc-editor.org/info/rfc4271>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC7432]  Sajassi, A., 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>.

   [RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", RFC 7911,
              DOI 10.17487/RFC7911, July 2016,
              <https://www.rfc-editor.org/info/rfc7911>.

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

Acknowledgements

   The multi-homing procedures in RFC 7432 and the ongoing work on its
   revision informed the requirements in this document.

Authors' Addresses

   Zhiqiang Li
   China Mobile
   Beijing
   100053
   China
   Email: lizhiqiangyjy@chinamobile.com

Li, et al.               Expires 5 January 2027                 [Page 5]
Internet-Draft             EVPN EAD Multipath                  July 2026

   Zongpeng Du
   China Mobile
   Beijing
   100053
   China
   Email: duzongpeng@chinamobile.com

   Junjie Wang
   Centec
   Shanghai
   201203
   China
   Email: wangjj@centec.com

   Wei Cheng
   Centec
   Shanghai
   201203
   China
   Email: chengw@centec.com

   Guoying Zhang
   Centec
   Shanghai
   201203
   China
   Email: zhanggy@centec.com

   Xun Sun
   Inesa
   Shanghai
   200030
   China
   Email: sunxun@inesa.com

   Chunhao Zhao
   SAIA
   Shanghai
   200125
   China
   Email: chunhao.zhao@sh-aia.com

Li, et al.               Expires 5 January 2027                 [Page 6]