Summary

  • Revision 19 makes BFD Up a prerequisite for BGP establishment only after both peers advertise strict-mode capability 74; that is a bilateral contract, not a local checkbox.
  • Current running code exposes different meanings and compatibility points: negotiated and unilateral modes, implementations aligned to different draft revisions, and one cited release without BfdHoldTimer.
  • Operators need proof of the exact mode, capabilities sent and received, pending FSM state, timers and BFD evidence before calling a pair interoperable.

The change window looked harmless. Both edge routers received the same instruction: enable BFD strict mode for the BGP neighbor. The first router interpreted the command as a proposal. It advertised capability 74 and would gate BGP only if the peer advertised the same capability. The second interpreted strictness as a veto. It refused to let BGP proceed until BFD came up, whether or not the peer had accepted the bargain.

Each box was configured. The pair did not share a contract.

That distinction is the operational centre of draft-ietf-idr-bgp-bfd-strict-mode-19. The document is an active IDR Working Group Internet-Draft dated 26 August 2026. Its header says Standards Track and proposes updating RFC 4271 if approved; Datatracker still says I-D Exists, with a Working Group milestone rather than an RFC. Early reviews remain part of the evidence: Operations requested clarification, Security called it ready with issues, and the BGP Directorate's review of revision 18 raised state-machine questions that revision 19 partly addresses. None of this is a verdict about a deployed network.

The motivation is strong. Under the ordinary RFC 5882 relationship, BGP may establish while the associated BFD session is not yet usable. A degraded link can then let BGP advertise routes before BFD tears the session down, generating churn. Strict mode changes the order: the BGP speaker waits for its associated BFD session to reach Up before the finite-state machine advances to the point where the session becomes Established.

The word “wait,” however, hides who agreed, which event releases the gate and how long either side may wait.

Capability 74 is a proposal, not proof of agreement

Revision 19 assigns the BFD Strict-Mode Capability code 74. A supporting speaker with strict mode enabled includes the zero-length capability in its OPEN. BfdStrictNegotiated becomes true only when both local and remote OPEN messages contain it. The common layer is deliberately small: two parties announce the same semantic option before that option changes the BGP FSM.

That is the running-code version of consent. A configured intention is local. A transmitted capability is an offer. A received capability is evidence about the peer's offer. Only the intersection authorizes the negotiated behavior.

Product interfaces can expose more choices. Current Cisco documentation distinguishes a proprietary or unilateral strict mode, a negotiated strict mode, and an override that enforces the gate without peer support. The documentation itself warns that nonstandard strict-mode behavior can keep BGP sessions from coming up. Juniper documents mutual capability advertisement and tells operators to configure peers consistently. These records do not prove a flaw in either product. They prove that a shared phrase is too coarse for an interoperability decision.

The inventory therefore cannot stop at strict=true. It needs the exact command and scope, the semantic mode attached to that command in that release, capability sent, capability received, negotiated result, and whether an override displaced negotiation. If any of those fields is missing, the operator knows only what one configuration intended, not what the pair agreed to do.

The Security Directorate review adds a second limit. Capability negotiation itself depends on the integrity of the BGP OPEN exchange. An on-path actor who can remove the strict-mode capability could silently disable the bilateral gate unless the session has appropriate integrity protection. Conversely, a local override can keep the gate active even when the peer did not announce support. The absence or presence of code 74 is evidence; it is not self-authenticating proof of policy authority.

The gate is a sequence of states, not a green light

Once strict mode is negotiated, revision 19 introduces pending substates for Connect, Active and OpenSent. The local system may have exchanged OPEN messages yet withhold its KEEPALIVE while waiting for local BFD Up. The remote BFD side can reach Up first, allowing the remote BGP speaker to send KEEPALIVE while the local BFD session is still pending. The draft therefore includes OpenSentConfirmedBfdUpPending: a receipt that the remote BGP handshake progressed without pretending the local BFD condition has been met.

