RFC 1268

Application of the Border Gateway Protocol in the Internet

📅 published October 1991, from ietf

Title Block 📜

Okay bestie, this is RFC 1268, called Application of the Border Gateway Protocol in the Internet 🎀 It's from the Network Working Group, dated October 1991. Y. Rekhter (T.J. Watson Research Center, IBM Corp.) and P. Gross (ANS) are the editors. It's an IAB standards track document, and it obsoletes RFC 1164. The title block doesn't list any RFC that it updates 💅

Status of this Memo 📜

So this protocol is being cooked up by the Border Gateway Protocol Working Group (BGP) of the Internet Engineering Task Force (IETF) 🍳 This RFC specifies an IAB standards track protocol for the Internet community, and it's basically asking everyone to talk about it and send in improvements 💬 If you want the current standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 🔍 And the best part: distribution of this memo is unlimited 🌈

Abstract 🌸

This document and its companion, "A Border Gateway Protocol (BGP-3)", together define an inter-autonomous system routing protocol for the Internet 🦋 The BGP protocol specification itself lives in "A Border Gateway Protocol (BGP-3)", while this document is all about how BGP gets used in the Internet ✨

Want news on BGP's progress? You can follow along and chat on the BGP mailing list (iwg@rice.edu) 💌

Table of Contents 🗂️

1. Introduction...................................................   2
2. BGP Topological Model..........................................   3
3. BGP in the Internet............................................   4
4. Policy Making with BGP.........................................   5
5. Path Selection with BGP........................................   6
6. Required set of supported routing policies.....................   8
7. Conclusion.....................................................   9
Appendix A. The Interaction of BGP and an IGP.....................   9
References........................................................  12
Security Considerations...........................................  12
Authors' Addresses................................................  13

Acknowledgements 🫶

