Summary

  • RFC 9786 changes EVPN DF election from per-service-tag choice to one decision for the Ethernet Segment port; it does not turn that decision into a health certificate for every service on the interface.
  • Port Mode requires unanimous algorithm and capability advertisements. One dissenting or legacy PE can force default-election fallback across the ES and widen disruption beyond the original inconsistency.
  • LACP state, ARP/ND/MAC/VRF synchronization, per-ES P/B advertisements, installed forwarding, packet behavior and customer acceptance are separate evidence objects.

One decision now carries many services

RFC 9786 adds Port-Active to the All-Active and Single-Active multihoming modes established by RFC 7432. Its purpose is not merely to choose another Designated Forwarder. It changes the unit of choice. Instead of electing per Ethernet Segment and Ethernet Tag, the participating PEs elect at the ES itself. One access interface is active; its peer interfaces are standby. Every L2 or L3 service attached to that port is intended to move with it.

That aggregation is useful. A customer edge can keep one LAG, while the provider obtains deterministic interface-level forwarding for functions such as QoS. The mode can sit above MPLS, VXLAN or SRv6 and can carry ordinary EVPN, VPWS, VPN routing or IRB services. It also avoids making ICCP and LDP mandatory for this active/standby pattern.

But aggregation changes the evidence problem. If a VLAN-specific election is wrong, its immediate scope can remain a service. If a Port-Active decision is wrong, the chosen object is the container for all those services. An operator therefore needs stronger evidence precisely because the protocol has made the control action simpler.

The standard states the intended result: the DF must keep its access interface up and forwarding. Non-DF PEs should block traffic in both directions across all VLANs. They may hold the interface down or, where LACP is used, advertise an Out-of-Sync state. Those are behavioral requirements. The DF label is not an observation that each one occurred.

Port Mode is a shared intention

The IANA BGP Extended Communities registry assigns DF Election Capability bit 5 to Port Mode. A PE advertising P=1 asks its peers to remove the Ethernet Tag from the election. Modulo uses ESI bytes rather than a VLAN value; HRW calculates weight for the ES; the preference algorithms in RFC 9785 rank the port rather than its individual tags. Don't Preempt can also preserve the incumbent port after recovery.

This signal is narrower than “the port is ready”. RFC 8584 says an advertising PE signals the preferred algorithm and capabilities, not every function it supports. A receiver follows the new procedure only if all ES routes agree. Absence of the community, more than one such community, or even one advertisement without the locally configured algorithm and bitmap means default DF Algorithm 0 with no capability.

RFC 9786 calls this unanimity. Its security section makes the operational consequence explicit: someone able to change one PE can force the whole ES back to the older procedure, potentially producing unfair load balancing, service disruption, loss or duplication. Consensus is therefore a fragile precondition, not an assurance that later forwarding succeeded.

The same distinction applies to the election output. The elected DF is the winner of an agreed calculation over the observed candidate set. It does not say whether the access optic is stable, whether the CE sees the expected LACP actor, whether a routed adjacency is usable, or whether local policy loaded the correct tables.

The standby problem begins after election

Port-Active has a physical asymmetry. A standby interface may be operationally down. Moving it to active requires the link to rise and the surrounding network to stabilize. RFC 9786 therefore identifies prior synchronization as beneficial. For IRB and Layer 3, ARP and Neighbor Discovery caches are recommended; associated VRF tables may also need synchronization. For Layer 2, MAC-table synchronization may be considered.

These verbs matter. The RFC does not say the election performs synchronization. It lists state that may have to exist before a rapid handover produces useful service. A platform can agree unanimously on P=1, elect PE2 and still discover that PE2's neighbor cache, MAC learning, VRF programming or CE-facing LACP state trails the control-plane decision.

Warm standby narrows one delay. A non-DF can keep LACP Out of Sync instead of forcing the member fully down, reducing the work required when it becomes active. Yet OOS is not a promise that every L2 and L3 dependency behind the member is current. It is one attachment-state receipt.

The same caution applies to Primary and Backup bits. RFC 8214 defines the L2 Attributes Extended Community; RFC 9786 recommends advertising P or B in Ethernet A-D per-ES routes so remote PEs can converge faster. Only P or B is meaningful there, and the per-ES parent bits should override per-EVI bits. A clean P/B record shows what role was advertised. It does not show that a packet crossed the newly primary interface.

Backward compatibility creates another boundary. Older RFC 7432 or RFC 8214 implementations ignore per-ES L2-Attr. They continue default path resolution, using the Single-Active signal from the ESI Label community and existing MAC or per-EVI behavior. A mixed segment may look coherent at one peer while another follows an older information set. The inventory of capabilities belongs beside the election result.

Port scope must not erase service scope

Port-Active intentionally ignores AC-DF. When P=1, A must be zero; a received A=1 is ignored. A sub-interface going down and withdrawing an Ethernet A-D per-EVI route does not influence the port-level election. This protects the interface-wide decision from service-level churn. It also proves why a continuing DF result cannot certify every service: the algorithm is designed not to react to that evidence.

An operator should therefore keep two linked views. The port view contains ESI, peer membership, algorithm, capability bitmap, timers, DF/BDF, LACP state and per-ES P/B advertisement. The service view contains each VLAN, EVI, VPWS or routed context, its MAC or neighbor state, VRF/FIB installation, local counters, remote reachability and customer probe. The first governs the bundle. The second establishes whether the contents survived the move.

RFC 9722 supplies fast-recovery timing mechanisms for EVPN DF election. Timing alignment reduces transient split-brain exposure; it still does not measure application delivery. Similarly, RFC 9784 defines virtual Ethernet Segments and separates one EVC failure from its physical ENNI. That article's failure-domain question is adjacent but different. RFC 9786 chooses the physical-port unit and asks what evidence must accompany that broader choice.

The RFC Editor information record, IETF Datatracker record and errata search establish the document record; no matching errata were listed when checked on 11 September 2026. They do not establish implementation, adoption or operational performance.