Framework for Ethernet VPN Designated Forwarder Election Extensibility
updated by
- rfc-9722 — Fast Recovery for EVPN Designated Forwarder Election
- rfc-9785 — Preference-Based EVPN Designated Forwarder (DF) Election
updates
- rfc-7432 — BGP MPLS-Based Ethernet VPN
Extracted elements (27)
The default DF election can black-hole traffic when an individual AC or bridge table is logically failed (e.g., administratively shut down) without triggering an ES route withdrawal, because the ACS is not a variable in the default algorithm. The AC-DF capability was introduced to allow ACS to influence DF election and protect against such logical failures.
The default modulus-based DF election (V mod N) fails under non-uniform Ethernet Tag distributions (e.g., all-even or all-odd tags), can assign all DFs to one PE, and causes widespread DF reassignment whenever N changes by 1 due to a PE joining or leaving—resulting in needless churn. HRW was chosen because it provides near-uniform distribution regardless of key distribution and minimizes reassignment when the PE set changes.
The DF election framework separates 'DF election algorithm' (the function mapping inputs to a winner PE) from 'DF election capability' (pre-processing steps that modify inputs or candidate lists before the algorithm runs). This separation allows new algorithms and capabilities to be introduced independently and combined in arbitrary pairings, as assessed case-by-case.
The HRW Weight function includes the ESI as an input parameter (in addition to Ethernet Tag and PE IP address) because if the same PE set is multihomed to multiple ESes, a two-input hash would elect the same PE as DF for the same BDs on each ES, harming load balancing and redundancy. Adding the ESI introduces entropy that significantly reduces this probability.
Unlike RFC 7432, which elects a single DF per <ES, EVI>, this document elects a DF per <ES, BD>. For VLAN-aware Bundle services this means multiple DFs per EVI (one per BD/VLAN), enabling finer-grained load balancing and allowing the AC-DF capability to prune candidates at the individual VLAN level.
Implementations complying only with RFC 7432 will not advertise the DF Election Extended Community; all other PEs in the ES will therefore receive no DF preferences and revert to the default DF election algorithm without AC-DF. An RFC 7432-only PE that receives a DF Election Extended Community will ignore it.
The default RFC 7432 modulus-based DF election cannot correctly order a candidate list that mixes IPv4 and IPv6 PE addresses, because RFC 7432 does not specify how to determine ordinal ranking when both address families are present. The HRW algorithm resolves this because only the low-order 31 bits of the PE IP address are significant in the weight computation, making address-family irrelevant.
A PE SHOULD attach the DF Election Extended Community to any advertised ES route. The Extended Community MUST be sent if the ES is configured with a non-default DF election algorithm or if a capability is required.
Absence of the DF Election Extended Community or presence of multiple DF Election Extended Communities in the same ES route MUST be interpreted by a receiving PE as indicating the default DF election algorithm (DF Alg 0, no capabilities).
EVPN implementations MUST conform to the DF election Finite State Machine prescribed in this document, which updates RFC 7432.
For VLAN Bundle service (and HRW), V in the DF algorithm denotes the lowest VLAN in the bundle, consistent with the 'lowest VLAN in bundle' logic of RFC 7432. Under AC-DF with the default algorithm, the numerically lowest VLAN value in the bundle MUST be used in the modulo function.
If all ES route advertisements for a given ES carry the same DF Alg and Bitmap, each PE MUST follow those procedures. If even a single ES route lacks the locally configured DF Alg or capability, the default DF election algorithm (DF Alg 0) MUST be used as per RFC 7432.
Receiving an unchanged BGP Update MUST NOT trigger the RCVD_ES event. If an MP_UNREACH_NLRI is seen for a route not previously advertised, the LOST_ES event MUST NOT be triggered.
The Ethernet Tag value used in the DF election MUST be different from zero.
Under AC-DF, 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 a candidate DF for an <ES, Ethernet Tag> if its Ethernet A-D per EVI route for that <ES, Ethernet Tag> is withdrawn.
Under AC-DF, the following events SHALL modify the candidate PE list and MUST trigger a transition from DF_DONE to DF_CALC: (1) local AC going DOWN/UP, (2) reception of a new Ethernet A-D per EVI route update/withdrawal for the <ES, Ethernet Tag>, and (3) reception of a new Ethernet A-D per ES route update/withdrawal.
When using the HRW algorithm, the ESI value in the Weight function SHOULD be set to that of the corresponding ES. The 14-octet stream for D(V,Es) MUST be formed by concatenating the 4-octet Ethernet Tag and the 10-octet ESI in network byte order.
For VLAN-aware Bundle services with AC-DF enabled, DF election is performed per <ES, VLAN> rather than per <ES, VLAN Bundle>. Each PE advertises one Ethernet A-D per EVI route per Ethernet Tag in the bundle, and withdrawal of any individual route signals ACS DOWN only for that specific VLAN, leaving other VLANs in the bundle unaffected.
The AC-Influenced DF Election (AC-DF) capability (Bitmap Bit 1) modifies the DF election by pruning from the candidate PE list any PE for which the Ethernet A-D per EVI route for the <ES, Ethernet Tag> has been withdrawn, indicating that PE's ACS is DOWN for that BD. A PE's Ethernet A-D per ES route withdrawal also removes it from the ES candidate list.
The DF Election Extended Community is attached to ES routes (Route Type 4) to signal the desired DF election algorithm (DF Alg field, 5 bits) and capabilities (Bitmap field, 2 octets). Only one such Extended Community may be sent per ES route, and it signals the preferred—not the full supported—set.
The Highest Random Weight (HRW) algorithm (DF Alg 1) elects the DF as the PE Si for which Weight(V, Es, Si) is highest, with ties broken by lowest IP address numerically. The Weight function is Wrand(V, Es, Si) = (1103515245·((1103515245·Si+12345) XOR D(V,Es))+12345) mod 2^31, where D(V,Es) is the 31-bit CRC-32 digest of the 14-octet concatenation of Ethernet Tag V and ESI Es in network byte order.
IANA allocated Sub-Type value 0x06 in the 'EVPN Extended Community Sub-Types' registry (defined in RFC 7153) for the DF Election Extended Community.
IANA created the 'DF Alg' registry for the 5-bit DF Alg field, governed by the RFC Required procedure. Initial values: 0 = Default DF Election (modulus), 1 = HRW Algorithm, 2–30 = Unassigned, 31 = Reserved for Experimental Use.
IANA created the 'DF Election Capabilities' registry for the 2-octet Bitmap field, governed by the RFC Required procedure. Initial values: Bit 0 = Unassigned, Bit 1 = AC-DF Capability, Bits 2–15 = Unassigned.
If an attacker modifies the DF election configuration of one PE in an ES so that it disagrees with the others on DF Alg or capabilities, the unanimity requirement causes all PEs in the ES to fall back to the default DF election algorithm (RFC 7432), re-exposing them to unfair load balancing, service disruption, and traffic black-holing. This fallback behavior is a security-relevant property that operators must account for.
The DF Election FSM runs per <ES, VLAN> (VLAN-based) or <ES, VLANs in VLAN Bundle>. States are INIT, DF_WAIT, DF_CALC, and DF_DONE. Key transitions: ES_UP moves INIT→DF_WAIT; DF_TIMER expiry moves DF_WAIT→DF_CALC; CALCULATED moves DF_CALC→DF_DONE; VLAN_CHANGE, RCVD_ES, or LOST_ES from DF_DONE re-enters DF_CALC; ES_DOWN from ANY_STATE stops the timer and assumes NDF.
The DF Election Extended Community is an 8-octet BGP transitive Extended Community (Type 0x06, Sub-Type 0x06). Octet 3 carries 3 reserved bits (RSV) followed by a 5-bit DF Alg field encoding algorithm values 0–31. Octets 4–5 carry a 2-octet Bitmap of capability flags. Octets 6–8 are reserved.