Graceful Restart Mechanism for BGP with MPLS
Extracted elements (24)
LSRs that cannot preserve MPLS forwarding state need only implement a subset of this mechanism (excluding Sections 4.1, 4.2, 4.3, and 5); this still reduces negative impact if their neighbors can preserve forwarding state.
Section 4 procedures (reconstructing same bindings) involve more computational overhead on the restarting router but require fewer label changes in neighbors, while Section 5 procedures (creating new bindings) are simpler but require twice as many labels. An LSR may mix approaches per AFI/SAFI.
The mechanism is intentionally agnostic to address family types in NLRI, so it works with any address family carried in BGP (IPv4, IPv6, etc.), by treating MPLS forwarding state preservation as orthogonal to address family.
This mechanism works in conjunction with RFC 4724 (Graceful Restart for BGP) and RFC 3107 (Carrying Label Information in BGP-4); implementations must support RFC 4724 as a prerequisite.
A neighbor of the restarting LSR SHOULD immediately remove all NLRI and associated MPLS labels received from the restarting LSR if the Graceful Restart Capability flags indicate the LSR was unable to retain its MPLS state across the restart.
After restart, the LSR MUST follow procedures specified in RFC 4724, and if MPLS forwarding state was preserved, SHOULD advertise this by setting the Flag for Address Family field in the Graceful Restart Capability for all applicable AFI/SAFI pairs.
An LSR MUST implement the Graceful Restart Mechanism for BGP as specified in RFC 4724.
An LSR SHOULD keep a label-to-FEC binding value for as long as it has a route to the FEC. When creating a new <label, FEC> binding, the LSR SHOULD pick the least recently used label to minimize misrouting.
For each next hop reachable via an LSP, the restarting LSR MUST be able to preserve the MPLS forwarding state associated with that LSP across the restart.
Labels retained from preserved MPLS forwarding state MUST NOT be used to create new local label bindings (but may be used to reconstruct existing bindings).
Once an LSR releases a label, it SHALL NOT re-use that label for advertising a <label, FEC> binding to a neighbor that supports graceful restart for at least the Restart Time advertised by that neighbor. This rule applies to any label release at any time.
The LSR SHOULD be capable of preserving its MPLS forwarding state across the restart of its control plane, including the restart of BGP.
The SAFI in the advertised Graceful Restart Capability MUST indicate that the NLRI field carries not only addressing information but also labels.
Under alternative procedures, the LSR SHOULD retain the preserved MPLS forwarding state at least until it sends an End-of-RIB marker to all neighbors, and SHOULD delete the preserved state after that (with an optional configurable additional retention period via MAY).
Under the alternative procedures (Section 5), the LSR SHOULD have at least as many unallocated labels as labels allocated for BGP-distributed <FEC -> label> bindings preserved across the restart.
When multiple protocol components (e.g., BGP, LDP, RSVP-TE) create label bindings and the LSR supports per-component restart, the LSR MUST preserve information about which protocol assigned which labels across the restart.
Capability advertisement for this mechanism uses the Graceful Restart Capability from RFC 4724, with the SAFI indicating that NLRI carries labels per RFC 3107.
MPLS forwarding state is defined as one of four mappings: <incoming label -> (outgoing label, next hop)>, <FEC -> (outgoing label, next hop)>, <incoming label -> label pop, next hop>, or <incoming label, label pop>.
A security issue arises if an upstream LSR continues using labels after expiration of the BGP session that caused their use, while the downstream LSR has already released and re-used those labels, potentially causing misrouting or unauthorized service access. The Restart Time extends the vulnerability window.
An intruder may impersonate a BGP peer to force TCP connection failure and reconnection with the Forwarding State (F) bit set to 0, causing all labels received from the peer to be released. Countermeasure: use BGP session authentication such as TCP MD5 (RFC 2385).
To reduce the label re-use misrouting risk, the document requires that labels are not re-used until at least the Restart Time has elapsed after release, ensuring the upstream LSR has had time to recognize session failure.
For Case 1 (best route received with a non-Implicit-NULL label, LSR advertises with itself as next hop): search preserved MPLS forwarding state for matching <outgoing label, next hop>; if found, unmark entry as stale and reuse incoming label when advertising; if not found, allocate a new label.
For Case 2 (best route received without label, with Implicit NULL, or originated by LSR; LSR must generate a non-Implicit-NULL label): search preserved MPLS forwarding state for a label-pop entry with matching next hop (and FEC if per-route labels); if found, reuse incoming label; otherwise allocate new label.
For Case 3 (LSR does not set BGP next hop to self): the LSR advertises its best route using the label received with it, or with no label if none was received, without allocating a new label.