rfc-9722

Fast Recovery for EVPN Designated Forwarder Election

P. Brissette, A. Sajassi, LA. Burdet (Editor), J. Drake, J. Rabadan
date2025-05 streamIETF areartg wgbess statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc9722 doi10.17487/RFC9722
The Ethernet Virtual Private Network (EVPN) solution in RFC 7432 provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying the Highest Random Weight (HRW) algorithm for DF election to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast DF election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This document updates RFC 8584 by optionally introducing delays between some of the events therein. The solution is independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment, and it is performed via a simple signaling in BGP between the recovered node and each of the other nodes in the multihoming group.

updates

Extracted elements (24)

design-rationale §2

A 'skew' (default 10 ms) is introduced so that previously inserted PEs perform DF-to-NDF transitions slightly before the SCT, ensuring both PEs are briefly in NDF state before NDF-to-DF transitions occur at the SCT. This eliminates overlapping DF roles and prevents duplicate traffic and loops.

routing, mpls

design-rationale §1.3

Existing timer-based DF election in RFC 7432 causes either loops and duplicates (timer too short) or prolonged traffic loss (timer too long). The HRW algorithm from RFC 8584 helps during failures but cannot prevent overlapping DF roles when a new PE is inserted, since there is no handshake mechanism.

routing, mpls

design-rationale §2.2

The NTP Era value is not exchanged; participating PEs assume timestamps are in the same Era as their local clock. An Era rollover event would not occur until February 7, 2036, and is addressed by the upper-bound SCT validation described in Section 2.2.

routing, mpls, ntp

design-rationale §3

The SCT approach makes BGP transmission delay a non-issue because the peering PE uses the absolute SCT to schedule carving regardless of when it received the RT-4. This effectively shortens the 3-second RFC 7432 discovery timer window to the order of milliseconds.

routing, mpls

design-rationale §1.4

The solution uses simple unidirectional signaling (one-way SCT advertisement) rather than complex handshake mechanisms or new state machines, and is agnostic of the actual time synchronization mechanism while using NTP-based time representation for BGP signaling.

routing, mpls

interoperability-note §4

PEs that operate using the baseline modulo-based DF election from RFC 7432 will simply discard the new SCT BGP Extended Community as unrecognized, ensuring backwards compatibility. A PE signals SCT support by setting T=1 in the DF Election Capability bitmap alongside the SCT extended community.

routing, mpls

normative-requirement §2.1 MUST NOT

A PE that does not support the Time Synchronization procedures or that receives a route from another PE in which the T-bit capability is not set MUST NOT delay DF election, as doing so could lead to duplicate traffic from overlapping DFs.

routing, mpls

normative-requirement §2.2 MUST

A PE that receives an SCT representing an offset larger than the local peering timer MUST discard the SCT and SHALL treat the DF Election at the peer as having already occurred, reverting to RFC 7432 behavior.

routing, mpls, ntp

normative-requirement §2.2 MUST

A PE that receives an SCT value smaller than its current local time MUST discard the Service Carving Time and SHALL treat the DF Election at the peer as having already occurred, falling back to RFC 7432 behavior without any additional timer delay.

routing, mpls, ntp

normative-requirement §4 MUST

If a new or extra RT-4 is received without the T-bit during an ongoing SCT-based DF Election sequence, all SCT-based delays MUST be canceled and DF Election is immediately applied as specified in RFC 7432, as if no SCT had been previously exchanged.

routing, mpls

normative-requirement §3.1 SHALL

If a PE recovers during the discovery window and does not support or advertise the T-bit, all PEs in the current peering sequence SHALL immediately revert to the default timer-based behavior described in RFC 7432.

routing, mpls

normative-requirement §4 SHALL

If any PE attached to an Ethernet Segment does not signal T=1, then all PEs in the Ethernet Segment SHALL revert to the timer-based approach specified in RFC 7432. This is critical to prevent VLAN shuffling when more than two PEs are involved.

routing, mpls

normative-requirement §2.2 MUST

Implementations MUST validate the received SCT against an upper bound to address both NTP Era rollover ambiguity and the attack vector of unreasonably large SCT values. The recommended approach is to compare the received offset to the local peering timer value.

routing, mpls, security, ntp

normative-requirement §3 SHOULD

To maintain the preference for minimal loss over duplicate traffic, the original (non-recovering) PE SHOULD carve slightly before the recovering PE by applying DF-to-NDF transitions at SCT minus skew and NDF-to-DF transitions at SCT.

routing, mpls

normative-requirement §3.1 SHALL

When multiple concurrent DF elections occur (multiple recovering PEs each advertising an SCT), all PEs SHALL execute only a single DF election at the service carving time corresponding to the largest (latest) received SCT timestamp value.

routing, mpls

normative-requirement §2 SHOULD NOT

Whenever possible, recovery activities for failed PEs SHOULD NOT be initiated until after the underlying clock synchronization protocol has converged, in order to benefit from the fast DF recovery procedures.

routing, mpls, ntp

protocol-element §2

The Service Carving Time (SCT) is an absolute time advertised by a newly inserted or recovering PE along with its Ethernet Segment Route Type 4 (RT-4), representing the common future time at which all peering PEs in the multihoming group will simultaneously perform DF election.

routing, mpls

protocol-element §2.1

The Time Synchronization capability (T-bit, Bit 3 of the Bitmap in the DF Election Extended Community) is advertised by a PE to indicate its support for SCT-based synchronized DF election. It is used in conjunction with the agreed-upon DF Election Type (e.g., HRW).

routing, mpls

registry §6

IANA assigned Bit 3 in the 'DF Election Capabilities' registry (established by RFC 8584) for the 'Time Synchronization' capability defined in this document.

registry, routing, mpls

registry §6

IANA assigned Sub-Type value 0x0F in the 'EVPN Extended Community Sub-Types' registry (established by RFC 7153) for the 'Service Carving Time' extended community defined in this document.

registry, routing, mpls

security-consideration §5

The SCT Extended Community introduces attack vectors: setting SCT to zero or a past value causes fallback to RFC 7432 behavior (handled naturally by Section 2.2 past-timestamp logic), while setting SCT to a large future value is mitigated by mandatory upper-bound validation against the local peering timer.

security, routing, mpls

state-machine §2.3

RFC 8584's DF Election FSM is updated in the DF_CALC state: upon receiving RCVD_ES with an SCT, the FSM delays transitioning back to DF_DONE. The PE waits until SCT minus skew to assume NDF role, then waits the remaining skew before assuming the final elected role (DF or NDF) and transitioning to DF_DONE.

routing, mpls

wire-format §2.1

The DF Election Extended Community (Type 0x06, Sub-Type 0x06) from RFC 8584 includes a 2-octet Bitmap field for capabilities. This document adds Bit 3 (Bit 27 of the Extended Community) as the Time Synchronization (T) capability flag; when set to 1, it signals willingness to use clock-synchronized carving.

routing, mpls

wire-format §2.1

The Service Carving Time BGP Extended Community uses Type 0x06 and Sub-Type 0x0F. It encodes a 32-bit NTP seconds field and the high-order 16 bits of the NTP fraction field (lower 16 bits implicitly set to zero), yielding approximately 15 microseconds (2^-16 s) precision.

routing, mpls, ntp