RFC 7911

Advertisement of Multiple Paths in BGP

📅 published July 2016, from ietf

RFC 7911: Advertisement of Multiple Paths in BGP 💖

okay bestie, the title block first, because it's the cute little ID card of this whole doc 🎀

  • Publisher: Internet Engineering Task Force (IETF) 🌸
  • Category: Standards Track, so this is an Internet Standards Track document 💅
  • Date: July 2016 📅
  • ISSN: 2070-1721
  • Authors: D. Walton (Cumulus Networks), A. Retana (Cisco Systems, Inc.), E. Chen (Cisco Systems, Inc.), and J. Scudder (Juniper Networks) 🫶
  • Obsoletes / Updates: the header doesn't list any document this one obsoletes or updates 🦋

Abstract ✨

okay so this doc adds a BGP extension that lets a BGP speaker advertise multiple paths for the same address prefix 🔥 The new paths don't just overwrite the old ones, which is the whole point. The secret sauce is that every path gets its own Path Identifier on top of the address prefix 💜

Status of This Memo 📜

this is an Internet Standards Track document 💅

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🌈 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 if you want more on Internet Standards, check out Section 2 of RFC 7841 📖

for info on the current status of this doc, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7911. 🎀

copyright (c) 2016 IETF Trust and the persons identified as the document authors, all rights reserved 🔒

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication 📄 please actually read those, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Specification of Requirements . . . . . . . . . . . . . .   2
2.  How to Identify a Path  . . . . . . . . . . . . . . . . . . .   3
3.  Extended NLRI Encodings . . . . . . . . . . . . . . . . . . .   3
4.  ADD-PATH Capability . . . . . . . . . . . . . . . . . . . . .   4
5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
6.  Deployment Considerations . . . . . . . . . . . . . . . . . .   5
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
  9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction ✨

so the BGP spec [RFC4271] defines an Update-Send Process that advertises the routes picked by the Decision Process to other BGP speakers 💅 there's zero provision for advertising multiple paths for the same address prefix or Network Layer Reachability Information (NLRI) 🙈 like, if a route shows up with the same NLRI as one that was already advertised, it just replaces the old one. no discussion 💀

this doc defines a BGP extension that lets a BGP speaker advertise multiple paths for the same address prefix without the new paths replacing the old ones 🦋 the essence is that each path is identified by a Path Identifier in addition to the address prefix 🔑

extra paths are lowkey a big deal. they can help reduce or eliminate persistent route oscillations [RFC3345] 🌀 they also help with optimal routing and routing convergence, by giving you potential alternate paths and backup paths, respectively 🧚

1.1. Specification of Requirements 🔠

the big caps-lock words are the BCP 14 key words, and they're interpreted as described in [RFC2119] 🔒 the key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 💖

2. How to Identify a Path 🦋

okay so as [RFC4271] defines it, a path is the info reported in the Path Attribute field of an UPDATE message 📦 since those procedures only allow one path to be advertised for a given address prefix, a path from a BGP peer for an address prefix can be keyed on just the address prefix 🗝️

to advertise multiple paths for the same address prefix, a BGP speaker needs a new identifier, called the "Path Identifier" from here on 🎀 with it, a particular path for an address prefix gets identified by the combo of the address prefix and the Path Identifier 💜

assigning a Path Identifier to a path is purely a local matter for the BGP speaker 🏠 BUT the Path Identifier MUST be assigned so that the BGP speaker can use the (Prefix, Path Identifier) pair to uniquely identify a path advertised to a neighbor 🫶 a BGP speaker that re-advertises a route MUST generate its own Path Identifier for that re-advertised route 🔁 and a BGP speaker that receives a route should not assume the identifier carries any particular semantics 🙅‍♀️

3. Extended NLRI Encodings 🧚

to carry the Path Identifier in an UPDATE message, the NLRI encoding MUST be extended by prepending the Path Identifier field, which is four octets long 💫

for example, the NLRI encoding from [RFC4271] gets extended like this:

                  +--------------------------------+
                  | Path Identifier (4 octets)     |
                  +--------------------------------+
                  | Length (1 octet)               |
                  +--------------------------------+
                  | Prefix (variable)              |
                  +--------------------------------+

the usage of the extended NLRI encodings is specified in Section 5 🔜

4. ADD-PATH Capability 👑

the ADD-PATH Capability is a BGP capability [RFC5492] with Capability Code 69 🎀 its Capability Length field is variable 📏 the Capability Value field holds one or more of these tuples:

                +------------------------------------------------+
                | Address Family Identifier (2 octets)           |
                +------------------------------------------------+
                | Subsequent Address Family Identifier (1 octet) |
                +------------------------------------------------+
                | Send/Receive (1 octet)                         |
                +------------------------------------------------+

