RFC 1773

Experience with the BGP-4 protocol 🦋

Okay bestie, so this is RFC 1773 💖 It's an Informational doc, which means it's sharing knowledge with the Internet community and doesn't set any standard 🎀. Its author is P. Traina from cisco Systems, and it dropped in March 1995 📅. It obsoletes RFC 1656 ✨, so it's basically the replacement for that one. The title block doesn't list any RFC it updates.

---

Status of This Memo 📜

So this memo is just here to give info to the Internet community 💅. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share the love 🫶

Introduction 🌸

The whole point of this memo is to document how the requirements for moving a routing protocol up to Draft Standard have been met by Border Gateway Protocol version 4 (BGP-4) 🔥 It's basically the receipts that BGP got the job done, lol. This report covers experience with BGP, and it's the second of two reports on the BGP protocol 🧚 The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG) asked for the first report, which is a performance analysis of BGP.

The rest of this memo shows how BGP satisfies the General Requirements in Section 3.0, along with the Requirements for Draft Standard in Section 5.0 of the "Internet Routing Protocol Standardization Criteria" document [1]. Very organized, very iconic 👑

This report is built on the early work of Peter Lothberg (Ebone), Andrew Partan (Alternet), and a bunch of other people 🍓 Their work was presented at the Twenty-fifth IETF meeting, and you can still find it in the IETF proceedings.

Send your comments to iwg@ans.net 💌

Acknowledgments 🫶

The BGP protocol was developed by the IDR (formerly BGP) Working Group of the Internet Engineering Task Force. I want to give the biggest thank-you to Yakov Rekhter and Sue Hares, who were co-chairs of the IDR working group 🙏 I also want to specifically thank Yakov Rekhter and Tony Li for reviewing this document and giving super constructive, valuable comments. They're the real MVPs 🏆

Documentation 📚

Okay, so BGP is an inter-autonomous system routing protocol made for TCP/IP internets 🌈 Version 1 was published in RFC 1105. After that, BGP Versions 2, 3, and 4 were developed. Version 2 is documented in RFC 1163, and Version 3 is documented in RFC 1267. The changes between versions 1, 2, and 3 are explained in Appendix 2 of [2]. The main takeaway is that everything that worked in the earlier versions still works in version 4 ✨

Here's how each version glowed up:

• BGP version 2 removed the concept of "up", "down", and "horizontal" relations between autonomous systems that version 1 had. It also introduced path attributes and cleared up parts of the protocol that were "under-specified" 💅
• BGP version 3 loosened some of the restrictions on the use of the NEXT_HOP path attribute. It also added the BGP Identifier field to the BGP OPEN message. And it clarified how BGP routes get distributed between BGP speakers inside an autonomous system 🧚
• BGP version 4 redefines the network layer reachability information in updates, which used to be class-based. Now prefixes can have arbitrary length, so multiple classful networks can be represented in a single entry, as discussed in [5] 🦋 It also changed the AS-PATH attribute so that sets of autonomous systems, as well as individual ASs, can be described. And it redescribed the INTER-AS METRIC attribute as the MULTI-EXIT DISCRIMINATOR, plus it added the new LOCAL-PREFERENCE and AGGREGATOR attributes. Main character energy, literally 👑

Possible applications of BGP on the Internet are documented in [3] 🌸

The BGP protocol was developed by the IDR Working Group of the Internet Engineering Task Force. This group has a mailing list, iwg@ans.net, where people chat about protocol features and how things operate 💜 The IDR Working Group meets regularly during the quarterly Internet Engineering Task Force conferences, and the reports from those meetings get published in the IETF's Proceedings 🍓

MIB 🎀

A BGP-4 Management Information Base has been published [4] ✨ It was written by Steve Willis (Wellfleet), John Burruss (Wellfleet), and John Chu (IBM). Iconic team 🙌

Apart from a few system variables, the BGP MIB is split into two tables: the BGP Peer Table and the BGP Received Path Attribute Table 🌈

The Peer Table holds info about BGP peer connections, like their state and what they're currently doing 🫶 The Received Path Attribute Table holds every attribute received from all peers before local routing policy gets applied. The attributes that actually get used to decide a route are only a subset of that received attribute table 🧚

