datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

Route Refresh Capability for BGP-4
RFC 2918

Document type: RFC - Proposed Standard (September 2000; No errata)
Updated by RFC 7313
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 2918 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

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.

Abstract

   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.

1. Introduction

   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
   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.

Chen                        Standards Track                     [Page 1]
RFC 2918                Route Refresh for BGP-4           September 2000

2. 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
   follows:

          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).

4. Operation

   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.

[include full document text]