Enhanced Route Refresh Capability for BGP-4
updates
- rfc-2918 — Route Refresh Capability for BGP-4
Extracted elements (20)
The enhancement adds BoRR and EoRR demarcation messages to allow online, non-disruptive RIB consistency validation between BGP speakers, replacing tedious offline manual operations that were previously required to detect missing route withdrawals.
The Reserved field in the original RFC 2918 ROUTE-REFRESH message is repurposed as Message Subtype rather than adding a new message type, allowing backward compatibility: subtype 0 retains the original RFC 2918 semantics.
The separation of EoR (Graceful Restart End-of-RIB) and EoRR (Enhanced Route Refresh End-of-Route-Refresh) is carefully maintained to prevent premature cleanup of stale routes during concurrent Graceful Restart and route refresh operations.
A BGP speaker MAY ignore any EoRR message received without a prior associated BoRR message; such messages MAY be logged. An implementation MAY impose a locally configurable upper bound on stale route retention, after which stale routes MAY be removed without waiting for EoRR.
A BGP speaker that has received the Graceful Restart Capability from its neighbor MUST ignore any BoRRs for an <AFI, SAFI> from that neighbor before receiving the EoR for that <AFI, SAFI>. The speaker SHOULD log an error for further analysis.
A BGP speaker that supports the enhanced ROUTE-REFRESH message subtypes SHOULD advertise the Enhanced Route Refresh Capability to its peers.
Before starting a route refresh (whether locally initiated or in response to a peer request), the speaker MUST send a BoRR message. After completing re-advertisement of the entire Adj-RIB-Out, it MUST send an EoRR message.
For speakers supporting BGP Graceful Restart, a BoRR MUST NOT be sent for an <AFI, SAFI> to a neighbor before the EoR (End-of-RIB from Graceful Restart) for that <AFI, SAFI> has been sent to that neighbor.
If the length (excluding the fixed-size message header) of a received ROUTE-REFRESH message with subtype 1 or 2 is not 4, the BGP speaker MUST send a NOTIFICATION with Error Code 'ROUTE-REFRESH Message Error' and subcode 'Invalid Message Length', including the complete ROUTE-REFRESH message in the Data field.
When a BGP speaker receives a BoRR message, it MUST mark all routes for the given <AFI, SAFI> from that peer as stale. Subsequent route advertisements from the peer replace corresponding stale routes.
When a BGP speaker receives a ROUTE-REFRESH message with a Message Subtype other than 0, 1, or 2, it MUST ignore the message. It SHOULD log an error for further analysis.
When a BGP speaker receives an EoRR message, it MUST immediately remove any routes from that peer still marked as stale for the given <AFI, SAFI>. Purged routes MAY be logged for future analysis.
The Enhanced Route Refresh Capability is a new BGP capability (RFC 5492) assigned Capability Code 70 by IANA, with a Capability Length of zero. Advertising it signals that the speaker supports ROUTE-REFRESH message subtypes and the related BoRR/EoRR procedures.
This document defines a new NOTIFICATION error code 7 named 'ROUTE-REFRESH Message Error', and error subcode 1 named 'Invalid Message Length', applicable when the Enhanced Route Refresh Capability has been negotiated.
IANA assigned Capability Code 70 to the Enhanced Route Refresh Capability in the existing 'Capability Codes' registry, referencing RFC 7313.
IANA created the 'BGP ROUTE-REFRESH Message Error subcodes' registry. Values 0–127 require Standards Action; 128–255 are First Come First Served. Initial values: 0 = Reserved, 1 = Invalid Message Length (RFC 7313).
IANA created the 'BGP Route Refresh Subcodes' registry under BGP Parameters. Values 0–127 require Standards Action; values 128–254 are First Come First Served. Initial values: 0 = Route-Refresh (RFC 2918/5291), 1 = BoRR (RFC 7313), 2 = EoRR (RFC 7313), 255 = Reserved.
Security considerations from RFC 4272 apply but do not cover Route-Refresh or many other BGP extensions. This document does not significantly change the underlying security issues for Route-Refresh, though improved error handling may aid operational security.
Route refresh state for an <AFI, SAFI>: on BoRR receipt, all routes from peer transition to Stale; incoming updates replace stale entries; on EoRR receipt, all remaining Stale routes are purged immediately; if stale timeout expires before EoRR, routes are purged without waiting.
The previously Reserved 1-byte field in the ROUTE-REFRESH message (RFC 2918) is redefined as Message Subtype: 0 = normal route refresh, 1 = Beginning of Route Refresh (BoRR), 2 = End of Route Refresh (EoRR), 255 = Reserved. Values 3–254 are reserved for future use.