Long-Lived Graceful Restart for BGP
updates
- rfc-6368 — Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
Extracted elements (27)
LLGR depreferences stale routes (treats them as least preferred), whereas conventional GR leaves route preference unchanged. This design choice reflects the expectation that LLGR stale routes may be retained for a potentially unbounded period, making it preferable to advertise new state and use stale information only as a last resort.
LLGR was motivated by two trends: widespread tunneled forwarding (e.g., MPLS) that reduces forwarding-loop risk from stale state, and BGP's growing use for non-forwarding data such as auto-discovery (VPLS) and filter programming (FLOWSPEC), where BGP data resembles configuration and does not need to be rapidly removed.
Requiring the GR Capability alongside the LLGR Capability allows LLGR to reuse base GR mechanisms—EoR origination, collection, processing, finite-state-machine modifications, and connection-reset logic—without duplicating their specification. The GR phase can effectively be skipped by advertising a Restart Time of zero.
For incremental deployment, stale routes MAY be advertised to IBGP or Confederation neighbors that have not advertised the LLGR Capability, provided the NO_EXPORT community is attached and LOCAL_PREF is set to zero. This option is not available for EBGP neighbors without the LLGR Capability.
In VPN deployments using EBGP as the PE-CE protocol, an implementation MAY advertise LLGR stale routes over a PE-CE session to a non-LLGR CE when explicitly configured to do so, bypassing the normal restriction. The NO_EXPORT community SHOULD be attached by default as an additional safeguard against unbounded stale route propagation.
When a Long-Lived Stale Time timer expires during synchronization (after session re-establishment but before EoR), any stale routes not refreshed by the peer are removed. If the session resets again before synchronization completes for an AFI/SAFI whose LLST timer already expired, all remaining routes for that AFI/SAFI MUST be removed immediately.
A BGP speaker configured to support LLGR procedures MUST use BGP Capabilities Advertisement (RFC 5492) to advertise the Long-Lived Graceful Restart Capability. The setting of AFI/SAFI parameters depends on speaker properties, network scale, and local configuration.
A least-preferred route MUST be treated as less preferred than any non-least-preferred route. Normal tiebreaking applies only when comparing two routes that are both least preferred.
A speaker that has advertised the LLGR Capability MUST treat any received LLGR_STALE route as the least preferred in route selection. Such routes SHOULD NOT be advertised to any neighbor from which the LLGR Capability has not been received, and the LLGR_STALE community MUST NOT be removed when the route is further advertised.
After a session goes down and before re-establishment, stale routes for each AFI/SAFI MUST be retained for the sum of the GR Restart Time and the Long-Lived Stale Time received in the peer's capabilities. The received LLST timers SHOULD be modifiable by local configuration that may impose upper or lower bounds.
If the LLGR Capability is advertised, the Graceful Restart Capability (RFC 4724) MUST also be advertised. If no GR Capability accompanies an LLGR Capability, the LLGR Capability MUST be disregarded entirely.
Implementations MUST NOT enable LLGR procedures by default. They MUST require affirmative configuration per AFI/SAFI before enabling these procedures.
Once the GR Restart Time period ends, the helper router MUST start an LLST timer per AFI/SAFI, attach the LLGR_STALE community to retained stale routes (requiring readvertisement), and delete those routes if the timer expires before session re-establishment.
Once the LLGR period begins, the helper MUST immediately remove all stale routes for an address family if the F bit is not set in the newly received LLGR Capability, if the AFI/SAFI is absent from the newly received LLGR Capability, or if no LLGR/GR Capability is received at all in the re-established session.
Routes marked with the NO_LLGR community—whether sent by the peer or applied by configured policy—MUST NOT be retained and MUST be removed per normal RFC 4271 operation when the LLGR period begins.
When IBGP is the PE-CE protocol in a VPN and a CE supports LLGR, the PE MUST include the LLGR_STALE community in routes advertised to the CE if it is present in the imported VPN route's path attributes, even if absent from the ATTR_SET. This updates RFC 6368.
LLGR_STALE is a well-known BGP community (value: 0xFFFF0006) used to mark stale routes being retained for a long-lived period. Routes carrying this community are subject to specific handling rules including depreference and restricted advertisement.
NO_LLGR is a well-known BGP community (value: 0xFFFF0007) used to mark routes that must not be retained as long-lived stale routes. Routes marked with NO_LLGR must be removed per normal BGP operation when the LLGR period begins.
The Flags field in each LLGR Capability tuple contains a single defined bit at position 0: the F bit (Preservation of state). When set to 1, it indicates that forwarding/routing state for routes of the given AFI/SAFI has been preserved during the previous BGP restart. Bits 1–7 are reserved and MUST be zero.
The Long-Lived Graceful Restart Capability (LLGR Capability) is a BGP capability with assigned code value 71. It allows a BGP speaker to signal its ability to retain stale routes for a period longer than conventional Graceful Restart permits. The capability consists of zero or more per-AFI/SAFI tuples each containing a Long-Lived Stale Time (LLST) field.
IANA assigned BGP Capability Code 71 to the Long-Lived Graceful Restart Capability in the 'Capability Codes' registry. IANA also assigned well-known community values 0xFFFF0006 (LLGR_STALE) and 0xFFFF0007 (NO_LLGR) in the 'BGP Well-known Communities' registry.
IANA established the 'Long-Lived Graceful Restart Flags for Address Family' registry under the BGP Parameters group, governed by Standards Action. It is initially populated with bit position 0 (F bit, 'Preservation of state') as defined by RFC 9494; bit positions 1–7 are unassigned.
Depreferencing IBGP routes based on per-router session state can lead to inconsistent route selection across routers in an AS, potentially causing forwarding loops in hop-by-hop routed networks. LLGR is not recommended for AFI/SAFIs carrying conventional reachability information in networks without tunneled forwarding (e.g., MPLS).
LLGR greatly extends the window during which stale routing information is present in the network, increasing the period during which certain attacks are feasible. This is especially relevant for MPLS VPN label entries: if an egress PE withdraws a VPN label L1 but ingress PEs still hold a long-lived stale route using L1, and L1 is reallocated to a different VPN before the stale routes expire, cross-VPN traffic leakage can occur.
To avoid MPLS VPN label reuse vulnerabilities, operators MUST ensure the lower bound for label reuse time on a PE exceeds the upper bound of the Long-Lived Stale Time before enabling LLGR for a VPN address family. Relevant factors include BGP route churn load, label pool size, label allocation scheme, and reallocation policy.
Session failure triggers two sequential stale-retention periods: (1) GR period—routes are retained per RFC 4724 at normal preference until the Restart Time expires; (2) LLGR period—routes are depreferenced, tagged with LLGR_STALE, and retained until the Long-Lived Stale Time expires or the session re-establishes and synchronizes. If both timers are zero, standard RFC 4271 withdrawal applies.
Each tuple in the LLGR Capability encodes: Address Family Identifier (16 bits), Subsequent Address Family Identifier (8 bits), Flags for Address Family (8 bits), and Long-Lived Stale Time (24 bits). Multiple AFI/SAFI tuples may be concatenated within a single capability value.