Summary

  • In RFC 9815's sparse-peering model, BGP sessions carry Link NLRIs but do not necessarily traverse or test the fabric links those records describe. Discovery and liveness belong to an external mechanism at the edge.
  • A usable SPF edge needs more than a fresh advertisement: scoped origin, status, optional EoR readiness, a matching reverse Link NLRI, valid descriptors and metrics, local computation, installation and data-plane observation remain separate receipts.
  • The control saving—fewer sessions and fewer replicated copies—is real only if the operator preserves that chain. A route reflector or controller may distribute a claim; it cannot acquire authority over the physical fact by repeating it.

Every dashboard was green

Consider the incident review that should make a network leader uncomfortable. Both route-reflector sessions remained Established. TCP authentication succeeded. The latest Link NLRI was present in the reflector's table. Sequence numbers advanced. SPF ran on schedule. A route appeared in the RIB. Yet one direction of the represented leaf-to-spine link no longer carried traffic.

Nothing in that sequence is paradoxical. Each indicator answered a different question. The BGP session proved that two control-plane endpoints could exchange BGP messages over its own path. Authentication strengthened the identity of the peer on that session. The sequence number ordered versions of one topology record. SPF computed a result from the records admitted to its graph. The RIB showed what the router intended to install. None of those observations was a direct test of the failed fabric direction.

The mistake would be organizational, not mathematical: management allowed the distributor's green state to inherit the authority of the witness it never was.

RFC 9815, published on the Standards Track in July 2025, creates BGP-LS-SPF SAFI 80. It keeps the BGP finite-state machine, messages, transport behavior and much of the existing error framework, while replacing the relevant decision process with shortest-path computation over BGP-LS-style Node, Link and Prefix NLRIs. Its applicability companion, RFC 9816, explains why a dense Clos fabric need not carry a BGP session on every physical link.

That is the attraction. It is also the exact point at which evidence custody must be redesigned.

Two graphs, not one

A data-centre fabric has a forwarding graph: interfaces, cables, link aggregates and silicon paths that can carry packets. BGP-LS-SPF has a distribution graph: the sessions over which topology records move. In the simplest RFC 9815 model, an EBGP single-hop session exists on each point-to-point fabric connection. There, the graphs are close to congruent. Establishing the session and negotiating the BGP-LS-SPF address family can make the corresponding link available from the protocol's perspective; losing the session withdraws that link's NLRI.

The other models deliberately separate them. Two directly connected routers may peer between loopbacks through one session even when several physical connections join them. In a sparse route-reflector or controller topology, a fabric node may peer only with a small set of reflectors or controllers. RFC 9816 even describes multi-hop sessions to two or more controllers. The reduction can be large in a fabric with 32-way or 64-way ECMP.

Once the graphs separate, the BGP session no longer supplies per-link discovery or liveness. RFC 9815 puts those functions outside BGP and recommends BFD in the directly connected and sparse models. BFD is useful because it can test the path between forwarding engines and is not tied to the routing engine's fate. But “BFD Up” still needs a scope. Which interface or path does the session bind to? Which address family? Which timers? Which direction and return path? A healthy BFD session over one route must not be silently reused as evidence for every parallel edge between the same nodes.

The minimum operational inventory therefore contains both graphs and the join between them. A record should identify the fabric edge, its local observation method, the node entitled to originate it, the BGP sessions that may distribute it, and the routers that consume it. A line on a topology screen without that chain is a symbol with borrowed authority.

The originator owns a bounded claim

RFC 9815 identifies each BGP-LS-SPF NLRI with a local node descriptor. Node and Link NLRIs use the direct-protocol identifier, and every router in the domain unconditionally advertises a Node NLRI. The topology record is not supposed to be a free-floating fact that any reflector can invent. A Link NLRI is a directional claim rooted at its local node.

That direction matters. A node can report its output-side metric and its view of the remote endpoint. The remote node supplies a separate record for the opposite direction. A reflector can carry both. It does not thereby become the observer of either.

Freshness has its own field. Every BGP-LS-SPF NLRI carries a mandatory 64-bit sequence number that must increase for each self-originated version and survive cold restarts through available mechanisms. Receivers normally select the highest sequence number, with special rules allowing directly connected peers to replace stale self-originated state after a restart. Changed NLRIs may be readvertised before the receiving router performs its own SPF calculation.

That design accelerates distribution, but it makes one sentence essential: newest means latest in the originator's version history, not most accurate in the physical world. A faulty detector, wrong interface binding or compromised authorized peer can produce a perfectly fresh false claim. Sequence ordering prevents an older copy from winning; it cannot audit the observation that produced the new copy.

