RFC 1655

RFC 1655 💖 Application of the Border Gateway Protocol in the Internet

Okay so here's the header tea ☕✨

• Working group: Network Working Group 🌸
• Authors: Y. Rekhter (T.J. Watson Research Center, IBM Corp.) and P. Gross (MCI), both listed as Editors 🎀
• Category: Standards Track 🦋
• Date: July 1994 🌈
• Obsoletes: RFC 1268 💅
• Updates: not listed in the header 🙈

---

Status of this Memo 🫶

This document is an Internet standards track protocol for the Internet community, and it asks 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 document and its companion, "A Border Gateway Protocol 4 (BGP-4)", together define an inter-autonomous system routing protocol for the Internet 🌐. The companion doc is where the BGP protocol spec itself lives, and this one is all about how BGP actually gets used in the Internet 🦋.

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

Acknowledgements 🎀

Okay, the shoutouts are iconic 👑. This document was originally published as RFC 1164 in June 1990. It was co-written by Jeffrey C. Honig (Cornell University), Dave Katz (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu (MERIT) 💖.

Other people who made key contributions to RFC 1164 were Guy Almes (ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans-Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT) 🌟.

We also want to thank Bob Braden (ISI) for reviewing the previous version of this document 🙏.

This updated version came out 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] 📚.

Last but not least, Dan Long (NEARNET) and Tony Li (cisco Systems) reviewed the current version and gave their comments 🫶.

1. Introduction 🛣️

Okay so this memo explains how the Border Gateway Protocol (BGP) [1] gets used in the Internet environment 🌍. BGP is an inter-Autonomous System routing protocol 💅. The reachability info that BGP exchanges 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 that includes full AS paths, and it enforces routing policies based on configuration info 🔥.

The Internet has evolved and grown a lot in recent years, and it has become painfully obvious that it's about to face some serious scaling problems 😭. These include:

• Exhaustion of the class-B network address space. One fundamental cause is that there's no network class sized right for mid-sized organizations. 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 what current software (and people) can effectively manage 💀.
• Eventual exhaustion of the 32-bit IP address space ⏳.

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 handle them by proposing a mechanism to slow the growth of the routing table and the need for allocating new IP network numbers 🎀. It doesn't try to solve the third problem, which is more long-term. Instead, it aims to ease enough of the short to mid-term difficulties so the Internet can 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 how BGP-4 is used in the Internet 🦋.

All of the discussion here is based on the assumption that the Internet is a collection of arbitrarily connected Autonomous Systems. So the Internet is 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. Those routers 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 definition was developed, it has become common for a single AS to use several interior gateway protocols and sometimes several sets of metrics. 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. It also presents a consistent picture of which networks 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 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 network between the two AS's, and on this shared network each AS has at least one border gateway belonging to that AS. So 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 networks via the advertising AS. We also add an extra restriction here: the BGP speakers that form the BGP connection must themselves share the same network that their border gateways share. So a BGP session between adjacent AS's needs no support from either Inter-AS or Intra-AS routing. Cases that don't 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 them are located on a shared network 🫧. BGP speakers don't need to be border gateways, 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 network. In other words, indirect neighbors are allowed 🧚.

Much of the traffic carried within an AS either originates or terminates 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 internal to that AS 🏠. Traffic like this is called "local traffic", and anything that doesn't 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, it falls 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.

A full AS path is an efficient and straightforward way of suppressing routing loops, and it eliminates the "count-to-infinity" problem associated with some distance vector algorithms. That's why BGP imposes no topological restrictions on the interconnection of AS's 🎉.

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 minimize the impact on the current Internet infrastructure, stub and multihomed AS's need not use BGP. They 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 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 is either destined to or originated from those stub or multihomed AS's 💅.

However, it is recommended that BGP be used for stub and multihomed AS's as well. In these situations, BGP provides an advantage in bandwidth and performance over some of the currently used protocols (such as EGP) 🔥. It would also reduce the need for default routes, and it would lead 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 significant issue 😭, and it's discussed at length later in Appendix A 💖.

3.3 BGP Neighbor Relationships ✨

Okay so the Internet is basically a big web of AS's that are connected in pretty much any arrangement 🌐. BGP speakers inside each AS talk to each other to share network reachability info, based on the policies that AS has set up for itself. Routers that talk directly to each other over BGP are called BGP neighbors 🤝. Neighbors can live in the same AS or in different ones. When they're in different AS's, that's External BGP, and when they're in the same AS, that's Internal BGP. Easy peasy 💅

There can be as many BGP speakers in an AS as it needs 🌸. Usually, if an AS has several connections to other AS's, it'll need several BGP speakers. All the BGP speakers representing the same AS MUST give a consistent picture of the AS to the outside world 🫶. That also means they need consistent routing info among themselves. These gateways can chat with each other over BGP or in some other way. And the policy constraints on every BGP speaker in an AS MUST be consistent, too 😭. You MAY use something like a tagged IGP (see A.2.2) to sniff out possible inconsistencies 🔍.

For External BGP, the BGP neighbors MUST belong to different AS's, but they have to share a common network 🧚. That shared network SHOULD be the one that carries the BGP messages between them. Running BGP across an intervening AS invalidates the AS path info, so that's a big no-no 💀. Also, an Autonomous System number MUST be used with BGP to say which AS the BGP speaker belongs to 👑.

---

4. Requirements for Route Aggregation ✨

Okay, this part is where things get serious, bestie 💅. A conformant BGP-4 implementation is REQUIRED to be able to say when an aggregated route MAY be generated out of partial routing info 🎀. For example, a BGP speaker at the border of an autonomous system (or a group of autonomous systems) MUST be able to generate an aggregated route for a whole set of destination IP addresses. In BGP-4 land, that set is called the Network Layer Reachability Information, or NLRI 🦋. The speaker has to have administrative control over those addresses (including the ones it has delegated), and this still works 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

By default, a BGP speaker SHOULD aggregate NLRI representing subnets to the corresponding network 💖.

Injecting NLRI representing arbitrary subnets into BGP without aggregation to the corresponding network SHALL be controlled via configuration parameters 🔧.

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 capability to enforce policies based on various routing preferences and constraints 👑. Policies aren't directly encoded in the protocol. Instead, they get handed to BGP as configuration info 🎀.

BGP enforces policies by affecting which path gets picked from multiple alternatives, and by controlling how routing info gets redistributed 🦋. Policies are determined by the AS administration, so the AS is the one calling the shots 💅.

Routing policies are tied to political, security, or economic considerations 🌍. For example, if an AS is unwilling to carry traffic to another AS, it can enforce a policy prohibiting that. 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 so by only advertising routes to networks 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 so by advertising its routing information to this 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. Info 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 (the ones that come out of policy combos 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 the 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 tasks of a BGP speaker is to evaluate the different paths to a destination network from its border gateways at that network, pick the best one, apply the appropriate policy constraints, and then advertise it to all of its BGP neighbors 🧚. The key issue is how the different paths get evaluated and compared. In traditional distance vector protocols (e.g., RIP), there's only one metric (e.g., hop count) attached to a path, so comparing paths is basically just comparing two numbers 🔢. Inter-AS routing gets complicated because there isn't a universally agreed-upon metric among AS's for evaluating external paths. Each AS MAY have its own set of criteria for path evaluation 💅.

A BGP speaker builds a routing database made up of all the feasible paths and the list of networks reachable through each path 🗂️. To be precise, it helps to think about the set of feasible paths for one destination network. In most cases, you'd expect to find only one feasible path. But when that's not the case, all feasible paths SHOULD be maintained, because maintaining them is what speeds up adapting 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 given destination network 📐. One way to define that complete order is 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 as configuration info ⚙️.

Assigning a degree of preference to a path can be based on several sources of info 🧩:

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 and SHOULD be treated very carefully 🥹.

7. Required set of supported routing policies ✨

okay bestie, so policies get handed to BGP as configuration info 🔧 and they're not encoded in the protocol itself, which means BGP can handle seriously complex routing policies 💅. Still, it is not REQUIRED that every BGP implementation supports such policies 🫶.

We're not trying to standardize which routing policies MUST be supported in every BGP implementation 🙈, but we strongly encourage all implementors to support this set 🌈:

1. BGP implementations SHOULD allow an AS to control announcements of BGP-learned routes to adjacent AS's. Implementations SHOULD also support that control with at least the granularity of a single network. Implementations SHOULD also support that control with the granularity of an autonomous system, where the autonomous system may be either the one that originated the route, or the one that advertised the route to the local system (the adjacent autonomous system) ✨. Care MUST be taken when a BGP speaker selects a new route that can't be announced to a particular external peer, while the previously selected route was announced to that peer 😭. Specifically, the local system MUST explicitly tell the peer that the previous route is now infeasible.
2. BGP implementations SHOULD allow an AS to prefer a particular path to a destination (when more than one path is available) 👑. At the minimum, an implementation SHALL support this by letting you administratively assign a degree of preference to a route based solely on the IP address of the neighbor the route is received from. The allowed range of that assigned degree of preference SHALL be between 0 and 2^(31) - 1 🎀.
3. BGP implementations SHOULD allow an AS to ignore routes with certain AS's in the AS_PATH path attribute 🙅. This can be done using the technique outlined in [2], by assigning "infinity" as "weights" for those AS's. The route selection process MUST ignore routes that have "weight" equal to "infinity" 💀.

8. Interaction with other exterior routing protocols 🦋

The guidelines in this section are consistent with the guidelines presented in [3] 🧚.

An AS SHOULD advertise a minimal aggregate for its internal networks, with respect to the amount of address space it is actually using. Admins of non-BGP 4 AS's can use this 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 that export can be accomplished without exploding the NLRI of the route 🙈.

8.1 Exchanging information with EGP2

This document suggests the following guidelines for exchanging routing information between BGP-4 and EGP2 🌸.

To provide for graceful migration, a BGP speaker MAY participate in EGP2, as well as in BGP-4. Thus, a BGP speaker MAY receive IP reachability information by means of EGP2 as well as by means of BGP-4. The information received by EGP2 can be injected into BGP-4 with the ORIGIN path attribute set to 1. Likewise, the information received via BGP-4 can be injected into EGP2 as well. In that latter case, though, you need to be aware of the potential information explosion when a given IP prefix received from BGP-4 denotes a set of consecutive A/B/C class networks 👀. Injection of 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 document suggests the following guidelines for exchanging routing information between BGP-4 and BGP-3 💖.

To provide for graceful migration, a BGP speaker MAY participate in BGP-3, as well as in BGP-4. Thus, a BGP speaker MAY receive IP reachability information by means of BGP-3, as well as by means of 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. While this procedure loses set/sequence information, it doesn't affect protection for routing loops suppression, but it may affect policies, if the policies are based on the content or ordering of the AS_PATH attribute 🤔.

While injecting BGP-4 derived NLRI into BGP-3, you need to be aware of the potential information explosion when a given IP prefix denotes a set of consecutive A/B/C class networks. Injection of 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 using BGP over Switched Virtual Circuit (SVC) subnetworks, it may be desirable to minimize the traffic BGP generates 🌙. Specifically, it may be desirable to eliminate traffic associated with periodic KEEPALIVE messages. BGP includes a mechanism for operation over switched virtual circuit (SVC) services which avoids keeping SVCs permanently open and allows it to stop sending periodic KEEPALIVE messages 🧚.

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

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

9.1 Establishing a BGP Connection

The feature is selected by specifying 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 in a predictable finite period of a failure occurring.
• 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 to process internal notifications from the circuit manager 🛠️:

• DEAD: Flush transmit queue and abort 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 will operate as a single entity; i.e., they can have a separate existence when the other has been stopped or has crashed 😬.

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 discovers the circuit manager has gone away, it SHOULD close all relevant TCP connections. If the circuit manager discovers the BGP process has gone away, it SHOULD close all its connections associated with the BGP process and reject any further incoming connections 🥺.

10. Conclusion 🎀

The BGP protocol provides a high degree of control and flexibility for doing interdomain routing 🦋, while enforcing policy and performance constraints and avoiding routing loops 👑. The guidelines presented here will provide a starting point for using BGP to provide more sophisticated and manageable routing in the Internet as it grows 🌈.

Appendix A. The Interaction of BGP and an IGP 💅

This section outlines methods by which BGP can exchange routing information with an IGP. The methods outlined here are not proposed as part of the standard BGP usage at this time 🙅. These methods are 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 ✨.

A.1. Overview ✨

okay bestie, so 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's literally the whole job of a transit AS! This means BGP and the Interior Gateway Protocol (IGP) used by that particular AS have to work together with a certain degree of interaction 🫶 Generally, traffic starting outside a given AS is gonna 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 keep BGP and the IGP consistent with each other 👀 since changes in state are likely to spread 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 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 keep these routing problems to a minimum 🧹 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 💅

okay here's the tea 🍵 the next bit walks through several techniques that can achieve stable interactions between BGP and the IGP within an Autonomous System ✨

A.2.1. Propagation of BGP Information via the IGP 🚀

BGP can totally bring its own mechanism for carrying BGP information within an AS 💁‍♀️ but you can also use an IGP to transport this info, as long as the IGP supports complete flooding of routing information (that's the bit that distributes the BGP information) and one pass convergence (which makes the mechanism effectively atomic) 🧚 If an IGP is used to carry BGP information, the period of desynchronization described earlier doesn't happen at all 🙌 since BGP info propagates within the AS synchronously with the IGP, and the IGP converges more or less at the same time the new routing info arrives. it's giving synchronized vibes 🫶 Note that the IGP only carries BGP information and should not interpret or process this information 🙈

A.2.2. Tagged Interior Gateway Protocol 🏷️

Certain IGPs can tag routes exterior to an AS with the identity of their exit points while propagating them within the AS 🏷️ Each border gateway should use identical tags for announcing exterior routing information (received via BGP) both into the IGP and into Internal BGP when propagating this information to other border gateways within the same AS. Tags generated by a border gateway must uniquely identify that particular border gateway -- different border gateways must use different tags 🫶

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 guarantee that no routing information is announced externally unless the IGP is capable of correctly supporting it 🛡️ It also avoids some causes of "black holes" 🕳️

One possible method for tagging BGP and IGP routes within an AS is to use the IP address of the exit border gateway announcing 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 for tagging BGP and IGP routes 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 🪪

A.2.3. Encapsulation 📦

Encapsulation provides the simplest (in terms of the interaction between the IGP and BGP) mechanism for carrying transit traffic across the AS 📦 In this approach, transit traffic gets wrapped inside an IP datagram addressed to the exit gateway. The only requirement imposed on the IGP by 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 specified in the BGP identifier field of the BGP OPEN message received from gateway A via Internal BGP by all other border gateways within the same AS. In order to route traffic to network 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 🎁✨

Since encapsulation does not 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 to be used 🔍

Note that, if a packet to be encapsulated has length that is very close to the MTU, that packet would be fragmented at the gateway that performs encapsulation 💀

A.2.4. Pervasive BGP 🌊

If all routers in an AS are BGP speakers, then there is no need to have any interaction between BGP and an IGP 🙌 In such cases, all routers in the AS already have full information of all BGP routes. The IGP is then only used for routing within the AS, and no BGP routes are imported into the IGP.

For routers to operate in this fashion, 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 this route. Since there is no need to delay for the IGP to converge, an implementation may advertise these routes without further delay due to the IGP ✨

A.2.5. Other Cases 🧩

There may be AS's with IGPs which can neither carry BGP information nor tag exterior routes (e.g., RIP). In addition, encapsulation may be either infeasible or undesirable. In such situations, 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 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. In contrast to tagged IGPs, these rules cannot ensure that interior routes to the proper exit gateways are in place before propagating the routes 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, and 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 which 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 1654, cisco Systems, T.J. Watson Research Center, IBM Corp., July 1994.

[2] Braun, H-W., "Models of Policy Based Routing", RFC 1104, Merit/NSFNET, July 1989.

[3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1519, 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 218
Yorktown Heights, NY 10598

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

Phill Gross
Director of Broadband Engineering
MCI Data Services Division
2100 Reston Parkway, Room 6001
Reston, VA 22091

Phone: +1 703 715 7432
Fax: +1 703 715 7436
EMail: 0006423401@mcimail.com

IETF BGP WG mailing list: bgp@ans.net
To be added: bgp-request@ans.net