As per Relevance of the word policies, we have this rfc below:
Network Working Group Y.
Request for Comments: 1268 T.J. Watson Research Center, IBM Corp
Obsoletes: RFC 1164 P.
October 1991
Application of the Border Gateway Protocol in the
Status of this
This protocol is being developed by the Border Gateway
Working Group (BGP) of the Internet Engineering Task Force (IETF).
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This document, together with its companion document, "A
Gateway Protocol (BGP-3)", define an inter-autonomous system
protocol for the Internet. "A Border Gateway Protocol (BGP-3)"
defines the BGP protocol specification, and this document
the usage of the BGP in the Internet
Information about the progress of BGP can be monitored and/
reported on the BGP mailing list (iwg@rice.edu).
Table of
1. Introduction................................................... 2
2. BGP Topological Model.......................................... 3
3. BGP in the Internet............................................ 4
4. Policy Making with BGP......................................... 5
5. Path Selection with BGP........................................ 6
6. Required set of supported routing policies..................... 8
7. Conclusion..................................................... 9
Appendix A. The Interaction of BGP and an IGP..................... 9
References........................................................ 12
Security Considerations........................................... 12
Authors' Addresses................................................ 13
This document was original published as RFC 1164 in June 1990,
BGP Working Group [Page 1]
RFC 1268 Application of BGP in the Internet October 1991
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).
This updated version of the document is the product of the IETF
Working Group with Phillip Gross (ANS) and Yakov Rekhter (IBM)
editors. John Moy (Proteon) contributed Section 6 "Recommended
of supported routing policies".
We also like to explicitly thank Bob Braden (ISI) for the review
this document as well as his constructive and valuable comments
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
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 networks are reachable through it.
the standpoint of exterior routing, an AS can be viewed
monolithic: networks within an AS must maintain connectivity
intra-AS paths
BGP Working Group [Page 2]
RFC 1268 Application of BGP in the Internet October 1991
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 network between the
AS's, and on this shared network each AS has at least one
gateway belonging to that AS. Thus the border gateway of each
can forward packets to the border gateway of the other AS
resort 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 to each
AS those routes through the physically connected border
of the other AS that can be used for specific networks.
this document we place an additional restriction on the
speakers that form the BGP connection: they must themselves
the same network that their border gateways share. Thus, a
session between the adjacent AS's requires no support from
Inter-AS or Intra-AS routing. Cases that do not conform to
restriction fall outside the scope of this 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 network. Note that BGP
do not need to be a border gateway, and vice versa. Paths
by a BGP speaker of one AS on a given connection are taken to
feasible for each of the border gateways of the other AS on the
connection, 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 on
network directly connected to that AS). Traffic that fits
description is called "local traffic". Traffic that does not fit
description is called "transit traffic". A major goal of BGP usage
to control the flow 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
BGP Working Group [Page 3]
RFC 1268 Application of BGP in the Internet October 1991
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
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 not local to the stub
multihomed AS's in question
However, it is recommended that BGP may be used for stub
multihomed AS's as well, providing an advantage in bandwidth
performance over some of the currently used protocols (such as EGP).
In addition, this would result in less need for the use of
and in better choices of Inter-AS routes for 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
BGP Working Group [Page 4]
RFC 1268 Application of BGP in the Internet October 1991
between AS's, a combination of BGP and an IGP carries
across an AS. Ensuring consistency of routing information
BGP and an IGP within an AS is a significant issue and is
at length later in Appendix A
3.3 BGP Neighbor
The Internet is viewed as a set of arbitrarily connected AS's.
speakers in each AS communicate with each other to exchange
reachability information based on a set of policies
within each AS. Routers that communicate directly with each other
BGP are known as BGP neighbors. BGP neighbors can be located
the same AS or in different AS's. For the sake of discussion,
communications with neighbors in different AS's will be referred
as External BGP, and with neighbors in the same AS as Internal BGP
There can be as many BGP speakers as deemed necessary within an AS
Usually, if an AS has multiple connections to other AS's,
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 tagged IGP (
A.2.2) may be employed to detect possible inconsistencies
In the case of External BGP, the BGP neighbors must belong
different AS's, but share a common network. 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. 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.
BGP Working Group [Page 5]
RFC 1268 Application of BGP in the Internet October 1991
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 not advertising routes to networks
than those directly connected to it.)
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
AS as a transit AS. (It does so by advertising its
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,
AS can use a variety of means to decide which of the
AS paths it will use. The quality of an AS can be measured
such things as diameter, link speed, capacity, tendency
become congested, and quality of operation. Information
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, 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
5. Path Selection with
One of the major tasks of a BGP speaker is to evaluate
paths to a destination network from its border gateways at
connection, select the best one, apply applicable policy constraints
and then advertise it to all of its BGP neighbors at that
connection. The key issue is how different paths are evaluated
compared
BGP Working Group [Page 6]
RFC 1268 Application of BGP in the Internet October 1991
In traditional distance vector protocols (e.g., RIP) there is
one metric (e.g., hop count) associated with a path. As such
comparison of different paths is reduced to simply comparing
numbers. A complication in Inter-AS routing arises from the lack of
universally agreed-upon metric among AS's that can be used
evaluate external paths. Rather, each AS may have its own set
criteria for path evaluation
A BGP speaker builds a routing database consisting of the set of
feasible paths and the list of networks reachable through each path
For purposes of precise discussion, it's useful to consider the
of feasible paths for a given destination network. In most cases,
would expect to find only one feasible path. However, when this
not the case, all feasible paths should be maintained, and
maintenance speeds adaptation to the loss of the primary path.
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 given
network. One way to define this partial order is to define a
that maps each full AS path to a non-negative integer that
the path's degree of preference. Path selection is then reduced
applying this function to all feasible paths and choosing the
with the highest degree of preference
In actual BGP implementations, criteria for assigning degree
preferences to a path are specified in 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 at configuration).
Possible criteria for assigning a degree of preference to a path are
- AS count. Paths with a smaller AS count are generally better
- Policy consideration. BGP supports policy-based routing
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
BGP Working Group [Page 7]
RFC 1268 Application of BGP in the Internet October 1991
- 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-
diameter) of certain AS's and may try to avoid or prefer 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 the
path. Any problem in the shorter path (such as an outage)
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
6. Required set of supported routing policies
Policies are provided to BGP in the form of
information. This information is not directly encoded in
protocol. Therefore, BGP can provides support for quite
routing policies. However, it is not required for all
implementations to 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
a single network. Implementations should also support
control with the granularity of an autonomous system,
the autonomous system may be either the autonomous system
originated the route, or the autonomous system that
the route to the local system (adjacent autonomous system).
2. BGP implementations should allow an AS to prefer a
path to a destination (when more than one path is available).
This function should be implemented by allowing
administrators to assign "weights" to AS's, and making
selection process to select a route with the lowest "weight
(where "weight" of a route is defined as a sum of "weights"
BGP Working Group [Page 8]
RFC 1268 Application of BGP in the Internet October 1991
all AS's in the AS_PATH path attribute associated with
route).
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 technique outlined in (2), and
assigning "infinity" as "weights" for such AS's. The
selection process must ignore routes that have "weight"
to "infinity".
7.
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
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
BGP Working Group [Page 9]
RFC 1268 Application of BGP in the Internet October 1991
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 a route to some exterior network X via border
(B) to all of its BGP neighbors in other AS's until all the
gateways within the AS are ready to route traffic destined to X
the correct exit border gateway (B). In other words, interior
should converge on the proper exit gateway before/advertising
via that exit gateway to other AS's
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)
onepass convergence (making the mechanism effectively atomic). If
IGP 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 into
BGP when propagating this information to other border gateways
the same AS. Tags generated by a border gateway must
identify that particular border gateway--different border
must use different tags
All Border Gateways within a single AS must observe the following
rules
BGP Working Group [Page 10]
RFC 1268 Application of BGP in the Internet October 1991
1. Information received via Internal BGP by a border gateway
declaring a network to be unreachable must immediately
propagated to all of the External BGP neighbors of A
2. Information received via Internal BGP by a border gateway
about a reachable network X cannot be propagated to any
the External BGP neighbors of A unless/until A has an
route to X and both the IGP and the BGP routing
have identical tags
These rules guarantee that no routing information is
externally unless the IGP is capable of correctly supporting it.
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
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 network X
specified in the BGP identifier field of the BGP OPEN
received from gateway A via Internal BGP by all other border
within the same AS. In order to route traffic to network X,
border gateway within the AS encapsulates it in datagrams
to gateway A. Gateway A then performs decapsulation and forwards
original packet to the proper gateway in another
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
BGP Working Group [Page 11]
RFC 1268 Application of BGP in the Internet October 1991
A.2.4 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 via Internal BGP by a border gateway
declaring a network to be unreachable must immediately
propagated to all of the External BGP neighbors of A
2. Information received via Internal BGP by a border gateway
about a reachable network X cannot be propagated to any
the External BGP neighbors of A unless A has an IGP route
X and sufficient time (holddown) has passed for the IGP
to have 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
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
[1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP
3)", RFC 1267, cisco Systems, T.J. Watson Research Center,
Corp., October 1991.
[2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
Merit/NSFNET, June 1989.
Security
Security issues are not discussed in this memo
BGP Working Group [Page 12]
RFC 1268 Application of BGP in the Internet October 1991
Authors'
Yakov
T.J. Watson Research Center IBM
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: yakov@watson.ibm.
Phill
Advanced Network and Services (ANS
100 Clearbrook
Elmsford, NY 10523
Phone: (914) 789-5300
Email: pgross@NIS.ANS.
IETF BGP WG mailing list: iwg@rice.
To be added: iwg-request@rice.
BGP Working Group [Page 13]
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