Duplicate origination is therefore a control event. RFC 9815 says instances of the same NLRI originated by multiple BGP speakers can indicate a configuration error or masquerading attack. A later copy is not just “more redundancy” if its claimed origin is wrong. The receipt needs origin node, peer path, sequence, content fingerprint and the local rule that selected it.

EoR is a readiness gate, not a pulse test

End-of-RIB is easily given too much meaning because it arrives at a consequential moment. RFC 9815 permits an operator to require the BGP-LS-SPF EoR marker from a peer before advertising the Link NLRI associated with that peer. When such configuration is supported, it must be consistent across the domain; when enabled, the default behavior is to wait indefinitely, although an operator may configure a maximum wait.

The risk being controlled is incomplete forwarding state. If one side advertises an adjacency before its peer has completed the initial transfer needed to compute and install routes, traffic can enter a node that is not ready to send it onward. RFC 9815 explicitly warns that inconsistent EoR configuration can produce transient micro-loops and drops.

In a controller topology, the document gives a stronger example: the controller may wait for EoR from both peers and Link NLRIs for the interconnecting link from both peers before releasing the link. This is an excellent commissioning pattern because it makes the join visible. It is still not a universal requirement, and it does not make EoR a liveness detector. EoR says that a peer reached the end of an initial address-family transfer under the relevant session state. It does not say the represented edge carried a probe before or after that marker.

An audit table should therefore avoid one “ready” column. Keep at least: distribution session established, address-family negotiated, initial RIB transfer complete, local link detector acceptable, local Link NLRI current, remote Link NLRI current, reciprocal match accepted, and forwarding verified. A single green badge collapses precisely the boundaries the protocol preserves.

A link enters SPF only as a reciprocal pair

The shortest-path calculation does not accept every one-sided arrow. For each current Link NLRI, the router searches the remote node's Link NLRIs for a record that points back to the current node. Numbered interfaces match by crossing local interface and remote neighbor addresses. The edge becomes usable only when the reverse record and the status rules support bidirectional connectivity.

Unnumbered links make the identity problem harder. RFC 9815 uses Link Local/Remote Identifiers and an Address Family Link Descriptor. If the address-family descriptor is absent, an unnumbered link is not used in either IPv4 or IPv6 SPF. If the remote identifier is unknown, zero is a wildcard. That permits operation but weakens precision: with parallel unnumbered links, the two speakers may temporarily disagree about which particular link is operational. The management section consequently recommends discovering or configuring remote identifiers when parallel unnumbered links exist.

This reciprocal test is important enough that the published wording needed correction. Verified Erratum 8835 notes that the original Section 6.3 repeated the same comparison twice. The corrected condition is two-sided: Current-Link Remote must match Remote-Link Local, and Current-Link Local must match Remote-Link Remote. The RFC Editor's inline-errata rendering incorporates that correction for information; the normative RFC and errata record remain the sources to cite.

The erratum is not proof that a product implemented the duplicated sentence or that traffic failed. It is evidence of why interface identity cannot be reduced to “the two nodes agree.” On parallel edges, the relevant question is whether they agree about the same directional pair. A wildcard can support a minimal interoperable start, but the operator should know exactly which ambiguity it has accepted.

The second verified erratum, EID 8836, corrects the RFC 8405 back-off parameter name from TIME_TO_LEARN to TIME_TO_LEARN_INTERVAL. It is an editorial terminology repair. Treating both errata as equivalent “bugs” would flatten a substantive matching correction and a naming correction into one misleading risk score.

Down must outrun stale copies

Sparse distribution means multiple copies of a topology record can remain in different places. Ordinary withdrawal waits until the last selected copy disappears. That can leave a failed link apparently usable for longer than the local detector intended.

RFC 9815 therefore recommends that the originator first advertise a newer version of the Link NLRI with SPF Status set to unreachable, then withdraw it after a configurable interval. The suggested LinkStatusDownAdvertise default is two seconds. If the link returns during that interval, the originator must advertise an even newer version without the down status. The status acts at the next SPF calculation.

This is a clever separation of ordering and deletion. A new explicit negative state can defeat older positive replicas before every copy is withdrawn. It does not promise two-second restoration, nor does it prove why the detector changed state. Operators need timestamps for detection, NLRI origination, receipt at each reflector and consumer, SPF scheduling, SPF start and finish, RIB update and packet recovery. Without those points, “fast convergence” is a product adjective rather than a measured chain.

Node failure exposes another subtlety. If the fastest distribution path disappears with the failed node, older NLRIs may remain via other paths. RFC 9815 relies on adjacent nodes advertising newer down link state and on the bidirectional-connectivity test failing. The corrective authority sits at the surviving edges, not solely at a central copy of the dead node's history.

Some records may travel but must not compute

