Network Working Group E. Chen
Request for Comments: 2918 Redback Networks
Category: Standards Track September 2000
Route Refresh Capability for BGP-4
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document defines a new Border Gateway Protocol (BGP) capability
termed 'Route Refresh Capability', which would allow the dynamic
exchange of route refresh request between BGP speakers and subsequent
re-advertisement of the respective Adj-RIB-Out. One possible
application of this capability is to facilitate non-disruptive
routing policy changes.
Currently there does not exist a mechanism in BGP-4 [BGP-4] to
dynamically request a re-advertisement of the Adj-RIB-Out from a BGP
peer. When the inbound routing policy for a peer changes, all
prefixes from that peer must be somehow made available and then re-
examined against the new policy. To accomplish this, a commonly used
approach, known as 'soft-reconfiguration', is to store an unmodified
copy of all routes from that peer at all times, even though routing
policies do not change frequently (typically no more than a couple
times a day). Additional memory and CPU are required to maintain
This document proposes an alternative solution that avoids the
additional maintenance cost. More specifically, it defines a new BGP
capability termed 'Route Refresh Capability', which would allow the
dynamic exchange of route refresh request between BGP speakers and
subsequent re-advertisement of the respective Adj-RIB-Out.
Chen Standards Track [Page 1]RFC 2918 Route Refresh for BGP-4 September 20002. Route Refresh Capability
To advertise the Route Refresh Capability to a peer, a BGP speaker
uses BGP Capabilities Advertisement [BGP-CAP]. This capability is
advertised using the Capability code 2 and Capability length 0.
By advertising the Route Refresh Capability to a peer, a BGP speaker
conveys to the peer that the speaker is capable of receiving and
properly handling the ROUTE-REFRESH message (as defined in Section 3)
from the peer.
3. Route-REFRESH Message
The ROUTE-REFRESH message is a new BGP message type defined as
Type: 5 - ROUTE-REFRESH
Message Format: One <AFI, SAFI> encoded as
0 7 15 23 31
| AFI | Res. | SAFI |
The meaning, use and encoding of this <AFI, SAFI> field is the
same as defined in [BGP-MP, sect. 7]. More specifically,
AFI - Address Family Identifier (16 bit).
Res. - Reserved (8 bit) field. Should be set to 0 by the
sender and ignored by the receiver.
SAFI - Subsequent Address Family Identifier (8 bit).
A BGP speaker that is willing to receive the ROUTE-REFRESH message
from its peer should advertise the Route Refresh Capability to the
peer using BGP Capabilities advertisement [BGP-CAP].
A BGP speaker may send a ROUTE-REFRESH message to its peer only if it
has received the Route Refresh Capability from its peer. The <AFI,
SAFI> carried in such a message should be one of the <AFI, SAFI> that
the peer has advertised to the speaker at the session establishment
time via capability advertisement.
Chen Standards Track [Page 2]RFC 2918 Route Refresh for BGP-4 September 2000
If a BGP speaker receives from its peer a ROUTE-REFRESH message with
the <AFI, SAFI> that the speaker didn't advertise to the peer at the
session establishment time via capability advertisement, the speaker
shall ignore such a message. Otherwise, the BGP speaker shall re-
advertise to that peer the Adj-RIB-Out of the <AFI, SAFI> carried in
the message, based on its outbound route filtering policy.