Cisco Systems

Ottawa ON Canada pbrisset@cisco.com

Cisco Systems

Canada lburdet@cisco.com

Comcast

United States of America Bin_Wen@comcast.com

Verizon Wireless

United States of America edward.leyton@verizonwireless.com

Nokia

United States of America jorge.rabadan@nokia.com

RTG bess Port-Active EVPN Multi-homing The Multi-Chassis Link Aggregation (MC-LAG) group technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The objective of MC-LAG is to enhance both network availability and bandwidth utilization through various modes of traffic load balancing. RFC 7432 defines an EVPN-based MC-LAG with Single-Active and All-Active multihoming redundancy modes. This document builds on the existing redundancy mechanisms supported by EVPN and introduces a new active/standby redundancy mode, called 'Port-Active'.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

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 () 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

• .  Introduction
  • .  Requirements Language
  • .  Multi-Chassis Link Aggregation (MC-LAG)
• .  Port-Active Redundancy Mode
  • .  Overall Advantages
  • .  Port-Active Redundancy Procedures
• .  Designated Forwarder Algorithm to Elect per Port-Active PE
  • .  Capability Flag
  • .  Modulo-Based Algorithm
  • .  Highest Random Weight Algorithm
  • .  Preference-Based DF Election
  • .  AC-Influenced DF Election
• .  Convergence Considerations
  • .  Primary/Backup Bits per Ethernet Segment
  • .  Backward Compatibility
• .  Applicability
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Contributors
• Authors' Addresses

Introduction EVPN defines the All-Active and Single-Active redundancy modes. All-Active redundancy provides per-flow load balancing for multihoming, while Single-Active redundancy ensures service carving where only one of the Provider Edge (PE) devices in a redundancy relationship is active per service. Although these two multihoming scenarios are widely utilized in data center and service provider access networks, there are cases where active/standby multihoming at the interface level is beneficial and necessary. The primary consideration for this new mode of load balancing is the determinism of traffic forwarding through a specific interface rather than statistical per-flow load balancing across multiple PEs providing multihoming. This determinism is essential for certain QoS features to function correctly. Additionally, this mode ensures fast convergence during failure and recovery, which is expected by customers. This document defines the Port-Active redundancy mode as a new type of multihoming in EVPN and details how this mode operates and is supported via EVPN.

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 when, and only when, they appear in all capitals, as shown here.

Multi-Chassis Link Aggregation (MC-LAG) When a Customer Equipment (CE) device is multihomed to a set of PE nodes using the Link Aggregation Control Protocol (LACP) , the PEs must function as a single LACP entity for the Ethernet links to form and operate as a Link Aggregation Group (LAG). To achieve this, the PEs connected to the same multihomed CE must synchronize LACP configuration and operational data among them. Historically, the Inter-Chassis Communication Protocol (ICCP) has been used for this synchronization. EVPN, as described in , covers the scenario where a CE is multihomed to multiple PE nodes, using a LAG to simplify the procedure significantly. However, this simplification comes with certain assumptions:

• A CE device connected to EVPN multihoming PEs MUST have a single LAG with all its links connected to the EVPN multihoming PEs in a redundancy group.
• Identical LACP parameters MUST be configured on peering PEs, including the system ID, port priority, and port key.

This document presumes proper LAG operation as specified in . Issues resulting from deviations in the aforementioned assumptions, LAG misconfiguration, and miswiring detection across peering PEs are considered outside the scope of this document.

MC-LAG Topology +-----+ | PE3 | +-----+ +-----------+ | MPLS/IP | | CORE | +-----------+ +-----+ +-----+ | PE1 | | PE2 | +-----+ +-----+ I1 I2 \ / \ / \ / +---+ |CE1| +---+

shows an MC-LAG multihoming topology where PE1 and PE2 are part of the same redundancy group providing multihoming to CE1 via interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG running LACP. The core, shown as IP or MPLS enabled, provides a wide range of L2 and L3 services. MC-LAG multihoming functionality is decoupled from those services in the core, and it focuses on providing multihoming to the CE. In Port-Active redundancy mode, only one of the two interfaces, I1 or I2, would be in forwarding, and the other interface would be in standby. This also implies that all services on the active interface operate in active mode and all services on the standby interface operate in standby mode.

Port-Active Redundancy Mode