here's what each field means 🍓

  • Address Family Identifier (AFI): same as the one used in [RFC4760] 💅
  • Subsequent Address Family Identifier (SAFI): also same as the one in [RFC4760] 💖
  • Send/Receive: this one says whether the sender is (a) able to receive multiple paths from its peer (value 1), (b) able to send multiple paths to its peer (value 2), or (c) both (value 3), for the <AFI, SAFI> 🌈

if any other value shows up, the capability SHOULD be treated as not understood and ignored [RFC5492] 🙈

and a BGP speaker that wants to indicate support for multiple AFI/SAFIs MUST do it by including that info in a single instance of the ADD-PATH Capability 🫶

✨ the ADD-PATH Capability is the one place where all of your AFI/SAFI support goes, so you only need one instance to cover them all. 🧚

8. Security Considerations 🔒✨

Okay bestie, security time, and this part is serious 😭🔥. This document adds a BGP extension that lets a router advertise multiple paths for the same address prefix without the new paths automatically kicking the old ones out 🫣. That's the whole point, but it also means a BGP speaker can end up receiving a ton of paths for a huge number of prefixes. That can eat up memory and even cause instability across the whole network, which counts as a denial-of-service attack 💀. ngl that's scary. BUT, and this matters, this is not a brand-new vulnerability. It's already there in the base BGP spec, as described in [RFC4272] 🫶.

The ADD-PATH Capability is meant to solve specific problems, like getting rid of route oscillations caused by the MULTI_EXIT_DISC (MED) attribute [STOP-OSC] 🦋. Describing every application of ADD-PATH is outside this document's scope, so the document just encourages people to look at how they behave and what impact they might have, using the best practices in [ADDPATH] 🧚. Do your homework, periodt 💅.

Security concerns from the base operation of BGP [RFC4271] also apply here 🌈. Nothing gets a pass just because it's a fun new feature 🙈.

9. References 📚

9.1. Normative References 💜

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271,
           DOI 10.17487/RFC4271, January 2006,
           <http://www.rfc-editor.org/info/rfc4271>.

[RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
           "Multiprotocol Extensions for BGP-4", RFC 4760,
           DOI 10.17487/RFC4760, January 2007,
           <http://www.rfc-editor.org/info/rfc4760>.

[RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
           with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
           2009, <http://www.rfc-editor.org/info/rfc5492>.

9.2. Informative References 🎀

[ADDPATH]  Uttaro, J., Francois, P., Patel, K., Haas, J., Simpson,
           A., and R. Fragassi, "Best Practices for Advertisement of
           Multiple Paths in IBGP", Work in Progress,
           draft-ietf-idr-add-paths-guidelines-08, April 2016.

[FAST]     Mohapatra, P., Fernando, R., Filsfils, C., and R. Raszuk,
           "Fast Connectivity Restoration Using BGP Add-path", Work
           in Progress, draft-pmohapat-idr-fast-conn-restore-03,
           January 2013.

[RFC3345]  McPherson, D., Gill, V., Walton, D., and A. Retana,
           "Border Gateway Protocol (BGP) Persistent Route
           Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345,
           August 2002, <http://www.rfc-editor.org/info/rfc3345>.

[RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
           RFC 4272, DOI 10.17487/RFC4272, January 2006,
           <http://www.rfc-editor.org/info/rfc4272>.

[RFC4724]  Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
           Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
           DOI 10.17487/RFC4724, January 2007,
           <http://www.rfc-editor.org/info/rfc4724>.

[STOP-OSC] Walton, D., Retana, A., Chen, E., and J. Scudder, "BGP
           Persistent Route Oscillation Solutions", Work in Progress,
           draft-ietf-idr-route-oscillation-stop-03, April 2016.

Acknowledgments 🫶

Huge thanks to David Cook and Naiming Shen for their work on designing and building this extension 👑.

Lots of people also gave really valuable comments and suggestions, and they deserve all the love 💖: Rex Fernando, Eugene Kim, Danny McPherson, Dave Meyer, Pradosh Mohapatra, Keyur Patel, Robert Raszuk, Eric Rosen, Srihari Sangli, Dan Tappan, Mark Turner, Jeff Haas, Jay Borkenhagen, Mach Chen, Denis Ovsienko, Carlos Pignataro, Meral Shirazipour, and Kathleen Moriarty ✨.

Authors' Addresses 🦋

Daniel Walton
Cumulus Networks
185 E. Dana Street
Mountain View, CA  94041
United States of America

Email: dwalton@cumulusnetworks.com


Alvaro Retana
Cisco Systems, Inc.
Kit Creek Rd.
Research Triangle Park, NC  27709
United States of America

Email: aretana@cisco.com


Enke Chen
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA  95134
United States of America

Email: enkechen@cisco.com


John Scudder
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA  94089
United States of America

Email: jgs@juniper.net
📦 where this page comes from