bess Z. Zhang Internet-Draft HPE Intended status: Standards Track C. Lin Expires: 23 April 2026 New H3C Technologies J. Rabadan Nokia 20 October 2025 EVPN Multi-Active Multihoming draft-zzhang-bess-evpn-multi-active-multihoming-00 Abstract EVPN supports All-Active and Single-Active multihoming, where either all multihoming PEs are active or only one is active. In some situations, it is desired to support Multi-Active with multiple yet not all active PEs. This document specifies the Multi-Active multihoming - some multihoming PEs are in All-Active mode while others are in Single-Active mode on the same multihoming Ethernet Segment, and ingress PEs load-balance to those in All-Active mode. 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 23 April 2026. Copyright Notice Copyright (c) 2025 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 Zhang, et al. Expires 23 April 2026 [Page 1] Internet-Draft EVPN Multi-Active Multihoming October 2025 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. Relationship with Single-Active, All-Active, and Port-Active . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Consider the following EVPN [RFC7432] multihoming situation: ce2 | ___ PE5____ / \ / \ \_____________/ PE1 PE2 PE3 PE4 \ | | / \ | | / \ | | / \ | | / ce1 CE1 is multihomed to PE1..4. It is desired that traffic from remote PEs, e.g., PE5, is load-balanced to PE1/PE2 normally, and only switch to PE3/PE4 when both PE1/PE2 are down. This cannot be achieved via the existing All-Active or Single-Active multihoming schemes, but it can be achieved via a new Multi-Active scheme introduced in this document: * The preferred PEs (e.g., PE1/PE2) in an MHES are considered in the All-Active mode. They set the P-bit in the L2-Attribute Extended Community to 1 and the B-bit to 0 in the Ethernet A-D per EVI routes. Zhang, et al. Expires 23 April 2026 [Page 2] Internet-Draft EVPN Multi-Active Multihoming October 2025 * Others are considered in the Single-Active mode. They set the P-bit to 0. One of them might be the BDF (if there is only one preferred PE, which is the DF), and its B-bit is set to 1 in that case, but that has no impact with respect to the Multi-Active behavior. * The preferred PEs are those advertising the highest (or lowest) preference value in the DF Election Extended Community. * Remote PEs load-balance to MHES PEs that advertise P-bit 1, with backup paths to MHES PEs that advertise P-bit 0. Note that the set of preferred PEs (and hence the rest of PEs) can change dynamically. In the above example, when PE1/PE2 goes down, PE3/PE4 becomes the preferred and advertises P-bit 1. Whether a PE is preferred depends on its DF Preference value in the DF Election Extended Community [RFC8584]. Notice that, even if the DF Election algorithm is not Highest- or Lowest-Preference [RFC9785], the DF Preference field is still used to signal the preference for the purpose of Multi-Active multihoming. 1.1. Relationship with Single-Active, All-Active, and Port-Active [RFC9786] specifies a Port-Active redundancy mode for multihoming, which is just the Single-Active mode without Service Carving. Per [RFC7432]: "The default procedure for DF election at the granularity of for VLAN-based service or for VLAN-(aware) bundle service is referred to as "service carving". With service carving, it is possible to elect multiple DFs per Ethernet segment (one per VLAN or VLAN bundle) in order to perform load balancing of multi-destination traffic destined to a given segment. The load- balancing procedures carve up the VLAN space per ES among the PE nodes evenly, in such a way that every PE is the DF for a disjoint set of VLANs or VLAN bundles for that ES." Per [RFC9786], Port-Active is still the Single-Active mode, but with the DF election performed per ES. As a result, the non-DFs (backup PEs) could transition the port to standby/down state because the port will not be used. Multi-active is a mix of All-Active and Single-Active, and service carving is still applicable. Some PEs on an MHES are All-Active while others are Single-Active, and they can change dynamically. Zhang, et al. Expires 23 April 2026 [Page 3] Internet-Draft EVPN Multi-Active Multihoming October 2025 2. Specification For an MHES to be Multi-Active, PEs on the ES MUST be configured with appropriate preferences that are advertised in the DF Election Extended Community, even if the DF election algorithm is not Highest- or Lowest-Preference. If the DF election algorithm is Highest- or Lowest-Preference, the same preference is used for both DF election and for determining if a PE is preferred for the Multi-Active purpose. A PE is considered preferred if one of the following conditions is met: * When the DF election algorithm is Highest- or Lowest-Preference, the PE has the highest or lowest preference of all those advertised in the DF Election Extended Communities. * When the DF election algorithm is neither Highest- nor Lowest- Preference, the PE has the highest preference of all those advertised in the DF Election Extended Communities. A Multi-Active MHES may be in strict or loose mode. The above conditions are for strict mode, in which only and all the PEs with strictly highest or lowest preference are preferred. In other words, as long as one of the previously multiple preferred PEs remains, other PEs will not become preferred. In the loose mode, there could be M preferred PEs in the MHES. Their preference values are higher (or lower) than those of others (with the IP address being the tie-breaker), but their preference values are not necessarily equal. For example, for PE1/2/3/4 with preference 100/100/80/80 in M=2 loose mode, PE1/2 are initially preferred. When PE1 goes down, PE2/3 are preferred while PE4 is not preferred (assuming PE3 has a higher IP address than PE4). For comparsion, in the strict mode, only PE2 remains preferred. If PE2 also goes down, then PE3/4 both become preferred. The provisioning of strict/loose mode and the M value SHOULD be consistent across the PEs on an MHES. However, the information is not signaled among the PEs. In the case of inconsistency, a PE may incorrectly set/clear the P-bit, leading to the undesired load- balancing. However, that should not lead to traffic blackholing. A preferred PE MUST operate in the All-Active mode. It sets the Multihoming Redundancy Mode bit in the ESI Label extended community to 0 (indicating All-Active), sets the P-bit in the L2-Attribute Extended Community to 1, and sets the B-bit to 0. Zhang, et al. Expires 23 April 2026 [Page 4] Internet-Draft EVPN Multi-Active Multihoming October 2025 Otherwise, the PE MUST operate in the Single-Active mode locally, though it sets the Multihoming Redundancy Mode bit in the ESI Label extended community to 0 (indicating All-Active). It sets the P-bit in the L2-Attribute Extended Community to 0. If it is the BDF, the B-bit is set to 1. When an ingress PE performs aliasing and load-balancing procedures for an MHES, load-balancing SHOULD be applied to all PEs setting the P-bit to 1 in the L2-Attribute Extended Community. Backup paths via PEs setting the P-bit to 0 SHOULD be set up. 3. Security Considerations This does not introduce additional security concerns beyond what are documented in [RFC7432]. 4. Acknowledgments The authors thank Soumyodeep Joarder, Vikram Nagarajan, and Vinod Kumar Nagaraj for the discussions on the use case and solution options. 5. References 5.1. Normative References [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, . [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", RFC 8584, DOI 10.17487/RFC8584, April 2019, . [RFC9785] Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and A. Sajassi, "Preference-Based EVPN Designated Forwarder (DF) Election", RFC 9785, DOI 10.17487/RFC9785, June 2025, . 5.2. Informative References [RFC9786] Brissette, P., Burdet, LA., Ed., Wen, B., Leyton, E., and J. Rabadan, "EVPN Port-Active Redundancy Mode", RFC 9786, DOI 10.17487/RFC9786, June 2025, . Zhang, et al. Expires 23 April 2026 [Page 5] Internet-Draft EVPN Multi-Active Multihoming October 2025 Authors' Addresses Zhaohui Zhang HPE Email: zzhang@juniper.net Changwang Lin New H3C Technologies Email: linchangwang.04414@h3c.com Jorge Rabadan Nokia Email: jorge.rabadan@nokia.com Zhang, et al. Expires 23 April 2026 [Page 6]