Summary

  • RFC 9785 lets operators order EVPN DF candidates with Highest-Preference or Lowest-Preference, but it expressly assumes candidates are already operationally ready.
  • Candidate eligibility, advertised preference, the elected DF, programmed BUM or Single-Active unicast forwarding, convergence and customer outcome are different facts.
  • Don't Preempt can avoid a second disruption when a preferred PE returns, but the price is that the incumbent may remain DF even when it is no longer the administrative favourite.

A preference field has a narrow job

In EVPN, the Designated Forwarder is the PE responsible for sending Broadcast, Unknown Unicast and Multicast traffic toward a multihomed device or network in All-Active mode. In Single-Active mode, its responsibility also includes unicast. RFC 7432 establishes that role; RFC 8584 makes the election process extensible.

RFC 9785 adds a more operator-directed choice. Algorithm 2 orders candidates by the highest numerical preference. Algorithm 3 orders them by the lowest. The two-octet value runs from 0 to 65535 and defaults to 32767. IANA's registry records both algorithms and the D, or Don't Preempt, capability.

That is meaningful control. An operator can lower the current DF's standing before maintenance, or change a preference dynamically through local policy. A PE can be selected independently of the IP-address ordering used by older procedures. But the standard's first requirement contains the limit: preference controls the order in which candidate PEs may become DF, assuming they are all operationally ready.

The assumption is not an output. A preference of 500 does not prove that an attachment circuit is usable, that the relevant forwarding table is installed, or that a customer path is accepting frames. It says how to rank a PE after it belongs in the candidate set.

Eligibility comes before rank

RFC 8584 defines election as more than running a comparison. PEs are discovered, a candidate list is maintained, and a winner is selected after DF_WAIT. With AC-DF enabled, RFC 9785 says a PE is not a candidate until the corresponding Ethernet A-D per ES and per EVI routes have been received. That provides a bounded eligibility test.

Even that test is control-plane evidence. It cannot see whether the data-plane programming completed, whether BUM replication points to the expected attachment, or whether Single-Active unicast arrived without loss. RFC 7432 warns about transient periods in which two PEs may both believe they are DF before an election settles. Its split-horizon machinery limits one failure mode; it does not convert a winner record into an end-to-end receipt.

Algorithm consistency is another prerequisite. If one PE advertises Highest-Preference and another Lowest-Preference, every participant falls back to the default RFC 7432 algorithm. The observed winner therefore needs the algorithm set that produced it. A dashboard showing only “DF: PE3” loses the reason, the candidate membership and whether a fallback occurred.

Administration and operation can intentionally diverge

Don't Preempt makes the evidence problem more interesting. Suppose a highly preferred PE fails. The next candidate takes over. When the former DF returns, immediate reversion would produce another forwarding transition and may cause unnecessary loss. RFC 9785 therefore permits non-revertive behavior.

After a boot or hold timer, the returning PE learns the current Ethernet Segment routes and selects a reference PE. If its configured preference would displace the incumbent, it can advertise an operational “in-use” preference inherited from that reference and set DP to zero. The incumbent still advertises DP=1 and wins the equal-preference tiebreak. The returning PE is present but does not retake the role.

The distinction is exact: administrative preference describes the desired order; advertised in-use preference may describe the temporary order needed to preserve incumbency. A sound record keeps both. Otherwise an audit may report that configuration and BGP disagree when the difference is the protocol's intended state.

Non-revertive is not a universal safety mode. It avoids the risk of one restoration-time move, yet can retain a PE that is no longer the operator's preferred choice. A later route withdrawal, failure of the reference PE, explicit preference change or algorithm conflict changes the calculation again. If a returning PE advertises a different algorithm, Don't Preempt cannot save the non-revertive state: the segment falls back to the default election.

Configuration is also an attack surface

RFC 9785's security section is unusually direct. Configuration supplies “absolute control” over which PE wins for a tag. An attacker who reaches that configuration can change preference and redirect the traffic responsibility. Conflicting algorithm advertisement can disable the non-revertive behavior through fallback.

Local per-tag overrides create a second consistency obligation. They can distribute tags between two PEs, but every PE must apply the same override. Inconsistent views can cause drops or duplicates. The shared preference is therefore only one coordinate in a larger change: configuration authority, candidate membership, algorithm consistency and forwarding observation all matter.

RFC 9784 confirms that the preference algorithms also apply to virtual Ethernet Segments. Its EVC-versus-ENNI failure scope, vES identity and grouping withdrawals belong to a different problem. Likewise, multicast-source redundancy belongs elsewhere. This analysis stays with the authority and evidence of preference-based DF choice.

The RFC Editor record, IETF Datatracker and errata search establish the document record; no matching errata were listed when checked. They do not establish adoption or performance.