rfc9786.original   rfc9786.txt 
BESS Working Group P. Brissette Internet Engineering Task Force (IETF) P. Brissette
Internet-Draft LA. Burdet, Ed. Request for Comments: 9786 LA. Burdet, Ed.
Intended status: Standards Track Cisco Systems Category: Standards Track Cisco Systems
Expires: 8 June 2025 B. Wen ISSN: 2070-1721 B. Wen
Comcast Comcast
E. Leyton E. Leyton
Verizon Wireless Verizon Wireless
J. Rabadan J. Rabadan
Nokia Nokia
5 December 2024 June 2025
EVPN Port-Active Redundancy Mode EVPN Port-Active Redundancy Mode
draft-ietf-bess-evpn-mh-pa-13
Abstract Abstract
The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables The Multi-Chassis Link Aggregation (MC-LAG) group technology enables
establishing a logical link-aggregation connection with a redundant establishing a logical link-aggregation connection with a redundant
group of independent nodes. The objective of MC-LAG is to enhance group of independent nodes. The objective of MC-LAG is to enhance
both network availability and bandwidth utilization through various both network availability and bandwidth utilization through various
modes of traffic load-balancing. RFC7432 defines EVPN-based MC-LAG modes of traffic load balancing. RFC 7432 defines an EVPN-based MC-
with Single-active and All-active multi-homing redundancy modes. LAG with Single-Active and All-Active multihoming redundancy modes.
This document builds on the existing redundancy mechanisms supported This document builds on the existing redundancy mechanisms supported
by EVPN and introduces a new active/standby redundancy mode, called by EVPN and introduces a new active/standby redundancy mode, called
'Port-Active'. 'Port-Active'.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 8 June 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9786.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
1.2. Multi-Chassis Link Aggregation (MC-LAG) . . . . . . . . . 3 1.2. Multi-Chassis Link Aggregation (MC-LAG)
2. Port-Active Redundancy Mode . . . . . . . . . . . . . . . . . 4 2. Port-Active Redundancy Mode
2.1. Overall Advantages . . . . . . . . . . . . . . . . . . . 4 2.1. Overall Advantages
2.2. Port-Active Redundancy Procedures . . . . . . . . . . . . 5 2.2. Port-Active Redundancy Procedures
3. Designated Forwarder Algorithm to Elect per Port-Active PE . 6 3. Designated Forwarder Algorithm to Elect per Port-Active PE
3.1. Capability Flag . . . . . . . . . . . . . . . . . . . . . 6 3.1. Capability Flag
3.2. Modulo-based Algorithm . . . . . . . . . . . . . . . . . 7 3.2. Modulo-Based Algorithm
3.3. Highest Random Weight Algorithm . . . . . . . . . . . . . 7 3.3. Highest Random Weight Algorithm
3.4. Preference-based DF Election . . . . . . . . . . . . . . 8 3.4. Preference-Based DF Election
3.5. AC-Influenced DF Election . . . . . . . . . . . . . . . . 8 3.5. AC-Influenced DF Election
4. Convergence considerations . . . . . . . . . . . . . . . . . 8 4. Convergence Considerations
4.1. Primary / Backup per Ethernet-Segment . . . . . . . . . . 9 4.1. Primary/Backup Bits per Ethernet Segment
4.2. Backward Compatibility . . . . . . . . . . . . . . . . . 10 4.2. Backward Compatibility
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Applicability
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 Acknowledgements
10.2. Informative References . . . . . . . . . . . . . . . . . 12 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses
1. Introduction 1. Introduction
EVPN [RFC7432] defines the All-Active and Single-Active redundancy EVPN [RFC7432] defines the All-Active and Single-Active redundancy
modes. All-Active redundancy provides per-flow load-balancing for modes. All-Active redundancy provides per-flow load balancing for
multi-homing, while Single-Active redundancy ensures service carving multihoming, while Single-Active redundancy ensures service carving
where only one of the Provider Edge (PE) devices in a redundancy where only one of the Provider Edge (PE) devices in a redundancy
relationship is active per service. relationship is active per service.
Although these two multi-homing scenarios are widely utilized in data Although these two multihoming scenarios are widely utilized in data
center and service provider access networks, there are cases where center and service provider access networks, there are cases where
active/standby multi-homing at the interface level is beneficial and active/standby multihoming at the interface level is beneficial and
necessary. The primary consideration for this new mode of load- necessary. The primary consideration for this new mode of load
balancing is the determinism of traffic forwarding through a specific balancing is the determinism of traffic forwarding through a specific
interface, rather than statistical per-flow load-balancing across interface rather than statistical per-flow load balancing across
multiple PEs providing multi-homing. This determinism is essential multiple PEs providing multihoming. This determinism is essential
for certain QoS features to function correctly. Additionally, this for certain QoS features to function correctly. Additionally, this
mode ensures fast convergence during failure and recovery, which is mode ensures fast convergence during failure and recovery, which is
expected by customers. expected by customers.
This document defines the Port-Active redundancy mode as a new type This document defines the Port-Active redundancy mode as a new type
of multi-homing in EVPN and details how this mode operates and is of multihoming in EVPN and details how this mode operates and is
supported via EVPN. supported via EVPN.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Multi-Chassis Link Aggregation (MC-LAG) 1.2. Multi-Chassis Link Aggregation (MC-LAG)
When a CE device is multi-homed to a set of PE nodes using the When a Customer Equipment (CE) device is multihomed to a set of PE
[IEEE_802.1AX_2014] Link Aggregation Control Protocol (LACP), the PEs nodes using the Link Aggregation Control Protocol (LACP)
must function as a single LACP entity for the Ethernet links to form [IEEE_802.1AX_2014], the PEs must function as a single LACP entity
and operate as a Link Aggregation Group (LAG). To achieve this, the for the Ethernet links to form and operate as a Link Aggregation
PEs connected to the same multi-homed CE must synchronize LACP Group (LAG). To achieve this, the PEs connected to the same
configuration and operational data among them. Historically, the multihomed CE must synchronize LACP configuration and operational
Interchassis Communication Protocol (ICCP) [RFC7275] has been used data among them. Historically, the Inter-Chassis Communication
for this synchronization. EVPN, as described in [RFC7432], covers Protocol (ICCP) [RFC7275] has been used for this synchronization.
the scenario where a CE is multi-homed to multiple PE nodes, using a EVPN, as described in [RFC7432], covers the scenario where a CE is
LAG to simplify the procedure significantly. This simplification, multihomed to multiple PE nodes, using a LAG to simplify the
however, comes with certain assumptions: procedure significantly. However, this simplification comes with
certain assumptions:
* a CE device connected to EVPN multi-homing PEs MUST have a single * A CE device connected to EVPN multihoming PEs MUST have a single
LAG with all its links connected to the EVPN multi-homing PEs in a LAG with all its links connected to the EVPN multihoming PEs in a
redundancy group. redundancy group.
* identical LACP parameters MUST be configured on peering PEs, * Identical LACP parameters MUST be configured on peering PEs,
including system ID, port priority, and port key. including the system ID, port priority, and port key.
This document presumes proper LAG operation as specified in This document presumes proper LAG operation as specified in
[RFC7432]. Issues resulting from deviations in the aforementioned [RFC7432]. Issues resulting from deviations in the aforementioned
assumptions, LAG misconfiguration, and miswiring detection across assumptions, LAG misconfiguration, and miswiring detection across
peering PEs are considered outside the scope of this document. peering PEs are considered outside the scope of this document.
+-----+ +-----+
| PE3 | | PE3 |
+-----+ +-----+
+-----------+ +-----------+
skipping to change at page 4, line 25 skipping to change at line 161
I1 I2 I1 I2
\ / \ /
\ / \ /
\ / \ /
+---+ +---+
|CE1| |CE1|
+---+ +---+
Figure 1: MC-LAG Topology Figure 1: MC-LAG Topology
Figure 1 shows a MC-LAG multi-homing topology where PE1 and PE2 are Figure 1 shows an MC-LAG multihoming topology where PE1 and PE2 are
part of the same redundancy group providing multi-homing to CE1 via part of the same redundancy group providing multihoming to CE1 via
interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG 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 running LACP. The core, shown as IP or MPLS enabled, provides a wide
range of L2 and L3 services. MC-LAG multi-homing functionality is range of L2 and L3 services. MC-LAG multihoming functionality is
decoupled from those services in the core and it focuses on providing decoupled from those services in the core, and it focuses on
multi-homing to the CE. In Port-Active redundancy mode, only one of providing multihoming to the CE. In Port-Active redundancy mode,
the two interfaces I1 or I2 would be in forwarding and the other only one of the two interfaces, I1 or I2, would be in forwarding, and
interface will be in standby. This also implies that all services on the other interface would be in standby. This also implies that all
the active interface are in active mode and all services on the services on the active interface operate in active mode and all
standby interface operate in standby mode. services on the standby interface operate in standby mode.
2. Port-Active Redundancy Mode 2. Port-Active Redundancy Mode
2.1. Overall Advantages 2.1. Overall Advantages
The use of Port-Active redundancy in EVPN networks provides the The use of Port-Active redundancy in EVPN networks provides the
following benefits: following benefits:
a. Port-Active redundancy offers open standards-based active/standby a. It offers open-standards-based active/standby redundancy at the
redundancy at the interface level, rather than VLAN granularity interface level rather than VLAN granularity [RFC7432].
[RFC7432].
b. Port-Active redundancy eliminates the need for ICCP and LDP b. It eliminates the need for ICCP and LDP [RFC5036] (e.g., Virtual
[RFC5306] (e.g., VXLAN [RFC7348] or SRv6 [RFC8402] may be used in eXtensible Local Area Network (VXLAN) [RFC7348] or Segment
the network). Routing over IPv6 (SRv6) [RFC8402] may be used in the network).
c. This mode is agnostic of the underlying technology (MPLS, VXLAN, c. This mode is agnostic of the underlying technology (MPLS, VXLAN,
SRv6) and associated services (L2, L3, Bridging, E-LINE, etc.) and SRv6) and associated services (Layer 2 (L2), Layer 3 (L3),
Bridging, E-LINE, etc.)
d. It enables deterministic QoS over MC-LAG attachment circuits. d. It enables deterministic QoS over MC-LAG attachment circuits.
e. Port-Active redundancy is fully compliant with [RFC7432] and does e. It is fully compliant with [RFC7432] and does not require any new
not require any new protocol enhancements to existing EVPN RFCs. protocol enhancements to existing EVPN RFCs.
f. It can leverage various Designated Forwarder (DF) election f. It can leverage various Designated Forwarder (DF) election
algorithms, such as modulo ([RFC7432]), Highest Random Weight algorithms, such as modulo [RFC7432], Highest Random Weight (HRW)
(HRW, [RFC8584]), etc. [RFC8584], etc.
g. Port-Active redundancy replaces legacy MC-LAG ICCP-based g. It replaces legacy MC-LAG ICCP-based solutions and offers the
solutions and offers the following additional benefits: following additional benefits:
* Efficient support for 1+N redundancy mode (with EVPN using BGP * Efficient support for 1+N redundancy mode (with EVPN using BGP
Route Reflector), whereas ICCP requires a full mesh of LDP Route Reflector), whereas ICCP requires a full mesh of LDP
sessions among PEs in the redundancy group. sessions among PEs in the redundancy group.
* Fast convergence with mass-withdraw is possible with EVPN, * Fast convergence with mass withdraw is possible with EVPN,
which has no equivalent in ICCP. which has no equivalent in ICCP.
2.2. Port-Active Redundancy Procedures 2.2. Port-Active Redundancy Procedures
The following steps outline the proposed procedure for supporting The following steps outline the proposed procedure for supporting
Port-Active redundancy mode with EVPN LAG: Port-Active redundancy mode with EVPN LAG:
a. The Ethernet-Segment Identifier (ESI) MUST be assigned per access a. The Ethernet Segment Identifier (ESI) MUST be assigned per access
interface as described in [RFC7432]. The ESI can be auto-derived interface as described in [RFC7432]. The ESI can be auto-derived
or manually assigned and the access interface MAY be a Layer-2 or or manually assigned, and the access interface MAY be an L2 or L3
Layer-3 interface. interface.
b. The Ethernet-Segment (ES) MUST be configured in Port-Active b. The Ethernet Segment (ES) MUST be configured in Port-Active
redundancy mode on peering PEs for the specified access redundancy mode on peering PEs for the specified access
interface. interface.
c. When ESI is configured on a Layer-3 interface, the Ethernet- c. When ESI is configured on an L3 interface, the ES route (Route
Segment (ES) route (Route Type-4) can be the only route exchanged Type-4) can be the only route exchanged by PEs in the redundancy
by PEs in the redundancy group. group.
d. PEs in the redundancy group leverage the DF election defined in d. PEs in the redundancy group leverage the DF election defined in
[RFC8584] to determine which PE keeps the port in active mode and [RFC8584] to determine which PE keeps the port in active mode and
which one(s) keep it in standby mode. Although the DF election which PE(s) keeps it in standby mode. Although the DF election
defined in [RFC8584] is per [ES, Ethernet Tag] granularity, the defined in [RFC8584] is per [ES, Ethernet Tag] granularity, the
DF election is performed per [ES] in Port-Active redundancy mode. DF election is performed per [ES] in Port-Active redundancy mode.
The details of this algorithm are described in Section 3. The details of this algorithm are described in Section 3.
e. The DF router MUST keep the corresponding access interface in an e. The DF router MUST keep the corresponding access interface in an
up and forwarding active state for that Ethernet-Segment. up and forwarding active state for that ES.
f. Non-DF routers SHOULD implement a bidirectional blocking scheme f. Non-DF routers SHOULD implement a bidirectional blocking scheme
for all traffic comparable to the Single-Active blocking scheme for all traffic comparable to the Single-Active redundancy mode
described in [RFC7432], albeit across all VLANs. described in [RFC7432], albeit across all VLANs.
* Non-DF routers MAY bring and keep the peering access interface * Non-DF routers MAY bring and keep the peering access interface
attached to them in an operational down state. attached to them in an operational down state.
* If the interface is running the LACP protocol, the non-DF PE * If the interface is running the LACP protocol, the non-DF PE
MAY set the LACP state to OOS (Out of Sync) instead of setting MAY set the LACP state to Out of Sync (OOS) instead of setting
the interface to a down state. This approach allows for the interface to a down state. This approach allows for
better convergence during the transition from standby to better convergence during the transition from standby to
active mode. active mode.
g. The primary/backup bits of the EVPN Layer 2 Attributes Extended g. The primary/backup bits of the EVPN Layer 2 Attributes (L2-Attr)
Community [RFC8214] SHOULD be used to achieve better convergence, Extended Community [RFC8214] SHOULD be used to achieve better
as described in Section 4.1. convergence, as described in Section 4.1.
3. Designated Forwarder Algorithm to Elect per Port-Active PE 3. Designated Forwarder Algorithm to Elect per Port-Active PE
The Ethernet-Segment (ES) routes operating in Port-Active redundancy The ES routes operating in Port-Active redundancy mode are advertised
mode are advertised with the new Port Mode Load-Balancing capability with the new Port Mode Load-Balancing capability bit in the DF
bit in the DF Election Extended Community as defined in [RFC8584]. Election Extended Community as defined in [RFC8584]. Additionally,
Additionally, the ES associated with the port utilizes the existing the ES associated with the port utilizes the existing Single-Active
Single-Active procedure and signals the Single-Active Multihomed site procedure and signals the Single-Active multihomed site redundancy
redundancy mode along with the Ethernet-AD per-ES route (refer to mode along with the Ethernet A-D per-ES route (refer to Section 7.5
Section 7.5 of [RFC7432]). Finally, The ESI label-based of [RFC7432]). Finally, The ESI label-based split-horizon procedures
split-horizon procedures specified in Section 8.3 of [RFC7432] SHOULD specified in Section 8.3 of [RFC7432] SHOULD be employed to prevent
be employed to prevent transient echo packets when Layer-2 circuits transient echo packets when L2 circuits are involved.
are involved.
Various algorithms for DF Election are detailed in Sections 3.2 to Various algorithms for DF election are detailed in Sections 3.2 to
3.5 for comprehensive understanding, although the choice of algorithm 3.5 for comprehensive understanding, although the choice of algorithm
in this solution does not significantly impact complexity or in this solution does not significantly impact complexity or
performance compared to other redundancy modes. performance compared to other redundancy modes.
3.1. Capability Flag 3.1. Capability Flag
[RFC8584] defines a DF Election extended community, and a Bitmap (2 [RFC8584] defines a DF Election Extended Community and a bitmap (2
octets) field to encode "DF Election Capabilities" to use with the DF octets) field to encode "DF Election Capabilities" to use with the DF
election algorithm in the DF algorithm field: election algorithm in the DF algorithm field:
Bit 0: D bit or 'Don't Pre-empt' bit, as explained in Bit 0: D bit or 'Don't Preempt' bit, as described in [RFC9785].
[I-D.ietf-bess-evpn-pref-df].
Bit 1: AC-Influenced DF election, as explained in [RFC8584]. Bit 1: AC-Influenced DF (AC-DF) election, as described in
[RFC8584].
Bit 3: Time Synchronization, as described in [RFC9722].
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |P| | |D|A| |T| |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Amended DF Election Capabilities in the DF Election Figure 2: Amended DF Election Capabilities in the DF Election
Extended Community Extended Community
This document defines the following value and extends the DF Election This document defines the following value and extends the DF Election
Capabilities bitmap field: Capabilities bitmap field:
Bit 5: Port Mode Designated Forwarder Election. This bit Bit 5: Port Mode Designated Forwarder Election. This bit
determines that the DF Election algorithm SHOULD be determines that the DF election algorithm SHOULD be
modified to consider the port ES only and not the Ethernet modified to consider the port ES only and not the Ethernet
Tags. Tags.
3.2. Modulo-based Algorithm 3.2. Modulo-Based Algorithm
The default DF Election algorithm, or modulo-based algorithm, as The default DF election algorithm, or modulo-based algorithm, as
described in [RFC7432] and updated by [RFC8584], is applied here at described in [RFC7432] and updated by [RFC8584], is applied here at
the granularity of ES only. Given that the ES-Import Route Target the granularity of ES only. Given that the ES-Import Route Target
extended community may be auto-derived and directly inherits its extended community may be auto-derived and directly inherits its
auto-derived value from ESI bytes 1-6, many operators differentiate auto-derived value from ESI bytes 1-6, many operators differentiate
ESIs primarily within these bytes. Consequently, bytes 3-6 are ESIs primarily within these bytes. Consequently, bytes 3-6 are
utilized to determine the designated forwarder using the modulo-based utilized to determine the designated forwarder using the modulo-based
DF assignment, achieving good entropy during modulo calculation DF assignment, achieving good entropy during modulo calculation
across ESIs. across ESIs.
Assuming a redundancy group of N PE nodes, the PE with ordinal i is 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 designated as the DF for an <ES> when (Es mod N) = i, where Es
represents bytes 3-6 of that ESI. represents bytes 3-6 of that ESI.
3.3. Highest Random Weight Algorithm 3.3. Highest Random Weight Algorithm
An application of Highest Random Weight (HRW) to EVPN DF Election is An application of Highest Random Weight (HRW) to EVPN DF election is
defined in [RFC8584] and MAY also be used and signaled. For Port- defined in [RFC8584], and it MAY be used and signaled. For Port-
Active this is modified to operate at the granularity of <ES> rather Active, this is modified to operate at the granularity of <ES> rather
than per <ES, VLAN>. than per <ES, VLAN>.
Section 3.2 of [RFC8584] describes computing a 32-bit CRC over the Section 3.2 of [RFC8584] describes computing a 32-bit Cyclic
concatenation of Ethernet Tag (V) and ESI (Es). For Port-Active Redundancy Check (CRC) over the concatenation of Ethernet Tag (V) and
redundancy mode, the Ethernet Tag is omitted from the CRC computation ESI (Es). For Port-Active redundancy mode, the Ethernet Tag is
and all references to (V, Es) are replaced by (Es). omitted from the CRC computation and all references to (V, Es) are
replaced by (Es).
The algorithm to detemine the DF Elected and Backup-DF Elected (BDF) The algorithm used to determine the DF and Backup Designated
at Section 3.2 of [RFC8584] is repeated and summarized below using Forwarder (BDF) per Section 3.2 of [RFC8584] is repeated and
only (Es) in the computation: summarized below using only (Es) in the computation:
1. DF(Es) = Si| Weight(Es, Si) >= Weight(Es, Sj), for all j. In the 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 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 least. Note that 0 <= i,j < number of PEs in the redundancy
group. group.
2. BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es, 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 Sk) >= Weight(Es, Sj). In the case of a tie, choose the PE whose
IP address is numerically the least. IP address is numerically the least.
Where: Where:
* DF(Es) is defined to be the address Si (index i) for which * DF(Es) is defined to be the address Si (index i) for which
Weight(Es, Si) is the highest; 0 <= i < N-1. Weight(Es, Si) is the highest; 0 <= i < N-1.
* BDF(Es) is defined as that PE with address Sk for which the * 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 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. is the running index from 0 to N-1; i and k are selected values.
3.4. Preference-based DF Election 3.4. Preference-Based DF Election
When the new capability 'Port Mode' is signaled, the preference-based When the new capability 'Port Mode' is signaled, the preference-based
DF Election algorithm in [I-D.ietf-bess-evpn-pref-df] is modified to DF election algorithm [RFC9785] is modified to consider the port only
consider the port only and not any associated Ethernet Tags. The and not any associated Ethernet Tags. The Port Mode capability is
Port Mode capability is compatible with the 'Don't Pre-empt' bit and compatible with the 'Don't Preempt' bit and both may be signaled.
both may be signaled. When an interface recovers, a peering PE When an interface recovers, a peering PE signaling the D bit enables
signaling D bit enables non-revertive behavior at the port level. non-revertive behavior at the port level.
3.5. AC-Influenced DF Election 3.5. AC-Influenced DF Election
The AC-DF bit defined in [RFC8584] MUST be set to 0 when advertising The AC-DF bit defined in [RFC8584] MUST be set to 0 when advertising
Port Mode Designated Forwarder Election capability (P=1). When an AC Port Mode Designated Forwarder Election capability (P=1). When an AC
(sub-interface) goes down, any resulting Ethernet A-D per EVI (sub-interface) goes down, any resulting Ethernet A-D per EVI
withdrawal does not influence the DF Election. withdrawal does not influence the DF election.
Upon receiving the AC-DF bit set (A=1) from a remote PE, it MUST be Upon receiving the AC-DF bit set (A=1) from a remote PE, it MUST be
ignored when performing Port Mode DF Election. ignored when performing Port Mode Designated Forwarder Election.
4. Convergence considerations 4. Convergence Considerations
To enhance convergence during failure and recovery when Port-Active To enhance convergence during failure and recovery when the Port-
redundancy mode is employed, prior synchronization between peering Active redundancy mode is employed, prior synchronization between
PEs may be beneficial. peering PEs may be beneficial.
The Port-Active mode poses a challenge to synchronization since the The Port-Active mode poses a challenge to synchronization since the
"standby" port may be in a down state. Transitioning a "standby" "standby" port may be in a down state. Transitioning a "standby"
port to an up state and stabilizing the network requires time. For port to an up state and stabilizing the network requires time. For
Integrated Routing and Bridging (IRB) and Layer 3 services, prior Integrated Routing and Bridging (IRB) and L3 services, prior
synchronization of ARP / ND caches is recommended. Additionally, synchronization of ARP / Neighbor Discovery (ND) caches is
associated VRF tables may need to be synchronized. For Layer 2 recommended. Additionally, associated Virtual Routing and Forwarding
services, synchronization of MAC tables may be considered. (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 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" port to an "out-of-sync" state, also known as "warm-
standby," can be utilized to improve convergence times. standby," can be utilized to improve convergence times.
4.1. Primary / Backup per Ethernet-Segment 4.1. Primary/Backup Bits per Ethernet Segment
The EVPN Layer 2 Attributes Extended Community ("L2-Attr") defined in The EVPN L2-Attr Extended Community defined in [RFC8214] SHOULD be
[RFC8214] SHOULD be advertised in the Ethernet A-D per ES route to advertised in the Ethernet A-D per ES route to enable fast
enable fast convergence. convergence.
Only the P and B bits of the Control Flags field in the L2-Attr 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 Extended Community are relevant to this document, specifically in the
context of Ethernet A-D per ES routes: context of Ethernet A-D per ES routes:
* When advertised, the L2-Attr Extended Community SHALL have only * 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 the P or B bits set in the Control Flags field, and all other bits
and fields MUST be zero. and fields MUST be zero.
* A remote PE receiving the optional L2-Attr Extended Community in * 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 Ethernet A-D per ES routes SHALL consider only the P and B bits
and ignore other values. and ignore other values.
For L2-Attr Extended Community sent and received in Ethernet A-D For the L2-Attr Extended Community sent and received in Ethernet A-D
per EVI routes used in [RFC8214], [RFC7432] and per EVI routes used in [RFC8214], [RFC7432], and [RFC9744]:
[I-D.ietf-bess-evpn-vpws-fxc]:
* P and B bits received SHOULD be considered overridden by "parent" * P and B bits received SHOULD be considered overridden by "parent"
bits when advertised in the Ethernet A-D per ES. bits when advertised in the Ethernet A-D per ES.
* Other fields and bits of the extended community are used according * Other fields and bits of the extended community are used according
to the procedures outlined in the referenced documents. to the procedures outlined in the referenced documents.
By adhering to these procedures, the network ensures proper handling By adhering to these procedures, the network ensures proper handling
of the L2-Attr Extended Community to maintain robust and efficient of the L2-Attr Extended Community to maintain robust and efficient
convergence across Ethernet Segments. convergence across Ethernet Segments.
4.2. Backward Compatibility 4.2. Backward Compatibility
Implementations that comply with [RFC7432] or [RFC8214] only (i.e., Implementations that comply with [RFC7432] or [RFC8214] only (i.e.,
implementations that predate this specification) which receive an implementations that predate this specification) and that receive an
L2-Attr Extended Community in Ethernet A-D per ES routes will ignore 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 it and continue to use the default path resolution algorithms of the
two specifications above: two specifications above:
* The L2-Attr Extended Community in Ethernet A-D per ES route is * The L2-Attr Extended Community in Ethernet A-D per ES route is
ignored ignored.
* The remote ESI Label Extended Community ([RFC7432]) signals * The remote ESI Label Extended Community [RFC7432] signals the
Single-Active (Section 3) Single-Active redundancy mode (Section 3).
* the remote MAC and/or Ethernet A-D per EVI routes are unchanged, * The remote Media Access Control (MAC) and/or Ethernet A-D per EVI
the P and B bits in the L2-Attr Extended Community in Ethernet A-D routes are unchanged; the P and B bits in the L2-Attr Extended
per EVI routes are used. Community in Ethernet A-D per EVI routes are used.
5. Applicability 5. Applicability
A prevalent deployment scenario involves providing L2 or L3 services A prevalent deployment scenario involves providing L2 or L3 services
on PE devices that offer multi-homing capabilities. The services may on PE devices that offer multihoming capabilities. The services may
include any L2 EVPN solutions such as EVPN VPWS or standard EVPN as include any L2 EVPN solutions such as EVPN Virtual Private Wire
defined in [RFC7432]. Additionally, L3 services may be provided Service (VPWS) or standard EVPN as defined in [RFC7432].
within a VPN context, as specified in [RFC4364], or within a global Additionally, L3 services may be provided within a VPN context, as
routing context. When a PE provides first-hop routing, EVPN IRB may specified in [RFC4364], or within a global routing context. When a
also be deployed on the PEs. The mechanism outlined in this document PE provides first-hop routing, EVPN IRB may also be deployed on the
applies to PEs providing L2 and/or L3 services where active/standby PEs. The mechanism outlined in this document applies to PEs
redundancy at the interface level is required. 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 An alternative solution to the one described in this document is MC-
Multi-Chassis Link Aggregation Group (MC-LAG) with ICCP active- LAG with ICCP active/standby redundancy, as detailed in [RFC7275].
standby redundancy, as detailed in [RFC7275]. However, ICCP requires However, ICCP requires LDP to be enabled as a transport for ICCP
LDP to be enabled as a transport for ICCP messages. There are messages. There are numerous scenarios where LDP is not necessary,
numerous scenarios where LDP is not necessary, such as deployments such as deployments utilizing VXLAN or SRv6. The solution using
utilizing VXLAN or SRv6. The solution described in this document EVPN, as described in this document, does not mandate the use of LDP
using EVPN does not mandate the use of LDP or ICCP and remains or ICCP and remains independent of the underlay encapsulation.
independent of the underlay encapsulation.
6. IANA Considerations 6. IANA Considerations
This document solicits the allocation of the following values from Per this document, IANA has added the following entry to the "DF
the "BGP Extended Communities" registry group : Election Capabilities" registry under the "Border Gateway Protocol
(BGP) Extended Communities" registry group:
* Bit 5 in the [RFC8584] DF Election Capabilities registry, "Port +=====+=========================================+===========+
Mode Designated Forwarder Election". | Bit | Name | Reference |
+=====+=========================================+===========+
| 5 | Port Mode Designated Forwarder Election | RFC 9786 |
+-----+-----------------------------------------+-----------+
Table 1
7. Security Considerations 7. Security Considerations
The Security Considerations described in [RFC7432] and [RFC8584] are The security considerations described in [RFC7432] and [RFC8584] are
applicable to this document. applicable to this document.
Introducing a new capability necessitates unanimity among PEs. Introducing a new capability necessitates unanimity among PEs.
Without consensus on the new DF Election procedures and Port Mode, Without consensus on the new DF election procedures and Port Mode,
the DF Election algorithm defaults to the procedures outlined in the DF election algorithm defaults to the procedures outlined in
[RFC8584] and [RFC7432].This fallback behavior could be exploited by [RFC8584] and [RFC7432].This fallback behavior could be exploited by
an attacker who modifies the configuration of one PE within the an attacker who modifies the configuration of one PE within the ES.
Ethernet Segment (ES). Such manipulation could force all PEs in the Such manipulation could force all PEs in the ES to revert to the
ES to revert to the default DF Election algorithm and capabilities. default DF election algorithm and capabilities. In this scenario,
In this scenario, the PEs may be subject to unfair load balancing, the PEs may be subject to unfair load balancing, service disruption,
service disruption, and potential issues such as black-holing or and potential issues such as traffic loss or duplicate traffic, as
duplicate traffic, as mentioned in the security sections of those mentioned in the security sections of those documents.
documents.
8. Acknowledgements
The authors thank Anoop Ghanwani for his comments and suggestions and
Stephane Litkowski and Gunter van de Velde for their careful reviews.
9. Contributors
In addition to the authors listed on the front page, the following
people have also contributed to this document:
Ali Sajassi
Cisco Systems
United States of America
Email: sajassi@cisco.com
Samir Thoria
Cisco Systems
United States of America
Email: sthoria@cisco.com
10. References
10.1. Normative References 8. References
[I-D.ietf-bess-evpn-pref-df] 8.1. Normative References
Rabadan, J., Sathappan, S., Lin, W., Drake, J., and A.
Sajassi, "Preference-based EVPN DF Election", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-13,
9 October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-bess-evpn-pref-df-13>.
[IEEE_802.1AX_2014] [IEEE_802.1AX_2014]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks -- Link Aggregation", IEEE 802-1ax-2014, networks -- Link Aggregation", IEEE 802-1ax-2014,
DOI 10.1109/IEEESTD.2014.7055197, 5 March 2015, DOI 10.1109/IEEESTD.2014.7055197, 5 March 2015,
<https://ieeexplore.ieee.org/document/7055197>. <https://ieeexplore.ieee.org/document/7055197>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 12, line 43 skipping to change at line 526
Rabadan, "Virtual Private Wire Service Support in Ethernet Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>. <https://www.rfc-editor.org/info/rfc8214>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility", VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019, RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>. <https://www.rfc-editor.org/info/rfc8584>.
10.2. Informative References [RFC9722] Brissette, P., Sajassi, A., Burdet, LA., Ed., Drake, J.,
and J. Rabadan, "Fast Recovery for EVPN Designated
Forwarder Election", RFC 9722, DOI 10.17487/RFC9722, May
2025, <https://www.rfc-editor.org/info/rfc9722>.
[I-D.ietf-bess-evpn-vpws-fxc] [RFC9785] Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and
Sajassi, A., Brissette, P., Uttaro, J., Drake, J., A. Sajassi, "Preference-Based EVPN Designated Forwarder
Boutros, S., and J. Rabadan, "EVPN VPWS Flexible Cross- (DF) Election", RFC RFC9785, DOI 10.17487/RFC9785, June
Connect Service", Work in Progress, Internet-Draft, draft- 2025, <https://www.rfc-editor.org/info/rfc9785>.
ietf-bess-evpn-vpws-fxc-10, 4 December 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess- 8.2. Informative References
evpn-vpws-fxc-10>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
RFC 5306, DOI 10.17487/RFC5306, October 2008, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
<https://www.rfc-editor.org/info/rfc5306>. October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M.,
Matsushima, S., and T. Nadeau, "Inter-Chassis Matsushima, S., and T. Nadeau, "Inter-Chassis
Communication Protocol for Layer 2 Virtual Private Network Communication Protocol for Layer 2 Virtual Private Network
(L2VPN) Provider Edge (PE) Redundancy", RFC 7275, (L2VPN) Provider Edge (PE) Redundancy", RFC 7275,
DOI 10.17487/RFC7275, June 2014, DOI 10.17487/RFC7275, June 2014,
<https://www.rfc-editor.org/info/rfc7275>. <https://www.rfc-editor.org/info/rfc7275>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[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,
<https://www.rfc-editor.org/info/rfc9744>.
Acknowledgements
The authors thank Anoop Ghanwani for his comments and suggestions and
Stephane Litkowski and Gunter Van de Velde for their careful reviews.
Contributors
In addition to the authors listed on the front page, the following
people have also contributed to this document:
Ali Sajassi
Cisco Systems
United States of America
Email: sajassi@cisco.com
Samir Thoria
Cisco Systems
United States of America
Email: sthoria@cisco.com
Authors' Addresses Authors' Addresses
Patrice Brissette Patrice Brissette
Cisco Systems Cisco Systems
Ottawa ON Ottawa ON
Canada Canada
Email: pbrisset@cisco.com Email: pbrisset@cisco.com
Luc Andre Burdet (editor) Luc André Burdet (editor)
Cisco Systems Cisco Systems
Canada Canada
Email: lburdet@cisco.com Email: lburdet@cisco.com
Bin Wen Bin Wen
Comcast Comcast
United States of America United States of America
Email: Bin_Wen@comcast.com Email: Bin_Wen@comcast.com
Edward Leyton Edward Leyton
Verizon Wireless Verizon Wireless
United States of America United States of America
Email: edward.leyton@verizonwireless.com Email: edward.leyton@verizonwireless.com
Jorge Rabadan Jorge Rabadan
Nokia Nokia
United States of America United States of America
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
 End of changes. 79 change blocks. 
245 lines changed or deleted 252 lines changed or added

This html diff was produced by rfcdiff 1.48.