Okay, the history: this document was originally published as RFC 1164 in June 1990 🕰️ It was jointly written by Jeffrey C. Honig (Cornell University), Dave Katz (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu (MERIT). Absolute legends 👑

Then there's the squad who also made key contributions to RFC 1164: Guy Almes (ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans-Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT) 🙌

This updated version came from the IETF BGP Working Group, with Phillip Gross (ANS) and Yakov Rekhter (IBM) as editors ✍️ John Moy (Proteon) contributed Section 6 "Recommended set of supported routing policies" 🧠

We also like to explicitly thank Bob Braden (ISI) for reviewing this document, plus his constructive and valuable comments 💖

1. Introduction ✨

Okay so this memo is all about how the Border Gateway Protocol (BGP) [1] gets used in the Internet environment 🌐 BGP is an inter-Autonomous System routing protocol, which means it's the one routing between AS's 💅 The network reachability info that BGP swaps around is enough to detect routing loops and enforce routing decisions based on performance preference and policy constraints, as outlined in RFC 1104 [2] 🔥 Specifically, BGP exchanges routing info with full AS paths and enforces routing policies based on configuration info 🎀

Every discussion in this paper is built on one big assumption: the Internet is a collection of arbitrarily connected Autonomous Systems 🕸️ So the Internet gets modeled as a general graph, where the nodes are AS's and the edges are the connections between pairs of AS's 📈

The classic definition of an Autonomous System is a set of routers under a single technical administration. They use an interior gateway protocol and common metrics to route packets within the AS, and an exterior gateway protocol to route packets to other AS's 🧚 Since that classic definition came out, it's become super common for a single AS to run several interior gateway protocols, and sometimes several sets of metrics inside the AS 🍓 The term Autonomous System here really stresses that, even with multiple IGPs and metrics, the administration of an AS still looks like one coherent interior routing plan to other AS's. It also presents a consistent picture of which networks are reachable through it 💜 From the standpoint of exterior routing, an AS can be viewed as monolithic: networks within an AS have to keep connectivity through intra-AS paths 🦋

AS's are assumed to be run by a single administrative entity, at least when it comes to representing routing info to systems outside the AS 💌

2. BGP Topological Model 🗺️

When we say a connection exists between two AS's, we mean two things, bestie 👯

  • Physical connection: There's a shared network between the two AS's, and on that shared network each AS has at least one border gateway belonging to that AS. So each AS's border gateway can forward packets to the other AS's border gateway without needing Inter-AS or Intra-AS routing 🌉
  • BGP connection: There's a BGP session between BGP speakers on each of the AS's. This session tells each connected AS which routes through the other AS's physically connected border gateways can be used for specific networks 📡 Throughout this document there's one extra restriction on the BGP speakers that form the BGP connection: they MUST themselves share the same network that their border gateways share 🔒 That means a BGP session between adjacent AS's needs no support from either Inter-AS or Intra-AS routing 🙌 Cases that don't follow this restriction are outside the scope of this document 🙅‍♀️

So at each connection, every AS has one or more BGP speakers and one or more border gateways, and they're all located on a shared network 🧸 Heads up: BGP speakers don't need to be a border gateway, and vice versa 💁‍♀️ Paths announced by a BGP speaker of one AS on a given connection are taken to be feasible for each of the border gateways of the other AS on the same connection. In other words, indirect neighbors are allowed 🫶

A lot of the traffic inside an AS either starts or ends at that AS. That means either the source IP address or the destination IP address of the IP packet identifies a host on a network directly connected to that AS 🏠 This is called "local traffic" 💖 Anything that doesn't fit that description is called "transit traffic" 🚚 A major goal of BGP usage is controlling the flow of transit traffic 🎯

Depending on how an AS deals with transit traffic, it can be placed into one of these categories ✨

  • stub AS: an AS that has only a single connection to one other AS. Naturally, a stub AS only carries local traffic 🌱
  • multihomed AS: an AS that has connections to more than one other AS, but refuses to carry transit traffic 🙅
  • transit AS: an AS that has connections to more than one other AS, and is designed (under certain policy restrictions) to carry both transit and local traffic 🛣️

Here's the tea 🫖: a full AS path is an efficient, straightforward way to suppress routing loops, and it gets rid of the "count-to-infinity" problem that some distance vector algorithms have. So BGP puts no topological restrictions on how AS's interconnect 🕊️

3. BGP in the Internet 🌈

3.1 Topology Considerations 🍓

The overall Internet topology can be viewed as an arbitrary interconnection of transit, multihomed, and stub AS's 🧩 To keep the impact on the current Internet infrastructure small, stub and multihomed AS's don't need to use BGP 🤍 These AS's MAY run other protocols (e.g., EGP) to exchange reachability info with transit AS's 🔁 Transit AS's using BGP will tag this info as having been learned by some method other than BGP 🏷️ The fact that BGP doesn't need to run on stub or multihomed AS's has no negative impact on the overall quality of inter-AS routing for traffic that isn't local to the stub or multihomed AS's in question 💯

However, it is RECOMMENDED that BGP MAY be used for stub and multihomed AS's as well 🌟 That gives an advantage in bandwidth and performance over some of the currently used protocols, like EGP 🚀 On top of that, it would mean less need for defaults and better choices of Inter-AS routes for multihomed AS's 🎀

3.2 Global Nature of BGP 💜

At a global level, BGP is used to distribute routing info among multiple Autonomous Systems 🌍 The info flows look like this 👇

             +-------+         +-------+
       BGP   |  BGP  |   BGP   |  BGP  |   BGP
    ---------+       +---------+       +---------
             |  IGP  |         |  IGP  |
             +-------+         +-------+

             <-AS A-->         <--AS B->

This diagram shows that while BGP alone carries info between AS's, a combo of BGP and an IGP carries info across an AS 🧁 Keeping routing info consistent between BGP and an IGP inside an AS is a big deal, and Appendix A talks about it at length 🤓

3.3 BGP Neighbor Relationships 👑

The Internet is viewed as a set of arbitrarily connected AS's 🕸️ BGP speakers in each AS talk to each other to swap network reachability info, based on a set of policies established inside each AS 🗣️ Routers that talk directly to each other via BGP are called BGP neighbors 👯‍♀️ BGP neighbors can live in the same AS or in different AS's 🏘️ For the sake of discussion, BGP communications with neighbors in different AS's are called External BGP, and communications with neighbors in the same AS are called Internal BGP 💬

There can be as many BGP speakers as deemed necessary within an AS 🙋 Usually, if an AS has multiple connections to other AS's, it needs multiple BGP speakers 🔌 All BGP speakers representing the same AS MUST give a consistent image of the AS to the outside 🪞 That requires the BGP speakers to have consistent routing info among themselves 🧠 These gateways can talk to each other via BGP or by other means 📮 The policy constraints applied to all BGP speakers within an AS MUST be consistent 📜 Techniques like using tagged IGP (see A.2.2) MAY be employed to detect possible inconsistencies 🕵️‍♀️

In the case of External BGP, the BGP neighbors MUST belong to different AS's, but they share a common network 🤝 This common network SHOULD be used to carry the BGP messages between them 📨 Using BGP across an intervening AS invalidates the AS path info ❌ And an Autonomous System number MUST be used with BGP to specify which Autonomous System the BGP speaker belongs to 🔢 Iykyk, and now you do too 💅

4. Policy Making with BGP ✨

okay so BGP can totally enforce policies based on different routing preferences and constraints 💅 but the policies aren't baked into the protocol itself. they get handed to BGP as configuration information 🎀

BGP enforces policies in two main ways. it affects which path gets picked from a bunch of alternatives, and it controls how routing information gets redistributed 🦋. the AS administration is the one who decides what the policies are 💖

routing policies are lowkey about politics, security, or money 💰. like, if an AS doesn't want to carry traffic to another AS, it can enforce a policy that just says no 🙅‍♀️. here are some routing policies you can enforce with BGP:

  1. A multihomed AS can refuse to act as a transit AS for other AS's. (It does this by not advertising routes to networks other than the ones directly connected to it.)
  2. A multihomed AS can become a transit AS for a restricted set of adjacent AS's, i.e., some, but not all, AS's can use the multihomed AS as a transit AS. (It does this by advertising its routing information to that set of AS's.)
  3. An AS can favor or disfavor the use of certain AS's for carrying transit traffic from itself.

a bunch of performance-related criteria can be controlled with BGP too 🏎️:

  1. An AS can minimize the number of transit AS's. (Shorter AS paths can be preferred over longer ones.)
  2. The quality of transit AS's. if an AS figures out that two or more AS paths can reach a given destination, it can use a variety of means to decide which candidate AS path it will use. the quality of an AS can be measured by things like diameter, link speed, capacity, tendency to become congested, and quality of operation. info about these qualities might come from somewhere other than BGP 🧠.
  3. Preference of internal routes over external routes.

for consistency within an AS, equal cost paths (the ones that come from combinations of policies and/or normal route selection procedures) must be resolved in a consistent fashion 🫶.

the big fundamental rule of BGP is that an AS advertises to its neighboring AS's only the routes that it actually uses 👑. this reflects the "hop-by-hop" routing paradigm that the current Internet generally uses, and it's giving very classic Internet energy 🌈.

5. Path Selection with BGP 🦋

one of the major jobs of a BGP speaker is to evaluate different paths to a destination network from its border gateways at that connection, select the best one, apply any applicable policy constraints, and then advertise it to all of its BGP neighbors at that same connection 💜. the key question is how different paths get evaluated and compared 🤔.

in traditional distance vector protocols (like RIP), there's only one metric (like hop count) attached to a path. so comparing paths is reduced to just comparing two numbers 🔢. inter-AS routing gets messy because there's no universally agreed-upon metric among AS's that can be used to evaluate external paths. instead, each AS may have its own set of criteria for path evaluation 🙃.

a BGP speaker builds a routing database made of the set of all feasible paths and the list of networks reachable through each path 🗂️. for precise discussion, it's useful to think about the set of feasible paths for a given destination network. in most cases we'd expect to find only one feasible path. but when that's not the case, all feasible paths should be maintained, and keeping them around speeds up adaptation to the loss of the primary path 🏃‍♀️. only the primary path at any given time will ever be advertised 📣.

the path selection process can be formalized by defining a partial order over the set of all feasible paths to a given destination network 📐. one way to define this partial order is to define a function that maps each full AS path to a non-negative integer, which denotes the path's degree of preference. path selection then comes down to applying this function to all feasible paths and choosing the one with the highest degree of preference 🏆.

in actual BGP implementations, the criteria for assigning degrees of preference to a path are specified in configuration information ⚙️.

the process of assigning a degree of preference to a path can be based on several sources of information:

  1. Information explicitly present in the full AS path.
  2. A combination of information that can be derived from the full AS path and information outside the scope of BGP (e.g., policy routing constraints provided at configuration).

possible criteria for assigning a degree of preference to a path are:

  • AS count. Paths with a smaller AS count are generally better.
  • Policy consideration. BGP supports policy-based routing based on the controlled distribution of routing information. A BGP speaker may be aware of some policy constraints (both within and outside of its own AS) and do appropriate path selection. Paths that do not comply with policy requirements are not considered further 🚫.
  • Presence or absence of a certain AS or AS's in the path. By means of information outside the scope of BGP, an AS may know some performance characteristics (e.g., bandwidth, MTU, intra-AS diameter) of certain AS's and may try to avoid or prefer them 🧐.
  • Path origin. A path learned entirely from BGP (i.e., one whose endpoint is internal to the last AS on the path) is generally better than one for which part of the path was learned via EGP or some other means 🌸.
  • AS path subsets. An AS path that is a subset of a longer AS path to the same destination should be preferred over the longer path. Any problem in the shorter path (such as an outage) will also be a problem in the longer path 💀.
  • Link dynamics. Stable paths should be preferred over unstable ones. Note that this criterion must be used in a very careful way to avoid causing unnecessary route fluctuation. Generally, any criteria that depend on dynamic information might cause routing instability and should be treated very carefully 🙈.

6. Required set of supported routing policies. 👑

policies are provided to BGP in the form of configuration information. this info isn't directly encoded in the protocol, so BGP can support some pretty complex routing policies 🧩. however, it is not required for all BGP implementations to support such policies.

we're not trying to standardize the routing policies that must be supported in every BGP implementation, but we strongly encourage all implementors to support the following set of routing policies 🥰:

  1. BGP implementations should allow an AS to control announcements of BGP-learned routes to adjacent AS's. Implementations should also support such control with at least the granularity of a single network. Implementations should also support such control with the granularity of an autonomous system, where the autonomous system may be either the autonomous system that originated the route, or the autonomous system that advertised the route to the local system (adjacent autonomous system) 📢.
  2. BGP implementations should allow an AS to prefer a particular path to a destination (when more than one path is available). This function should be implemented by allowing system administrators to assign "weights" to AS's, and making the route selection process select a route with the lowest "weight" (where the "weight" of a route is defined as the sum of the "weights" of all AS's in the AS_PATH path attribute associated with that route) ⚖️.
  3. BGP implementations should allow an AS to ignore routes with certain AS's in the AS_PATH path attribute. This function can be implemented by using the technique outlined in (2), and by assigning "infinity" as the "weight" for such AS's. The route selection process must ignore routes that have a "weight" equal to "infinity" 🙅.

7. Conclusion 🎀

the BGP protocol gives a high degree of control and flexibility for doing interdomain routing 🌐. it enforces policy and performance constraints while avoiding routing loops 🔁, and the guidelines here are a starting point for using BGP to deliver more sophisticated and manageable routing as the Internet keeps growing 📈. literally iconic ✨.

Appendix A. The Interaction of BGP and an IGP 🧚

this section outlines methods for BGP to exchange routing information with an IGP. these methods aren't proposed as part of standard BGP usage at this time 🙅‍♀️. they're here for information purposes only. implementors may want to consider these methods when importing IGP information 📚.

this is general info that applies to any generic IGP. interaction between BGP and any specific IGP is outside the scope of this section. methods for specific IGP's should be proposed in separate documents, and they could be proposed for standard usage in the future 🔮.

Overview

by definition, all transit AS's must be able to carry traffic that originates from and/or is destined to locations outside of that AS 🚚. this requires a certain degree of interaction and coordination between BGP and the Interior Gateway Protocol (IGP) used by that particular AS. in general, traffic originating outside a given AS is going to pass through both interior gateways (gateways that support the IGP only) and border gateways (gateways that support both the IGP and BGP). all interior gateways receive information about external routes from one or more of the border gateways of the AS via the IGP 🗺️.

depending on the mechanism used to propagate BGP information within a given AS, special care must be taken to ensure consistency between BGP and the IGP, since changes in state are likely to propagate at different rates across the AS 😬. there may be a time window between the moment when some border gateway (A) receives new BGP routing information that was originated from another border gateway (B) within the same AS, and the moment the IGP within this AS is capable of routing transit traffic to that border gateway (B). during that time window, either incorrect routing or "black holes" can occur 🕳️.

to minimize these routing problems, border gateway (A) should not advertise a route to some exterior network X via border gateway (B) to all of its BGP neighbors in other AS's until all the interior gateways within the AS are ready to route traffic destined to X via the correct exit border gateway (B). in other words, interior routing should converge on the proper exit gateway before/advertising routes via that exit gateway to other AS's 🚦.

A.2 Methods for Achieving Stable Interactions 🌷

the following discussion outlines several techniques capable of achieving stable interactions between BGP and the IGP within an Autonomous System 💫.

A.2.1 Propagation of BGP Information via the IGP ✨

okay so BGP can carry its own info around inside an AS 💅 but you can also use an IGP to haul that info instead, as long as the IGP does two things: complete flooding of routing info (that's how the BGP info gets spread around) and onepass convergence (which makes the whole thing basically atomic) 🫶. If an IGP is carrying BGP info, the desync period we talked about earlier just doesn't happen at all 🙈. BGP info moves through the AS in lockstep with the IGP, and the IGP converges more or less right when the new routing info shows up. Note that the IGP ONLY carries BGP info and SHOULD NOT interpret or process this information 💀.

A.2.2 Tagged Interior Gateway Protocol 🏷️

certain IGPs can tag exterior routes with the identity of their exit points while they're spreading them around the AS 🧚. Each border gateway SHOULD use identical tags when it announces exterior routing info (learned via BGP) into the IGP and into Internal BGP, so the other border gateways in the same AS get the same tags 🎀. Tags made by a border gateway MUST uniquely identify that particular border gateway, because different border gateways MUST use different tags. no sharing allowed 🙅‍♀️

All Border Gateways within a single AS MUST observe the following two rules:

  1. Information received via Internal BGP by a border gateway A declaring a network to be unreachable MUST immediately be propagated to all of the External BGP neighbors of A.
  2. Information received via Internal BGP by a border gateway A about a reachable network X cannot be propagated to any of the External BGP neighbors of A unless/until A has an IGP route to X and both the IGP and the BGP routing information have identical tags.

These rules basically guarantee that nothing gets announced externally unless the IGP can actually handle it properly 🔒. It also helps avoid some causes of "black holes" 🕳️💀.

One possible way to tag BGP and IGP routes inside an AS is to use the IP address of the exit border gateway that's announcing the exterior route into the AS. In that case, the gateway field in the BGP UPDATE message is what gets used as the tag 🦋.

A.2.3 Encapsulation 📦

Encapsulation is the simplest option (in terms of how the IGP and BGP have to interact) for carrying transit traffic across the AS 🍓. Here, transit traffic gets wrapped up inside an IP datagram addressed to the exit gateway. The only requirement the IGP has to meet for this approach is that it SHOULD be capable of supporting routing between border gateways within the same AS.

The address of the exit gateway A for some exterior network X is listed in the BGP identifier field of the BGP OPEN message. All the other border gateways in the same AS get that message from gateway A via Internal BGP 🫧. To route traffic to network X, each border gateway in the AS encapsulates it in datagrams addressed to gateway A. Gateway A then decapsulates it and forwards the original packet to the proper gateway in another AS 🚀.

Since encapsulation doesn't rely on the IGP to carry exterior routing info, no synchronization between BGP and the IGP is REQUIRED 🙌.

Some way of identifying datagrams that contain encapsulated IP, such as an IP protocol type code, MUST be defined if this method is going to be used 🧾.

Note that if a packet being encapsulated is very close to the MTU in length, that packet would get fragmented at the gateway doing the encapsulation 🧩.

A.2.4 Other Cases 🌈

There may be AS's with IGPs that can neither carry BGP info nor tag exterior routes (RIP, for example) 🦖. On top of that, encapsulation might be either infeasible or undesirable. In situations like these, the following two rules MUST be observed:

  1. Information received via Internal BGP by a border gateway A declaring a network to be unreachable MUST immediately be propagated to all of the External BGP neighbors of A.
  2. Information received via Internal BGP by a border gateway A about a reachable network X cannot be propagated to any of the External BGP neighbors of A unless A has an IGP route to X and sufficient time (holddown) has passed for the IGP routes to have converged ⏳.

The rules above are necessary (but not sufficient) conditions for passing BGP routing info on to other AS's. Compared with tagged IGPs, these rules cannot ensure that interior routes to the proper exit gateways are in place before the routes get propagated to other AS's 🫠.

If the convergence time of an IGP is less than some small value X, then the window during which the IGP and BGP are out of sync is less than X too. In that case the whole issue can be ignored, at the cost of short bursts (shorter than X) of routing instability 🌸. What counts as a reasonable value for X is a matter for further study, but X SHOULD probably be less than one second ⏱️.

If the convergence time of an IGP can't be ignored, a different approach is needed. The mechanisms and techniques that might work in that situation are subjects for further study 🔮.

References 📚

  • [1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM Corp., October 1991.
  • [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104, Merit/NSFNET, June 1989.

Security Considerations 🔐

Honestly? This memo doesn't discuss security issues at all 💀. Security issues are not discussed in this memo. 🙈

Authors' Addresses 💌

Yakov Rekhter
T.J. Watson Research Center IBM Corporation
P.O. Box 218
Yorktown Heights, NY 10598

Phone:  (914) 945-3896
EMail: yakov@watson.ibm.com


Phill Gross
Advanced Network and Services (ANS)
100 Clearbrook Road
Elmsford, NY 10523

Phone: (914) 789-5300
Email: pgross@NIS.ANS.NET

IETF BGP WG mailing list: iwg@rice.edu
To be added: iwg-request@rice.edu
📦 where this page comes from