Route Refresh Capability for BGP-4
updated by
- rfc-7313 — Enhanced Route Refresh Capability for BGP-4
Extracted elements (12)
Route Refresh Capability is proposed as an alternative to 'soft-reconfiguration', which requires storing an unmodified copy of all routes from each peer at all times even though policies rarely change. The new mechanism avoids the additional memory and CPU cost of maintaining these stored routes.
A BGP speaker MAY send a ROUTE-REFRESH message to its peer only if it has received the Route Refresh Capability from that peer.
A BGP speaker that is willing to receive ROUTE-REFRESH messages SHOULD advertise the Route Refresh Capability to its peer using BGP Capabilities Advertisement.
If a BGP speaker receives a ROUTE-REFRESH message with an <AFI, SAFI> that it did not advertise to the peer at session establishment, the speaker SHALL ignore such a message.
The <AFI, SAFI> carried in a ROUTE-REFRESH message SHOULD be one of the <AFI, SAFI> pairs that the peer advertised to the speaker at session establishment via capability advertisement.
The Reserved (Res.) field in the ROUTE-REFRESH message SHOULD be set to 0 by the sender and ignored by the receiver.
Upon receiving a valid ROUTE-REFRESH message, the BGP speaker SHALL re-advertise to that peer the Adj-RIB-Out for the <AFI, SAFI> carried in the message, based on its outbound route filtering policy.
ROUTE-REFRESH is a new BGP message type assigned Type 5. Its message format encodes a single <AFI, SAFI> tuple in a 32-bit field: AFI (16 bits), Reserved (8 bits), SAFI (8 bits).
The Route Refresh Capability is advertised using BGP Capabilities Advertisement with Capability code 2 and Capability length 0. Advertising this capability conveys that the speaker can receive and properly handle ROUTE-REFRESH messages.
This document implicitly allocates BGP Capability code 2 for the Route Refresh Capability and BGP message Type 5 for the ROUTE-REFRESH message.
This extension to BGP does not change the underlying security issues inherent in BGP-4.
The ROUTE-REFRESH message body is 4 bytes: AFI (16-bit Address Family Identifier), Res (8-bit Reserved field), and SAFI (8-bit Subsequent Address Family Identifier), encoded in that order. The encoding and semantics of <AFI, SAFI> match RFC 2858 section 7.