RFC 9785

Preference-Based EVPN Designated Forwarder (DF) Election

📅 published June 2025, from ietf

RFC 9785: Preference-Based EVPN Designated Forwarder (DF) Election 🎀

okay bestie, let's start with the title block 💅 RFC 9785 came out in June 2025 from the IETF, and it's a Standards Track document, so it's a real spec people are supposed to implement 🔥 The authors are J. Rabadan (Ed.), S. Sathappan (Nokia), W. Lin (Juniper Networks), J. Drake (Independent), and A. Sajassi (Cisco Systems) 🫶 The ISSN is 2070-1721 🌸 The big news is that it updates RFC 8584 🦋 It doesn't list anything it obsoletes.

Abstract

okay so the Designated Forwarder (DF) in an EVPN is the PE router in charge of sending BUM traffic (Broadcast, Unknown Unicast, and Multicast) to a multihomed device or network 💖 In an All-Active Ethernet Segment (ES) it handles BUM traffic, and in Single-Active multihoming it handles BUM and unicast traffic ✨ The DF gets picked from a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) into the EVPN network, using the default DF election algorithm 🧚

The default algorithm is efficient and automatic, and it picks DFs nicely across different Ethernet Tags in the ES 💅 But some use cases need something more "deterministic" and user-controlled 😭 Network operators also want an easy way to force an on-demand DF switchover, so they can do maintenance on the current DF or decide whether a new active PE is allowed to preempt the current DF PE 🍓

This document proposes a DF election algorithm that gives you determinism and operation control 👑 It updates RFC 8584 by changing the definition of the DF Election Extended Community 🎀

Status of This Memo

This is an Internet Standards Track document 🌈

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ If you want more on Internet Standards, check Section 2 of RFC 7841 💜

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9785 🦋

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 🌸 Please read those carefully, because they describe your rights and restrictions for this document ⭐ Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🔥

Table of Contents

1.  Introduction
  1.1.  Problem Statement
  1.2.  Solution Requirements
  1.3.  Solution Overview
2.  Requirements Language and Terminology
3.  EVPN BGP Attribute Extensions
4.  Solution Description
  4.1.  Use of the Highest-Preference and Lowest-Preference
        Algorithm
  4.2.  Use of the Highest-Preference or Lowest-Preference
        Algorithm in Ethernet Segments
  4.3.  The Non-Revertive Capability
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction ✨

1.1. Problem Statement

okay so [RFC7432] defines the DF in EVPN networks as the PE in charge of sending BUM traffic to a multihomed device or network 💅 That's for an All-Active multihoming Ethernet Segment, and for Single-Active multihoming it's BUM and unicast traffic to a multihomed device or network 🦋 The DF is picked from a candidate list of PEs that advertise the ESI to the EVPN network, using the DF election algorithm or the DF Alg from [RFC8584] 🧚

The default DF algorithm and the Highest Random Weight (HRW) algorithm [RFC8584] are efficient and automatic, and they pick DFs across different Ethernet Tags in the ES 🌸 But there are use cases that need a more user-controlled method 😭 Operators also need an easy way to force an on-demand DF switchover, for maintenance on the existing DF or to control whether a new active PE can preempt the existing DF PE 🍓

1.2. Solution Requirements

The procedures in this document meet the following requirements 💖

  • a. The solution gives you an administrative preference option, so you control the order in which candidate PEs become the DF, assuming they're all operationally ready to take over 👑 The operator decides whether the Highest-Preference or Lowest-Preference PE in the Ethernet Segment gets elected as the DF, based on the DF algorithms in this document ✨
  • b. The extensions here work for Ethernet Segments [RFC7432] and for virtual Ethernet Segments as defined in [RFC9784] 🫶
  • c. The user can force a PE to preempt the existing DF for a given Ethernet Tag, without reconfiguring every PE in the Ethernet Segment. You just change the existing administrative preference on that PE 🔥
  • d. The solution has an option to NOT preempt the current DF (the "Don't Preempt" Capability), even if the former DF PE comes back up after a failure 💜 This is also called "non-revertive" behavior 🌈 The DF election procedures in [RFC7432] are always revertive, because the winner of the default DF election algorithm always takes over as the operational DF 🙈
  • e. The procedures here support both Single-Active and All-Active multihoming Ethernet Segments 🦋

1.3. Solution Overview