Distribution and computation eligibility remain separate even under error handling. A malformed status or address-family descriptor is treated as withdrawn. An NLRI that arrives without the BGP-LS Attribute—possibly because attribute-discard handling removed it—may be preserved and propagated, but it must not be returned for SPF use. A monitoring tool that counts received records without reporting “eligible for LSDB lookup” can therefore overstate the graph available to the algorithm.

If two BGP-LS-SPF speakers' link-state databases lose synchronization, RFC 9815 requires a session reset unless another resynchronization method is used. It defines the Loss of LSDB Synchronization notification but leaves detection mechanisms outside scope. Again, a standard action exists only after a local system produces the evidence that authorizes it.

Authentication also stops at a boundary. RFC 9815 recommends TCP-AO to reduce the risk of masquerading peers. It then warns that a compromised authorized peer can advertise modified Node, Link or Prefix NLRIs, cause misrouting, repeat origination or trigger excessive SPF work. Authenticating the courier does not validate the parcel's account of a physical edge.

The right response is not to distrust BGP-LS-SPF. It is to state what each protection buys. TCP-AO protects the session-peer relationship. Descriptor validation protects syntax and identity joins. Sequence numbers protect ordering. Reciprocal records protect graph symmetry. EoR protects a readiness boundary. SPF logs protect computational traceability. None alone certifies delivery.

The minimum test before session reduction

Build a small fabric with at least one parallel unnumbered pair and a distribution topology that is not congruent with the fabric. Capture a baseline in which both directions are live, both endpoint records match, EoR gates are satisfied, every consumer holds the same eligible graph, and probes traverse each intended ECMP member.

Then break one direction without taking down the route-reflector session. Record which detector changes first. Verify that only the entitled originator advances the correct Link NLRI, that the down status reaches every consumer ahead of stale positive copies, that reverse-link admission fails, and that the affected next hop leaves the forwarding set. Restore the edge and prove that a still newer record removes the down status without resurrecting an old identity.

Repeat with a missing address-family descriptor, swapped local/remote identifiers, remote identifier zero on parallel links, divergent metrics, delayed EoR, malformed status, attribute discard, a cold restart that loses local sequence state, duplicate origination, an LSDB mismatch and failure of one reflector. Test policy filters as well: RFC 9816 warns that filtering different NLRIs to different routers produces different local routing tables and can create unreachable destinations or loops.

For each case, retain a joined evidence row: edge identity; detector session and scope; raw event time; origin node; NLRI descriptor and attribute fingerprints; sequence and status; sending and receiving peer; EoR state; SPF eligibility reason; LSDB generation; scheduled/start/end time; Local-RIB diff; GLOBAL-RIB or FIB diff; probes from defined ingress points; alarm; operator decision; rollback result. That is the smallest useful account of “the link was removed.”

This is Running-Code Primacy without mythology. The specification supplies a testable coordination language. Configuration expresses local choices. Logs expose executed transitions. Probes reveal a slice of forwarding reality. None should be promoted into the next layer without a receipt.

What RFC 9815 does not establish

The sources do not show a named operator deployment, implementation matrix, vendor default, measured convergence distribution, outage reduction or security incident. RFC 9816's statements about efficiency and convergence are design and applicability claims. They are not a benchmark.

Nor is sparse peering a universally superior topology. Its value depends on flooding redundancy, controller reachability, detector scope, policy consistency, implementation quality and operational ability to diagnose two graphs instead of one. The standards deliberately leave several choices local: deployment model, some liveness mechanisms, controller constraints, SPF scheduling, timeout values and LSDB mismatch detection.

That restraint reflects Minimum Initial Specification. A common layer can define the SAFI, record identities, sequence, status, reciprocal admission and error behavior while leaving topology and operating policy to adopters. The price of local freedom is local proof.

Sources

  1. RFC 9815 Datatracker record
  2. RFC 9815 history
  3. RFC 9815 references
  4. RFC 9815 referenced-by record
  5. RFC 9815 information page
  6. RFC 9815: BGP-LS SPF Routing
  7. RFC 9815 errata
  8. RFC 9815 informative inline-errata rendering
  9. RFC 9816 information page
  10. RFC 9816: Usage and Applicability of BGP-LS SPF
  11. RFC 4271: BGP-4
  12. RFC 9552: BGP-LS
  13. RFC 5880: BFD
  14. RFC 4724: BGP Graceful Restart and EoR
  15. RFC 8405: SPF Back-Off Delay
  16. RFC 7606: Revised BGP UPDATE Error Handling
  17. RFC 5925: TCP-AO
  18. Heng Lu: Running-Code Primacy
  19. Heng Lu: Minimum Initial Specification
  20. Heng Lu: On Reality Layers