Notification Message Support for BGP Graceful Restart
updates
- rfc-4724 — Graceful Restart Mechanism for BGP
Extracted elements (25)
The Hard Reset encapsulates a full NOTIFICATION message (ErrCode, Subcode, Data) in its data portion so the actual reason for termination is not lost; otherwise, wrapping in Cease/Hard Reset would discard the original error context.
The Hard Reset subcode exists to defeat graceful restart semantics when a full session teardown is warranted, such as for permanent errors (Maximum Prefixes Reached, Administrative Shutdown, Peer De-configured). Transient conditions (Connection Rejected, Configuration Change, Out of Resources) are better served by Graceful Cease.
The stale timer, previously OPTIONAL in RFC 4724, is made MUST to mitigate the risk introduced by relaxing protection against repeated resets. Without a mandatory upper bound, an attacker could repeatedly reset sessions to prevent stale routes from ever being deleted.
When a BGP session is reset under this extension, both speakers operate as 'Receiving Speakers' per RFC 4724, retaining each other's routes to avoid reachability flapping while the session recovers. This applies symmetrically to both the sender and receiver of the NOTIFICATION.
A Hard Reset sent to a peer that has not advertised the 'N' bit will still result in a session reset per RFC 4271 and RFC 4724, since any NOTIFICATION causes a reset; the only negative effect is the peer cannot properly log the encapsulated error information.
RFC 8203 Administrative Shutdown Communication interacts with Hard Reset by requiring encapsulation: the Hard Reset subcode is outermost, and the RFC 8203 subcode and message appear in the encapsulated data field.
A BGP speaker SHOULD NOT send a Hard Reset to a peer from which it has not received the 'N' bit. The negative effect would be that the peer cannot properly log the associated information.
A BGP speaker willing to send and receive NOTIFICATION messages under these procedures MUST advertise the 'N' bit using the Graceful Restart Capability.
An implementation MUST support a (configurable) stale timer that imposes an upper bound on route retention time. A suggested default is 180 seconds. An implementation MAY allow disabling the timer but MUST NOT do so by default.
If the 'N' bit has not been exchanged with the peer, a route from the peer previously marked as stale MUST be deleted to deal with possible consecutive restarts. When the 'N' bit has been exchanged, this deletion rule is removed.
New Graceful Restart parameters from a speaker that previously advertised a different set only apply once the new session has transitioned into ESTABLISHED state.
Once the session is re-established, both BGP speakers SHOULD set their Forwarding State bit to 1. Failure to do so causes routes to be flushed per RFC 4724 Section 4.2, defeating the goals of this specification.
When a BGP speaker resets its session due to HOLDTIME expiry, it should generate the relevant BGP NOTIFICATION message per RFC 4271 but subsequently MUST follow the Receiving Speaker rules in Section 4.1.
When reporting a Hard Reset to network management, the error code and subcode reported MUST be Cease and Hard Reset, respectively. If the management layer permits it, the Data portion SHOULD be reported as well.
When RFC 8203 is used in conjunction with Hard Reset, the subcode of the outermost Cease MUST be Hard Reset, with the Administrative Shutdown or Administrative Reset subcodes encapsulated within. The encapsulated message MUST subsequently be processed according to RFC 8203.
When the 'N' bit has been exchanged with a peer and a BGP NOTIFICATION message other than a Hard Reset is received from that peer, the receiving speaker MUST follow the Receiving Speaker rules in Section 4.1. The speaker generating the NOTIFICATION MUST also follow the Receiving Speaker rules.
Whenever a BGP speaker receives a Hard Reset, the speaker MUST terminate the BGP session following the standard procedures in RFC 4271, with no graceful restart semantics applied.
A new subcode called 'Hard Reset' (value 9) is defined for BGP Cease NOTIFICATION messages. When the 'N' bit has been exchanged, a Hard Reset signals that the session is to be fully terminated rather than gracefully restarted.
The Graceful Restart Capability Restart Flags field is extended with a second bit, the Graceful Notification ('N') bit (bit position 1). A BGP speaker sets this bit to indicate support for Graceful Restart procedures when a NOTIFICATION message is received or Hold Time expires.
IANA assigned subcode 9 ('Hard Reset') in the 'BGP Cease NOTIFICATION message subcodes' registry.
IANA created the 'BGP Graceful Restart Flags for Address Family' sub-registry under 'Border Gateway Protocol (BGP) Parameters', with registration procedure Standards Action. Initial values: bit 0 = Forwarding State (F, RFC 4724), bits 1-7 = Unassigned.
IANA created the 'BGP Graceful Restart Flags' sub-registry under 'Border Gateway Protocol (BGP) Parameters', with registration procedure Standards Action. Initial values: bit 0 = Restart State (R, RFC 4724), bit 1 = Notification (N, RFC 8538), bits 2-3 = Unassigned.
This specification relaxes RFC 4724's protection against repeated session resets, creating a risk that an attacker could use repeated resets to prevent stale routes from ever being deleted. The mandatory stale timer mitigates this risk. The extension may modestly increase control-plane resilience, but no general claims can be made due to deployment-specific factors.
When a session resets (NOTIFICATION received or HOLDTIME expired) and the 'N' bit has been exchanged, both speakers transition to the Receiving Speaker state retaining stale routes. A Hard Reset bypasses this and triggers full session termination per RFC 4271.
The data portion of a Hard Reset message encodes ErrCode (1 octet), Subcode (1 octet), and Data, effectively encapsulating another NOTIFICATION message within the Hard Reset's data field.