Summary

  • In RFC 9815, a BGP-LS-SPF Node NLRI is advertised unconditionally, while its Node SPF Status TLV is optional. If a previously advertised status 2 disappears from a later Node NLRI, the old status is implicitly withdrawn and the node returns to the default state of being up and available for transit. That is a restoration of eligibility, not evidence that SPF, installed forwarding state or any particular flow will actually use the node.
  • Reachability and non-transit behavior are separate acceptance facts. Status 2 allows the node and its prefixes to remain reachable while SPF skips expansion of that node’s outgoing Link NLRIs for transit. Operations therefore need one check for positive service reachability and another, bounded check for preservation of the negative non-transit constraint.

The cold restart that changes a negative fact

Consider an explicitly hypothetical cold restart. A server hosting an application, or a controller resident on a server, returns to service. Its service prefixes are reachable. Its Node NLRI is again present. Yet the Node SPF Status TLV that previously carried value 2 is absent.

Nothing in that sequence proves an outage, and nothing proves that traffic has started crossing the host. But the protocol meaning has changed. RFC 9815 §5.2.1.1 says every router in the BGP SPF routing domain must advertise its Node NLRI unconditionally. The same section defines the optional Node SPF Status TLV, type 1184, and says that when the TLV is absent the node is considered up and available for transit. If a Node NLRI arrives without the TLV after status information was previously received, that earlier status is considered implicitly withdrawn.

The result is precise but easy to overstate. Omission restores eligibility for transit in the SPF model. It does not establish that the node will appear on any shortest path, that a computed route will be installed, or that tested packets will traverse it. Those outcomes depend on the surrounding topology, metrics, the actual SPF computation, the route-installation state and the flows chosen for observation. The right operational reading is therefore: “the explicit non-transit constraint is no longer present,” not “the node is now carrying transit.”

That distinction creates a governance problem inside configuration automation. Who owns preservation of a negative constraint that can disappear without making the node unreachable? The team responsible for intent may believe “this host must never be transit” is still true; the system that generates configuration may emit no status; the restarted implementation may advertise a perfectly valid Node NLRI; and basic reachability tests may all pass. The technical state can be valid while the intended restriction has silently ceased to be represented.

Reachable is not the same as transit-capable

RFC 9815 §6.3 makes the separation visible in the SPF procedure. Step 3 discards a node whose status is 1, meaning unreachable with respect to BGP SPF. Step 4 then considers prefixes associated with the current reachable node. Step 5 considers that node’s outgoing Link NLRIs, but if the current node carries status 2, SPF does not expand those links for transit.

That is why a status-2 host can remain reachable for its own prefixes without serving as an intermediate hop. Positive reachability is one fact: can the routing system and data path reach the service destination? Bounded non-transit behavior is another: for the defined topology state and tested flows, is the node excluded from carrying traffic between other endpoints?

The second fact is negative and needs careful language. A successful set of tests cannot prove that no conceivable packet, at any later time, under any topology or metric change, will ever traverse the node. It can show only that specified flows did not use it under specified conditions and observation points. Protocol-state inspection can add stronger evidence about the intended SPF treatment, but it still should not be confused with an unlimited claim about all future forwarding.

The status value is a small field with four different meanings

The Node SPF Status registry has sharply different classes. Value 1 means the node is unreachable with respect to BGP SPF. Value 2 means it does not support transit traffic with respect to BGP SPF. Values 3 through 254 are unassigned; RFC 9815 says an unknown value SHOULD be advertised onward, MUST be ignored by SPF, and MAY be logged. Values 0 and 255 are reserved. If either reserved value appears in the Node SPF Status TLV, the TLV is malformed and RFC 9815 §7.1 requires the corresponding Node NLRI to be handled as treat-as-withdraw.

The registries matter because they prevent operational shorthand from mutating into protocol meaning. RFC 9815 §8.2 and the IANA BGP-LS Parameters registry place 1184 | SPF Status in the BGP-LS NLRI and Attribute TLV space. RFC 9815 §8.3 and IANA’s separate BGP SPF registry give the Node values: 0 reserved, 1 unreachable, 2 non-transit, 3-254 unassigned, 255 reserved.

That allocation does not make value 2 a general-purpose “maintenance” or “overload” signal. The binding semantics are narrower: non-transit with respect to BGP SPF.

RFC 9816 narrows the use case rather than broadening it

RFC 9816 is the usage and applicability companion to the Standards Track RFC 9815. Its §7 gives two non-transit examples: a server that needs to expose application services without acting as a router, and a controller resident on a server that must remain directly reachable without carrying transit traffic. The section does not define status 2 as a maintenance or overload condition, and the examples do not establish that anyone has deployed them in a particular network.

This is useful discipline for change reviews. A team may have perfectly reasonable local reasons to set or clear status 2, but those reasons should not be projected back into the RFC as if the standard had assigned them. The protocol field states a routing property. Local automation, maintenance procedures and change controls decide why an operator wants that property.

Topology visibility and forwarding evidence answer different questions

RFC 9816 §5.5.2, not RFC 9815, explains that BGP-LS-SPF advertisements can be used to construct topology for management, troubleshooting and consistency checking. It adds that a central controller or management tool used for that visibility could also be used for data-path verification, while leaving the exact algorithms and applications out of scope.

The operational inference is important: seeing the intended topology and seeing actual forwarding are complementary, not interchangeable. After a restart, operators can verify that status 2 is present in the advertised Node state and separately test selected flows. If status 2 is absent, the protocol-level negative constraint has already changed even if every sampled flow still happens to avoid the node. Conversely, a correctly advertised status 2 is not a substitute for any implementation-specific forwarding checks that an operator considers necessary.

That is the acceptance split worth preserving: can I still reach the host and its services? and has the bounded non-transit condition remained in force? Passing the first does not answer the second.