RFC relevance of destination

As per Relevance of the word destination, we have this rfc below:

Network Working Group Y.
Request for Comments: 1772 T.J. Watson Research Center, IBM Corp
Obsoletes: 1655 P.
Category: Standards Track

March 1995

Application of the Border Gateway Protocol in the

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

This document, together with its companion document, "A
Gateway Protocol 4 (BGP-4)", define an inter-autonomous
routing protocol for the Internet. "A Border Gateway Protocol 4
(BGP-4)" defines the BGP protocol specification, and this
describes the usage of the BGP in the Internet

Information about the progress of BGP can be monitored and/
reported on the BGP mailing list (bgp@ans.net).

This document was originally published as RFC 1164 in June 1990,
jointly authored by Jeffrey C. Honig (Cornell University), Dave
(MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica
(MERIT).

The following also made key contributions to RFC 1164 -- Guy
(ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans
Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT).

We like to explicitly thank Bob Braden (ISI) for the review of
previous version of this document

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

Rekhter & Gross [Page 1]

RFC 1772 BGP-4 Application March 1995

John Moy (Proteon) contributed Section 7 "Required set of
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
(Spider).

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

We would like to acknowledge Dan Long (NEARNET) and Tony Li (
Systems) for their review and comments on the current version of
document

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

1.

This memo describes the use of the Border Gateway Protocol (BGP) [1]
in the Internet environment. BGP is an inter-Autonomous
routing protocol. The network reachability information exchanged
BGP provides sufficient information to detect routing loops
enforce routing decisions based on performance preference and
constraints as outlined in RFC 1104 [2]. In particular, BGP
routing information containing full AS paths and enforces
policies based on configuration information

As the Internet has evolved and grown over in recent years, it
become painfully evident that it is soon to face several
scaling problems. These include

- Exhaustion of the class-B network address space.
fundamental cause of this problem is the lack of a
class of a size which is appropriate for mid-
organization; class-C, with a maximum of 254 host addresses,
too small while class-B, which allows up to 65534 addresses,
too large to be densely populated

- Growth of routing tables in Internet routers are beyond
ability of current software (and people) to effectively manage

- Eventual exhaustion of the 32-bit IP address space

It has become clear that the first two of these problems are
to become critical within the next one to three years.
inter-domain routing (CIDR) attempts to deal with these problems

Rekhter & Gross [Page 2]

RFC 1772 BGP-4 Application March 1995

proposing a mechanism to slow the growth of the routing table and
need for allocating new IP network numbers. It does not attempt
solve the third problem, which is of a more long-term nature,
instead endeavors to ease enough of the short to mid-
difficulties to allow the Internet to continue to
efficiently while progress is made on a longer-term solution

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

All of the discussions in this paper are based on the assumption
the Internet is a collection of arbitrarily connected
Systems. That is, the Internet will be modeled as a general
whose nodes are AS's and whose edges are connections between pairs
AS's

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

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

2. BGP Topological

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

Physical connection: There is a shared Data Link
between the two AS's, and on this shared subnetwork each AS has
least one border gateway belonging to that AS. Thus the
gateway of each AS can forward packets to the border gateway
the other AS without resorting to Inter-AS or Intra-AS routing

BGP connection: There is a BGP session between BGP speakers
each of the AS's, and this session communicates those routes
can be used for specific destinations via the advertising AS

Rekhter & Gross [Page 3]

RFC 1772 BGP-4 Application March 1995

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

Thus, at each connection, each AS has one or more BGP speakers
one or more border gateways, and these BGP speakers and
gateways are all located on a shared Data Link subnetwork. Note
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
taken to be feasible for each of the border gateways of the other
on the same shared subnetwork, i.e. indirect neighbors are allowed

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

Based on how a particular AS deals with transit traffic, the AS
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
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
transit and local traffic

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

Rekhter & Gross [Page 4]

RFC 1772 BGP-4 Application March 1995

3. BGP in the

3.1 Topology

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

However, it is recommended that BGP be used for stub and
AS's as well. In these situations, BGP will provide an advantage
bandwidth and performance over some of the currently used
(such as EGP). In addition, this would reduce the need for the
of default routes and in better choices of Inter-AS routes
multihomed AS's

3.2 Global Nature of

At a global level, BGP is used to distribute routing
among multiple Autonomous Systems. The information flows can
represented as follows

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

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

This diagram points out that, while BGP alone carries
between AS's, both BGP and an IGP may carry information across an AS
Ensuring consistency of routing information between BGP and an
within an AS is a significant issue and is discussed at length
in Appendix A

3.3 BGP Neighbor

The Internet is viewed as a set of arbitrarily connected AS's
Routers that communicate directly with each other via BGP are
as BGP speakers. BGP speakers can be located within the same AS or
different AS's. BGP speakers in each AS communicate with each

Rekhter & Gross [Page 5]

RFC 1772 BGP-4 Application March 1995

to exchange network reachability information based on a set
policies established within each AS. For a given BGP speaker,
other BGP speaker with which the given speaker communicates
referred to as an external peer if the other speaker is in
different AS, while if the other speaker is in the same AS it
referred to as an internal peer

There can be as many BGP speakers as deemed necessary within an AS
Usually, if an AS has multiple connections to other AS's,
BGP speakers are needed. All BGP speakers representing the same
must give a consistent image of the AS to the outside. This
that the BGP speakers have consistent routing information among them
These gateways can communicate with each other via BGP or by
means. The policy constraints applied to all BGP speakers within
AS must be consistent. Techniques such as using a tagged IGP (
A.2.2) may be employed to detect possible inconsistencies

In the case of external peers, the peers must belong to
AS's, but share a common Data Link subnetwork. This common
should be used to carry the BGP messages between them. The use of
across an intervening AS invalidates the AS path information.
Autonomous System number must be used with BGP to specify
Autonomous System the BGP speaker belongs to

4. Requirements for Route

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

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

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

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

- Install both the less and the more specific

- Install the more specific route

Rekhter & Gross [Page 6]

RFC 1772 BGP-4 Application March 1995

- Install the less specific route

- Install neither

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

5. Policy Making with

BGP provides the capability for enforcing policies based on
routing preferences and constraints. Policies are not
encoded in the protocol. Rather, policies are provided to BGP in
form of configuration information

BGP enforces policies by affecting the selection of paths
multiple alternatives and by controlling the redistribution
routing information. Policies are determined by the
administration

Routing policies are related to political, security, or
considerations. For example, if an AS is unwilling to carry
to another AS, it can enforce a policy prohibiting this.
following are examples of routing policies that can be enforced
the use of BGP

1. A multihomed AS can refuse to act as a transit AS for
AS's. (It does so by only advertising routes to
internal to the AS.)