okay here's the plan 🧚 To meet all those requirements, we introduce two new DF algorithms that can be advertised in the DF Election Extended Community (Section 3) 💖 Those new DF Election Extended Community variants carry a DF election preference for each PE, and that preference decides which PE becomes the DF (Section 4.1) 🌸 The advertised DF election preference can change dynamically from the administratively configured preference, which gives you non-revertive behavior (Section 4.3) ✨ Section 4.2 covers an optional solution for Ethernet Segments with lots of Ethernet Tags that need to balance load across multiple DFs 🎀

2. Requirements Language and Terminology

Here's the key word part, bestie 🤓 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], but only when they appear in all capitals, as shown here 💅

Now the glossary, the terms you'll see all over this doc 🦋

  • AC: Attachment Circuit. An AC has an Ethernet Tag associated to it. 🌸
  • CE: Customer Equipment router 🧚
  • DF: Designated Forwarder 💖
  • DF Alg: Refers to the DF election algorithm, which this document sometimes shortens to "Alg" ✨
  • DP: Refers to the "Don't Preempt" Capability in the DF Election Extended Community 👑
  • ENNI: External Network-Network Interface 🎀
  • ES and vES: Ethernet Segment and virtual Ethernet Segment. 🫶
  • Ethernet A-D per EVI route: Refers to Route Type 1 or Auto-Discovery per EVPN Instance route [RFC7432] 🔥
  • EVC: Ethernet Virtual Circuit 💜
  • EVI: EVPN Instance 🌈
  • Ethernet Tag: Used to represent a broadcast domain that's configured on a given Ethernet Segment for the purpose of DF election 🙈 Any of these may represent a broadcast domain: VLAN IDs (VIDs) (including Q-in-Q tags), configured IDs, VXLAN Network Identifiers (VNIs), normalized VIDs, Service Instance Identifiers (I-SIDs), etc., as long as the broadcast domains are represented consistently across the multihomed PEs attached to that Ethernet Segment 🦋 The Ethernet Tag value MUST NOT be zero. 🛑
  • HRW: Highest Random Weight, as per [RFC8584] 🌸
  • OAM: Operations, Administration, and Maintenance. 🍓

3. EVPN BGP Attribute Extensions ✨

okay so this solution is literally built on top of the DF Election Extended Community from [RFC8584] 💅 it rides along with the Ethernet Segment route, and we just repurpose its last two reserved octets when the DF algorithm is Highest-Preference or Lowest-Preference 🎀 we also get a brand new capability called the "Don't Preempt" Capability, and it MAY be used with either of those two algorithms 🦋 here's what the format looks like:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06     | Sub-Type(0x06)| RSV |  DF Alg |    Bitmap     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~     Bitmap    |   Reserved    |   DF Preference (2 octets)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: DF Election Extended Community

okay now let's break down each field 🧚

  • The DF algorithm can have the following values:
    • Alg 0 - Default DF election algorithm, i.e., the modulus-based algorithm as per [RFC7432].
    • Alg 1 - HRW algorithm as per [RFC8584].
    • Alg 2 - Highest-Preference Algorithm (Section 4.1).
    • Alg 3 - Lowest-Preference Algorithm (Section 4.1).
  • Bitmap (2 octets) encodes "capabilities" [RFC8584], but this document defines the "Don't Preempt" Capability, which is used to indicate if a PE supports a non-revertive behavior 🌸
                       1 1 1 1 1 1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |D|A|                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Bitmap Field in the DF Election Extended Community

  • Bit 0 (corresponds to Bit 24 of the DF Election Extended Community, and it is defined by this document): the D bit, aka the "Don't Preempt" Capability, tells us if the PE advertising the Ethernet Segment route is asking the remote PEs in that Ethernet Segment to not preempt it as the Designated Forwarder 🙈 the default is DP=0, which is compatible with the 'preempt' or 'revertive' behavior in the default DF algorithm [RFC7432]. The "Don't Preempt" Capability is supported by the Highest-Preference or Lowest-Preference Algorithms. The procedures for other DF algorithms are out of the scope of this document. The procedures for the Highest-Preference and Lowest-Preference Algorithms are described in Section 4.1 ✨
  • Bit 1: AC-Influenced DF (AC-DF) election is described in [RFC8584]. When set to 1, it indicates the desire to use AC-DF with the rest of the PEs in the Ethernet Segment. The AC-DF capability bit MAY be set along with the "Don't Preempt" Capability and Highest-Preference or Lowest-Preference Algorithms 💜
  • Designated Forwarder (DF) Preference: defines a 2-octet value that indicates the PE preference to become the Designated Forwarder in the Ethernet Segment, as described in Section 4.1 👑 the allowed values are within the range 0-65535, and the default value MUST be 32767. This is the midpoint of the allowed Preference range, which gives the operator a ton of flexibility to pick a bunch of values above or below the default Preference 🍓 a numerically higher or lower value is more preferred for DF election depending on the DF algorithm being used, as explained in Section 4.1. The Designated Forwarder Preference field is specific to the Highest-Preference and Lowest-Preference Algorithms, and this document doesn't define any meaning for other algorithms. If the DF algorithm is different from Highest-Preference or Lowest-Preference, these 2 octets can be encoded differently 🌈
  • RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to 47): when the DF algorithm is set to Highest-Preference or Lowest-Preference, the values are set to zero when advertising the Ethernet Segment route, and they're ignored when receiving the Ethernet Segment route 🫶