Overall Advantages The use of Port-Active redundancy in EVPN networks provides the following benefits:

1. It offers open-standards-based active/standby redundancy at the interface level rather than VLAN granularity .
2. It eliminates the need for ICCP and LDP (e.g., Virtual eXtensible Local Area Network (VXLAN) or Segment Routing over IPv6 (SRv6) may be used in the network).
3. This mode is agnostic of the underlying technology (MPLS, VXLAN, and SRv6) and associated services (Layer 2 (L2), Layer 3 (L3), Bridging, E-LINE, etc.)
4. It enables deterministic QoS over MC-LAG attachment circuits.
5. It is fully compliant with and does not require any new protocol enhancements to existing EVPN RFCs.
6. It can leverage various Designated Forwarder (DF) election algorithms, such as modulo , Highest Random Weight (HRW) , etc.
7. It replaces legacy MC-LAG ICCP-based solutions and offers the following additional benefits:
   • Efficient support for 1+N redundancy mode (with EVPN using BGP Route Reflector), whereas ICCP requires a full mesh of LDP sessions among PEs in the redundancy group.
   • Fast convergence with mass withdraw is possible with EVPN, which has no equivalent in ICCP.

Port-Active Redundancy Procedures The following steps outline the proposed procedure for supporting Port-Active redundancy mode with EVPN LAG:

1. The Ethernet Segment Identifier (ESI) MUST be assigned per access interface as described in . The ESI can be auto-derived or manually assigned, and the access interface MAY be an L2 or L3 interface.
2. The Ethernet Segment (ES) MUST be configured in Port-Active redundancy mode on peering PEs for the specified access interface.
3. When ESI is configured on an L3 interface, the ES route (Route Type-4) can be the only route exchanged by PEs in the redundancy group.
4. PEs in the redundancy group leverage the DF election defined in to determine which PE keeps the port in active mode and which PE(s) keeps it in standby mode. Although the DF election defined in is per [ES, Ethernet Tag] granularity, the DF election is performed per [ES] in Port-Active redundancy mode. The details of this algorithm are described in .
5. The DF router MUST keep the corresponding access interface in an up and forwarding active state for that ES.
6. Non-DF routers SHOULD implement a bidirectional blocking scheme for all traffic comparable to the Single-Active redundancy mode described in , albeit across all VLANs.
   • Non-DF routers MAY bring and keep the peering access interface attached to them in an operational down state.
   • If the interface is running the LACP protocol, the non-DF PE MAY set the LACP state to Out of Sync (OOS) instead of setting the interface to a down state. This approach allows for better convergence during the transition from standby to active mode.
7. The primary/backup bits of the EVPN Layer 2 Attributes (L2-Attr) Extended Community SHOULD be used to achieve better convergence, as described in .

Designated Forwarder Algorithm to Elect per Port-Active PE The ES routes operating in Port-Active redundancy mode are advertised with the new Port Mode Load-Balancing capability bit in the DF Election Extended Community as defined in . Additionally, the ES associated with the port utilizes the existing Single-Active procedure and signals the Single-Active multihomed site redundancy mode along with the Ethernet A-D per-ES route (refer to ). Finally, The ESI label-based split-horizon procedures specified in SHOULD be employed to prevent transient echo packets when L2 circuits are involved. Various algorithms for DF election are detailed in Sections to for comprehensive understanding, although the choice of algorithm in this solution does not significantly impact complexity or performance compared to other redundancy modes.

Capability Flag defines a DF Election Extended Community and a bitmap (2 octets) field to encode "DF Election Capabilities" to use with the DF election algorithm in the DF algorithm field:

Bit 0:

D bit or 'Don't Preempt' bit, as described in .

Bit 1:

AC-Influenced DF (AC-DF) election, as described in .

Bit 3:

Time Synchronization, as described in .

Amended DF Election Capabilities in the DF Election Extended Community 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|A| |T| |P| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This document defines the following value and extends the DF Election Capabilities bitmap field:

Bit 5:

Port Mode Designated Forwarder Election. This bit determines that the DF election algorithm SHOULD be modified to consider the port ES only and not the Ethernet Tags.