This detail carries more truth than a combined dashboard badge. It preserves two observations that can temporarily disagree: the peer has sent KEEPALIVE, and local BFD is not yet Up. Revision 18's BGP Directorate review called out the race because ordinary OpenSent handling could treat that early KEEPALIVE as an FSM error and reset the TCP connection. Revision 19's explicit handling shows why state visibility is not optional diagnostic decoration. It is how operators distinguish a valid wait from a broken handshake.

When BFD goes Down before establishment under negotiated strict mode, the draft sends Cease with the BFD Down subcode, drops TCP, releases BGP resources and returns to Idle. Once Established, BFD Down also deletes routes learned on that connection. RFC 9384 gives the closure a better reason code. It still does not tell the observer whether the cause was a real path failure, asymmetric configuration, timer mismatch, congestion, attack, authentication trouble or implementation behavior.

Running code belongs to compatibility sets

The implementation appendix is unusually revealing. It records Junos 23.2R1 and later as used with compatibility against revision 17; IOS XR 24.3.1 and later as used with capability-negotiation coverage against revision 12; and Nokia 23.7R1 as used against revision 07, with BfdHoldTimer not implemented in the cited release. These are implementation-status statements in a draft, not independent certification or a promise about every platform.

They demonstrate a structural point. “Implemented” is not one versionless fact. A pair can contain running code derived from different points in an evolving state machine. Later text may add an event, clarify a counter, change a pending transition or assign meaning to a timer that one side lacks. The standard document can describe the desired compatibility set; only observed negotiation and behavior can show whether two deployed members actually belong to it.

Timers deepen the distinction. The draft defines a configurable BfdHoldTime, defaulting to 30 seconds, and a BfdHoldTimer for the case where negotiated BGP holdtime is zero. A separate BFD hold-down can require the session to remain Up before BGP enters Established. The two sides configure hold-down locally. The document recommends similar values; it does not negotiate a common number. If the BGP holdtime does not cover BFD initialization and the remote hold-down, one peer may enter Established and wait for KEEPALIVEs that the other is not yet permitted to send.

The feature intended to reduce churn can then manufacture it. One router closes for holdtime expiry. The other reports a different pending condition. Automation sees “BFD strict enabled” on both and assumes symmetry that never existed.

An interoperability receipt must be bilateral and replayable

A useful prechange record has two columns, not one. For each peer, preserve platform, release, exact semantic mode, draft or documented behavior, BGP holdtime, BFD hold time, hold-down or dampening value, authentication mode and expected pending states. Then capture capability 74 as sent and received, BfdStrictNegotiated, BFD discriminators and endpoints, transition times, BGP substate, and final notification reason.

The canary must exercise asymmetry deliberately. Enable negotiation on one side only and confirm ordinary BGP behavior rather than a hidden unilateral wait. Use unequal hold-down values and observe which peer reaches Established first. Delay local BFD while allowing the remote side to progress, then verify OpenSentConfirmedBfdUpPending rather than an unexplained reset. Suppress BFD packets and confirm that the resulting availability failure is visible as evidence, not mislabeled as a generic BGP problem.

Rollback is also bilateral. Removing a local gate does not prove that the peer stopped waiting. Changing strict mode after a session is Established may not affect that running session until restart. A safe rollback specifies the order, confirms both effective modes and capabilities, and preserves the trace that explains why the previous attempt stalled.

Heng Lu's Running-Code Primacy gives the correct hierarchy. The specification defines the smallest shared rule. Implementations create compatibility sets. Operators adopt a behavior by running it, validating it and choosing counterparties that share it. A command name cannot overrule the state of the pair.

BFD strict mode is useful precisely because it can withhold route exchange until a forwarding-failure detector is ready. That power deserves exact semantics. If one router thinks capability 74 is a pact and the other thinks a local checkbox is a veto, strictness has not made the session safer. It has merely hidden the disagreement behind the same word.

Sources