Summary

  • RFC 9722 carries an absolute Service Carving Time (SCT) in an Ethernet Segment route and coordinates capable peers around that target; a valid SCT proves only what the sender declared.
  • A defensible “synchronised recovery” claim needs clock-quality, route-receipt, capability-set, timer, DF/NDF programming and per-traffic observations tied to one recovery generation.
  • “No loss” is a customer-data result. It cannot be inferred from a successful BGP update, a completed election or a quiet alarm panel.

An appointment is not an outcome

An EVPN provider edge returns after a failure. It discovers its multihoming partners, computes an absolute time and advertises that Service Carving Time in its Ethernet Segment route. Its peers now have an appointment for the DF election. At the appointed instant, however, one forwarding ASIC may still be installing filters, another clock may be several milliseconds away, and a third peer may never have received the route. The control plane can be internally consistent while customer packets are lost or duplicated.

RFC 9722, published as a Standards Track RFC in May 2025, updates the DF election procedures of RFC 8584. Its contribution is deliberately bounded: when a PE recovers, it can announce a common future instant so the Ethernet Segment peers rerun election in a coordinated way. The mechanism reduces the hazards of independently expiring local timers. It does not turn the timestamp into a distributed transaction.

The distinction matters because ordinary EVPN multihoming already has two bad edges. If a recovering candidate starts forwarding before the old DF stops, duplicate delivery or a loop can appear. If the old DF stops before the new one is ready, traffic can be dropped. A longer discovery timer can reduce premature action but prolong outage. RFC 9722 makes the transition schedulable; it does not make readiness observable.

What the wire actually carries

The SCT is encoded in a BGP extended community on the Ethernet Segment route, Route Type 4. IANA assigns the Transitive Opaque Extended Community subtype 0x0F to Service Carving Time. The value is an adapted NTP timestamp: 32 bits of seconds and the high 16 bits of the fractional second, giving roughly 15-microsecond representation granularity. The NTP era is not carried.

The recovering PE derives SCT by adding its local partner-discovery period to its local current time. This proves two propositions when the update is validly received: the sender asserted a local notion of “now,” and it asserted a waiting interval. It does not prove that the local clock was correct, that every peer shares the same era and offset, that the BGP update arrived in time, or that the chosen interval covers control-plane propagation and hardware programming.

The T capability bit—bit 3 in the DF Election Capabilities field—prevents selective participation from being mistaken for agreement. Every PE on the Ethernet Segment must advertise support. If a non-T-capable peer is detected, participating PEs revert immediately to the baseline procedure and cancel SCT-based delay. This is a safety rule, but it turns membership knowledge into evidence: an inventory snapshot taken before the recovery is not enough. The relevant record is the capability set actually observed for that Ethernet Segment and recovery generation.

Reception has rejection semantics

RFC 9722 requires receivers to compare an SCT with local time. A value in the past is discarded. So is a value whose future offset exceeds the receiver's locally configured peering timer. In either case, the receiver treats the peer's election as having already occurred. This bounds obviously stale or far-future claims, but it also means that two correct implementations can take different actions if their clocks or timer configurations differ.

A useful incident record therefore preserves the raw route, receipt timestamp, parsed SCT, local offset calculation, local timer bound and accept-or-discard decision for every PE. “BGP route received” collapses the most important branch. A value can be structurally valid and operationally rejected; it can also be accepted against a clock that later proves untrustworthy.

Concurrent recoveries create another branch. RFC 9722 orders the announced times and performs one election at the largest—the latest—SCT. Earlier pending actions must be cancelled or moved. That rule prevents several elections from firing independently, provided each participant saw the same set in time. Evidence must show the candidate SCT set, its ordering, which timer was replaced and why the final maximum was authoritative. Merely logging the winning timestamp cannot reveal a late route or a cancelled timer that still fired.

Clock synchronisation needs its own receipts

RFC 5905 gives NTP a vocabulary richer than “synchronised”: offset, delay, dispersion, jitter and root distance describe the quality and uncertainty of a clock. RFC 8633 recommends multiple independent, diverse time sources—at least four when accurate time is required—and continuous monitoring. Several sources can still share one failure or disagree through leap-smear policy. RFC 8915 lets Network Time Security authenticate the server and exchange and resist replay; it does not certify that the time value is objectively correct.

This yields a practical rule: an operator should not attach a clock-confidence claim to an SCT unless it retains the time source set, selection state, offset, root distance, dispersion, jitter, leap state, last update and any step or slew event around the recovery. “NTP up” is a process status. It is not a bound on disagreement between PE clocks.

RFC 9722 uses a configurable skew, with 10 milliseconds as the default. Around the chosen SCT, a PE moving from DF to NDF applies the NDF state at SCT − skew; the election result is applied at SCT. That interval is intended to avoid simultaneous forwarding. Its safe value depends on scale, hardware behaviour and clock accuracy. A default is therefore not a measured safety margin. Operators need the observed distribution of clock error, route processing, election computation and data-plane programming latency.

The forwarding plane has more than one clock

The election algorithm produces a role. Software then has to translate the role into VLAN or Ethernet-tag state, program filters and replication, and receive confirmation from hardware. A device may acknowledge an API before the relevant table is active. A chassis may update line cards at different times. Hundreds of VLANs may drain through a queue rather than change atomically.

For every service being claimed, preserve at least four times: election decision, programming submission, hardware acknowledgement and first observed forwarding state. Record old and new DF identity, Ethernet Segment, VLAN or Ethernet tag, recovery generation and error path. Aggregating all services into “DF converged” can hide a long tail in which a small set of customers remains black-holed or dual-forwarded.

Packet evidence must then close the chain. Use bidirectional test or customer telemetry with sequence numbers and timestamps across a declared observation window. Count gaps, reordering, duplicates and unexpected path changes; retain both ingress and egress viewpoints where loops are plausible. Absence of an alarm or complaint is not zero loss. A sampled flow can only support a bounded claim about the sampled traffic, vantage points and interval.

A claim ladder for recovery

The evidence can be stated without overreach:

  1. SCT advertised: a named PE emitted a parseable RT-4 with a particular SCT and T capability.
  2. SCT accepted: each named peer received it before its deadline and recorded the same capability set and final maximum SCT.
  3. Clock bound: each peer's independent time evidence supports a stated maximum disagreement for the interval.
  4. Election coordinated: timers were installed, cancelled or reordered consistently, and the same DF result was computed.
  5. Data plane applied: relevant services received confirmed NDF/DF state within a measured window.
  6. Traffic outcome observed: named probes or counters saw stated loss, duplication, reordering and loop results.

Only the sixth level supports a traffic claim, and even then only within its coverage. The lower levels are not failures; they are narrower facts.

Sources

Primary standards and registries: RFC 9722, its RFC Editor record and IETF record, RFC 8584, RFC 7432, RFC 5905, RFC 8633, RFC 8915 and the IANA BGP Extended Communities registry.