Metrics ✨

okay so BGP version 4 took the old INTER-AS metric and re-defined it as the MULTI-EXIT-DISCRIMINATOR 💅 this value may be used in the tie breaking process when someone is picking a preferred path to a given address space. the MED is only meant to be used when you're comparing paths that came in from different external peers in the same AS, so it shows the preference of the originating AS 🎀

the MED was purposely designed to be a "weak" metric, which is giving humble 🥺 it only gets used really late in the best-path decision process. the BGP working group was lowkey worried that any metric set by a remote operator would only mess with routing inside a local AS if no other preference had been specified 😭 so a paramount goal of the MED design was making sure peers could not "shed" or "absorb" traffic for the networks they advertise 🫶

the LOCAL-PREFERENCE attribute was added so a local operator could easily set up a policy that overrides the standard best path determination mechanism, without having to configure local preference on each router 👑

one shortcoming in the BGP4 spec was a suggestion for a default value of LOCAL-PREF to be assumed if none was provided 🙈 defaults of 0 or the maximum value each have range limitations, so a common default would help multi-vendor routers in the same AS get along. (since LOCAL-PREF is a local administration knob, there is no interoperability drawback across AS boundaries 🌈)

another area that still needs exploring is a method where an originating AS may influence the best path selection process 🔍 for example, a dual-connected site may select one AS as a primary transit service provider and have one as a backup.

                    /---- transit B ----\
        end-customer                     transit A----
                    \---- transit C ----/

in a topology where the two transit service providers connect to a third provider, the real decision is made by the third provider 😬 and there is literally no mechanism for indicating a preference should the third provider wish to respect that preference.

a general purpose suggestion that has been brought up is carrying an optional vector corresponding to the AS-PATH, where each transit AS may indicate a preference value for a given route 💜 cooperating ASs may then choose traffic based on comparing the "interesting" portions of this vector according to routing policy.

while protecting a given AS's routing policy is of paramount concern, avoiding extensive hand configuration of routing policies needs to be examined more carefully in future BGP-like protocols 🦋

Internal BGP in large autonomous systems

while not strictly a protocol issue, one other concern has been raised by network operators who need to maintain autonomous systems with a large number of peers 🌸 each speaker peering with an external router is responsible for propagating reachability and path information to all other transit and border routers within that AS. this is typically done by establishing internal BGP connections to all transit and border routers in the local AS.

in a large AS, this leads to an n^2 mesh of TCP connections and some method of configuring and maintaining those connections 😵‍💫 BGP does not specify how this information is to be propagated, so alternatives, such as injecting BGP attribute information into the local IGP, have been suggested. also, there is effort underway to develop internal BGP "route reflectors" or a reliable multicast transport of IBGP information, which would reduce the configuration, memory and CPU requirements of conveying information to all other internal BGP peers 🧚

Internet Dynamics

as discussed in [7], the driving force in CPU and bandwidth utilization is the dynamic nature of routing in the Internet 📈 as the net has grown, the number of changes per second has increased. we automatically get some level of damping when more specific NLRI is aggregated into larger blocks, however this isn't sufficient 🙃 in Appendix 6 of [2] are descriptions of dampening techniques that should be applied to advertisements. in future specifications of BGP-like protocols, damping methods should be considered for mandatory inclusion in compliant implementations 🔥

---

Author's Address

Paul Traina
cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134

EMail: pst@cisco.com

References

[1] Hinden, R., "Internet Routing Protocol Standardization Criteria", RFC 1264, BBN, October 1991.

[2] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995.

[3] Rekhter, Y., and P. Gross, Editors, "Application of the Border Gateway Protocol in the Internet", RFC 1772, T.J. Watson Research Center, IBM Corp., MCI, March 1995.

[4] Willis, S., Burruss, J., and J. Chu, "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, Wellfleet Communications Inc., IBM Corp., July 1994.

[5] Fuller V., Li. T., Yu J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, cisco, MERIT, OARnet, September 1993.

[6] Traina P., "BGP-4 Protocol Document Roadmap and Implementation Experience", RFC 1656, cisco Systems, July 1994.

[7] Traina P., "BGP Version 4 Protocol Analysis", RFC 1774, cisco Systems, March 1995.