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 Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis 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. 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 these routes. 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.
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. 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). 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.
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. [BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 4)", RFC 1771, March 1995. [BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.