4. Solution Description ✨

Figure 3 shows an example we'll use to walk through the solution 🦋

           EVPN Network
      +-------------------+
      |                +-------+  ENNI    Aggregation
      |   <---ESI1,500 |  PE1  |   /\  +----Network---+
      | <-----ESI2,100 |       |===||===              |
      |                |       |===||== \      vES1   |  +----+
  +-----+              |       |   \/  |\----------------+CE1 |
CE3--+ PE4 |              +-------+       | \   ------------+    |
  +-----+                 |            |  \ /         |  +----+
      |                   |            |   X          |
      |   <---ESI1,255  +-----+============ \         |
      | <-----ESI2,200  | PE2 |==========    \ vES2   | +----+
      |                 +-----+        | \    ----------+CE2 |
      |                   |            |  --------------+    |
      |                 +-----+   ----------------------+    |
      | <-----ESI2,300  | PE3 +--/     |              | +----+
      |                 +-----+        +--------------+
      --------------------+

Figure 3: Preference-Based DF Election

Figure 3 has three PEs connecting EVCs coming from the Aggregation Network to their EVIs in the EVPN network 🌸 CE1 is connected to vES1, which spans PE1 and PE2, and CE2 is connected to vES2, which is attached to PE1, PE2, and PE3 💖

so if vES1 and vES2 use the Highest-Preference or Lowest-Preference Algorithm, the PEs may become the Designated Forwarder regardless of their IP address, and it's all based on the administrative preference value 👑 the next sections walk through some examples of how these procedures get applied to the Figure 3 use case 🎀

4.1. Use of the Highest-Preference and Lowest-Preference Algorithm 💖

okay so, if the operator wants real control over which PE becomes the Designated Forwarder (DF) for a virtual Ethernet Segment, and the order the PEs take over when stuff fails, the Highest-Preference or Lowest-Preference Algorithms are the move 💅 Using the example in Figure 3, here's how they work 🦋

a. vES1 and vES2 get three optional parameters, all signaled in the DF Election Extended Community ✨ They are the Preference, the Preemption (or "Don't Preempt" Capability) option, and the DF algorithm. We'll write these as (Pref, DP, Alg). So vES1 (Pref, DP, Alg) is configured like this:

(500, 0, Highest-Preference) in PE1,
(255, 0, Highest-Preference) in PE2.

and vES2 is configured like this:

(100, 0, Highest-Preference) in PE1,
(200, 0, Highest-Preference) in PE2, and
(300, 0, Highest-Preference) in PE3.

b. The PEs advertise an Ethernet Segment route for each virtual Ethernet Segment, with those three parameters from (a) inside the DF Election Extended Community (encoded as described in Section 3) 🎀