2. A multihomed AS can become a transit AS for a restricted set
adjacent AS's, i.e., some, but not all, AS's can use
multihomed AS as a transit AS. (It does so by advertising
routing information to this set of AS's.)

3. An AS can favor or disfavor the use of certain AS's
carrying transit traffic from itself

A number of performance-related criteria can be controlled with
use of BGP

1. An AS can minimize the number of transit AS's. (Shorter
paths can be preferred over longer ones.)

2. The quality of transit AS's. If an AS determines that two
more AS paths can be used to reach a given destination, that
can use a variety of means to decide which of the candidate

Rekhter & Gross [Page 7]

RFC 1772 BGP-4 Application March 1995

paths it will use. The quality of an AS can be measured by
things as diameter, link speed, capacity, tendency to
congested, and quality of operation. Information about
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, resulting
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
neighboring AS's only those routes that it uses. This rule
the "hop-by-hop" routing paradigm generally used by the
Internet

6. Path Selection with

One of the major tasks of a BGP speaker is to evaluate
paths from itself to a set of destination covered by an
prefix, select the best one, apply appropriate policy constraints
and then advertise it to all of its BGP neighbors. The key issue
how different paths are evaluated and compared. In
distance vector protocols (e.g., RIP) there is only one metric (e.g.,
hop count) associated with a path. As such, comparison of
paths is reduced to simply comparing two numbers. A complication
Inter-AS routing arises from the lack of a universally agreed-
metric among AS's that can be used to evaluate external paths
Rather, each AS may have its own set of criteria for path evaluation

