Summary

  • RFC 3277 identifies a specific IS-IS reboot race: neighbours can advertise new adjacencies to a returning router while the network still holds that router’s old LSP, allowing SPF to compose records from two different incarnations.
  • The overload bit can withhold transit while the router rebuilds BGP reachability, but clearing it needs stronger evidence than elapsed time, a prefix count or a healthy adjacency; route identity, FIB installation and packet delivery remain later receipts.

The line between “down” and “up” is too coarse for a transit router.

Suppose RtrB carried the shortest path between RtrA and an external destination behind RtrD. RtrB failed, so RtrA moved traffic across RtrC. That path had already converged and its forwarding table included the external reachability learned by BGP. RtrB then rebooted. Its IS-IS adjacencies returned quickly, and the topology again made RtrB look like the shortest path. Its BGP session and external routes did not return at the same speed. Packets moved back to RtrB and died there.

That is the deterministic blackhole in RFC 3277, published in April 2002 as an Informational RFC. The memo did not add a new protocol field. It described an operational use of the existing IS-IS LSP Overload bit: keep the returning router’s locally connected networks reachable, but prevent other routers from calculating transit paths through it until associated routing state such as BGP has had time to converge.

The interesting failure is not merely that BGP can be slower than an IGP. It is how the network can authorize the premature path before the returning router has published its current state.

A fresh edge can revive a stale node

When RtrB disappears, its old LSP does not necessarily vanish immediately from every other IS-IS database. When it returns, its neighbours establish adjacencies and originate new LSPs describing those links. Those neighbour records are fresh. Yet RtrB may still be synchronizing and may not have originated a replacement LSP carrying the overload bit.

Other routers now possess enough material to run SPF: new neighbour-to-RtrB edges and the old RtrB node record. The graph is syntactically usable. Each record may be authentic within the protocol. The graph is nevertheless temporally incoherent. It joins an adjacency from the new process life to a self-description from the previous one.

RFC 3277 recommends an ordering rule. Each time the returning router establishes an adjacency, it should update and flood its own LSP immediately, before beginning database synchronization. The purpose is not cosmetic freshness. It is to ensure that the overload state reaches the domain before a neighbour’s new adjacency makes the old LSP actionable again.

This is an evidence problem with routing consequences. “Adjacency is UP” proves a current relationship. “LSP is still valid” proves a retained control record. Neither proves that both belong to one coherent router incarnation. A topology engine that combines them is making an identity decision, whether or not the operator’s interface names it that way.

The receipt chain therefore needs more than timestamps. It needs boot or restart identity, LSP origin and sequence, adjacency establishment order, flood receipt, SPF input generation and the exact route decision that followed. A newer wall-clock observation of an old object does not make the object current.

Overload is a transit instruction, not a health certificate

With the overload bit set, other routers should continue using the established alternative path rather than selecting the returning router for transit. The returning router can still advertise its loopback and other locally connected prefixes. That exception matters because iBGP sessions in service-provider networks commonly use loopback addresses. Flooding an empty LSP would hide the very address needed to reconstruct BGP reachability.

The design therefore expresses an intermediate state: reachable as a node, not yet eligible as a corridor.

That state resembles the broad intuition behind OSPF Stub Router Advertisement, but it is not a second article about RFC 3137. The OSPF mechanism raises link costs so transit becomes undesirable, with special behavior when no alternative exists. RFC 3277’s selected mechanism removes the overloaded IS-IS router from transit calculation. This Article’s central object is narrower still: the old self-LSP that can be reactivated by a new neighbour advertisement before the overload bit arrives.

The overload bit does not say why the router is withheld. It does not enumerate missing BGP routes, certify preserved forwarding state or prove that hardware is ready. It conveys one operational instruction to the rest of the IS-IS domain: do not use this node for transit now.

Clearing the bit reverses that instruction. It makes the router eligible in subsequent SPF calculations. It does not certify all the facts an operator may wish to infer from that eligibility.

“N prefixes” is a count, not the required route set

RFC 3277 leaves the trigger policy to the implementation. It offers examples: wait a configured number of seconds after boot, or wait until a configured number of BGP prefixes appears in the Loc-RIB.

Both are operationally useful approximations. Neither is a proof by itself.

A timer records duration. It cannot show whether a slow peer established, whether the route reflector delivered the expected address families, whether policy rejected an important route or whether next-hop resolution succeeded. A previously adequate interval can become inadequate after table growth, control-plane contention or a change in peer topology.

A prefix count records cardinality. Ten thousand routes before failure and ten thousand routes after restart need not be the same ten thousand routes. A default route may be absent while thousands of less relevant entries satisfy the threshold. A route may exist in the Loc-RIB while its next hop is unresolved. It may be selected but not installed in the FIB. A FIB entry may exist while the relevant interface or label operation is not usable.

This does not make timers and counts worthless. It makes their authority bounded. The operator can use them as gates only after defining what false readiness costs, what route classes are indispensable, how the threshold was derived and what later checks can revoke the decision.