c. According to [RFC8584], each PE runs the DF election algorithm when the DF Wait timer expires 🌸 Each PE runs the Highest-Preference or Lowest-Preference Algorithm for each Ethernet Segment like this:

  • The PE checks the DF algorithm value in each Ethernet Segment route. If all the Ethernet Segment routes (including the local route) agree on this DF algorithm (so they're all Highest-Preference or all Lowest-Preference, no mixing), the PE runs the procedure in this section. Otherwise, it falls back to the default DF algorithm [RFC7432]. Highest-Preference and Lowest-Preference are different algorithms, so if two PEs configured for Highest-Preference and Lowest-Preference, respectively, are attached to the same Ethernet Segment, the operational DF election algorithm falls back to the default DF algorithm 🙈
  • If all the PEs attached to the Ethernet Segment advertise the Highest-Preference Algorithm, each PE builds a list of candidate PEs ordered by preference value, from the numerically highest value to the lowest. For example, PE1 builds a candidate list for vES1 ordered by Preference, high to low: <PE1, PE2> (since PE1's preference is more preferred than PE2's). So PE1 becomes the Designated Forwarder for vES1. In the same way, PE3 becomes the Designated Forwarder for vES2 👑
  • If all the PEs attached to the Ethernet Segment advertise the Lowest-Preference Algorithm, the candidate list is ordered from the numerically lowest preference value to the highest. For example, PE1's ordered list for vES1 is <PE2, PE1>. So PE2 becomes the Designated Forwarder for vES1. In the same way, PE1 becomes the Designated Forwarder for vES2 🧚

d. Say some maintenance has to happen on a PE. The operator may want to make sure that PE isn't the DF so the impact on the service stays small 🍓 For example, if PE3 is going into maintenance and the DF algorithm is Highest-Preference, the operator could change vES2's Preference on PE3 from 300 to, e.g., 50 (so the Ethernet Segment route from PE3 gets updated with the new preference value). That forces PE2 to take over as Designated Forwarder for vES2, irrespective of the "Don't Preempt" Capability ✨ Once the maintenance on PE3 is done, the operator can leave the latest preference value in place or set the original initial value back 💜 A similar procedure works for the Lowest-Preference Algorithm too. For example, suppose the algorithm for vES2 is Lowest-Preference and PE1 (the DF) goes into maintenance mode. The operator could change vES2's Preference on PE1 from 100 to, e.g., 250, so PE2 is forced to take over as the Designated Forwarder for vES2 🌈

e. When two or more PEs in the Ethernet Segment have equal Preference, the "Don't Preempt" Capability and the numerically lowest IP address of the candidate PE(s) act as tiebreakers 🫶 The procedures for the "Don't Preempt" Capability are in Section 4.3. If more than one PE is advertising itself as the preferred Designated Forwarder, an implementation MUST first select the PE advertising the "Don't Preempt" Capability set, and then select the PE with the lowest IP address (if the "Don't Preempt" Capability selection doesn't give a unique candidate) 🔥 The PE's IP address is the address used in the candidate list, and it's derived from the Originating Router's IP address of the Ethernet Segment route. If PEs use Originating Router IP addresses of different families, an IPv4 address is always considered numerically lower than an IPv6 address. Here are some examples of the "Don't Preempt" Capability and IP address tiebreakers in action 👀

  • If vES1 parameters were (500, 0, Highest-Preference) in PE1 and (500, 1, Highest-Preference) in PE2, PE2 gets elected because of the "Don't Preempt" Capability. Same example applies if PE1 and PE2 advertise the Lowest-Preference Algorithm instead.
  • If vES1 parameters were (500, 0, Highest-Preference) in PE1 and (500, 0, Highest-Preference) in PE2, PE1 gets elected if PE1's IP address is lower than PE2's. Or PE2 gets elected if PE2's IP address is lower than PE1's. Same example applies if PE1 and PE2 advertise the Lowest-Preference Algorithm instead.

f. Preference is an administrative option that MUST be configured on a per-Ethernet-Segment basis, and it's normally configured from the management plane 🌸 The preference value MAY also be changed dynamically based on local policies that react to events on the PE. The examples below show local policy changing the preference value on the fly ✨

  • On PE1, if the DF algorithm is Highest-Preference, ES1's preference value can be lowered from 500 to 100 if the bandwidth on the ENNI port drops by 50% (which could happen if, e.g., the 2-port Link Aggregation Group between PE1 and the Aggregation Network loses one port) 😭
  • Local policy MAY also trigger dynamic Preference changes based on the PE's bandwidth availability in the core, specific ports going operationally down, etc. 🦋
  • The definition of the actual local policies is out of scope of this document 🙈

Highest-Preference and Lowest-Preference Algorithms MAY be used along with the AC-DF capability 💖 Assuming all the PEs in the Ethernet Segment are configured consistently with the Highest-Preference or Lowest-Preference Algorithm and the AC-DF capability, a given PE in the Ethernet Segment isn't considered a candidate for DF election until its corresponding Ethernet A-D per ES and Ethernet A-D per EVI routes are received, as described in [RFC8584] 🎀

Highest-Preference and Lowest-Preference Algorithms can be used in different virtual Ethernet Segments on the same PE 🧚 For instance, PE1 and PE2 can use Highest-Preference for vES1 and PE1, and PE2 and PE3 can use Lowest-Preference for vES2. Picking one DF algorithm over the other is the operator's choice. Having both gives flexibility and full control to the operator 👑

The procedures in this document can be used in an Ethernet Segment as defined in [RFC7432] or a virtual Ethernet Segment per [RFC9784], and also in EVPN networks as described in [RFC8214], [RFC7623], or [RFC8365] 🌈

4.2. Use of the Highest-Preference or Lowest-Preference Algorithm in Ethernet Segments 🦋

okay so the Highest-Preference or Lowest-Preference Algorithm from Section 4.1 is usually used in virtual Ethernet Segment setups, where each virtual Ethernet Segment normally has one single Ethernet Tag. BUT 😭 the existing definition of an Ethernet Segment [RFC7432] actually allows potentially up to thousands of Ethernet Tags on the very same Ethernet Segment. 💅 If that's the case, and the Highest-Preference or Lowest-Preference Algorithm is configured on all the PEs of the Ethernet Segment, then the same PE gets elected as the Designated Forwarder for every single Ethernet Tag on that segment. 🙈 Not it, not cute. There's a potential way to get more granular load balancing, and it's described below 🎀

The Ethernet Segment gets configured with an administrative preference value and an administrative DF algorithm, which is either Highest-Preference or Lowest-Preference. 🌸 However, the administrative DF algorithm (the one used to signal the DF algorithm for the Ethernet Segment) MAY be overridden by a different operational DF algorithm for a range of Ethernet Tags. 🧚 With this option, the PE builds a list of candidate PEs ordered by Preference. The catch is that the Designated Forwarder for a given Ethernet Tag gets determined by the locally overridden DF algorithm instead. ✨

For instance:

  • Say ES3 is defined in PE1 and PE2. PE1 may be configured as (500, 0, Highest-Preference) and PE2 as (100, 0, Highest-Preference) for ES3. Both PEs advertise the Ethernet Segment routes for ES3 with those parameters in the DF Election Extended Community. 💜
  • Also, say there are VLAN-based service interfaces and the PEs are attached to all Ethernet Tags in the range 1-4000. Then both PE1 and PE2 may be configured with (Ethernet Tag-range, Lowest-Preference), e.g., (2001-4000, Lowest-Preference). 🍓
  • This results in PE1 being the Designated Forwarder for Ethernet Tags 1-2000 (since they use the default Highest-Preference Algorithm), and PE2 being the Designated Forwarder for Ethernet Tags 2001-4000, because the local policy overrides the Highest-Preference Algorithm. 👑

Here's the thing ngl 🥹 while the above logic gives a perfect load-balancing distribution of Ethernet Tags per Designated Forwarder when there are only two PEs, things get trickier for Ethernet Segments attached to three or more PEs. In that case there would be only two Designated Forwarder PEs for all the Ethernet Tags. 🫶 Any other logic that gives a fair distribution of the Designated Forwarder function among three or more PEs is valid, as long as that logic is consistent across all the PEs in the Ethernet Segment. 🌈

Now, this part is SUPER important, bestie 🚨 When a local policy overrides the Highest-Preference or Lowest-Preference signaled by all the PEs in the Ethernet Segment, this local policy MUST be consistent in all the PEs of the Ethernet Segment. 💀 If the local policy is inconsistent for a given Ethernet Tag in the Ethernet Segment, packet drops or packet duplication may occur on that Ethernet Tag. Yikes. 😭

Main character energy check: the Designated Forwarder logic has to match on every PE, or the traffic gets messy. Keep your policies in sync! 🎀

So for all these reasons, the use of virtual Ethernet Segments is RECOMMENDED for cases where more than two PEs per Ethernet Segment exist and a good load-balancing distribution per Ethernet Tag of the Designated Forwarder function is desired. It's giving "use the right tool for the job" energy 🦋✨

4.3. The Non-Revertive Capability ✨

Okay so bestie, remember item d of Section 1.2? 🎀 That's where we decided we need a way to NOT preempt the existing Designated Forwarder for all the Ethernet Tags in the Ethernet Segment. So this capability gets added to the DF Election Extended Community, and it lets the DF election behave in a non-revertive way. It's giving stability 🦋

Here's the vibe. When a PE in an Ethernet Segment gets taken down for maintenance, the Preference might get changed before it comes back, so you get non-revertive behavior that way. 🧚 The "Don't Preempt" Capability and the mechanism in this section are for the other case: a former Designated Forwarder comes back up without any controlled maintenance, and you still want the non-revertive option so you don't get service impact. Main character energy for uptime 💅

In Figure 3, we assume that based on the Highest-Preference Algorithm, PE3 is the Designated Forwarder for ESI2. 🌸

If PE3 has a link, EVC, or node failure, PE2 takes over as the Designated Forwarder. Then if/when PE3 comes back up, PE3 takes over again 😭 and that causes some unnecessary packet loss in the Ethernet Segment. Not me watching this happen for no reason 💀

So the following procedure avoids preemption upon failure recovery (see Figure 3). 🫶 It supports a non-revertive mode that can be used along with:

  • Highest-Preference Algorithm 👑
  • Lowest-Preference Algorithm 🍓
  • Highest-Preference or Lowest-Preference Algorithm, where a local policy overrides the Highest-/Lowest-Preference tiebreaker for a range of Ethernet Tags (Section 4.2) ✨

The procedure is described assuming the Highest-Preference Algorithm in the Ethernet Segment, where local policy overrides the tiebreaker for a given Ethernet Tag. The other cases above are a subset of this one, and the differences get explained. Iykyk 🌈

  1. A "Don't Preempt" Capability is defined on a per-PE / per-Ethernet-Segment basis, as described in Section 3. If "Don't Preempt" is disabled (default behavior), the PE sets DP to zero and advertises it in an Ethernet Segment route. If "Don't Preempt" is enabled, the Ethernet Segment route from the PE indicates the desire of not being preempted by the other PEs in the Ethernet Segment. All the PEs in an Ethernet Segment should be consistent in their configuration of the "Don't Preempt" Capability, however this document does not enforce consistency across all the PEs. In case of inconsistency in the support of the "Don't Preempt" Capability in the PEs of the same Ethernet Segment, non-revertive behavior is not guaranteed. However, PEs supporting this capability still attempt this procedure. ngl the "should" here is doing a lot 🙈
  2. Assuming we want to avoid 'preemption' in all the PEs in the Ethernet Segment, the three PEs are configured with the "Don't Preempt" Capability. In this example, we assume ESI2 is configured as 'DP=enabled' in the three PEs. 💜
  3. We also assume vES2 is attached to Ethernet Tag-1 and Ethernet Tag-2. vES2 uses Highest-Preference as the DF algorithm, and a local policy is configured in the three PEs to use Lowest-Preference for Ethernet Tag-2. When vES2 is enabled in the three PEs, the PEs exchange the Ethernet Segment routes and select PE3 as the Designated Forwarder for Ethernet Tag-1 (due to the Highest-Preference) and PE1 as the Designated Forwarder for Ethernet Tag-2 (due to the Lowest-Preference). 🦋
  4. If PE3's vES2 goes down (due to an EVC failure (as detected by OAM protocols), a port failure, or a node failure), PE2 becomes the Designated Forwarder for Ethernet Tag-1. No changes occur for Ethernet Tag-2. 🌸
  5. When PE3's vES2 comes back up, PE3 starts a boot-timer (if booting up) or hold-timer (if the port or EVC recovers). That timer gives PE3 some time to receive the Ethernet Segment routes from PE1 and PE2. This timer is applied between the INIT and the DF_WAIT states in the DF election Finite State Machine described in [RFC8584]. PE3 then does the following:
    • Selects a "reference-PE" among the Ethernet Segment routes in the virtual Ethernet Segment. If the Ethernet Segment uses the Highest-Preference Algorithm, it selects a "Highest-PE". If it uses the Lowest-Preference Algorithm, it selects a "Lowest-PE". If a local policy is in use, to override the Highest-/Lowest-Preference for a range of Ethernet Tags (as discussed in Section 4.2), it is necessary to select both a Highest-PE and a Lowest-PE. They are selected as follows:
      • The Highest-PE is the PE with higher Preference, using the "Don't Preempt" Capability first (with DP=1 being better) and, after that, the lower PE-IP address as tiebreakers.
      • The Lowest-PE is the PE with lower Preference, using the "Don't Preempt" Capability first (with DP=1 being better) and, after that, the lower PE-IP address as tiebreakers.
      • In our example, the Highest-Preference Algorithm is used, with a local policy to override it to use Lowest-Preference for a range of Ethernet Tags. Therefore, PE3 selects a Highest-PE and a Lowest-PE. PE3 selects PE2 as the Highest-PE over PE1, because when comparing (Pref, DP, PE-IP), (200, 1, PE2-IP) wins over (100, 1, PE1-IP). PE3 selects PE1 as the Lowest-PE over PE2, because (100, 1, PE1-IP) wins over (200, 1, PE2-IP). Note that if there were only one remote PE in the Ethernet Segment, the Lowest and Highest PE would be the same PE. 🧠
    • Checks its own administrative Pref and compares it with the one of the Highest-PE and Lowest-PE that have the "Don't Preempt" Capability set in their Ethernet Segment routes. Depending on this comparison, PE3 sends the Ethernet Segment route with a (Pref, DP) that may be different from its administrative (Pref, DP):
      • If PE3's Pref value is higher than or equal to the Highest-PE's, PE3 sends the Ethernet Segment route with an 'in-use' operational Pref equal to the Highest-PE's and DP=0.
      • If PE3's Pref value is lower than or equal to the Lowest-PE's, PE3 sends the Ethernet Segment route with an 'in-use' operational Preference equal to the Lowest-PE's and DP=0.
      • If PE3's Pref value is not higher than or equal to the Highest-PE's and is not lower than or equal to the Lowest-PE's, PE3 sends the Ethernet Segment route with its administrative (Pref, DP)=(300, 1).
      • In this example, PE3's administrative Pref=300 is higher than the Highest-PE with DP=1, that is, PE2 (Pref=200). Hence, PE3 inherits PE2's preference and sends the Ethernet Segment route with an operational 'in-use' (Pref, DP)=(200, 0). 🎀
    • Sends its "Don't Preempt" Capability set to zero, as long as the advertised Pref is the 'in-use' operational Pref (as opposed to the 'administrative' Pref).
    • Does not trigger any Designated Forwarder changes for Ethernet Tag-1. This Ethernet Segment route update sent by PE3, with (200, 0, PE3-IP), does not cause any Designated Forwarder switchover for any Ethernet Tag. This is because the "Don't Preempt" Capability is used as a tiebreaker in the DF election. That is, if a PE has two candidate PEs with the same Pref, it picks the one with DP=1. There are no Designated Forwarder changes for Ethernet Tag-2 either. 👑
  6. For any subsequent received update/withdraw in the Ethernet Segment, the PEs go through the process described in (5) to select the Highest-PEs and Lowest-PEs, now considering themselves as candidates. For instance, if PE2 fails upon receiving PE2's Ethernet Segment route withdrawal, PE3 and PE1 go through the selection of the new Highest-PEs and Lowest-PEs (considering their own active Ethernet Segment route), and then they run the DF election.
    • If a PE selects itself as the new Highest-PE or Lowest-PE and it was not before, the PE then compares its operational 'in-use' Pref with its administrative Pref. If different, the PE sends an Ethernet Segment route update with its administrative Pref and DP values. In the example, PE3 becomes the new Highest-PE; therefore, it sends an Ethernet Segment route update with (Pref, DP)=(300, 1). ✨
    • After running the DF election, PE3 becomes the new Designated Forwarder for Ethernet Tag-1. No changes occur for Ethernet Tag-2. 🥳

Note that, irrespective of the "Don't Preempt" Capability, when a PE or Ethernet Segment comes back and the PE advertises a DF election algorithm different from the one configured in the rest of the PEs in the Ethernet Segment, all the PEs in the Ethernet Segment MUST fall back to the default DF algorithm [RFC7432]. 🚨

This document does not modify the use of the P and B bits in the Ethernet A-D per EVI routes [RFC8214] advertised by the PEs in the Ethernet Segment after running the DF election, irrespective of the revertive or non-revertive behavior in the PE. 💖

5. Security Considerations 🔐

This document describes a DF election algorithm that provides absolute control (by configuration) over what PE is the Designated Forwarder for a given Ethernet Tag. While this control is desired in many situations, a malicious user who gets access to the configuration of a PE in the Ethernet Segment may change the behavior of the network. In other DF algorithms such as HRW, the DF election is more automated and cannot be determined by configuration. If the DF algorithm is Highest-Preference or Lowest-Preference, an attacker may change the configuration of the preference value on a PE and Ethernet Segment to impact the traffic going through that PE and Ethernet Segment. 😱

The non-revertive capability described in this document may be seen as a security improvement over the regular EVPN revertive DF election: an intentional link (or node) "flapping" on a PE only causes service disruption once, when the PE goes to Non-Designated Forwarder state. However, an attacker who gets access to the configuration of a PE in the Ethernet Segment is able to disable the non-revertive behavior, by advertising a conflicting DF election algorithm and thereby forcing fallback to the default DF algorithm. 💀

The document also describes how a local policy can override the Highest-Preference or Lowest-Preference Algorithms for a range of Ethernet Tags in the Ethernet Segment. If the local policy is not consistent across all PEs in the Ethernet Segment and there is an Ethernet Tag that ends up with an inconsistent use of Highest-Preference or Lowest-Preference in different PEs, packet drop or packet duplication may occur for that Ethernet Tag. 🙀

Finally, the two DF election algorithms specified in this document (Highest-Preference and Lowest-Preference) do not change the way the PEs share their Ethernet Segment information, compared to the algorithms in [RFC7432] and [RFC8584]. Therefore, the security considerations in [RFC7432] and [RFC8584] apply to this document as well. 🫶

6. IANA Considerations ✨

okay so IANA has been busy 🦋 here's what they did for this doc:

  • They allocated two new values in the "DF Alg" registry that [RFC8584] created, and they look like this 💖
+=====+==============================+===========+
| Alg | Name                         | Reference |
+=====+==============================+===========+
| 2   | Highest-Preference Algorithm | RFC 9785  |
+-----+------------------------------+-----------+
| 3   | Lowest-Preference Algorithm  | RFC 9785  |
+-----+------------------------------+-----------+

                     Table 1
  • They also allocated a new value in the "DF Election Capabilities" registry that [RFC8584] created. This one is for the 2-octet Bitmap field in the DF Election Extended Community, and it lives under the "Border Gateway Protocol (BGP) Extended Communities" registry group 🌈
+=====+==============================+===========+
| Bit | Name                         | Reference |
+=====+==============================+===========+
| 0   | D (Don't Preempt) Capability | RFC 9785  |
+-----+------------------------------+-----------+

                     Table 2
  • Last one: they listed this document as an additional reference for the DF Election Extended Community field in the "EVPN Extended Community Sub-Types" registry 🫶
+================+================================+==============+
| Sub-Type Value | Name                           | Reference    |
+================+================================+==============+
| 0x06           | DF Election                    | [RFC8584]    |
|                | Extended Community             | and RFC 9785 |
+----------------+--------------------------------+--------------+

                             Table 3

7. References 📚

7.1. Normative References 💜

7.2. Informative References 🧚

Acknowledgements 🙌

The authors would like to thank Kishore Tiruveedhula and Sasha Vainshtein for their reviews and comments. Also, thank you to Luc André Burdet and Stephane Litkowski for their thorough reviews and suggestions for a new Lowest-Preference Algorithm 🍓

Contributors 🎀

In addition to the authors listed, the following individuals also contributed to this document 💅

  • Tony Przygienda, Juniper
  • Satya Mohanty, Cisco
  • Kiran Nagaraj, Nokia
  • Vinod Prabhu, Nokia
  • Selvakumar Sivaraj, Juniper
  • Sami Boutros, VMWare

Authors' Addresses 🌸

  • Jorge Rabadan (editor), Nokia, 520 Almanor Avenue, Sunnyvale, CA 94085, United States of America. Email: jorge.rabadan@nokia.com
  • Senthil Sathappan, Nokia. Email: senthil.sathappan@nokia.com
  • Wen Lin, Juniper Networks. Email: wlin@juniper.net
  • John Drake, Independent. Email: je_drake@yahoo.com
  • Ali Sajassi, Cisco Systems. Email: sajassi@cisco.com
📦 where this page comes from