Modulo-Based Algorithm The default DF election algorithm, or modulo-based algorithm, as described in and updated by , is applied here at the granularity of ES only. Given that the ES-Import Route Target extended community may be auto-derived and directly inherits its auto-derived value from ESI bytes 1-6, many operators differentiate ESIs primarily within these bytes. Consequently, bytes 3-6 are utilized to determine the designated forwarder using the modulo-based DF assignment, achieving good entropy during modulo calculation across ESIs. Assuming a redundancy group of N PE nodes, the PE with ordinal i is designated as the DF for an <ES> when (Es mod N) = i, where Es represents bytes 3-6 of that ESI.

Highest Random Weight Algorithm An application of Highest Random Weight (HRW) to EVPN DF election is defined in , and it MAY be used and signaled. For Port-Active, this is modified to operate at the granularity of <ES> rather than per <ES, VLAN>. describes computing a 32-bit Cyclic Redundancy Check (CRC) over the concatenation of Ethernet Tag (V) and ESI (Es). For Port-Active redundancy mode, the Ethernet Tag is omitted from the CRC computation and all references to (V, Es) are replaced by (Es). The algorithm used to determine the DF and Backup Designated Forwarder (BDF) per is repeated and summarized below using only (Es) in the computation:

1. DF(Es) = Si| Weight(Es, Si) >= Weight(Es, Sj), for all j. In the case of a tie, choose the PE whose IP address is numerically the least. Note that 0 <= i,j < number of PEs in the redundancy group.
2. BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es, Sk) >= Weight(Es, Sj). In the case of a tie, choose the PE whose IP address is numerically the least.

Where:

• DF(Es) is defined to be the address Si (index i) for which Weight(Es, Si) is the highest; 0 <= i < N-1.
• BDF(Es) is defined as that PE with address Sk for which the computed Weight is the next highest after the Weight of the DF. j is the running index from 0 to N-1; i and k are selected values.

Preference-Based DF Election When the new capability 'Port Mode' is signaled, the preference-based DF election algorithm is modified to consider the port only and not any associated Ethernet Tags. The Port Mode capability is compatible with the 'Don't Preempt' bit and both may be signaled. When an interface recovers, a peering PE signaling the D bit enables non-revertive behavior at the port level.

AC-Influenced DF Election The AC-DF bit defined in MUST be set to 0 when advertising Port Mode Designated Forwarder Election capability (P=1). When an AC (sub-interface) goes down, any resulting Ethernet A-D per EVI withdrawal does not influence the DF election. Upon receiving the AC-DF bit set (A=1) from a remote PE, it MUST be ignored when performing Port Mode Designated Forwarder Election.

Convergence Considerations To enhance convergence during failure and recovery when the Port-Active redundancy mode is employed, prior synchronization between peering PEs may be beneficial. The Port-Active mode poses a challenge to synchronization since the "standby" port may be in a down state. Transitioning a "standby" port to an up state and stabilizing the network requires time. For Integrated Routing and Bridging (IRB) and L3 services, prior synchronization of ARP / Neighbor Discovery (ND) caches is recommended. Additionally, associated Virtual Routing and Forwarding (VRF) tables may need to be synchronized. For L2 services, synchronization of MAC tables may be considered. Moreover, for members of a LAG running LACP, the ability to set the "standby" port to an "out-of-sync" state, also known as "warm-standby," can be utilized to improve convergence times.

Primary/Backup Bits per Ethernet Segment The EVPN L2-Attr Extended Community defined in SHOULD be advertised in the Ethernet A-D per ES route to enable fast convergence. Only the P and B bits of the Control Flags field in the L2-Attr Extended Community are relevant to this document, specifically in the context of Ethernet A-D per ES routes:

• When advertised, the L2-Attr Extended Community SHALL have only the P or B bits set in the Control Flags field, and all other bits and fields MUST be zero.
• A remote PE receiving the optional L2-Attr Extended Community in Ethernet A-D per ES routes SHALL consider only the P and B bits and ignore other values.

For the L2-Attr Extended Community sent and received in Ethernet A-D per EVI routes used in , , and :

• P and B bits received SHOULD be considered overridden by "parent" bits when advertised in the Ethernet A-D per ES.
• Other fields and bits of the extended community are used according to the procedures outlined in the referenced documents.

By adhering to these procedures, the network ensures proper handling of the L2-Attr Extended Community to maintain robust and efficient convergence across Ethernet Segments.