A stronger readiness receipt might include the expected BGP peer set, address families, route-set or digest identity, required default and infrastructure prefixes, next-hop resolution, RIB-to-FIB installation status and a controlled probe across the intended transit path. Different networks will choose different evidence. The common mistake is to let one easy metric inherit all those meanings.

The alternative path is part of the safety case

The overload technique is conservative only when another usable path exists. RFC 3277 is explicit about the edge: because no transit path is calculated through an overloaded router, setting the bit can eliminate the only feasible route to downstream routers. A mechanism that prevents blackholing in a redundant topology can reduce availability in a non-redundant one.

Nor does the presence of an alternative in the link-state graph prove that it can safely absorb traffic. Its capacity, forwarding state, policy, failure independence and current congestion are separate questions. The alternate RtrC path in the RFC’s example is assumed to have a complete FIB because it remained available. An operator must verify that assumption in the actual network.

Mixed interpretation is another boundary. RFC 3277 warns that if systems in the domain do not implement the overload behavior correctly, forwarding loops can occur. An authenticated LSP proves who originated a bit under the routing security model; it does not prove that every implementation will interpret, calculate and install the intended result.

The deployment decision therefore has two sides. The returning router needs a credible condition for clearing overload. The surrounding domain needs verified support and a viable path for the period in which the router remains excluded.

Later restart signaling made the incarnation problem explicit

Standards work did not stop with the 2002 operational technique. RFC 5306 defined IS-IS restart signaling in 2008, and RFC 8706 replaced it in 2020.

RFC 8706 distinguishes restart from start. A restarting router maintains forwarding-plane state while its control function resumes. A starting router has not preserved forwarding state. Confusing those conditions is dangerous: planned-restart signaling without maintained forwarding state can sustain a topology claim that the data plane cannot honor.

For a starting router, the later RFC directly names the previous-incarnation problem. Copies of its older LSPs may remain in the network and can appear newer than the first LSPs generated after sequence numbers are reinitialized. Those retained records can cause temporary blackholes until newer replacements propagate.

The SA flag in the Restart TLV changes the ordering. A starting router can ask its neighbours to suppress advertisement of their adjacency to it. Until they receive an IIH with SA clear, neighbours must withhold that adjacency and must not use it in their own SPF calculation. Instead of racing to flood an overloaded self-LSP before the new edge spreads, the protocol can hold the edge back until the new incarnation has caught up.

This evolution is analytically useful. It confirms that “UP” is not one indivisible state. Adjacency liveness, database synchronization, self-record freshness, preserved forwarding, BGP recovery and transit admission need different evidence. RFC 8706 does not prove that every deployed implementation supports the mechanism, that every operator enables it or that all mixed-version behavior is safe.

Fast recovery mechanisms do not collapse the receipts

BGP Graceful Restart can retain forwarding state while a peer’s control plane recovers. IP Fast Reroute can provide local protection after a detected failure. Ordered FIB convergence can sequence updates to reduce transient loops and blackholes after topology change. Each mechanism addresses a real part of recovery.

None lets an operator infer that a new IS-IS adjacency belongs with a retained self-LSP. None makes a prefix count identify the missing routes. None turns an overload-clear LSP into proof that hardware installed the complete forwarding state or that traffic reached its destination.

The mechanisms may be composed, but their receipts should not be. A BGP stale-route marker, an IS-IS Restart TLV, an overload bit, a completed SPF run, a RIB row, a FIB readback and a packet probe answer different questions. A resilient design connects them without pretending that the earliest positive signal proves the final outcome.

A graph needs temporal integrity as well as correct edges

The Heng Lu doctrine in the disclosed source packet treats protocol objects, local policy, running state and outcomes as separate authority layers. RFC 3277 offers a concise routing example of why. Every input in an SPF graph can be correctly encoded and legitimately originated while the composed graph still crosses a forbidden time boundary.

The minimal interoperable signal should remain minimal. An overload bit can instruct peers not to calculate transit through a node. It should not be presented as a universal diagnosis or a certificate of route completeness. Local operators retain the harder decision: what evidence makes transit safe to restore, what uncertainty remains, who can approve the threshold and how quickly the network can return to overload if observation contradicts the gate.

The durable operational record is a chain: process incarnation; forwarding-state custody; adjacency establishment; current self-LSP origination; network receipt; overload interpretation; synchronized IS-IS view; BGP peer and required-route-set state; next-hop resolution; FIB installation; controlled transit admission; packet observation; service result; rollback.

The router is not ready because it has returned. It is ready for a particular role only when the evidence required for that role belongs to the same current life.

Uncertainty

This Article analyzes protocol text, not a named outage or a current implementation survey. RFC 3277’s statement that the technique had been used in large networks does not identify those networks or establish present adoption. Support for RFC 8706, trigger policy, mixed implementations, table scale, hardware programming and alternative-path capacity must be verified in the specific environment. No packet-loss quantity or performance gain is claimed here.

Sources