Summary
- RFC 9978 experimentally adds a per-session count of missed BFD control packets that ordinary BFD Up/Down state can leave invisible.
- The counter can justify a scoped investigation. It cannot, by itself, prove loss of customer traffic, delay, a bad LAG member, a routing failure, or a safe automated action.
The attractive thing about a counter is that it appears to settle an argument. A BFD dashboard shows a session as Up, then a new lost-packet-count rises. Someone asks whether the link is failing; someone else asks whether traffic must move. The number feels more truthful than the old binary state, so it is quickly promoted from an observation into a verdict.
RFC 9978 is useful precisely because it refuses that promotion. Published in June 2026 as an Experimental Protocol rather than an Internet Standards Track specification, it adds a method for observing missed BFD control packets. Base BFD may keep a session Up when at least one control packet arrives inside Detection Time. The experiment makes the other missed packets visible before that threshold is crossed. Its scope stops there: RFC 9978 explicitly does not measure data-traffic loss or delay on a link or tunnel.
That boundary is not a defect in the document. It is the operating discipline the measurement needs.
What the count actually witnesses
The method needs a meticulous BFD authentication type: each new control packet has a sequence number that advances by one. With the stability feature enabled, the ietf-bfd-stability YANG augmentation exposes lost-packet-count for a session. A receiver sees a valid packet, later sees a non-consecutive sequence number, and can count the gap. The first accepted non-zero sequence number only initializes the observation; it is not history.
This is a claim about one observed stream, at one receiver, for one session and configuration epoch. It can identify a control signal that deserves attention even though ordinary BFD state has not declared the path down. It can help an operator decide to gather more evidence before a hard failure creates a larger blast radius.
It cannot identify the missing packets' cause. RFC 9978 points to a central complication: LAGs and ECMP can deliver packets out of order without losing them. A strict sequence comparison can therefore turn reordering into apparent loss. The RFC permits implementations to account for expected packets that arrived out of order. Without the delivery context, a rising counter is evidence of a discontinuity in the received sequence, not a diagnosis of a physical member, a congested queue, a remote process or a service path.
The counter also does not witness application traffic. A BFD control packet may travel through an encapsulation, QoS treatment, hashing choice, filter set or failure domain that differs from the customer flow under discussion. The counter may rise while an application remains healthy; a service can fail while its BFD control stream remains clean. Neither observation invalidates the other, because they answer different questions.
The NULL trap
RFC 9978 registers BFD authentication type 6, NULL, so an otherwise unauthenticated session can carry the sequence number needed for stability measurement. Its name is a warning, not a security property. The RFC states that it provides none of the desired authentication properties. A maliciously injected packet can resemble high packet loss without resetting the session; unauthenticated BFD's reset exposure remains.
That creates a governance choice. On a trusted, bounded management surface, a NULL-auth-derived counter may be an acceptable diagnostic prompt if it is labelled with its integrity limit. On a multi-hop routed path, a tunnel or another surface where injection is material, treating the counter as an automatic reroute instruction would be an unjustified escalation. The faster a number can move traffic, the more the number's provenance has to be part of its meaning.
The meticulous requirement is equally important. RFC 9986 explains that “meticulous” means incrementing the sequence number on every newly sent packet; it does not mean that the resulting metric has authenticated the service, measured a customer flow or identified the responsible subsystem. Sequence continuity is a narrow kind of evidence. It should stay narrow until other evidence joins it.
A useful escalation chain
The clean operational use is to make the counter an opening event. Preserve the exact BFD session identity, remote endpoint, path type, authentication mode, sequence/reset context, configuration version, receiver and timestamp. Check whether an out-of-order mechanism could plausibly explain the observed discontinuity. Compare the BFD observation with the BFD client state and with control-plane events, rather than assuming that an Up session has made those systems irrelevant.
Then select a measurement that actually shares the claim at stake. RFC 9978 itself points operators toward OAM Connectivity Fault Management and MPLS loss/delay measurement to isolate a problem. RFC 6374 is deliberately a different surface: it defines MPLS loss and delay measurement, including data-plane measurement. Its existence is a reminder that a control-packet count cannot silently inherit a data-plane conclusion.
For a proposed routing or protection action, add the local RIB/FIB evidence, the intended versus observed forwarding scope, relevant queue or member evidence, and a service-level canary. For a high-consequence change, retain an expiry and rollback condition. The evidence chain should name the strongest statement presently supported: “BFD stability anomaly observed” is a precise alert. “Customer path impaired” needs customer-path evidence. “Automatic failover is safe” needs still more.
This matches Heng Lu's practical distinction between a common observable and a local decision. RFC 9978 supplies a small interoperable observation. It cannot standardise the failure budget, cost of movement, customer promise or responsibility arrangement of every operator. Turning it into an all-purpose service verdict hides those local decisions exactly when they need named owners.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