A BGP speaker builds a routing database consisting of the set of
feasible paths and the list of destinations (expressed as
prefixes) reachable through each path. For purposes of
discussion, it's useful to consider the set of feasible paths for
set of destinations associated with a given address prefix. In
cases, we would expect to find only one feasible path. However,
this is not the case, all feasible paths should be maintained,
their maintenance speeds 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
order over the set of all feasible paths to a set of
associated with a given address prefix. One way to define
complete order is to define a function that maps each full AS path
a non-negative integer that denotes the path's degree of preference
Path selection is then reduced to applying this function to
feasible paths and choosing the one with the highest degree
preference

Rekhter & Gross [Page 8]

RFC 1772 BGP-4 Application March 1995

In actual BGP implementations, the criteria for assigning degree
preferences to a path are specified as configuration information

The process of assigning a degree of preference to a path can
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
AS path and information outside the scope of BGP (e.g.,
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
on the controlled distribution of routing information. A
speaker may be aware of some policy constraints (both
and outside of its own AS) and do appropriate path selection
Paths that do not comply with policy requirements are
considered further

- Presence or absence of a certain AS or AS's in the path.
means of information outside the scope of BGP, an AS may
some performance characteristics (e.g., bandwidth, MTU, intra
AS diameter) of certain AS's and may try to avoid or
them

- Path origin. A path learned entirely from BGP (i.e.,
endpoint is internal to the last AS on the path) is
better than one for which part of the path was learned via
or some other means

- AS path subsets. An AS path that is a subset of a longer
path to the same destination should be preferred over
longer path. Any problem in the shorter path (such as
outage) will also be a problem in the longer path

- Link dynamics. Stable paths should be preferred over
ones. Note that this criterion must be used in a very
way to avoid causing unnecessary route fluctuation. Generally
any criteria that depend on dynamic information might
routing instability and should be treated very carefully

Rekhter & Gross [Page 9]

RFC 1772 BGP-4 Application March 1995

7. Required set of supported routing

Policies are provided to BGP in the form of
information. This information is not directly encoded in
protocol. Therefore, BGP can provide support for very complex
policies. However, it is not required that all BGP
support such policies

We are not attempting to standardize the routing policies that
be supported in every BGP implementation; we strongly encourage
implementors to support the following set of routing policies

1. BGP implementations should allow an AS to control
of BGP-learned routes to adjacent AS's. Implementations
also support such control with at least the granularity of
single address prefix. Implementations should also
such control with the granularity of an autonomous system
where the autonomous system may be either the autonomous
that originated the route, or the autonomous system
advertised the route to the local system (adjacent
system). Care must be taken when a BGP speaker selects a
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 indicate to
peer that the previous route is now infeasible

2. BGP implementations should allow an AS to prefer a
path to a destination (when more than one path is available).
At the minimum an implementation shall support
functionality by allowing to administratively assign a
of preference to a route based solely on the IP address of
neighbor the route is received from. The allowed range of
assigned degree of preference shall be between 0 and 2^(31) -
1.

3. BGP implementations should allow an AS to ignore routes
certain AS's in the AS_PATH path attribute. Such function
be implemented by using the technique outlined in [2], and
assigning "infinity" as "weights" for such AS's. The
selection process must ignore routes that have "weight"
to "infinity".

8. Interaction with other exterior routing

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

Rekhter & Gross [Page 10]

RFC 1772 BGP-4 Application March 1995

An AS should advertise a minimal aggregate for its
destinations with respect to the amount of address space that it
actually using. This can be used by administrators of non-BGP 4 AS'
to determine how many routes to explode from a single aggregate

A route that carries the ATOMIC_AGGREGATE path attribute shall not
exported into either BGP-3 or EGP2, unless such an exportation can
accomplished without exploding the NLRI of the route

8.1 Exchanging information with EGP

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

To provide for graceful migration, a BGP speaker may participate
EGP2, as well as in BGP-4. Thus, a BGP speaker may receive
reachability information by means of EGP2 as well as by means
BGP-4. The information received by EGP2 can be injected into BGP-4
with the ORIGIN path attribute set to 1. Likewise, the
received via BGP-4 can be injected into EGP2 as well. In the
case, however, one needs to be aware of the potential
explosion when a given IP prefix received from BGP-4 denotes a set
consecutive A/B/C class networks. Injection of BGP-4 received
that denotes IP subnets requires the BGP speaker to inject
corresponding network into EGP2. The local system shall
mechanisms to control the exchange of reachability
between EGP2 and BGP-4. Specifically, a conformant implementation
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

- allow controlled deaggregation, but only of specific routes
allow export of non-aggregated

- allow export of only non-aggregated

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

8.2 Exchanging information with BGP-3

This document suggests the following guidelines for
routing information between BGP-4 and BGP-3.

To provide for graceful migration, a BGP speaker may participate
BGP-3, as well as in BGP-4. Thus, a BGP speaker may receive

Rekhter & Gross [Page 11]

RFC 1772 BGP-4 Application March 1995

reachability information by means of BGP-3, as well as by means
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
segments, then the AS_PATH attribute of the BGP-3 route shall
constructed by treating the AS_SET segments as AS_SEQUENCE segments
with the resulting AS_PATH being a single AS_SEQUENCE. While
procedure loses set/sequence information, it doesn't
protection for routing loops suppression, but may affect policies,
the policies are based on the content or ordering of the AS_
attribute

While injecting BGP-4 derived NLRI into BGP-3, one needs to be
of the potential information explosion when a given IP prefix
a set of consecutive A/B/C class networks. Injection of BGP-4
NLRI that denotes IP subnets requires the BGP speaker to inject
corresponding network into BGP-3. The local system shall
mechanisms to control the exchange of routing information
BGP-3 and BGP-4. Specifically, a conformant implementation
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

- allow controlled deaggregation, but only of specific routes
allow export of non-aggregated

- allow export of only non-aggregated

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

9. Operations over Switched Virtual

When using BGP over Switched Virtual Circuit (SVC) subnetworks it
be desirable to minimize traffic generated by BGP. Specifically,
may be desirable to eliminate traffic associated with
KEEPALIVE messages. BGP includes a mechanism for operation
switched virtual circuit (SVC) services which avoids keeping
permanently open and allows it to eliminates periodic sending
KEEPALIVE messages

Rekhter & Gross [Page 12]

RFC 1772 BGP-4 Application March 1995

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

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

9.1 Establishing a BGP

The feature is selected by specifying zero Hold Time in the
message

9.2 Circuit Manager

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

- It must be able to determine link layer unreachability in
predictable finite period of a failure occurring

- On determining unreachability it should

- start a configurable dead timer (comparable to
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

A small modification must be made to TCP to process
notifications from the circuit manager

- DEAD: Flush transmit queue and abort TCP connection

Rekhter & Gross [Page 13]

RFC 1772 BGP-4 Application March 1995

- UP: Transmit any queued data or allow an outgoing TCP call
proceed

9.4 Combined

Some implementations may not be able to guarantee that the
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
has crashed

If this is the case, a periodic two-way poll between the BGP
and the circuit manager should be implemented. If the BGP
discovers the circuit manager has gone away it should close
relevant TCP connections. If the circuit manager discovers the
process has gone away it should close all its connections
with the BGP process and reject any further incoming connections

10.

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

Rekhter & Gross [Page 14]

RFC 1772 BGP-4 Application March 1995

Appendix A. The Interaction of BGP and an

This section outlines methods by which BGP can exchange
information with an IGP. The methods outlined here are not
as part of the standard BGP usage at this time. These methods
outlined for information purposes only. Implementors may want
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
this section. Methods for specific IGP's should be proposed
separate documents. Methods for specific IGP's could be proposed
standard usage in the future

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

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

In order to minimize such routing problems, border gateway (A)
not advertise to any of its external peers a route to some set
exterior destinations associated with a given address prefix X
border gateway (B) until all the interior gateways within the AS
ready to route traffic destined to these destinations via the
exit border gateway (B). In other words, interior routing
converge on the proper exit gateway before/advertising routes
that exit gateway to external peers

Rekhter & Gross [Page 15]

RFC 1772 BGP-4 Application March 1995

A.2 Methods for Achieving Stable

The following discussion outlines several techniques capable
achieving stable interactions between BGP and the IGP within
Autonomous System

A.2.1 Propagation of BGP Information via the

While BGP can provide its own mechanism for carrying BGP
within an AS, one can also use an IGP to transport this information
as long as the IGP supports complete flooding of routing
(providing the mechanism to distribute the BGP information) and
pass convergence (making the mechanism effectively atomic). If an
is used to carry BGP information, then the period
desynchronization described earlier does not occur at all, since
information propagates within the AS synchronously with the IGP,
the IGP converges more or less simultaneously with the arrival of
new routing information. Note that the IGP only carries
information and should not interpret or process this information

A.2.2 Tagged Interior Gateway

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

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

1. Information received from an internal peer by a border
A declaring a set of destination associated with a
address prefix to be unreachable must immediately be
to all of the external peers of A

2. Information received from an internal peer by a border
A about a set of reachable destinations associated with a
address prefix X cannot be propagated to any of the
peers of A unless/until A has an IGP route to the set
destinations covered by X and both the IGP and the BGP
information have identical tags

These rules guarantee that no routing information is
externally unless the IGP is capable of correctly supporting it.

Rekhter & Gross [Page 16]

RFC 1772 BGP-4 Application March 1995

also avoids some causes of "black holes".

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

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

A.2.3

Encapsulation provides the simplest (in terms of the
between the IGP and BGP) mechanism for carrying transit
across the AS. In this approach, transit traffic is
within an IP datagram addressed to the exit gateway. The
requirement imposed on the IGP by this approach is that it should
capable of supporting routing between border gateways within the
AS

The address of the exit gateway A for some exterior destination X
specified in the BGP identifier field of the BGP OPEN
received from gateway A (via BGP) by all other border gateways
the same AS. In order to route traffic to destination X, each
gateway within the AS encapsulates it in datagrams addressed
gateway A. Gateway A then performs decapsulation and forwards
original packet to the proper gateway in another AS

Since encapsulation does not rely on the IGP to carry
routing information, no synchronization between BGP and the IGP
required

Some means of identifying datagrams containing encapsulated IP,
as an IP protocol type code, must be defined if this method is to
used

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

A.2.4 Pervasive

If all routers in an AS are BGP speakers, then there is no need
have any interaction between BGP and an IGP. In such cases,
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

Rekhter & Gross [Page 17]

RFC 1772 BGP-4 Application March 1995

routes are imported into the IGP

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

Since the IGP carries no external information in this scenario,
routers in the AS will have converged as soon as all BGP
have new information about this route. Since there is no need
delay for the IGP to converge, an implementation may advertise
routes without further delay due to the IGP

A.2.5 Other

There may be AS's with IGPs which can neither carry BGP
nor tag exterior routes (e.g., RIP). In addition, encapsulation
be either infeasible or undesirable. In such situations,
following two rules must be observed

1. Information received from an internal peer by a border
A declaring a destination to be unreachable must immediately
propagated to all of the external peers of A

2. Information received from an internal peer by a border
A about a reachable destination X cannot be propagated to
of the external peers of A unless A has an IGP route to X
sufficient time has passed for the IGP routes to
converged

The above rules present necessary (but not sufficient) conditions
propagating BGP routing information to other AS's. In contrast
tagged IGPs, these rules cannot ensure that interior routes to
proper exit gateways are in place before propagating the routes
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
is less than X as well, and the whole issue can be ignored at
cost of transient periods (of less than length X) of
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
approach is needed. Mechanisms and techniques which might
appropriate in this situation are subjects for further study

Rekhter & Gross [Page 18]

RFC 1772 BGP-4 Application March 1995

[1] Rekhter Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4),
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:
Address Assignment and Aggregation Strategy", RFC1519, BARRNet
cisco, MERIT, OARnet, September 1993.

Security

Security issues are not discussed in this memo

Authors'

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

Phone: +1 914 784 7361
EMail: yakov@watson.ibm.

Phill
MCI Data Services
2100 Reston Parkway, Room 6001,
Reston, VA 22091

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

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

Rekhter & Gross [Page 19]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX