RFC 1772

Application of the Border Gateway Protocol in the Internet

📅 published March 1995, from ietf

Application of the Border Gateway Protocol in the Internet 🦋

okay bestie, so this is RFC 1772 ✨ It's a Standards Track doc from the Network Working Group, dated March 1995. It obsoletes RFC 1655, so that one's retired now 🫡 The title block doesn't list any RFCs it updates. The editors are Y. Rekhter (T.J. Watson Research Center, IBM Corp.) and P. Gross (MCI) 👑

Status of this Memo 📜

this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 For the 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 🌈

Abstract ✨

this doc, together with its companion doc, "A Border Gateway Protocol 4 (BGP-4)", defines an inter-autonomous system routing protocol for the Internet 🛣️ "A Border Gateway Protocol 4 (BGP-4)" is where the BGP protocol specification lives, and this doc is all about how BGP gets used on the Internet 💅

Info about how BGP is progressing can be monitored and/or reported on the BGP mailing list (bgp@ans.net) 📬

Acknowledgements 🫶

this doc was originally published as RFC 1164 in June 1990 🕰️ It was jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu (MERIT) 🌸

The following folks 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) 💜

We'd like to explicitly thank Bob Braden (ISI) for reviewing the previous version of this doc 🙏

This updated version is the product of the IETF BGP Working Group, with Phill Gross (MCI) and Yakov Rekhter (IBM) as editors 🎀

John Moy (Proteon) contributed Section 7 "Required set of supported routing policies" 🍓

Scott Brim (Cornell University) contributed the basis for Section 8 "Interaction with other exterior routing protocols" 🧚

Most of the text in Section 9 was contributed by Gerry Meyer (Spider) 🦋

Parts of the Introduction were taken almost verbatim from [3] 📚

We'd also like to acknowledge Dan Long (NEARNET) and Tony Li (cisco Systems) for their review and comments on the current version of the doc 🫶

The work of Yakov Rekhter was supported in part by the National Science Foundation under Grant Number NCR-9219216 💖

1. Introduction ✨

okay so this memo describes how the Border Gateway Protocol (BGP) [1] gets used in the Internet environment 🌐 BGP is an inter-Autonomous System routing protocol 💅 The network reachability info exchanged via BGP is enough to detect routing loops and enforce routing decisions based on performance preference and policy constraints, as outlined in RFC 1104 [2] 🔥 In particular, BGP exchanges routing information containing full AS paths and enforces routing policies based on configuration information 🫶

As the Internet has evolved and grown over recent years, it's become painfully evident that it's soon going to face several serious scaling problems 😭 These include:

  • Exhaustion of the class-B network address space. One fundamental cause of this problem is the lack of a network class of a size which is appropriate for mid-sized organization: class-C, with a maximum of 254 host addresses, is too small, while class-B, which allows up to 65534 addresses, is too large to be densely populated. 🙈
  • Growth of routing tables in Internet routers is beyond the ability of current software (and people) to effectively manage. 💀
  • Eventual exhaustion of the 32-bit IP address space. 🌈

It's become clear that the first two of these problems are likely to become critical within the next one to three years ⏰ Classless inter-domain routing (CIDR) tries to tackle these problems by proposing a mechanism to slow the growth of the routing table and the need for allocating new IP network numbers 🧠 It does not attempt to solve the third problem, which is more long-term in nature. Instead it endeavors to ease enough of the short to mid-term difficulties to let the Internet keep functioning efficiently while progress is made on a longer-term solution ✨

BGP-4 is an extension of BGP-3 that provides support for routing information aggregation and reduction based on the Classless inter-domain routing architecture (CIDR) [3] 💜 This memo describes the usage of BGP-4 in the Internet 🦋

All of the discussions here are based on the assumption that the Internet is a collection of arbitrarily connected Autonomous Systems. That is, the Internet will be modeled as a general graph whose nodes are AS's and whose edges are connections between pairs of AS's 🕸️

The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other AS's 🏠 Since this classic definition was developed, it's become common for a single AS to use several interior gateway protocols and sometimes several sets of metrics within an AS. So the use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other AS's to have a single coherent interior routing plan, and it presents a consistent picture of which destinations are reachable through it 👑

AS's are assumed to be administered by a single administrative entity, at least for the purposes of representing routing information to systems outside of the AS 🎀

2. BGP Topological Model 🌸

when we say that a connection exists between two AS's, we mean two things:

  • Physical connection: There is a shared Data Link subnetwork between the two AS's, and on this shared subnetwork each AS has at least one border gateway belonging to that AS. Thus the border gateway of each AS can forward packets to the border gateway of the other AS without resorting to Inter-AS or Intra-AS routing. 🧚
  • BGP connection: There is a BGP session between BGP speakers in each of the AS's, and this session communicates those routes that can be used for specific destinations via the advertising AS. 🦋

Throughout this document we place an additional restriction on the BGP speakers that form the BGP connection: they must themselves share the same Data Link subnetwork that their border gateways share. Thus, a BGP session between adjacent AS's requires no support from either Inter-AS or Intra-AS routing. Cases that do not conform to this restriction fall outside the scope of this document 🚫

So at each connection, each AS has one or more BGP speakers and one or more border gateways, and all of these BGP speakers and border gateways are located on a shared Data Link subnetwork 🫶 Note that BGP speakers do not 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 shared subnetwork, i.e. indirect neighbors are allowed 🌈

Much of the traffic carried within an AS either originates or terminates at that AS (i.e., either the source IP address or the destination IP address of the IP packet identifies a host internal to that AS) 🏡 Traffic that fits this description is called "local traffic". Traffic that does not fit this description is called "transit traffic". A major goal of BGP usage is to control the flow of transit traffic 🎯

Based on how a particular AS deals with transit traffic, the AS may now be placed into one of the following 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. 🚚

Since a full AS path provides an efficient and straightforward way of suppressing routing loops, and it eliminates the "count-to-infinity" problem associated with some distance vector algorithms, BGP imposes no topological restrictions on the interconnection of AS's 🧠🔥

3. BGP in the Internet 💜

3.1 Topology Considerations

the overall Internet topology may be viewed as an arbitrary interconnection of transit, multihomed, and stub AS's 🕸️ To minimize the impact on the current Internet infrastructure, stub and multihomed AS's need not use BGP. These AS's may run other protocols (e.g., EGP) to exchange reachability information with transit AS's. Transit AS's using BGP will tag this information as having been learned by some method other than BGP 🏷️ The fact that BGP need not run on stub or multihomed AS's has no negative impact on the overall quality of inter-AS routing for traffic that is either destined to or originated from the stub or multihomed AS's in question 💅

However, it is recommended that BGP be used for stub and multihomed AS's as well 👀 In these situations, BGP will provide an advantage in bandwidth and performance over some of the currently used protocols (such as EGP). On top of that, this would reduce the need for default routes, and it leads to 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 information among multiple Autonomous Systems 🌍 The information flows can be represented like this:

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

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

This diagram points out that, while BGP alone carries information between AS's, both BGP and an IGP may carry information across an AS 🫧 Making sure routing information stays consistent between BGP and an IGP within an AS is a big deal, and it's discussed at length later in Appendix A 🌟

3.3 BGP Neighbor Relationships ✨

okay so the internet is basically a giant web of arbitrarily connected AS's 🌐. Routers that talk to each other directly over BGP are called BGP speakers 🗣️. Speakers can live in the same AS or in totally different AS's, and the speakers in each AS chat with each other to swap network reachability info based on policies that AS has set up for itself 💅. From one speaker's point of view, another speaker it talks to is an external peer if it's in a different AS, and an internal peer if it's in the same AS. iconic 👑

There can be as many BGP speakers as deemed necessary within an AS 🌸. Usually, if an AS has multiple connections to other AS's, you'll need multiple BGP speakers. All the speakers representing the same AS must give a consistent image of that AS to the outside world, which basically means they need consistent routing information among themselves 🫶. Those gateways can chat over BGP or by other means 📡. The policy constraints for every BGP speaker inside an AS must be consistent 🧩. Techniques like using a tagged IGP (see A.2.2) may be employed to sniff out possible inconsistencies 🕵️‍♀️.

For external peers, the two peers must belong to different AS's but share a common Data Link subnetwork 🔗. That common subnetwork should be used to carry the BGP messages between them 📬. Running BGP across an intervening AS invalidates the AS path information 💀. An Autonomous System number must be used with BGP to say which Autonomous System the BGP speaker belongs to 🔢.

4. Requirements for Route Aggregation 🎀

okay this part is a big deal 🍓. A conformant BGP-4 implementation is required to have the ability to specify when an aggregated route may be generated out of partial routing information. For example, a BGP speaker at the border of an autonomous system (or group of autonomous systems) must be able to generate an aggregated route for a whole set of destination IP addresses (in BGP-4 terminology, such a set is called the Network Layer Reachability Information or NLRI) over which it has administrative control, including the addresses it has delegated, even when not all of them are reachable at the same time.

A conformant implementation may provide the capability to specify when an aggregated NLRI may be generated.

A conformant implementation is required to have the ability to specify how NLRI may be de-aggregated.

A conformant implementation is required to support the following options when dealing with overlapping routes:

  • Install both the less and the more specific routes
  • Install the more specific route only
  • Install the less specific route only
  • Install neither route

Certain routing policies may depend on the NLRI (e.g. "research" versus "commercial"). Therefore, a BGP speaker that performs route aggregation should be cognizant, if possible, of potential implications on routing policies when aggregating NLRI 🧠.

5. Policy Making with BGP 💅

BGP gives you the ability to enforce policies based on various routing preferences and constraints 💖. Policies aren't directly encoded in the protocol. Instead, they're handed to BGP as configuration information ⚙️.

BGP enforces policies by affecting which paths get picked from multiple alternatives, and by controlling how routing information gets redistributed 🔀. The AS administration is the one who decides what the policies are 👩‍💼.

Routing policies are tied to political, security, or economic considerations. For example, if an AS doesn't want to carry traffic to another AS, it can enforce a policy that prohibits this 🚫. Here are some examples of 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 only advertising routes to destinations internal to the AS.)
  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 number of performance-related criteria can also be controlled with BGP ⚡:

  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 determines that two or more AS paths can be used to reach a given destination, that AS can use a variety of means to decide which of the candidate AS paths 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. Information about these qualities might be determined by means other than BGP.
  3. Preference of internal routes over external routes.

For consistency within an AS, equal cost paths, which come from combinations of policies and/or normal route selection procedures, must be resolved in a consistent fashion 🎯.

Fundamental to BGP is the rule that an AS advertises to its neighboring AS's only those routes that it uses. This rule reflects the "hop-by-hop" routing paradigm generally used by the current Internet 🌈.

6. Path Selection with BGP 👑

One of the major jobs of a BGP speaker is to evaluate the different paths from itself to a set of destinations covered by an address prefix, pick the best one, apply the appropriate policy constraints, and then advertise it to all of its BGP neighbors 📣. The key question is how the different paths get evaluated and compared. In traditional distance vector protocols (e.g., RIP), a path has only one metric (e.g., hop count) attached to it, so comparing paths just means comparing two numbers 🔢. Inter-AS routing gets complicated 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 up of the set of all feasible paths and the list of destinations (expressed as address prefixes) reachable through each path 🗂️. For the sake of precise discussion, it's useful to think about the set of feasible paths for a set of destinations associated with a given address prefix. In most cases, you'd expect to find only one feasible path. But when that isn't the case, all feasible paths should be maintained, because 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 complete order over the set of all feasible paths to a set of destinations associated with a given address prefix 📐. One way to define this complete order is to define a function that maps each full AS path to a non-negative integer, which denotes that path's degree of preference. Path selection then just means 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 as 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 as configuration information).

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

  • AS count. Paths with a smaller AS count are generally better.
  • Policy considerations. 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., 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, so they should be treated very carefully 🥹.

7. Required set of supported routing policies 🌸

okay so policies get handed to BGP as configuration information 🎀. That info isn't directly encoded in the protocol, which is why BGP can support super complex routing policies 🧠. However, it is not required that all BGP implementations support such policies.

Real talk, we're not trying to standardize the routing policies that must be supported in every BGP implementation 🙅‍♀️. We're just really, really encouraging all

implementors to support this set of routing policies, bestie 💖:

  1. okay so BGP implementations SHOULD let an AS control the announcements of BGP-learned routes to its adjacent AS's 🎀. That control SHOULD work at least at the granularity of a single address prefix ✨, and implementations SHOULD also support it at the granularity of an autonomous system 🫶. That autonomous system can be either the one that originated the route or the one that advertised the route to the local system (the adjacent AS) 💅.

this next part is the big one 😭 Care MUST be taken when a BGP speaker picks a new route that can't be announced to a particular external peer, while the route it picked before was announced to that peer. Specifically, the local system MUST explicitly tell the peer that the previous route is now infeasible 🙈.

  1. BGP implementations SHOULD let an AS prefer a particular path to a destination when more than one path is available 👑. At the very minimum, an implementation SHALL support this by letting someone administratively assign a degree of preference to a route, based solely on the IP address of the neighbor the route came from ✨. The allowed range for that degree of preference SHALL be between 0 and 2^(31) - 1 🔥.
  2. BGP implementations SHOULD let an AS ignore routes that have certain AS's in the AS_PATH path attribute 🙈. This can be done with the technique from [2], by assigning "infinity" as "weights" for those AS's 💀. The route selection process MUST ignore routes that have a "weight" equal to "infinity" 🧚.

8. Interaction with other exterior routing protocols ✨

The guidelines in this section are consistent with the ones in [3] 🎀.

An AS SHOULD advertise a minimal aggregate for its internal destinations, based on how much address space it's actually using 🍓. Admins of non-BGP 4 AS's can use that to figure out how many routes to explode from a single aggregate 🧩.

A route that carries the ATOMIC_AGGREGATE path attribute SHALL NOT be exported into either BGP-3 or EGP2, unless the export can happen without exploding the NLRI of the route 🚫.

8.1 Exchanging information with EGP2 💖

This doc suggests the following guidelines for swapping routing information between BGP-4 and EGP2 ✨.

For graceful migration, a BGP speaker MAY participate in EGP2 as well as in BGP-4 🦋. So a BGP speaker MAY receive IP reachability information through EGP2 as well as through BGP-4 🌸. Info received by EGP2 can be injected into BGP-4 with the ORIGIN path attribute set to 1 ✨. And the reverse works too: info received via BGP-4 can be injected into EGP2 🔁. In that case, though, you have to watch out for the potential information explosion when a given IP prefix received from BGP-4 denotes a set of consecutive A/B/C class networks 💀. Injecting BGP-4 received NLRI that denotes IP subnets requires the BGP speaker to inject the corresponding network into EGP2 🧩. The local system SHALL provide mechanisms to control the exchange of reachability information between EGP2 and BGP-4 🎀. Specifically, a conformant implementation is REQUIRED to support all of the following options when injecting BGP-4 received reachability information into EGP2 👑:

  • inject default only (0.0.0.0); no export of any other NLRI 🎯
  • allow controlled deaggregation, but only of specific routes; allow export of non-aggregated NLRI 🧁
  • allow export of only non-aggregated NLRI 🌷

The exchange of routing information via EGP2 between a BGP speaker participating in BGP-4 and a pure EGP2 speaker MAY occur only at the domain (autonomous system) boundaries 🚧.

8.2 Exchanging information with BGP-3 🌈

This doc suggests the following guidelines for swapping routing information between BGP-4 and BGP-3 💅.

For graceful migration, a BGP speaker MAY participate in BGP-3 as well as in BGP-4 🦋. So a BGP speaker MAY receive IP reachability information through BGP-3 as well as through BGP-4 🌸.

A BGP speaker MAY inject the information received by BGP-4 into BGP-3 as follows 👇.

If an AS_PATH attribute of a BGP-4 route carries AS_SET path segments, then the AS_PATH attribute of the BGP-3 route SHALL be constructed by treating the AS_SET segments as AS_SEQUENCE segments, with the resulting AS_PATH being a single AS_SEQUENCE ✨. Yes, this loses the set/sequence info, but it doesn't mess with the protection against routing loops 🔁. It may affect policies, though, if they're based on the content or ordering of the AS_PATH attribute 🤔.

While injecting BGP-4 derived NLRI into BGP-3, you have to watch out for the potential information explosion when a given IP prefix denotes a set of consecutive A/B/C class networks 💥. Injecting BGP-4 derived NLRI that denotes IP subnets requires the BGP speaker to inject the corresponding network into BGP-3 🧩. The local system SHALL provide mechanisms to control the exchange of routing information between BGP-3 and BGP-4 🎀. Specifically, a conformant implementation is REQUIRED to support all of the following options when injecting BGP-4 received routing information into BGP-3 👑:

  • inject default only (0.0.0.0), no export of any other NLRI 🎯
  • allow controlled deaggregation, but only of specific routes; allow export of non-aggregated NLRI 🧁
  • allow export of only non-aggregated NLRI 🌷

The exchange of routing information via BGP-3 between a BGP speaker participating in BGP-4 and a pure BGP-3 speaker MAY occur only at the autonomous system boundaries 🚧. Within a single autonomous system, BGP conversations between all the BGP speakers of that autonomous system have to be either BGP-3 or BGP-4, but not a mixture 🙅.

9. Operations over Switched Virtual Circuits 🧚

When BGP runs over Switched Virtual Circuit (SVC) subnetworks, it may be desirable to minimize the traffic BGP generates 💸. In particular, it may be desirable to get rid of the traffic from periodic KEEPALIVE messages 🙈. BGP has a mechanism for operating over SVC services that avoids keeping SVCs permanently open, and it lets BGP stop sending periodic KEEPALIVE messages 🦋.

This section describes how to operate without periodic KEEPALIVE messages, to keep SVC usage low when you're using an intelligent SVC circuit manager 🧠. The proposed scheme MAY also be used on "permanent" circuits that support a feature like link quality monitoring or echo request to determine the status of link connectivity ✨.

The mechanism described in this section is only suitable between BGP speakers that are directly connected over a common virtual circuit 💕.

9.1 Establishing a BGP Connection 🎀

The feature gets selected by setting a zero Hold Time in the OPEN message 🔑.

9.2 Circuit Manager Properties 🛠️

The circuit manager MUST have sufficient functionality to be able to compensate for the lack of periodic KEEPALIVE messages 💪:

  • It MUST be able to determine link layer unreachability within a predictable, finite period after a failure occurs 🧭.
  • On determining unreachability, it SHOULD:
    • start a configurable dead timer (comparable to a typical Hold timer value) ⏱️
    • attempt to re-establish the Link Layer connection 🔄
  • If the dead timer expires, it SHOULD:
    • send an internal circuit DEAD indication to TCP 💀
  • If the connection is re-established, it SHOULD:
    • cancel the dead timer 🙅
    • send an internal circuit UP indication to TCP 🦋

9.3 TCP Properties 🌸

A small modification MUST be made to TCP so it can process internal notifications from the circuit manager 🧁:

  • DEAD: flush the transmit queue and abort the TCP connection 🗑️
  • UP: transmit any queued data, or allow an outgoing TCP call to proceed 🚀

9.4 Combined Properties 🫶

Some implementations may not be able to guarantee that the BGP process and the circuit manager operate as a single entity 🤷. In other words, they can have a separate existence, so one can be stopped or crash while the other keeps going 💔.

If this is the case, a periodic two-way poll between the BGP process and the circuit manager SHOULD be implemented 🔁. If the BGP process finds out the circuit manager has gone away, it SHOULD close all relevant TCP connections 🚪. If the circuit manager finds out the BGP process has gone away, it SHOULD close all of its connections associated with the BGP process and reject any further incoming connections 🙅.

10. Conclusion 🎉

BGP gives you a high degree of control and flexibility for interdomain routing 💖. It enforces policy and performance constraints and avoids routing loops while doing it 🌈. The guidelines presented here are a starting point for using BGP to build more sophisticated and manageable routing as the Internet grows 🌍.

Appendix A. The Interaction of BGP and an IGP ✨

This section outlines ways BGP can exchange routing information with an IGP 🌷. The methods here are not proposed as part of standard BGP usage at this time. They're outlined for information purposes only 💡. Implementors may want to consider these methods when importing IGP information 🤔.

This is general information 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 📄. Methods for specific IGP's 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 🚚. That requires a certain amount 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 originated from another border gateway (B) within the same AS, and the moment the IGP within that AS is capable of routing transit traffic to border gateway (B). During that time window, either incorrect routing or "black holes" can occur 🕳️.

To minimize such routing problems, border gateway (A) SHOULD NOT advertise to any of its external peers a route to some set of exterior destinations associated with a given address prefix X via border gateway (B) until all the interior gateways within the AS are ready to route traffic destined to these destinations 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 external peers 🫶.

A.2 Methods for Achieving Stable Interactions ✨

okay so this bit is all about the ways BGP and the IGP can get along inside one Autonomous System without drama 💅. The following techniques are the ones that can get them to play nice 🫶.

A.2.1 Propagation of BGP Information via the IGP

ngl, BGP can totally carry its own BGP info around inside an AS 💖. BUT you can also have the IGP transport it instead 🚀, as long as the IGP does complete flooding of routing info (that's the part that spreads the BGP info around) AND does one pass convergence (which makes the whole thing effectively atomic ✨).

So if the IGP is carrying the BGP info, the desynchronization period we talked about earlier just... doesn't happen at all 🙈. BGP info moves through the AS in sync with the IGP, and the IGP converges more or less at the same time the new routing info shows up. Main character energy 👑.

Bestie, the one thing to remember is that the IGP only carries BGP information. It should not interpret or process this information.

A.2.2 Tagged Interior Gateway Protocol

Some IGPs can tag routes that are exterior to an AS with the identity of their exit points while they propagate them inside the AS 🏷️. Each border gateway should use identical tags for announcing exterior routing information (received via BGP), both into the IGP and when it's passing that info along to other internal peers (peers within the same AS) 🎀. Tags generated by a border gateway must uniquely identify that particular border gateway--different border gateways must use different tags. Unique tags only, no copycats 💅.

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

  1. Information received from an internal peer by a border gateway A declaring a set of destination associated with a given address prefix to be unreachable must immediately be propagated to all of the external peers of A. 🚨
  2. Information received from an internal peer by a border gateway A about a set of reachable destinations associated with a given address prefix X cannot be propagated to any of the external peers of A unless/until A has an IGP route to the set of destinations covered by X and both the IGP and the BGP routing information have identical tags. 🫠

These rules guarantee that no routing information is announced externally unless the IGP is actually capable of correctly supporting it 🧚. They also avoid some causes of "black holes" 🕳️. Iconic, honestly.

One possible method for tagging BGP and IGP routes within an AS is to use the IP address of the exit border gateway that announces the exterior route into the AS 🌸. In this case, the "gateway" field in the BGP UPDATE message is used as the tag.

An alternate method is to have BGP and the IGP agree on a router ID 💜. In this case, the router ID is available to all BGP (version 3 or higher) speakers. Since this ID is already unique, it can be used directly as the tag in the IGP. Simple and slay ✨.

A.2.3 Encapsulation

Encapsulation is the simplest mechanism (in terms of the interaction between the IGP and BGP) for carrying transit traffic across the AS 🎁. In this approach, transit traffic is encapsulated within an IP datagram addressed to the exit gateway. The only requirement this puts on the IGP 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 destination X is specified in the BGP identifier field of the BGP OPEN message that gateway A sends (via BGP), and every other border gateway within the same AS receives it 📬. To route traffic to destination X, each border gateway within the AS encapsulates it in datagrams addressed to gateway A. Gateway A then performs decapsulation and forwards the original packet to the proper gateway in another AS. Packet inception, but make it networking 🍓.

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

Some means of identifying datagrams containing 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 to be encapsulated has a length that is very close to the MTU, that packet would be fragmented at the gateway that performs the encapsulation 🙈.

A.2.4 Pervasive BGP

If all routers in an AS are BGP speakers, then there is no need for any interaction between BGP and an IGP at all 💖. In that case, all routers in the AS already have full information about all BGP routes. The IGP is then only used for routing within the AS, and no BGP routes get imported into the IGP. Clean and minimal, iykyk 🌈.

For routers to operate this way, they must be able to perform a recursive lookup in their routing table 🔍. The first lookup will use a BGP route to establish the exit router, while the second lookup will determine the IGP path to the exit router.

Since the IGP carries no external information in this scenario, all routers in the AS will have converged as soon as all BGP speakers have new information about the route ⚡. There's no need to wait on the IGP to converge, so an implementation may advertise these routes without any further delay due to the IGP. Zero waiting, full vibes 💅.

A.2.5 Other Cases

Some ASes might have IGPs that can neither carry BGP information nor tag exterior routes (e.g., RIP) 😬. On top of that, encapsulation may be either infeasible or undesirable. In situations like these, the following two rules must be observed:

  1. Information received from an internal peer by a border gateway A declaring a destination to be unreachable must immediately be propagated to all of the external peers of A. 🚨
  2. Information received from an internal peer by a border gateway A about a reachable destination X cannot be propagated to any of the external peers of A unless A has an IGP route to X and sufficient time has passed for the IGP routes to have converged. ⏳

The above rules present necessary (but not sufficient) conditions for propagating BGP routing information to other AS's. Unlike tagged IGPs, these rules cannot ensure that interior routes to the proper exit gateways are in place before the routes are propagated to other AS's 🫣.

If the convergence time of an IGP is less than some small value X, then the time window during which the IGP and BGP are unsynchronized is less than X as well. In that case the whole issue can be ignored, at the cost of transient periods (of less than length X) of routing instability 🌀. 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 cannot be ignored, a different approach is needed. Mechanisms and techniques that might be appropriate in this situation are subjects for further study 🔮.

References

  • [1] 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.
  • [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104, Merit/NSFNET, June 1989.
  • [3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, OARnet, September 1993.

Security Considerations

Security issues are not discussed in this memo. 🚨

Authors' Addresses

Yakov Rekhter
T.J. Watson Research Center IBM Corporation
P.O. Box 704, Office H3-D40
Yorktown Heights, NY 10598

Phone: +1 914 784 7361
EMail: yakov@watson.ibm.com
Phill Gross
MCI Data Services Division
2100 Reston Parkway, Room 6001,
Reston, VA 22091

Phone: +1 703 715 7432
EMail: 0006423401@mcimail.com
IETF IDR WG mailing list: bgp@ans.net
To be added: bgp-request@ans.net
📦 where this page comes from