RFC 2918

Route Refresh Capability for BGP-4

📅 published September 2000, from ietf

RFC 2918: Route Refresh Capability for BGP-4 ✨

Okay bestie, so RFC 2918 🎀 was written by E. Chen from Redback Networks, it's on the Standards Track, and it's dated September 2000. The title block doesn't list anything it obsoletes or updates, so nothing else to track there 💅

Status of This Memo 🌸

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🦋

Okay so this doc introduces a brand new Border Gateway Protocol (BGP) capability called 'Route Refresh Capability' 🔥 It lets BGP speakers dynamically swap route refresh requests and then re-advertise the matching Adj-RIB-Out. The big payoff? You can make routing policy changes without causing a disruption ✨

1. Introduction 🧚

Right now, BGP-4 [BGP-4] has no way to dynamically ask a BGP peer to re-advertise its Adj-RIB-Out 💀 When a peer's inbound routing policy changes, every prefix from that peer has to be somehow made available and then re-checked against the new policy. The usual workaround is called 'soft-reconfiguration', which stores an unmodified copy of every route from that peer all the time. That's a lot of extra memory and CPU, even though routing policies usually only change a couple of times a day, max 😭

This document proposes a better option that skips that ongoing maintenance cost. It defines the 'Route Refresh Capability', a new BGP capability that lets BGP speakers dynamically exchange route refresh requests and then re-advertise the respective Adj-RIB-Out. Main character energy 👑

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.

When a BGP speaker advertises the Route Refresh Capability to a peer, it's telling that peer it can receive and properly handle the ROUTE-REFRESH message (defined in Section 3) from that peer 🫶

3. Route-REFRESH Message 🦋

The ROUTE-REFRESH message is a brand new BGP message type, and here's how it's laid out:

          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 are the same as defined in [BGP-MP, sect. 7]. 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 that 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 that peer. The <AFI, SAFI> carried in such a message should be one of the <AFI, SAFI> values the peer advertised to the speaker at session establishment time via capability advertisement.

If a BGP speaker gets a ROUTE-REFRESH message from its peer with an <AFI, SAFI> it didn't advertise to that peer at session establishment time via capability advertisement, the speaker shall ignore that 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 💅

Heads up: the ignore-or-re-advertise rule above is the key part. Match the AFI/SAFI pair exactly, or the speaker ignores the message! 🙈

5. Security Considerations 💀

This extension to BGP does not change the underlying security issues.

6. Acknowledgments 🫶

The concept of Route Refresh proposed here is similar to the one used in IDRP.

The author would like to thank Yakov Rekhter, Ravi Chandra, Srihari Ramachandra and Bruce Cole for their review and comments. Iconic squad 💖

7. References 📚

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

8. Author's Address 🍓

Enke Chen
Redback Networks Inc.
350 Holger Way
San Jose, CA 95134

EMail: enke@redback.com

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. This is allowed as long as 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. The exceptions are when needed for developing Internet standards, in which case the copyright procedures defined in the Internet Standards process must be followed, or when translating 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 ✨

📦 where this page comes from