RFC 8584
Framework for Ethernet VPN Designated Forwarder Election Extensibility
Framework for Ethernet VPN Designated Forwarder Election Extensibility 🎀
📜 Okay so the vibe check: this is RFC 8584, a Standards Track doc from April 2019 (ISSN 2070-1721) 💅. It's written by J. Rabadan (Ed., Nokia), S. Mohanty (Ed.), A. Sajassi (Cisco), J. Drake (Juniper), K. Nagaraj (Nokia), and S. Sathappan (Nokia) 🫶. The title block doesn't list anything it obsoletes, but it does update RFC 7432 ✨. That's the core EVPN spec, so this one is basically a glow-up for it 🦋.
Abstract 🌸
Okay bestie, so there's an alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) 🧚. The DF is the Provider Edge (PE) router that's in charge of 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) 💖. The doc also lets you influence the DF election result for a VLAN based on whether the associated Attachment Circuit (AC) is up or down, which is so iconic 🔥. It also clarifies the DF election Finite State Machine in EVPN services, so it updates the EVPN specification (RFC 7432) 👑.
Status of This Memo 📜
This is an Internet Standards Track document 💜.
It's a product of the Internet Engineering Task Force (IETF) and 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 out Section 2 of RFC 7841 🍓.
For the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8584 ⭐.
Copyright Notice 🦋
Copyright (c) 2019 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) as in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅.
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Conventions and Terminology ................................3
1.2. Default Designated Forwarder (DF) Election in EVPN
Services ...................................................5
1.3. Problem Statement ..........................................8
1.3.1. Unfair Load Balancing and Service Disruption ........8
1.3.2. Traffic Black-Holing on Individual AC Failures .....10
1.4. The Need for Extending the Default DF Election in
EVPN Services .............................................12
2. Designated Forwarder Election Protocol and BGP Extensions ......13
2.1. The DF Election Finite State Machine (FSM) ................13
2.2. The DF Election Extended Community ........................16
2.2.1. Backward Compatibility .............................19
3. The Highest Random Weight DF Election Algorithm ................19
3.1. HRW and Consistent Hashing ................................20
3.2. HRW Algorithm for EVPN DF Election ........................20
4. The AC-Influenced DF Election Capability .......................22
4.1. AC-Influenced DF Election Capability for
VLAN-Aware Bundle Services ................................24
5. Solution Benefits ..............................................25
6. Security Considerations ........................................26
7. IANA Considerations ............................................27
8. References .....................................................28
8.1. Normative References ......................................28
8.2. Informative References ....................................29
Acknowledgments ...................................................30
Contributors ......................................................30
Authors' Addresses ................................................311. Introduction ✨
The Designated Forwarder (DF) in Ethernet VPNs (EVPNs) is the Provider Edge (PE) router that's 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) 💖. The DF gets picked from the set of multihomed PEs attached to a given ES. Each of those PEs advertises an ES route for the ES, identified by its Ethernet Segment Identifier (ESI) 🫶. By default, EVPN uses a DF election algorithm called "service carving" 🍓. That algorithm is based on a modulus function, V mod N, which takes the number of PEs in the ES (N) and the VLAN value (V) as input 🔥.
This document fixes the inefficiencies in the default DF election algorithm 💅. It does that by defining a new DF election algorithm, plus a way to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) 🦋. To avoid any mix-up with the identifier used in the DF election algorithm, this document uses the term "Ethernet Tag" instead of "VLAN" 🌸. It also creates an IANA registry for future DF election algorithms and capabilities (see Section 7) 📜. Finally, it presents a formal definition and clarification of the DF election Finite State Machine (FSM) 🧚. Because of all that, this document updates [RFC7432], and EVPN implementations MUST conform to the prescribed FSM 👑. No cap, that MUST is non-negotiable 🙈.
The procedures in this document apply to DF election in all EVPN solutions, including the ones described in [RFC7432] and [RFC8214] ✨. Apart from the formal description of the FSM, this document doesn't mean to update any other procedures from [RFC7432] 🌈. It's really just about making DF election behave better on PEs that get upgraded to follow the procedures here 💜.
1.1. Conventions and Terminology 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀.
Here's the glossary, bestie 📖:
- AC: Attachment Circuit. Every AC has an Ethernet Tag associated with it 🌸.
- ACS: Attachment Circuit Status 🦋.
- BUM: Broadcast, unknown unicast, and multicast 🌈.
- DF: Designated Forwarder 👑.
- NDF: Non-Designated Forwarder 🙈.
- BDF: Backup Designated Forwarder 🧚.
- Ethernet A-D per ES route: Refers to Route Type 1 as defined in [RFC7432], or to Auto-discovery per Ethernet Segment route 💖.
- Ethernet A-D per EVI route: Refers to Route Type 1 as defined in [RFC7432], or to Auto-discovery per EVPN Instance route 🫶.
- ES: Ethernet Segment 🍓.
- ESI: Ethernet Segment Identifier 🔥.
- EVI: EVPN Instance ✨.
- MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on a PE 💜.
- BD: Broadcast Domain. An EVI may be made up of one BD (VLAN-based or VLAN Bundle services) or multiple BDs (VLAN-aware Bundle services) 💅.
- Bridge table: An instantiation of a BD on a MAC-VRF 🎀.
- HRW: Highest Random Weight ⭐.
- VID: VLAN Identifier 🌸.
- CE-VID: Customer Edge VLAN Identifier 🦋.
- Ethernet Tag: Used to represent a BD that's configured on a given ES for the purpose of DF election. Any of the following can represent a BD: VIDs (including Q-in-Q tags), configured IDs, VNIs (Virtual Extensible Local Area Network (VXLAN) Network Identifiers), normalized VIDs, I-SIDs (Service Instance Identifiers), and so on. The only catch is that the representation of the BDs has to be configured consistently across the multihomed PEs attached to that ES 🧚. The Ethernet Tag value MUST be different from zero 🙈. Zero is a hard no, bestie 🚫.
- Ethernet Tag ID: Refers to the identifier used in the EVPN routes defined in [RFC7432]. Its value may be the same as the Ethernet Tag value (see the Ethernet Tag definition) when advertising routes for VLAN-aware Bundle services. Note that for VLAN-based or VLAN Bundle services, the Ethernet Tag ID is zero 🌈.
- DF election procedure: Also called "DF election". This is the whole process, including discovering the PEs in the ES, creating and maintaining the PE candidate list, and selecting a PE 👑.
- DF algorithm: A component of the DF election procedure. Strictly speaking, it's the selection of a PE for a given <ES, Ethernet Tag> 💖.
- RR: Route Reflector. A network routing component for BGP [RFC4456]. It's an alternative to the logical full-mesh requirement of the Internal Border Gateway Protocol (IBGP) 🫶. The whole point of an RR is concentration: multiple BGP routers can peer with one central point, the RR, which acts as a route reflector server, instead of peering with every other router in a full mesh 🍓. The result is O(N) peering instead of O(N^2) 🔥.
- TTL: Time To Live ✨.
This document also assumes you're familiar with the terminology in [RFC7432] 💜.
1.2. Default Designated Forwarder (DF) Election in EVPN Services 💖
okay so first things first, [RFC7432] defines the DF as the EVPN PE responsible for two jobs ✨
- Flooding BUM traffic on a given Ethernet Tag on a particular ES to the CE. This is valid for Single-Active and All-Active EVPN multihoming.
- Sending unicast traffic on a given Ethernet Tag on a particular ES to the CE. This is valid for Single-Active multihoming.
Figure 1 is the example we'll use to explain how the DF works 🧚
+---------------+
| IP/MPLS |
| Core |
+----+ ES1 +----+ +----+
| CE1|-----| | | |____ES2
+----+ | PE1| | PE2| \
| | +----+ \+----+
+----+ | | CE2|
| +----+ /+----+
| | |____/ |
| | PE3| ES2 /
| +----+ /
| | /
+-------------+----+ /
| PE4|____/ES2
| |
+----+Figure 1: EVPN Multihoming
so in Figure 1 there are two ESes, ES1 and ES2 🎀 PE1 hooks CE1 up through ES1, while PE2, PE3, and PE4 all hook CE2 up through ES2. That means PE2, PE3, and PE4 form a redundancy group 👑 Since CE2 is multihomed to different PEs on the same ES, those three PEs have to agree on a DF in order to meet the requirements above 🫶
okay the forwarding loop situation in a Layer 2 network is genuinely scary 💀 Ethernet traffic is broadcast by nature and there's no TTL to stop things from circling forever. So it's super important that, when a CE is multihomed, only one of the PEs is used to send BUM traffic to it 😭
one of the prerequisites for this to work is that the participating PEs all have to agree on who the DF is 🔥 That agreement needs to come from a distributed algorithm where each participating PE independently and unambiguously picks one of the participating PEs as the DF. The result should be consistent and unanimous, no drama ✨
the default DF election algorithm defined by [RFC7432] works at the granularity of (ESI, EVI), and this document calls it "service carving" 💅 In this document, service carving and the default DF election algorithm mean the same thing. With service carving it's possible to elect multiple DFs per ES (one per EVI), which is how you get load balancing of traffic headed to a given ES. The goal is that the load-balancing procedures carve up the BD space among the redundant PE nodes evenly, so that every PE is the DF for a distinct set of EVIs 🌈
the DF election algorithm (as described in [RFC7432], Section 8.5) is based on a modulus operation 🧮 The PEs that the ES (the one DF election is being run for, per EVI) is multihomed to form an ordered (ordinal) list, sorted in ascending order by PE IP address value. For example, if there are N PEs, PE0, PE1,... PE(N-1), ranked by increasing IP address in the ordinal list, then for each VLAN with Ethernet Tag V configured on ES1, PEx is the DF for VLAN V on ES1 when x equals (V mod N). In the case of a VLAN Bundle, only the lowest VLAN is used. When the planned density is high (meaning there are a significant number of VLANs and the Ethernet Tags are uniformly distributed), the thinking is that DF election gets spread across the PEs hosting that ES, and good load balancing can be achieved 🦋
BUT ngl the default algorithm has some undesirable properties 🙈 In some cases it can be kinda disruptive and unfair. This document goes through those issues and defines a mechanism for dealing with them. These mechanisms do change the default DF election algorithm, but they don't require any changes to the EVPN route exchange, and changes to the EVPN routes are minimal 💜
on top of that, there's a need to extend the DF election procedures so new algorithms and capabilities are possible. A single algorithm (the default DF election algorithm) may not meet the requirements in every use case 🍓
one thing to note: while [RFC7432] elects a DF per <ES, EVI>, this document elects a DF per <ES, BD>. So unlike [RFC7432], where a VLAN-aware Bundle service EVI has only one DF for the whole EVI, this document specifies that there will be multiple DFs, one for each BD configured in that EVI 🎀
1.3. Problem Statement 🔍
this section covers some potential issues with the default DF election algorithm 👀
1.3.1. Unfair Load Balancing and Service Disruption ⚖️
there are three fundamental problems with the current default DF election algorithm 😤
- The algorithm doesn't perform well when the Ethernet Tag follows a non-uniform distribution, for instance when the Ethernet Tags are all even or all odd. Say the ES is multihomed to two PEs. Then one of the PEs gets elected as the DF for all of the VLANs. That is SO suboptimal 💀 It defeats the whole purpose of service carving, because the DFs aren't really spread evenly across the PEs hosting the ES. In this particular case, one of the PEs never gets elected as the DF at all, so it doesn't take on any DF responsibilities. Now look at another example. Referring to Figure 1, let's assume that (1) PE2, PE3, and PE4 are listed in ascending order by IP address, and (2) each VLAN configured on ES2 is associated with an Ethernet Tag of the form (3x+1), where x is an integer. This results in PE3 always being selected as the DF 😭
- The Ethernet Tag that identifies the BD can be as large as 2^24. However, it's not guaranteed that the tenant BDs on the ES will follow a uniform distribution. Honestly, it's up to the customer which BDs they configure on the ES 🧐 Quoting [Knuth]:
In general, we want to avoid values of M that divide r^k+a or
r^k-a, where k and a are small numbers and r is the radix of
the alphabetic character set (usually r=64, 256 or 100), since
a remainder modulo such a value of M tends to be largely a
simple superposition of key digits. Such considerations
suggest that we choose M to be a prime number such that
r^k!=a(modulo)M or r^k!=?a(modulo)M for small k & a.In our case, N is the number of PEs (Section 8.5 of [RFC7432]). N corresponds to M above. Since N, N-1, or N+1 need not satisfy the primality properties of M, as per the modulo-based DF assignment in [RFC7432], then whenever a PE goes down or a new PE boots up (attached to the same ES), the modulo scheme won't necessarily map BDs to PEs uniformly 🌸
- Disruption is the third problem 🥺 Picture the same ES multihomed to a set of PEs. When the ES goes DOWN on one of the PEs, say PE1, or PE1 itself reboots, or the BGP process goes down, or the connectivity between PE1 and an RR goes down, the effective number of PEs in the system drops to N-1, and DFs get computed again for all the VLANs configured on that ES. In general, if the DF for a VLAN V isn't PE1 but some other PE, say PE2, it's likely that yet another PE (different from PE1 and PE2) becomes the new DF. That's not desirable at all 🙅♀️ Likewise, when a new PE hosts the same ES, the mapping changes again because of the modulus operation. All of this causes needless churn. Once more referring to Figure 1, say V1, V2, and V3 are VLANs configured on ES2 with Ethernet Tags of 999, 1000, and 1001, respectively. So PE1, PE2, and PE3 are the DFs for V1, V2, and V3. Now when PE3 goes down, PE2 becomes the DF for V1 and PE1 becomes the DF for V2 💔
one point to note: the default DF election algorithm assumes that all the PEs multihomed to the same ES (and interested in DF election through EVPN route exchange) use an Originating Router's IP address [RFC7432] of the same family. That doesn't have to be the case 🌐 The EVPN address family can be carried over an IPv4 or IPv6 peering, and the PEs attached to the same ES may each use an address of either family.
mathematically, a conventional hash function maps a key k to a number i representing one of m hash buckets through a function h(k), i.e., i = h(k). In the EVPN case, h is simply a modulo-m hash function, viz. h(V) = V mod N, where N is the number of PEs multihomed to the ES in question. It's well known that for good hash distribution using the modulus operation, the modulus N should be a prime number not too close to a power of 2 [CLRS2009]. When the effective number of PEs changes from N to N-1 (or vice versa), all the objects (VLAN V) get remapped, except those for which V mod N and V mod (N-1) refer to the same PE in the previous and subsequent ordinal rankings, respectively. From a forwarding perspective this is churn 🌀, because it means reprogramming the PE ports as either blocking or non-blocking at the PEs where the DF state changes ⭐
this document addresses this problem and furnishes a solution to this undesirable behavior 🫧
1.3.2. Traffic Black-Holing on Individual AC Failures 🕳️
okay so the default DF election algorithm from [RFC7432] only looks at two things in its modulus math for a given ES: whether the PE's IP address is in the candidate list, and the locally provisioned Ethernet Tags. that's it 💅
if the DF for an <ESI, EVI> dies because of a physical link or node failure, an ES route withdrawal makes the NDF PEs re-elect the DF for that <ESI, EVI>, and the service recovers. iconic, no notes ✨
BUT, and this is a big but 🙈, the default DF election procedure has zero protection against "logical" failures or human errors happening at the service level on the DF while the list of active PEs for that ES stays exactly the same. these failures can hurt not just the PE where the problem happens but also every other PE on the ES. some examples of these logical failures:
- (a) A given individual AC defined in an ES is accidentally shut down or is not provisioned yet (hence, the ACS is DOWN), while the ES is operationally active (since the ES route is active).
- (b) A given MAC-VRF with a defined ES is either shut down or not provisioned yet, while the ES is operationally active (since the ES route is active). In this case, the ACS of all the ACs defined in that MAC-VRF is considered to be DOWN.
neither (a) nor (b) triggers DF re-election on the remote multihomed PEs for that ES, because the ACS isn't part of the DF election procedures at all 😭. the ACS does act as a DF election tiebreaker and trigger in Virtual Private LAN Service (VPLS) multihoming procedures [VPLS-MH], but the EVPN specification [RFC7432] doesn't define any procedure that triggers DF re-election based on an ACS change on the DF. not it 💀
Figure 2 shows an example of logical AC failure. look at this little setup 🦋
+---+
|CE4|
+---+
|
PE4 |
+-----+-----+
+---------------| +-----+ |---------------+
| | | BD-1| | |
| +-----------+ |
| |
| EVPN |
| |
| PE1 PE2 PE3 |
| (NDF) (DF) (NDF)|
+-----------+ +-----------+ +-----------+
| | BD-1| | | | BD-1| | | | BD-1| |
| +-----+ |-------| +-----+ |-------| +-----+ |
+-----------+ +-----------+ +-----------+
AC1\ ES12 /AC2 AC3\ ES23 /AC4
\ / \ /
\ / \ /
+----+ +----+
|CE12| |CE23|
+----+ +----+Figure 2: Default DF Election and Traffic Black-Holing
okay so BD-1 is defined on PE1, PE2, PE3, and PE4. CE12 is a multihomed CE connected to ES12 on PE1 and PE2. CE23 is multihomed to PE2 and PE3 using ES23. both CE12 and CE23 hook into BD-1 through VLAN-based service interfaces: CE12-VID 1 (VID 1 on CE12) is associated with AC1 and AC2 in BD-1, while CE23-VID 1 is associated with AC3 and AC4 in BD-1. there are other ACs on these ESes mapped to different BDs too, they just aren't drawn here 🎀
after running the default DF election algorithm from [RFC7432], PE2 ends up as the DF for ES12 and ES23 in BD-1. and then these issues can pop up 😬
- (a) If AC2 is accidentally shut down or is not configured yet, CE12 traffic gets impacted. with All-Active multihoming, the BUM traffic to CE12 gets "black-holed", and with Single-Active multihoming, all the traffic to and from CE12 gets discarded. this happens because a logical failure on PE2's AC2 may not trigger an ES route withdrawal for ES12 (there are still other ACs active on ES12), so PE1 won't rerun the DF election procedures.
- (b) If the bridge table for BD-1 is administratively shut down or isn't configured yet on PE2, then CE12 and CE23 both get hit 🥺. BUM traffic to both CEs gets discarded with All-Active multihoming, and all traffic to and from the CEs gets discarded with Single-Active multihoming. PE1 and PE3 won't rerun the DF election procedures and will keep assuming PE2 is the DF.
the rules say, quoting [RFC7432]: "When an Ethernet tag is decommissioned on an Ethernet segment, then the PE MUST withdraw the Ethernet A-D per EVI route(s) announced for the <ESI, Ethernet tags> that are impacted by the decommissioning." but even though this A-D per EVI route withdrawal is used by remote PEs doing aliasing or backup procedures, it is NOT used to influence the DF election for the affected EVIs. 🙃
so this document adds an optional modification to the DF election procedure, so the ACS can be taken into account as a variable in the DF election. that way EVPN can actually protect against logical failures. main character energy 👑
1.4. The Need for Extending the Default DF Election in EVPN Services 🌈
Section 1.3 describes some of the issues with the default DF election procedures. to fix those, this document introduces a brand new DF election framework 🧚. the framework lets PEs agree on a common DF election algorithm, plus the capabilities they can turn on during the DF election procedure. basically, "DF election algorithm" is the algorithm that takes a set of input parameters and figures out the DF PE, while "DF election capability" is an extra feature that can run before the algorithm is invoked, like changing the inputs (or the list of candidate PEs).
inside this framework, this document defines a new DF election algorithm and a new capability that can influence the DF election result:
- The new DF election algorithm is referred to as "Highest Random Weight" (HRW). The HRW procedures are described in Section 3.
- The new DF election capability is referred to as "AC-Influenced DF election" (AC-DF). The AC-DF procedures are described in Section 4.
- HRW and AC-DF mechanisms are independent of each other. So a PE may support either HRW or AC-DF on its own, or it may support both together. A PE may also support the AC-DF capability along with the default DF election algorithm per [RFC7432].
also, this document defines a way to signal support for HRW and/or AC-DF along with the EVPN ES routes advertised for a given ES. see Section 2.2 for the deets 💖
2. Designated Forwarder Election Protocol and BGP Extensions 💜
this section describes the BGP extensions required to support the new DF election procedures. and since the EVPN specification [RFC7432] leaves several questions open about the precise FSM behavior of DF election, Section 2.1 precisely describes the intended behavior. no more guessing, bestie 🫶
2.1. The DF Election Finite State Machine (FSM) 🌀
Okay so, per [RFC7432], the FSM in Figure 3 gets run per <ES, VLAN> for VLAN-based service, or per <ES, [VLANs in VLAN Bundle]> for a VLAN Bundle, on each participating PE 💖 Real talk, the FSM is conceptual. Any design or implementation MUST comply with behavior that is equivalent to the behavior outlined in this FSM ✨
VLAN_CHANGE VLAN_CHANGE
RCVD_ES RCVD_ES
LOST_ES LOST_ES
+----+ +-------+
| | | v
| +-+----+ ES_UP ++-------++
+->+ INIT +-------------->+ DF_WAIT |
++-----+ +-------+-+
^ |
+-----------+ | |DF_TIMER
| ANY_STATE +-------+ VLAN_CHANGE |
+-----------+ ES_DOWN +-----------------+ |
| RCVD_ES v v
+--------++ LOST_ES ++------+-+
| DF_DONE +<--------------+ DF_CALC +<-+
+---------+ CALCULATED +-------+-+ |
| |
+----+
VLAN_CHANGE
RCVD_ES
LOST_ESFigure 3: DF Election Finite State Machine
Observe 👀 that each EVI is locally configured on each of the multihomed PEs attached to a given ES, and the FSM doesn't protect you at all from inconsistent configuration between these PEs. Like, for a given EVI, one or more of the PEs could be inadvertently configured with a different set of VLANs for a VLAN-aware Bundle service, or with different VLANs for a VLAN-based service. Yikes 😭
Here are the states and events from Figure 3, bestie 🎀
States:
- INIT: Initial state.
- DF_WAIT: State in which the participant waits for enough information to perform the DF election for the EVI/ESI/VLAN combination.
- DF_CALC: State in which the new DF is recomputed.
- DF_DONE: State in which the corresponding DF for the EVI/ESI/VLAN combination has been elected.
- ANY_STATE: Refers to any of the above states.
Events:
- ES_UP: The ES has been locally configured as "UP".
- ES_DOWN: The ES has been locally configured as "DOWN".
- VLAN_CHANGE: The VLANs configured in a bundle (that uses the ES) changed. This event is necessary for VLAN Bundles only.
- DF_TIMER: DF timer [RFC7432] (referred to as "Wait timer" in this document) has expired.
- RCVD_ES: A new or changed ES route is received in an Update message with an
MP_REACH_NLRI. Receiving an unchanged Update MUST NOT trigger this event. - LOST_ES: An Update message with an
MP_UNREACH_NLRIfor a previously received ES route has been received. If such a message is seen for a route that has not been advertised previously, the event MUST NOT be triggered. - CALCULATED: DF has been successfully calculated.
Corresponding actions when transitions are performed or states are entered/exited:
- ANY_STATE on ES_DOWN:
- (i) Stop the DF Wait timer.
- (ii) Assume an NDF for the local PE.
- INIT on ES_UP: Transition to DF_WAIT.
- INIT on VLAN_CHANGE, RCVD_ES, or LOST_ES: Do nothing.
- DF_WAIT on entering the state:
- (i) Start the DF Wait timer if not started already or expired.
- (ii) Assume an NDF for the local PE.
- DF_WAIT on VLAN_CHANGE, RCVD_ES, or LOST_ES: Do nothing.
- DF_WAIT on DF_TIMER: Transition to DF_CALC.
- DF_CALC on entering or re-entering the state:
- (i) Rebuild the candidate list, perform a hash, and perform the election.
- (ii) Afterwards, the FSM generates a CALCULATED event against itself.
- DF_CALC on VLAN_CHANGE, RCVD_ES, or LOST_ES: Do as prescribed in Transition 7.
- DF_CALC on CALCULATED: Mark the election result for the VLAN or bundle, and transition to DF_DONE.
- DF_DONE on exiting the state: If a new DF election is triggered and the current DF is lost, then assume an NDF for the local PE for the VLAN or VLAN Bundle.
- DF_DONE on VLAN_CHANGE, RCVD_ES, or LOST_ES: Transition to DF_CALC.
The above events and transitions are defined for the default DF election algorithm. As described in Section 4, the use of the AC-DF capability introduces additional events and transitions ✨
2.2. The DF Election Extended Community 🦋
For the DF election procedures to be consistent and unanimous, it is necessary that all the participating PEs agree on the DF election algorithm and capabilities to be used. Like, it's not possible for some PEs to keep using the default DF election algorithm while others use HRW 🙈 For brownfield deployments and for interoperability with legacy PEs, it's important that all PEs have the ability to fall back on the default DF election. A PE can indicate its willingness to support HRW and/or AC-DF by signaling a DF Election Extended Community along with the ES route (Route Type 4) 💅
The DF Election Extended Community is a new BGP transitive Extended Community attribute [RFC4360] that is defined to identify the DF election procedure to be used for the ES. Figure 4 shows the encoding of it, and it's giving very precise bit-level energy 🧚
0 1 2 3
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: DF Election Extended Community
Where:
Type:0x06, as registered with IANA (Section 7) for EVPN Extended Communities.Sub-Type:0x06. "DF Election Extended Community", as registered with IANA.RSV/Reserved: Reserved bits for information that is specific to DF Alg.DF Alg(5 bits): Encodes the DF election algorithm values (between 0 and 31) that the advertising PE desires to use for the ES. This document creates an IANA registry called "DF Alg" (Section 7), which contains the following values:- Type 0: Default DF election algorithm, or modulus-based algorithm as defined in [RFC7432].
- Type 1: HRW Algorithm (Section 3).
- Types 2-30: Unassigned.
- Type 31: Reserved for Experimental Use.
Bitmap(2 octets): Encodes "capabilities" to use with the DF election algorithm in the DF Alg field. This document creates an IANA registry (Section 7) for the Bitmap field, with values 0-15. This registry is called "DF Election Capabilities" and includes the bit values listed below.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Bitmap Field in the DF Election Extended Community
- Bit 0 (corresponds to Bit 24 of the DF Election Extended Community): Unassigned.
- Bit 1: AC-DF Capability (AC-Influenced DF election; see Section 4). When set to 1, it indicates the desire to use AC-DF with the rest of the PEs in the ES.
- Bits 2-15: Unassigned.
The DF Election Extended Community is used as follows 💖
- A PE SHOULD attach the DF Election Extended Community to any advertised ES route, and the Extended Community MUST be sent if the ES is locally configured with a DF election algorithm other than the default DF election algorithm or if a capability is required to be used. In the Extended Community, the PE indicates the desired "DF Alg" algorithm and "Bitmap" capabilities to be used for the ES.
- Only one DF Election Extended Community can be sent along with an ES route. Note that the intent is not for the advertising PE to indicate all the supported DF election algorithms and capabilities but to signal the preferred one.
- DF Alg values 0 and 1 can both be used with Bit 1 (AC-DF) set to 0 or 1.
- In general, a specific DF Alg SHOULD determine the use of the reserved bits in the Extended Community, which may be used in a different way for a different DF Alg. In particular, for DF Alg values 0 and 1, the reserved bits are not set by the advertising PE and SHOULD be ignored by the receiving PE.
- When a PE receives the ES routes from all the other PEs for the ES in question, it checks to see if all the advertisements have the Extended Community with the same DF Alg and Bitmap:
- If they do, this particular PE MUST follow the procedures for the advertised DF Alg and capabilities. For instance, if all ES routes for a given ES indicate DF Alg HRW and AC-DF set to 1, then the PEs attached to the ES will perform the DF election as per the HRW algorithm and following the AC-DF procedures.
- Otherwise, if even a single advertisement for Route Type 4 is received without the locally configured DF Alg and capability, the default DF election algorithm MUST be used as prescribed in [RFC7432]. This procedure handles the case where participating PEs in the ES disagree about the DF algorithm and capability to be applied.
- The absence of the DF Election Extended Community or the presence of multiple DF Election Extended Communities (in the same route) MUST be interpreted by a receiving PE as an indication of the default DF election algorithm on the sending PE -- that is, DF Alg 0 and no DF election capabilities.
- When all the PEs in an ES advertise DF Type 31, they will rely on the local policy to decide how to proceed with the DF election.
- For any new capability defined in the future, the applicability/compatibility of this new capability to/with the existing DF Alg values must be assessed on a case-by-case basis.
- Likewise, for any new DF Alg defined in the future, its applicability/compatibility to/with the existing capabilities must be assessed on a case-by-case basis.
2.2.1. Backward Compatibility 🌸
Implementations that comply with [RFC7432] only (i.e., implementations that predate this specification) will not advertise the DF Election Extended Community. That means all other participating PEs in the ES won't receive DF preferences, and they'll revert to the default DF election algorithm without AC-DF 😭
Similarly, an implementation that complies with [RFC7432] only, and that receives a DF Election Extended Community, will ignore it and will continue to use the default DF election algorithm. Main character energy for the legacy PEs, honestly 👑
3. The Highest Random Weight DF Election Algorithm ✨
Okay bestie, this section is the main event 💅 It's all about HRW (Highest Random Weight), the algorithm that picks the DF. The procedure here works for DF election in EVPN services [RFC7432] and for the EVPN Virtual Private Wire Service (VPWS) [RFC8214]. 🦋
HRW was first proposed in [HRW1999] for Internet caching and proxy server load balancing 🌸 The idea is that you take an object name and a set of servers, and HRW maps each request to a server using the object-name (object-id) and the server-name (server-id), not the server states. It hashes the server-id together with the object-id to build an ordered list of servers for that object. The server with the highest hash value is the primary, responsible for that object. The server with the next-highest value is the backup. HRW always maps a given object name to the same server within a given cluster, so it can be used at client sites to reach global consensus on object-to-server mappings 🤝 And when the primary server goes down, the backup becomes the responsible designate. Iconic redundancy behavior, honestly 👑
Picking a hash function is a big deal here. It needs to be statistically oblivious to the key distribution and give a nice, uniform spread of hash outputs ✨ Luckily, there are lots of options. [HRW1999] gives pseudorandom functions based on the Unix utilities rand and srand, plus simple XOR functions that have the hashing properties we want. HRW is already used in multicast and ECMP [RFC2991] [RFC2992] 🌈
3.1. HRW and Consistent Hashing
Ngl, HRW isn't the only algorithm that tackles the object-to-server mapping problem. It also aims for fair load distribution, redundancy, and fast access 🧚 There's another family, the Consistent Hashing Algorithms [CHASH], that solves the same problem. We're not going to cover those here 🙈
3.2. HRW Algorithm for EVPN DF Election
This subsection explains how HRW gets applied to DF election 💖 The variables are: DF(V) is the DF, BDF(V) is the BDF for the Ethernet Tag V, Si is the IP address of PE i, Es is the ESI, and Weight is a function of V, Si, and Es.
Here's the tea ☕ The default DF election algorithm in [RFC7432] uses a PE address and a VLAN as inputs. This document uses an Ethernet Tag, a PE address, and an ESI instead 🎀 Why? If the same set of PEs is multihomed to the same set of ESes, the [RFC7432] algorithm would elect the same PE as DF for the same set of BDs on each ES. That can hurt both load balancing and redundancy 😭 Adding the ESI brings in extra entropy, which hugely lowers the chance that the same PE keeps getting picked as DF for the same BDs on every ES. So when you use HRW for EVPN DF election, the ESI value in the Weight function below SHOULD be set to that of the corresponding ES 🫶
For a VLAN Bundle service, V stands for the lowest VLAN, same vibe as the "lowest VLAN in bundle" logic in [RFC7432] 💜
The election rules go like this:
1. DF(V) = Si| Weight(V, Es, Si) >= Weight(V, 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(V) = Sk| Weight(V, Es, Si) >= Weight(V, Es, Sk), and
Weight(V, Es, Sk) >= Weight(V, Es, Sj). In the case of a tie,
choose the PE whose IP address is numerically the least.Where:
DF(V)is defined to be the addressSi(index i) for whichWeight(V, Es, Si)is the highest;0 <= i < N-1.BDF(V)is defined as that PE with addressSkfor which the computed Weight is the next highest after the Weight of the DF.jis the running index from 0 to N-1;iandkare selected values.
Since the Weight is a pseudorandom function with the three-tuple (V, Es, S) as its domain, it's efficient and deterministic, and it doesn't depend on how the Ethernet Tag V sample space is distributed 🦋 Picking a good hash function for that pseudorandom function really matters if this algorithm is going to beat the default one ✨ As mentioned earlier, those functions live in [HRW1999]. The candidate hash function we use is the first of the two listed as preferred in [HRW1999] 🍓
Wrand(V, Es, Si) = (1103515245((1103515245.Si+12345) XOR
D(V, Es))+12345)(mod 2^31)Here, D(V, Es) is the 31-bit digest (CRC-32 with the most significant bit (MSB) discarded, as noted in [HRW1999]) of the 14-octet stream. That stream is the 4-octet Ethernet Tag V followed by the 10-octet ESI. The 14-octet stream is formed by concatenating the Ethernet Tag and the ESI in network byte order, which is mandated 📋 The CRC should proceed as if the stream is in network byte order (big-endian). Si is the address of the ith server. The server's IP address length doesn't matter, since only the low-order 31 bits are modulo significant 💅
Here's the key point 🔑 The Weight function looks at the combination of the Ethernet Tag, the ES, and the PE IP address. The actual length of the server IP address, whether IPv4 or IPv6, isn't really relevant. The default algorithm in [RFC7432] can't handle both IPv4 and IPv6 PE addresses, because [RFC7432] doesn't say how to order the ordinal list when both kinds of PEs are present 😭 HRW doesn't have that problem.
HRW fixes the disadvantages pointed out in Section 1.3.1 of this document and ensures that:
- With very high probability, DF election for the VLANs configured on an ES is more or less equally spread across the PEs, even with just two PEs (see the first fundamental problem listed in Section 1.3.1) ⭐
- If a PE that is not the DF or the BDF for that VLAN goes down, or its connection to the ES goes down, it doesn't cause a DF or BDF reassignment. That saves computation, especially when the connection flaps 🎀
- Even better, it avoids the third fundamental problem listed in Section 1.3.1 (needless disruption) that is inherent in the existing default DF election 🙌
- On top of the DF, the algorithm also gives you the BDF, which becomes the DF if the current DF fails 👑
4. The AC-Influenced DF Election Capability ✨
okay bestie, this section is all about the AC-influenced DF capability 🦋 it works for DF election in EVPN services [RFC7432] and EVPN VPWS [RFC8214], so both get the glow-up 💖
The AC-DF capability is expected to be generally applicable to any future DF algorithm 🌈 it changes the DF election procedures by removing from consideration any candidate PE in the ES that cannot forward traffic on the AC that belongs to the BD. this section applies to VLAN-based and VLAN Bundle service interfaces. for VLAN-aware Bundle service interfaces, see Section 4.1 ✨
when it's used with the default DF algorithm, the AC-DF capability modifies Step 3 in the DF election procedure described in [RFC7432], Section 8.5, like this:
- When the timer expires, each PE builds an ordered candidate list of the IP addresses of all the PE nodes attached to the ES (including itself), in increasing numeric value. The candidate list is based on the Originating Router's IP addresses of the ES routes but excludes any PE from whom no Ethernet A-D per ES route has been received or from whom the route has been withdrawn. Afterwards, the DF election algorithm is applied on a per
<ES, Ethernet Tag>; however, the IP address for a PE will not be considered to be a candidate for a given<ES, Ethernet Tag>until the corresponding Ethernet A-D per EVI route has been received from that PE. In other words, the ACS on the ES for a given PE must be UP so that the PE is considered to be a candidate for a given BD.
If the default DF algorithm is used, every PE in the resulting candidate list is then given an ordinal indicating its position in the ordered list, starting with 0 as the ordinal for the PE with the numerically lowest IP address. The ordinals are used to determine which PE node will be the DF for a given Ethernet Tag on the ES, using the following rule:
Assuming a redundancy group of N PE nodes, for VLAN-based service, the PE with ordinal i is the DF for an <ES, Ethernet Tag V> when (V mod N) = i. In the case of a VLAN (-aware) Bundle service, the numerically lowest VLAN value in that bundle on that ES MUST be used in the modulo function as the Ethernet Tag.
It should be noted that using the Originating Router's IP Address field [RFC7432] in the ES route to get the PE IP address needed for the ordered list allows for a CE to be multihomed across different Autonomous Systems (ASes) if such a need ever arises 🌸
the modified Step 3 above differs from [RFC7432], Section 8.5, Step 3 in two ways 💅
- Any DF Alg can be used. It's not only the described modulus-based DF Alg (referred to as the default DF election or "DF Alg 0" in this document).
- The candidate list is pruned based upon non-receipt of Ethernet A-D routes. A PE's IP address MUST be removed from the ES candidate list if its Ethernet A-D per ES route is withdrawn. A PE's IP address MUST NOT be considered to be a candidate DF for an
<ES, Ethernet Tag>if its Ethernet A-D per EVI route for the<ES, Ethernet Tag>is withdrawn.
the example below shows how the AC-DF behavior plays out with the default DF election algorithm, assuming the network in Figure 2 🧚
(a) When PE1 and PE2 discover ES12, they advertise an ES route for ES12 with the associated ES-Import Extended Community and the DF Election Extended Community indicating AC-DF = 1. They start a DF Wait timer (independently). Likewise, PE2 and PE3 advertise an ES route for ES23 with AC-DF = 1 and start a DF Wait timer.
(b) PE1 and PE2 advertise an Ethernet A-D per ES route for ES12. PE2 and PE3 advertise an Ethernet A-D per ES route for ES23.
(c) In addition, PE1, PE2, and PE3 advertise an Ethernet A-D per EVI route for AC1, AC2, AC3, and AC4 as soon as the ACs are enabled. Note that the AC can be associated with a single customer VID (e.g., VLAN-based service interfaces) or a bundle of customer VIDs (e.g., VLAN Bundle service interfaces) 🎀
(d) When the timer expires, each PE builds an ordered candidate list of the IP addresses of all the PE nodes attached to the ES (including itself) as explained in the modified Step 3 above. Any PE from which an Ethernet A-D per ES route has not been received is pruned from the list.
(e) When electing the DF for a given BD, a PE will not be considered to be a candidate until an Ethernet A-D per EVI route has been received from that PE. In other words, the ACS on the ES for a given PE must be UP so that the PE is considered to be a candidate for a given BD. For example, PE1 will not consider PE2 as a candidate for DF election for <ES12, VLAN-1> until an Ethernet A-D per EVI route is received from PE2 for <ES12, VLAN-1> 🫶
(f) Once the PEs with ACS = DOWN for a given BD have been removed from the candidate list, the DF election can be applied for the remaining N candidates 👑
Note that this procedure only modifies the existing EVPN control plane by adding and processing the DF Election Extended Community and by pruning the candidate list of PEs that take part in the DF election 💜
In addition to the events defined in the FSM in Section 2.1, the following events SHALL modify the candidate PE list and trigger the DF re-election in a PE for a given <ES, Ethernet Tag>. In the FSM shown in Figure 3, the events below MUST trigger a transition from DF_DONE to DF_CALC:
- Local AC going DOWN/UP.
- Reception of a new Ethernet A-D per EVI route update/withdrawal for the
<ES, Ethernet Tag>. - Reception of a new Ethernet A-D per ES route update/withdrawal for the ES.
4.1. AC-Influenced DF Election Capability for VLAN-Aware Bundle Services
the procedure described in Section 4 works for VLAN-based and VLAN Bundle service interfaces because, for those service types, a PE advertises only one Ethernet A-D per EVI route per <ES, VLAN> or <ES, VLAN Bundle> ✨ in Section 4, an Ethernet Tag represents a given VLAN or VLAN Bundle for the purpose of DF election. The withdrawal of such a route means that the PE cannot forward traffic on that particular <ES, VLAN> or <ES, VLAN Bundle>, so the PE can be removed from consideration for DF election 🦋
according to [RFC7432], in VLAN-aware Bundle services, the PE advertises multiple Ethernet A-D per EVI routes per <ES, VLAN Bundle> (one route per Ethernet Tag), while the DF election is still performed per <ES, VLAN Bundle>. The withdrawal of an individual route only indicates the unavailability of a specific AC and not necessarily all the ACs in the <ES, VLAN Bundle> 🤔
this document modifies the DF election for VLAN-aware Bundle services in the following ways:
- After confirming that all the PEs in the ES advertise the AC-DF capability, a PE will perform a DF election per
<ES, VLAN>, as opposed to per<ES, VLAN Bundle>as described in [RFC7432]. Now, the withdrawal of an Ethernet A-D per EVI route for a VLAN will indicate that the advertising PE's ACS is DOWN, and the rest of the PEs in the ES can remove the PE from consideration for DF election in the<ES, VLAN>. - The PEs will now follow the procedures in Section 4.
for example, let's say there are three bridge tables in PE1 for the same MAC-VRF, each one associated with a different Ethernet Tag (e.g., VLAN-1, VLAN-2, and VLAN-3). PE1 will advertise three Ethernet A-D per EVI routes for ES12. Each of the three routes will indicate the status of each of the three ACs in ES12. PE1 will be considered to be a valid candidate PE for DF election in <ES12, VLAN-1>, <ES12, VLAN-2>, and <ES12, VLAN-3> as long as its three routes are active 🌈 for instance, if PE1 withdraws the Ethernet A-D per EVI routes for <ES12, VLAN-1>, the PEs in ES12 will not consider PE1 as a suitable DF candidate for <ES12, VLAN-1>. PE1 will still be considered for <ES12, VLAN-2> and <ES12, VLAN-3>, since its routes are active 💖
5. Solution Benefits ⭐
the solution in this document gives you these benefits, bestie 👑
- (a) It extends the DF election as defined in [RFC7432] to address the unfair load balancing and potential black-holing issues with the default DF election algorithm. The solution is applicable to the DF election in EVPN services [RFC7432] and EVPN VPWS [RFC8214].
- (b) It defines a way to signal the DF election algorithm and capabilities intended by the advertising PE. This is done by defining the DF Election Extended Community, which allows the advertising PE to indicate its support for the capabilities defined in this document as well as any subsequently defined DF election algorithms or capabilities 🎀
- (c) It is backwards compatible with the procedures defined in [RFC7432]. If one or more PEs in the ES do not support the new procedures, they will all follow DF election as defined in [RFC7432] 🫶
6. Security Considerations 🔥
okay this part is serious, so read it carefully 🙈 this document addresses some identified issues in the DF election procedures described in [RFC7432] by defining a new DF election framework. In general, this framework allows the PEs that are part of the same ES to exchange additional information and agree on the DF election type and capabilities to be used.
by following the procedures in this document, the operator will minimize such undesirable situations as unfair load balancing, service disruption, and traffic black-holing. Because such situations could be purposely created by a malicious user with access to the configuration of one PE, this document also enhances the security of the network. Note that the network will not benefit from the new procedures if the DF election algorithm is not consistently configured on all the PEs in the ES. If there is no unanimity among all the PEs, the DF election algorithm falls back to the default DF election as provided in [RFC7432] 😭
This behavior could be exploited by an attacker that manages to modify the configuration of one PE in the ES so that the DF election algorithm and capabilities in all the PEs in the ES fall back to the default DF election. If that is the case, the PEs will be exposed to the unfair load balancing, service disruption, and black-holing mentioned earlier. 💀
in addition, the new framework is extensible and allows for new security enhancements in the future. Note that such enhancements are out of scope for this document. Finally, since this document extends the procedures in [RFC7432], the same security considerations as those described in [RFC7432] are valid for this document 🌸
7. IANA Considerations 📝✨
Okay bestie, IANA is the registry keeper for all the protocol numbers, and here's what they're doing for this spec 🦋
- IANA has:
- Allocated Sub-Type value 0x06 in the "EVPN Extended Community Sub-Types" registry defined in [RFC7153] as follows:
Sub-Type Value Name Reference
-------------- ------------------------------ -------------
0x06 DF Election Extended Community This document- Set up a registry called "DF Alg" for the DF Alg field in the Extended Community. New registrations will be made through the "RFC Required" procedure defined in [RFC8126]. Value 31 is for experimental use and does not require any other RFC than this document. The following initial values in that registry exist:
Alg Name Reference
---- ----------------------------- -------------
0 Default DF Election This document
1 HRW Algorithm This document
2-30 Unassigned
31 Reserved for Experimental Use This document- Set up a registry called "DF Election Capabilities" for the 2-octet Bitmap field in the Extended Community. New registrations will be made through the "RFC Required" procedure defined in [RFC8126]. The following initial value in that registry exists:
Bit Name Reference
---- ---------------- -------------
0 Unassigned
1 AC-DF Capability This document
2-15 Unassigned8. References 📚
Here are all the docs this spec leans on, and yes, I read every single one 💅
8.1. Normative References
These are the big ones you need in your back pocket to actually get this spec 🫶
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432,
February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.8.2. Informative References
These ones are the extra reading for the curious, the deep-dive and history crowd 🧚
[VPLS-MH] Kothari, B., Kompella, K., Henderickx, W., Balus, F., and
J. Uttaro, "BGP based Multi-homing in Virtual Private LAN
Service", Work in Progress,
draft-ietf-bess-vpls-multihoming-03, March 2019.
[CHASH] Karger, D., Lehman, E., Leighton, T., Panigrahy, R.,
Levine, M., and D. Lewin, "Consistent Hashing and Random
Trees: Distributed Caching Protocols for Relieving Hot
Spots on the World Wide Web", ACM Symposium on Theory of
Computing, ACM Press, New York, DOI 10.1145/258533.258660,
May 1997.
[CLRS2009] Cormen, T., Leiserson, C., Rivest, R., and C. Stein,
"Introduction to Algorithms (3rd Edition)", MIT
Press, ISBN 0-262-03384-8, 2009.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991,
DOI 10.17487/RFC2991, November 2000,
<https://www.rfc-editor.org/info/rfc2991>.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,
<https://www.rfc-editor.org/info/rfc2992>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[HRW1999] Thaler, D. and C. Ravishankar, "Using Name-Based Mappings
to Increase Hit Rates", IEEE/ACM Transactions on
Networking, Volume 6, No. 1, February 1998,
<https://www.microsoft.com/en-us/research/wp-content/
uploads/2017/02/HRW98.pdf>.
[Knuth] Knuth, D., "The Art of Computer Programming: Volume 3:
Sorting and Searching", 2nd Edition, Addison-Wesley,
Page 516, 1998.Acknowledgments 🙏
Huge thank-you to everyone who reviewed this and dropped their contributions, you literally made this doc better 🌈 Ranganathan Boovaraghavan, Sami Boutros, Luc Andre Burdet, Anoop Ghanwani, Mrinmoy Ghosh, Jakob Heitz, Leo Mermelstein, Mankamana Mishra, Tamas Mondal, Laxmi Padakanti, Samir Thoria, and Sriram Venkateswaran, you're all iconic 👑 Special shoutout to Stephane Litkowski for his thorough review and detailed contributions, absolutely main character energy 💖
The authors also want to thank their working group chairs, Matthew Bocci and Stephane Litkowski, plus their AD, Martin Vigoureux, for the guidance and support 🫶
And last but definitely not least, thanks to the Directorate reviewers and the ADs for their thorough reviews and probing questions 🔥 Those answers seriously leveled up the quality of the document.
Contributors 🌸
These people put in substantial work on this document and should be treated as coauthors 💅
Antoni Przygienda
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America
Email: prz@juniper.net
Vinod Prabhu
Nokia
Email: vinod.prabhu@nokia.com
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com
Wen Lin
Juniper Networks, Inc.
Email: wlin@juniper.net
Patrice Brissette
Cisco Systems
Email: pbrisset@cisco.com
Keyur Patel
Arrcus, Inc.
Email: keyur@arrcus.com
Autumn Liu
Ciena
Email: hliu@ciena.comAuthors' Addresses 🌟
And here are the official authors, the squad who made this whole thing happen 🦋
Jorge Rabadan (editor)
Nokia
777 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: jorge.rabadan@nokia.com
Satya Mohanty (editor)
Cisco Systems, Inc.
225 West Tasman Drive
San Jose, CA 95134
United States of America
Email: satyamoh@cisco.com
Ali Sajassi
Cisco Systems, Inc.
225 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com
John Drake
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America
Email: jdrake@juniper.net
Kiran Nagaraj
Nokia
701 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: kiran.nagaraj@nokia.com
Senthil Sathappan
Nokia
701 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: senthil.sathappan@nokia.com📦 where this page comes from
- ietf: rfc8584 2019-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms