Summary

  • RFC 9494 can retain stale BGP routes beyond the ordinary Graceful Restart interval, but only for negotiated address families and a bounded Long-Lived Stale Time. It marks them LLGR_STALE, makes them least preferred and restricts their propagation.
  • Enke Chen co-authored both RFC 4724 and RFC 9494. The later standard does not certify that an old path still works: NO_LLGR, local timer limits, End-of-RIB synchronisation and documented forwarding risks keep continued use conditional and revocable.

The session is gone; the route is not

At the moment a BGP session fails, two facts that normally arrive together split apart. The control relationship is gone. The forwarding state learned before the failure may still carry packets. Immediate withdrawal treats the first fact as decisive. Indefinite retention pretends the second can never change. Long-Lived Graceful Restart occupies the uncomfortable interval between them.

That interval matters because BGP no longer transports only conventional Internet reachability. In tunneled networks, a control process may restart while a separate forwarding system continues to switch packets. BGP also distributes information used for VPN discovery, signalling and traffic policy, where loss of the session does not necessarily mean every installed object became useless at the same instant. Removing all state immediately can turn a repairable control failure into a wider service interruption.

The opposite mistake is more dangerous because it looks calm. A route retained after its source stops speaking is old evidence. It may point to forwarding that survived; it may point into a black hole; it may preserve incompatible choices on different routers. The engineering question is therefore not whether stale state is good or bad. It is how to expose its age, reduce its authority and force its eventual expiry.

From a short grace period to a second state

RFC 4724, published in 2007, introduced the Graceful Restart capability and End-of-RIB marker for BGP. Its authors are Srihari Sangli, Enke Chen, Ramachandra Fernando, John Scudder and Yakov Rekhter. A restarting speaker can preserve forwarding state while sessions and routing information are rebuilt; a receiving speaker can retain routes from that peer and mark them stale.

The ordinary mechanism is deliberately finite. Restart Time occupies 12 bits, giving an encoded ceiling of 4,095 seconds. RFC 4724 suggests a default no greater than the HOLDTIME announced in the BGP OPEN. If the session does not return within the advertised interval, retained routes are removed. A receiver that determines the peer's forwarding is no longer viable may remove them earlier. RFC 8538 later extended the circumstances in which graceful procedures can follow a session failure and added an explicit Hard Reset signal.

Ordinary graceful restart keeps route preference unchanged during that short recovery window. That choice suppresses churn, but it also lets the network continue to prefer information whose control source is temporarily absent. The bargain is tolerable only while the interval is short and the forwarding-state claim remains plausible.

RFC 9494, published in November 2023, creates a distinct Long-Lived Graceful Restart state. James Uttaro, Enke Chen, Bruno Decraene and John G. Scudder are the named authors. This is collective IETF work; Chen's role is a documented contribution to both the base mechanism and its long-lived extension, not a claim of sole invention.

A lease on old evidence

LLGR capability code 71 carries one or more tuples of AFI, SAFI, flags and Long-Lived Stale Time. Each address-family pair can receive a different interval. There is no suggested LLST default because the relevant failure modes and data differ too much. The receiving network may impose a local upper bound, lower bound or both, and may reduce the time offered by its peer.

The capability cannot stand alone. A speaker advertising LLGR must also advertise ordinary Graceful Restart; otherwise the peer ignores LLGR. The two states can then run serially. During conventional GR, stale routes keep their preference. When that period ends, the LLGR interval begins and the routes are explicitly degraded. An operator that wants no conventional phase can advertise or configure a zero Restart Time.

At the LLGR boundary, the helper starts a timer for each negotiated AFI/SAFI and attaches the well-known community LLGR_STALE, value 0xFFFF0006. The marked route must rank below every route that is not least preferred. Only when all available choices are least preferred does normal tie-breaking resume.

This is not cosmetic labelling. A fresh alternative should displace a long-lived stale route even when ordinary BGP attributes would have favoured the old path. But if no fresh route exists, the stale route can remain best and continue to forward. The mechanism therefore buys an option, not an assurance: use the old path as a last resort until better evidence appears or the clock runs out.

The marker also constrains propagation. A speaker should not advertise an LLGR_STALE route to a neighbour that did not advertise LLGR capability, apart from a tightly limited optional procedure for internal BGP or confederation peers. When the route is propagated, the marker must not be removed. Degradation has to travel with the object; otherwise the next receiver could mistake inherited doubt for ordinary reachability.

Refusal, synchronisation and expiry

RFC 9494 supplies more than a way to say “keep this.” The well-known community NO_LLGR, value 0xFFFF0007, says the opposite. A route carrying it must not be retained under LLGR. The sender can mark information whose failure semantics make prolonged survival unacceptable, and receiver policy can apply the same refusal locally.

The timer is also resistant to convenient amnesia. A re-established TCP session does not by itself make the retained information fresh or reset its lifetime. For an address family, synchronisation is completed by the relevant End-of-RIB marker or by the selection-deferral boundary. If LLST expires before that process refreshes a route, the helper removes the unrefreshed state. A second restart cannot simply grant the old evidence a new full life.

Capability changes terminate the exception as well. If the returning peer no longer advertises the required GR and LLGR capabilities, omits the address family or fails to assert retained forwarding state where required, the helper removes the associated stale routes. The system distinguishes “the session came back” from “the prior forwarding claim was renewed.”

RFC 9494's worked example makes the sequence concrete. A route reflector offers a one-second ordinary Restart Time and an LLST of 3,600 seconds. After the first second, its routes receive LLGR_STALE and lose preference. If no alternative exists, the border router still uses and exports them to an LLGR-capable external peer. At expiry, it deletes the routes and sends withdrawals. If the session resynchronises after 180 seconds, refreshed routes lose the stale marker. If the external peer never advertised the capability, the border router withdraws from that peer at the start of LLGR instead.

Continuity can become a loop

The caution section is central, not an appendix. A stale more-specific prefix can still win longest-prefix forwarding even when a fresh less-specific route exists. Making the stale BGP path least preferred does not change that lookup rule. The result can be persistent packet loss for the covered destination.

Depreference can also make routers disagree. RFC 9494 illustrates an internal topology where one router abandons an old exit after its route becomes least preferred while another router continues to prefer that same exit. Packets then alternate between the two. Ordinary GR can expose similar faults, but a long stale interval makes the consequence last much longer.

The document's cardinal operational rule is direct: LLGR is not recommended when the affected routes drive hop-by-hop forwarding inside an autonomous system. Tunneled forwarding, or BGP information used more like configuration than a conventional next hop, reduces some of that risk. It does not justify casual enablement. Forwarding-state bits must still represent whether state survived, and timer values must reflect the actual failure domain.

VPNs add a less visible hazard. A label from a withdrawn VPN route may later be assigned to a different context. If the old route remains stale long enough, traffic can arrive carrying a label whose meaning changed. RFC 9494 advises making the minimum label-reuse delay greater than the maximum LLST before enabling the feature for a VPN address family. Continuity without coordinated resource lifetime can cross a security boundary.

A narrow shared rule, a local risk decision

Lu Heng's Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption offers a useful later frame. The common layer can remain precise and small: capability negotiation, per-family scope, a degradation marker, a refusal marker, least-preferred selection and deterministic expiry. The receiving operator keeps the decisions that depend on its network: whether an address family is eligible, how much of a remote LLST to accept, whether forwarding is tunneled, how labels are reused and which events end retention early.

That separation prevents two errors. A shared protocol does not become a central command to keep stale routes. Local discretion does not become permission to erase the marker or misrepresent old evidence as fresh. Interoperability defines the state; the party carrying the forwarding risk decides whether to use it.

Running-Code Primacy makes the evidence test stricter. A configured feature and an Established session prove little. Operators need the negotiated AFI/SAFI tuples, the advertised and locally capped timers, counts of routes entering and leaving LLGR, selected-path changes, export withdrawals, End-of-RIB progress, forwarding loss, loop indicators and final cleanup. These are Sofia Ren's applications of Lu Heng's later principles, not positions attributed to Chen or the RFC authors.

The most honest feature of RFC 9494 is its name for the route. It remains stale. The standard does not replace truth with continuity; it makes the temporary use of old evidence visible, subordinate and finite. Chen's place in that documentary chain matters because the mechanism gives operators room to survive a failed session without granting the past an unlimited right to govern the present.

Sources