Browse Prior Art Database

Route Refresh Capability for BGP-4 (RFC2918)

IP.com Disclosure Number: IPCOM000005100D
Original Publication Date: 2000-Sep-01
Included in the Prior Art Database: 2001-Aug-15
Document File: 5 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Chen: AUTHOR

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 47% of the total text.

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 encoded as

0 7 15 23 31 AFI Res. SAFI

The meaning, use and encoding of this 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...