Backward Compatibility Implementations that comply with or only (i.e., implementations that predate this specification) and that receive an L2-Attr Extended Community in Ethernet A-D per ES routes will ignore it and continue to use the default path resolution algorithms of the two specifications above:

• The L2-Attr Extended Community in Ethernet A-D per ES route is ignored.
• The remote ESI Label Extended Community signals the Single-Active redundancy mode ().
• The remote Media Access Control (MAC) and/or Ethernet A-D per EVI routes are unchanged; the P and B bits in the L2-Attr Extended Community in Ethernet A-D per EVI routes are used.

Applicability A prevalent deployment scenario involves providing L2 or L3 services on PE devices that offer multihoming capabilities. The services may include any L2 EVPN solutions such as EVPN Virtual Private Wire Service (VPWS) or standard EVPN as defined in . Additionally, L3 services may be provided within a VPN context, as specified in , or within a global routing context. When a PE provides first-hop routing, EVPN IRB may also be deployed on the PEs. The mechanism outlined in this document applies to PEs providing L2 and/or L3 services where active/standby redundancy at the interface level is required. An alternative solution to the one described in this document is MC-LAG with ICCP active/standby redundancy, as detailed in . However, ICCP requires LDP to be enabled as a transport for ICCP messages. There are numerous scenarios where LDP is not necessary, such as deployments utilizing VXLAN or SRv6. The solution using EVPN, as described in this document, does not mandate the use of LDP or ICCP and remains independent of the underlay encapsulation.

IANA Considerations Per this document, IANA has added the following entry to the "DF Election Capabilities" registry under the "Border Gateway Protocol (BGP) Extended Communities" registry group:

Bit	Name	Reference
5	Port Mode Designated Forwarder Election	RFC 9786

Security Considerations The security considerations described in and are applicable to this document. Introducing a new capability necessitates unanimity among PEs. Without consensus on the new DF election procedures and Port Mode, the DF election algorithm defaults to the procedures outlined in and .This fallback behavior could be exploited by an attacker who modifies the configuration of one PE within the ES. Such manipulation could force all PEs in the ES to revert to the default DF election algorithm and capabilities. In this scenario, the PEs may be subject to unfair load balancing, service disruption, and potential issues such as traffic loss or duplicate traffic, as mentioned in the security sections of those documents.

References Normative References Institute of Electrical and Electronics Engineers

USA New York http://www.ieee.org

MAC-independent Link Aggregation capability and general information relevant to specific MAC types are defined in this standard. Link Aggregation allows parallel full-duplex point-to-point links to be used as if they were a single link and also supports the use of multiple links as a resilient load sharing interconnect between multiple nodes in two separately administered networks. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES). In addition, the ability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite State Machine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432). The Ethernet Virtual Private Network (EVPN) solution in RFC 7432 provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying the Highest Random Weight (HRW) algorithm for DF election to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast DF election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This document updates RFC 8584 by optionally introducing delays between some of the events therein. The solution is independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment, and it is performed via a simple signaling in BGP between the recovered node and each of the other nodes in the multihoming group. Nokia Nokia Juniper Networks Independent Cisco Systems Informative References This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK] This document specifies an Inter-Chassis Communication Protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems. It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms. This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. This document describes a new EVPN Virtual Private Wire Service (VPWS) service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments (ESs) and physical interfaces into a single EVPN-VPWS service tunnel and still providing Single-Active and All-Active multi-homing. This new service is referred to as the EVPN-VPWS Flexible Cross-Connect (FXC) service. This document specifies a solution based on extensions to EVPN-VPWS (RFC 8214), which in turn is based on extensions to EVPN (RFC 7432). Therefore, a thorough understanding of RFCs 7432 and 8214 are prerequisites for this document.

Acknowledgements The authors thank for his comments and suggestions and and for their careful reviews.

Contributors In addition to the authors listed on the front page, the following people have also contributed to this document: Cisco Systems

United States of America sajassi@cisco.com

Cisco Systems

United States of America sthoria@cisco.com

Authors' Addresses Cisco Systems

Ottawa ON Canada pbrisset@cisco.com

Cisco Systems

Canada lburdet@cisco.com

Comcast

United States of America Bin_Wen@comcast.com

Verizon Wireless

United States of America edward.leyton@verizonwireless.com

Nokia

United States of America jorge.rabadan@nokia.com