draft-ietf-idr-bgp-route-refresh-00.txt   rfc2918.txt 
Network Working Group Enke Chen
Internet Draft Siara Systems
Expiration Date: May 2000
Route Refresh Capability for BGP-4
draft-ietf-idr-bgp-route-refresh-00.txt Network Working Group E. Chen
Request for Comments: 2918 Redback Networks
1. Status of this Memo Category: Standards Track September 2000
This document is an Internet-Draft and is in full conformance with Route Refresh Capability for BGP-4
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as ``work in progress.'' Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
2. Abstract Abstract
This document defines a new BGP capability termed 'Route Refresh This document defines a new Border Gateway Protocol (BGP) capability
Capability', which would allow the dynamic exchange of route refresh termed 'Route Refresh Capability', which would allow the dynamic
request between BGP speakers and subsequent re-advertisement of the exchange of route refresh request between BGP speakers and subsequent
respective Adj-RIB-Out. One possible application of this capability re-advertisement of the respective Adj-RIB-Out. One possible
is to facilitate non-disruptive routing policy changes. application of this capability is to facilitate non-disruptive
routing policy changes.
3. Introduction 1. Introduction
Currently there does not exist a mechanism in BGP-4 [BGP-4] to 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 dynamically request a re-advertisement of the Adj-RIB-Out from a BGP
peer. When the inbound routing policy for a peer changes, all peer. When the inbound routing policy for a peer changes, all
prefixes from that peer must be somehow made available and then re- prefixes from that peer must be somehow made available and then re-
examined against the new policy. To accomplish this, a commonly used examined against the new policy. To accomplish this, a commonly used
approach, known as 'soft-reconfiguration', is to store an unmodified approach, known as 'soft-reconfiguration', is to store an unmodified
copy of all routes from that peer at all times, even though routing copy of all routes from that peer at all times, even though routing
policies do not change frequently (typically no more than a couple policies do not change frequently (typically no more than a couple
times a day). Additional memory and CPU are required to maintain times a day). Additional memory and CPU are required to maintain
these routes. these routes.
This document proposes an alternative solution that avoids the This document proposes an alternative solution that avoids the
additional maintenance cost. More specifically, it defines a new BGP additional maintenance cost. More specifically, it defines a new BGP
capability termed 'Route Refresh Capability', which would allow the capability termed 'Route Refresh Capability', which would allow the
dynamic exchange of route refresh request between BGP speakers and dynamic exchange of route refresh request between BGP speakers and
subsequent re-advertisement of the respective Adj-RIB-Out. subsequent re-advertisement of the respective Adj-RIB-Out.
4. Route Refresh Capability 2. Route Refresh Capability
To advertise the Route Refresh Capability to a peer, a BGP speaker To advertise the Route Refresh Capability to a peer, a BGP speaker
uses BGP Capabilities Negotiation [BGP-CAP]. This capability is uses BGP Capabilities Advertisement [BGP-CAP]. This capability is
advertised using the Capability code [TBD] and Capability length 0. advertised using the Capability code 2 and Capability length 0.
By advertising the Route Refresh Capability to a peer, a BGP speaker By advertising the Route Refresh Capability to a peer, a BGP speaker
conveys to the peer that the speaker is capable of receiving and conveys to the peer that the speaker is capable of receiving and
properly handling the ROUTE-REFRESH message (as defined in Section 5) properly handling the ROUTE-REFRESH message (as defined in Section 3)
from the peer. from the peer.
5. Route-REFRESH Message 3. Route-REFRESH Message
The ROUTE-REFRESH message is a new BGP message type defined as The ROUTE-REFRESH message is a new BGP message type defined as
follows: follows:
Type: TBD - ROUTE-REFRESH Type: 5 - ROUTE-REFRESH
Message Format: One <AFI, SAFI> encoded as Message Format: One <AFI, SAFI> encoded as
0 7 15 23 31 0 7 15 23 31
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| AFI | Res. | SAFI | | AFI | Res. | SAFI |
+-------+-------+-------+-------+ +-------+-------+-------+-------+
The meaning, use and encoding of this <AFI, SAFI> field is the The meaning, use and encoding of this <AFI, SAFI> field is the
same as defined in [BGP-MP, sect. 8]. More specifically, same as defined in [BGP-MP, sect. 7]. More specifically,
AFI - Address Family Identifier (16 bit). AFI - Address Family Identifier (16 bit).
Res. - Reserved (8 bit) field. Should be set to 0 by the Res. - Reserved (8 bit) field. Should be set to 0 by the
sender and ignored by the receiver. sender and ignored by the receiver.
SAFI - Subsequent Address Family Identifier (8 bit). SAFI - Subsequent Address Family Identifier (8 bit).
6. Operation 4. Operation
A BGP speaker that is willing to receive the ROUTE-REFRESH message A BGP speaker that is willing to receive the ROUTE-REFRESH message
from its peer should advertise the Route Refresh Capability to the from its peer should advertise the Route Refresh Capability to the
peer using BGP Capabilities negotiation [BGP-CAP]. peer using BGP Capabilities advertisement [BGP-CAP].
A BGP speaker may send a ROUTE-REFRESH message to its peer only if it 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, 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 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 the peer has advertised to the speaker at the session establishment
time via capability negotiation. time via capability advertisement.
If a BGP speaker receives from its peer a ROUTE-REFRESH message with 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 the <AFI, SAFI> that the speaker didn't advertise to the peer at the
session establishment time via capability negotiation, the speaker session establishment time via capability advertisement, the speaker
shall ignore such a message. Otherwise, the BGP speaker shall re- 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 advertise to that peer the Adj-RIB-Out of the <AFI, SAFI> carried in
the message, based on its outbound route filtering policy. the message, based on its outbound route filtering policy.
7. Security Considerations 5. Security Considerations
This extension to BGP does not change the underlying security issues. This extension to BGP does not change the underlying security issues.
8. Acknowledgments 6. Acknowledgments
The concept of Route Refresh proposed is similar to the one used in The concept of Route Refresh proposed is similar to the one used in
IDRP. IDRP.
The author would like to thank Yakov Rekhter, Ravi Chandra, Srihari The author would like to thank Yakov Rekhter, Ravi Chandra, Srihari
Ramachandra and Bruce Cole for their review and comments. Ramachandra and Bruce Cole for their review and comments.
9. References 7. References
[BGP-4] Rekhter, Y., and T. Li, 'A Border Gateway Protocol 4 (BGP- [BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
4)', RFC 1771, March 1995. 4)", RFC 1771, March 1995.
[BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., [BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
'Multiprotocol Extensions for BGP-4', work in progress "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-CAP] Chandra, R., Scudder, J., 'Capabilities Negotiation with [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement
BGP-4', work in progress with BGP-4", RFC 2842, May 2000.
10. Author Information 8. Author's Address
Enke Chen Enke Chen
Siara Systems Incorporated Redback Networks Inc.
300 Ferguson Drive 350 Holger Way
Mountain View, CA 94043 San Jose, CA 95134
e-mail: enkechen@siara.com
EMail: enke@redback.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 28 change blocks. 
51 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/