RFC 5882 - Generic Application of Bidirectional Forwarding Detection (BFD)

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

Negative

what Ze owes

The 8 shares marked as a part above are the whole of the 3 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

At a glance

Enrolment

Enrolled: Generic Application of BFD: three MUST-level requirements. RFC5882-4.4-1 (multiple control protocols wanting a BFD session to the same remote/data-protocol MUST share a single BFD session) is met for every configuration in which the clients reach one session, and PARTIALLY met in the two configurations named below, which is what docs/features/rfc-status.md publishes. The registry half is complete: EnsureSession (internal/component/bfd/engine/engine.go:344) is refcounted and path-keyed on api.Key{Peer,Local,Interface,VRF,Mode}, deliberately excluding timers (internal/component/bfd/api/events.go:155-156), and both polarities are proven by TestBFDSharedSessionSameKey (a second same-Key request bumps the refcount to 2 on ONE session, which survives until the last release) and TestBFDDistinctSessionsDifferentKey (two different remotes get two distinct sessions). The key half has two steps. api.SessionRequest.Canonical completes what a client left out from the link table, and clears a multi-hop interface; it never derives a multi-hop local address, so a multi-hop session is keyed on peer, VRF and mode, plus the local address only where a client pinned one (RFC 5883 Section 4.1 makes a pinned address part of the identity). Then engine.Loop.EnsureSession joins a request that left a field unset to the ONE live session it cannot be told apart from (sharedEntryLocked, sharesSession), in either arrival order, which closes the multi-hop cases (no route, an egress interface with no or several addresses, a non-default VRF, no interface backend) and the single-hop cases for a global peer (two links on one subnet, a peer on no connected prefix, no interface backend). TestMultiHopClientsInAVRFShareOneSession proves it through applyPinned and pluginService.EnsureSession, and TestMultiHopClientsToTwoRemoteSystemsGetTwoSessions proves a different remote system still gets its own session. Two configurations still give two sessions, listed under "Multiple Control Protocols (Section 4.4)" on this page: an IPv6 link-local peer whose client names no interface (RFC 4007 Section 6: the address does not name one system), and a client that left a field unset while two or more live sessions to that peer differ in it (it could mean either, so it is not merged by a guess). Each closes when the client names the interface or the local address. RFC5882-4.1-1 (establishment allowed under AdminDown) is {not-applicable}: Ze never gates control-protocol establishment on BFD state -- the BFD client attaches only after the adjacency is up (BGP on StateEstablished, OSPF on Full) and is strictly additive, so no AdminDown session can block establishment. RFC5882-10.1.3-1 (OSPF virtual links MUST use RFC 5883 multihop) is {not-applicable}: Ze does not run BFD on OSPF virtual links (the BFD-for-OSPF client keys on per-interface config; a virtual link is a synthetic backbone link, not a configured interface, so it never gets a session). RFC5882-4.2-1 (no control protocol action on Up to AdminDown, or on Up to Down caused by the remote system's AdminDown) is MET, at the service boundary and at both clients, BGP and OSPF. api.StateChange.RemoteAdminDown carries the neighbor's AdminDown, which RFC 5880 Section 6.8.6 otherwise erases into a local Down with the same diagnostic a peer-signaled Down produces, and both polarities are proven by TestRFC5882RemoteAdminDownIsDistinguished and TestRFC5882NeighborDownIsNotRemoteAdminDown. Those two check what the event SAYS; Peer.runBFDSubscriber (internal/component/bgp/reactor/peer_bfd.go) then reads the field and raises no FSM event for that case, which is the "control protocol action" Section 4.2 names, and TestBFDRemoteAdminDownDoesNotTeardown checks what the client DOES with a control in the same body: the same local state and diagnostic with the neighbor not AdminDown is a path failure and still drops the session. The recording of state and time is deliberately left to run, because the OPEN rail reads it and bfdStrictHolds must still see a session that is not Up. Section 3.2 conditions the obligation on the client having "independent means of liveness detection", and BGP's hold timer is one. The OSPF client, engine.runBFDSubscriber (internal/plugins/ospf/bfd_client.go), takes no action on a local AdminDown or on a Down with RemoteAdminDown set: it neither declares the neighbor down nor releases the session, and TestOSPFBFDAdminDownTakesNoAction and TestOSPFBFDRemoteAdminDownTakesNoAction (internal/plugins/ospf/rfc5882_bfd_client_test.go) check it, the second with a control in the same body (the same Down without the flag still declares the neighbor down). OSPF's RouterDeadInterval is its independent liveness detection. The other SHOULD/SHOULD-NOT clauses (single session per path, hysteresis notify, bring-up connectivity semantics, GR fate-sharing, static-route withdrawal, planned-outage AdminDown, authentication) and the MAY clauses are not gated.

What the public ledger says

Status: Partial

What the ledger says is covered:

What the ledger says remains:

Coverage

Annotated (including scoped evidence) (3): RFC5882-4.1-1, RFC5882-4.4-1, RFC5882-10.1.3-1

Partial proof; remaining gap (subset of annotated; zero whole-requirement credit) (1): RFC5882-4.4-1

Requirements

Gaps and untested MUSTs

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

RFC5882-4.1-1

If the session state on either the local or remote system (if known) is AdminDown, BFD has been administratively disabled, and the establishment of a control protocol adjacency MUST be allowed. (§4.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5882-4.1-1, so no unit is bound to it.

RFC5882-4.4-1

If multiple control protocols wish to establish BFD sessions with the same remote system for the same data protocol, all MUST share a single BFD session. (§4.4)

Scoped tag-claim records only: tested "all MUST share a single BFD session"; gap "with the same remote system"; internal/component/bfd/engine/shared_session.go::sharedEntryLocked is the boundary: Tested covers the BGP request builder, the OSPF request builder and the pinned-session parser reaching one canonical key for one neighbor, two requests on one key sharing one session at refcount 2 that lives until the last release, a multi-hop BGP request with no local address joining the pinned session to the same peer in a VRF at refcount 2, a session opened by an unpinned multi-hop client answering for the unpinned key again after a pinned client leaves so that a client pinned to another local address joins it, and a request to a different remote system getting its own session; Gap is the two configurations in which Ze cannot tell from the request that two clients name the same remote system, so they still get two sessions: an IPv6 link-local peer whose client names no interface (RFC 4007 Section 6: the address alone does not name one system), and a client that left a field unset while two or more live sessions to that peer differ in that field (it could mean either, so it is not merged by a guess); each closes when the client names the interface or the local address; zero whole-requirement credit.

Audit verdict: partial (the tests enforce only the declared tested scope; the whole requirement remains unmet), fresh. Re-judge 2026-10-12 (independent auditor, not the author of the {partial} marker) after the marker was added. RFC 5882 Section 4.4 re-read in rfc/full/rfc5882.txt: 'If multiple control protocols wish to establish BFD sessions with the same remote system for the same data protocol, all MUST share a single BFD session.' Verdict partial. Tested selector: "all MUST share a single BFD session". Gap selector: "with the same remote system". Producer: internal/component/bfd/engine/shared_session.go::sharedEntryLocked (with sharesSession, which it calls). What the tagged bodies check, each with a current verified revert record: TestBFDSharedSessionSameKey (one key, two EnsureSession calls: exactly 1 session at refcount 2, refcount 1 after one release, 0 sessions after the last); TestBFDDistinctSessionsDifferentKey (negative: two peers, 2 sessions each at refcount 1); TestCanonicalCollapsesEveryClientShapeOntoOneKey, TestCanonicalCollapsesMultiHopShapesOntoOneKey, TestPinnedSessionReachesTheSharedKey, TestStrictPeerRequestReachesTheSharedKey, TestOSPFNeighborRequestReachesTheSharedKey (the pinned parser, bfdRequestFor and bfdRequestForNeighbor reach one exact key, asserted by equality, so they share through the exact-key registry); TestMultiHopClientsInAVRFShareOneSession (pinned multi-hop entry with a local address in VRF red, then a BGP request with none through pluginService.EnsureSession: 1 session at refcount 2); TestMultiHopClientsToTwoRemoteSystemsGetTwoSessions (negative: a different peer that matches on every other field gets its own session); TestSharedSessionWidensOnRelease (after a pinned client joins and leaves, entry.joined is the unpinned key again and a client pinned elsewhere gets the same session, 1 session at refcount 2; with the pinned client still attached the other pinned client gets its own, RFC 5883 Section 4.1). Q1 the assertions are session counts and refcounts, which is what the RFC says, not what the code does. Q2 every unit has an observed-red revert record (./le rfc discriminate stem rfc5882: none stale, none unproven). Q3 the engine tests use bare loops and Snapshot, nothing else can cut the count. Q4 not the whole MUST: the two configurations the Gap names still give two sessions by design, read at the producer: sharesSession requires equal interfaces for an IPv6 link-local peer, and sharedEntryLocked answers no session when a request with an unset field matches two or more live sessions (sharedMatch.only). Marker corrected in this re-judge: the earlier Tested reason said the join holds 'in either arrival order' and for 'a request that left a field unset' in general; the tagged bodies check only the multi-hop local-address case, pinned entry first, and no tagged unit drives a single-hop request with an unset interface or local address through sharedEntryLocked, so the reason now names exactly the shapes the bodies check. Not covered by the Gap and not judged here: two clients asking for different hop modes to one peer address get two sessions (sharesSession compares Mode); under the partial rules that obligation stays unproven, not met.

RFC5882-10.1.3-1

If it is desired to use BFD for failure detection of OSPF Virtual Links, the mechanism described in [BFD-MULTI] MUST be used, since OSPF Virtual Links may traverse an arbitrary number of hops. (§10.1.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5882-10.1.3-1, so no unit is bound to it.

RFC5882-4.2-1

If a BFD session transitions from Up state to AdminDown, or the session transitions from Up to Down because the remote system is indicating that the session is in state AdminDown, clients SHOULD NOT take any control protocol action. (§4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-12 (independent auditor). SHIFTED by 6e063fb498 (tests: give ten assert-nothing tests a real assertion), whose hunks sit in untagged sibling tests and the import block. The tagged unit is byte-identical (gate-verified) and no helper it calls changed. Verdict stands. Judge rejudge 2026-09-30 (bfd AdminDown, OSPF client). D-8 fixed: engine.runBFDSubscriber (internal/plugins/ospf/bfd_client.go, shared by OSPFv2 and v3) no longer declares the neighbor down on StateAdminDown or on a Down with RemoteAdminDown; the 4.2 quote sits above the statement. + TestOSPFBFDAdminDownTakesNoAction and + TestOSPFBFDRemoteAdminDownTakesNoAction (Up, change, Up; later Up read, neighbor not down, no release, session_down_total 0; arm 2 carries an in-body control: the same Down without the flag still declares the neighbor down). TestOSPFBFDAdminDownTreatedAsDown, which asserted the defect and carried no tag, replaced (D-15). Judge overlays: the old condition reds both new tests; removing only the RemoteAdminDown guard reds only arm 2. BGP arms and engine +/- unchanged (see previous verdict). Every client with independent liveness (BGP hold timer, OSPF RouterDeadInterval) now meets the SHOULD; static routes have none, so treating AdminDown as Down is correct under Section 3.2. Records: revert ospf runBFDSubscriber observed red for both units.

RFC5882-4.2.2.1-1

when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path in the topology corresponding to the BFD session. (§4.2.2.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-12 (independent auditor). SHIFTED by 6e063fb498 (tests: give ten assert-nothing tests a real assertion), whose hunks sit in untagged sibling tests and the import block. The tagged unit is byte-identical (gate-verified) and no helper it calls changed. Verdict stands. Judge rejudge 2026-09-30 (last five). + reactor TestBFDClient_TeardownOnDown: a non-initial BFD Down StateChange (DiagControlDetectExpired) on an Established peer puts Cease / BFD Down on the wire and moves the session to Idle; asserts the wire, not the opQueue. Producer Peer.runBFDSubscriber -> Session.bfdTeardown (Established arm). MP-BGP is the multi-data-protocol client; ending the session considers the path failed for every family, which is the shared-topology action. {single-polarity: positive} accepted: the obligation is to act on Up->Down and its violation is inaction, which no input presents for refusal; the only no-action boundaries are Up->AdminDown / remote AdminDown (RFC5882-4.2-1, enforced on its own tags, a neighbour row) and the Initial snapshot (not a transition), neither violates this row; no negative existed at HEAD. Record: bfdTeardown revert observed red; author's targeted overlay (Established arm off) red.

RFC5882-4.2.2.1-2

If this cannot be signaled otherwise, a control protocol timeout SHOULD be emulated for the associated neighbor. (§4.2.2.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-12 (independent auditor). SHIFTED by 6e063fb498 (tests: give ten assert-nothing tests a real assertion), whose hunks sit in untagged sibling tests and the import block. The tagged unit is byte-identical (gate-verified) and no helper it calls changed. Verdict stands. Judge rejudge 2026-09-30 (last five). + TestBFDClient_TeardownOnDown: BGP has no per-path announcement short of the session, so Ze emulates the hold-timer outcome: NOTIFICATION then Idle, with RFC 9384 Cease subcode 10 as the code (msg[19]/msg[20] asserted, state polled to Idle). {single-polarity: positive} accepted: action-on-event SHOULD, failure is inaction, no refusal path; the AdminDown no-action case is RFC5882-4.2-1's. Record: bfdTeardown revert observed red.

RFC5882-4.2.2.2-1

when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path in the topology over which BFD is running. (§4.2.2.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-12 (independent auditor). SHIFTED by 6e063fb498 (tests: give ten assert-nothing tests a real assertion), whose hunks sit in untagged sibling tests and the import block. The tagged unit is byte-identical (gate-verified) and no helper it calls changed. Verdict stands. Judge rejudge 2026-09-30 (last five). Earlier weak note said Ze acts on the whole session rather than one topology. Re-read §4.2.2.2: the SHOULD is 'action SHOULD be taken in the control protocol to signal the lack of connectivity for the path in the topology over which BFD is running'; the next sentence 'Generally, this can be done without impacting the connectivity of other topologies' carries no keyword and states feasibility, not an obligation to spare the others; §10.2 asks the EBGP session 'should be torn down in accordance with Section 3.2'. Ending the BGP session signals the loss in the BFD topology, so the author's reading holds. + TestBFDClient_TeardownOnDown (Cease/BFD Down on the wire, Idle). {single-polarity: positive} accepted for the same reason as 4.2.2.1-1. Record: bfdTeardown revert observed red.

RFC5882-10.2-1

BFD authentication SHOULD be used and is strongly encouraged. (§10.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Judge 2026-10-11 (independent re-judge after ef70c19e79 changed TestRFC5882AuthJoinDifferentAuthRefused; judge authored none of it). Row quotes Section 10.2 verbatim (rfc5882.txt 'BFD authentication SHOULD be used and is strongly encouraged.'). Ze's part: let an EBGP-advised BFD session run authenticated, hold it to that, and name the unauthenticated case. Unchanged units re-read against the 2026-09-30 judgement: + SignsItsSession (A bit, Auth Type 4, Len 28, Key ID 7, Up), - MismatchedNeighbor and - UnauthenticatedNeighbor (never Up, no fallback), - WithoutAuthRunsUnauthenticated; reactor + NamesAuthenticatedProfile and the four commit Warn units. Changed unit - AuthJoinDifferentAuthRefused now runs seven cases on both join arms (exact key, shared join): auth->none, none->auth, key id, secret, Auth Type alone (keyed-md5 vs keyed-sha1), keyed-sha1 then meticulous-keyed-sha1, and the Meticulous flag alone (resolved 'secure' auth with Meticulous inverted, sent under no profile because authTypeFromEnum ties each meticulous enum to its own wire Auth Type). Each asserts errors.Is ErrAuthMismatch, peer named, one session, first session's next Control packet keeps its auth or none. The earlier caveat (Type and Meticulous comparisons in engine sameAuth unexercised) is closed: judge re-ran go test -overlay with each comparison deleted; the Type mutant reddens only different_auth_type on both arms, the Meticulous mutant only different_meticulous_flag on both arms; clean run green (-race). Discrimination record for the negative (revert of joinAuthCheck) re-written at unit-sha 15bc152837a4dfa6; it proves the refusal path, the overlay mutants prove the field comparisons. + AuthJoinIdenticalAuthShares unchanged (same auth under two names; none twice). Remaining limit: the Meticulous-alone case is a request no profile can produce, so it guards the comparison rather than a configured path.

Extraction sign-off

Sections

Excluded sentences

The walk over RFC 5882 declined no sentence: every site it found is mapped to a requirement.

Superseded

No document obsoletes RFC 5882, so its obligations are stated where they were written.