draft-ietf-idr-bgp-analysis-07.txt   rfc4274.txt 
INTERNET-DRAFT D. Meyer Network Working Group D. Meyer
draft-ietf-idr-bgp-analysis-07.txt K. Patel Request for Comments: 4274 K. Patel
Category Informational Category: Informational Cisco Systems
Expires: June 2005 December 2004 January 2006
BGP-4 Protocol Analysis BGP-4 Protocol Analysis
<draft-ietf-idr-bgp-analysis-07.txt>
Status of this Memo
Status of this Memo Status of This Memo
This document is an Internet-Draft and is subject to all
provisions of section 3 of RFC 3667. By submitting this
Internet-Draft, each author represents that any applicable patent
or other IPR claims of which he or she is aware have been or will
be disclosed, and any of which he or she become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
This document is a product of the IDR Working Group This memo provides information for the Internet community. It does
WG. Comments should be addressed to the authors, or the not specify an Internet standard of any kind. Distribution of this
mailing list at idr@ietf.org. memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
The purpose of this report is to document how the requirements for The purpose of this report is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard publication of a routing protocol as an Internet Draft Standard have
have been satisfied by Border Gateway Protocol version 4 (BGP-4). been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as This report satisfies the requirement for "the second report", as
described in Section 6.0 of [RFC1264]. In order to fulfill the described in Section 6.0 of RFC 1264. In order to fulfill the
requirement, this report augments [RFC1774] and summarizes the key requirement, this report augments RFC 1774 and summarizes the key
features of BGP-4 protocol, and analyzes the protocol with respect features of BGP-4, as well as analyzes the protocol with respect to
to scaling and performance. scaling and performance.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................2
2. Key Features and algorithms of the BGP protocol. . . . . . . . 4 2. Key Features and Algorithms of BGP ..............................3
2.1. Key Features. . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Key Features ...............................................3
2.2. BGP Algorithms. . . . . . . . . . . . . . . . . . . . . . . 5 2.2. BGP Algorithms .............................................4
2.3. BGP Finite State Machine (FSM). . . . . . . . . . . . . . . 6 2.3. BGP Finite State Machine (FSM) .............................4
3. BGP Capabilities . . . . . . . . . . . . . . . . . . . . . . . 7 3. BGP Capabilities ................................................5
4. BGP Persistent Peer Oscillations . . . . . . . . . . . . . . . 7 4. BGP Persistent Peer Oscillations ................................6
5. Implementation Guidelines. . . . . . . . . . . . . . . . . . . 7 5. Implementation Guidelines .......................................6
6. BGP Performance characteristics and Scalability. . . . . . . . 8 6. BGP Performance Characteristics and Scalability .................6
6.1. Link bandwidth and CPU utilization. . . . . . . . . . . . . 8 6.1. Link Bandwidth and CPU Utilization .........................7
6.1.1. CPU utilization. . . . . . . . . . . . . . . . . . . . . 9 7. BGP Policy Expressiveness and its Implications ..................9
6.1.2. Memory requirements. . . . . . . . . . . . . . . . . . . 10 7.1. Existence of Unique Stable Routings .......................10
7. BGP Policy Expressiveness and its Implications . . . . . . . . 11 7.2. Existence of Stable Routings ..............................11
7.1. Existence of Unique Stable Routings . . . . . . . . . . . . 12 8. Applicability ..................................................12
7.2. Existence of Stable Routings. . . . . . . . . . . . . . . . 13 9. Acknowledgements ...............................................12
8. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations .......................................12
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15 11. References ....................................................13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References ....................................13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References ..................................14
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 18
13. Author's Addresses. . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
BGP-4 is an inter-autonomous system routing protocol designed for BGP-4 is an inter-autonomous system routing protocol designed for
TCP/IP internets. Version 1 of the BGP-4 protocol was published in TCP/IP internets. Version 1 of BGP-4 was published in [RFC1105].
[RFC1105]. Since then BGP versions 2, 3, and 4 have been developed. Since then, BGP versions 2, 3, and 4 have been developed. Version 2
Version 2 was documented in [RFC1163]. Version 3 is documented in was documented in [RFC1163]. Version 3 is documented in [RFC1267].
[RFC1267]. Version 4 is documented in the [BGP4] (version 4 of BGP Version 4 is documented in [BGP4] (version 4 of BGP will hereafter be
will hereafter be referred to as BGP). The changes between versions referred to as BGP). The changes between versions are explained in
are explained in Appendix A of [BGP4]. Possible applications of BGP Appendix A of [BGP4]. Possible applications of BGP in the Internet
in the Internet are documented in [RFC1772]. are documented in [RFC1772].
BGP introduced support for Classless Inter-Domain Routing BGP introduced support for Classless Inter-Domain Routing (CIDR)
[RFC1519]. Since earlier versions of BGP lacked the support [RFC1519]. Because earlier versions of BGP lacked the support for
for CIDR, they are considered obsolete and unusable in CIDR, they are considered obsolete and unusable in today's Internet.
today's Internet.
2. Key Features and algorithms of the BGP protocol The purpose of this report is to document how the requirements for
publication of a routing protocol as an Internet Draft Standard have
been satisfied by Border Gateway Protocol version 4 (BGP-4).
This section summarizes the key features and algorithms of the This report satisfies the requirement for "the second report", as
BGP protocol. BGP is an inter-autonomous system routing described in Section 6.0 of [RFC1264]. In order to fulfill the
protocol; it is designed to be used between multiple requirement, this report augments [RFC1774] and summarizes the key
autonomous systems. BGP assumes that routing within an features of BGP-4, as well as analyzes the protocol with respect to
autonomous system is done by an intra-autonomous system scaling and performance.
routing protocol. BGP also assumes that data packets are
routed from source towards destination independent of the
source. BGP does not make any assumptions about
intra-autonomous system routing protocols deployed within the
various autonomous systems. Specifically, BGP does not require
all autonomous systems to run the same intra-autonomous system
routing protocol (i.e., interior gateway protocol or IGP).
Finally, note that BGP is a real inter-autonomous system 2. Key Features and Algorithms of BGP
routing protocol, and as such it imposes no constraints on the
underlying interconnect topology of the autonomous This section summarizes the key features and algorithms of BGP. BGP
systems. The information exchanged via BGP is sufficient to is an inter-autonomous system routing protocol; it is designed to be
construct a graph of autonomous systems connectivity from used between multiple autonomous systems. BGP assumes that routing
which routing loops may be pruned and many routing policy within an autonomous system is done by an intra-autonomous system
decisions at the autonomous system level may be enforced. routing protocol. BGP also assumes that data packets are routed from
source towards destination independent of the source. BGP does not
make any assumptions about intra-autonomous system routing protocols
deployed within the various autonomous systems. Specifically, BGP
does not require all autonomous systems to run the same intra-
autonomous system routing protocol (i.e., interior gateway protocol
or IGP).
Finally, note that BGP is a real inter-autonomous system routing
protocol; and, as such, it imposes no constraints on the underlying
interconnect topology of the autonomous systems. The information
exchanged via BGP is sufficient to construct a graph of autonomous
systems connectivity from which routing loops may be pruned, and many
routing policy decisions at the autonomous system level may be
enforced.
2.1. Key Features 2.1. Key Features
The key features of the protocol are the notion of path The key features of the protocol are the notion of path attributes
attributes and aggregation of Network Layer Reachability and aggregation of Network Layer Reachability Information (NLRI).
Information (NLRI).
Path attributes provide BGP with flexibility and Path attributes provide BGP with flexibility and extensibility. Path
extensibility. Path attributes are partitioned into well-known attributes are either well-known or optional. The provision for
and optional. The provision for optional attributes allows optional attributes allows experimentation that may involve a group
experimentation that may involve a group of BGP routers of BGP routers without affecting the rest of the Internet. New
without affecting the rest of the Internet. New optional optional attributes can be added to the protocol in much the same way
attributes can be added to the protocol in much the same way that new options are added to, for example, the Telnet protocol
that new options are added to, say, the Telnet protocol [RFC854]. [RFC854].
One of the most important path attributes is the Autonomous One of the most important path attributes is the Autonomous System
System Path, or AS_PATH. As the reachability information Path, or AS_PATH. As the reachability information traverses the
traverses the Internet, this (AS_PATH) information is Internet, this (AS_PATH) information is augmented by the list of
augmented by the list of autonomous systems that have been autonomous systems that have been traversed thus far, forming the
traversed thus far, forming the AS_PATH. The AS_PATH allows AS_PATH. The AS_PATH allows straightforward suppression of the
straightforward suppression of the looping of routing looping of routing information. In addition, the AS_PATH serves as a
information. In addition, the AS_PATH serves as a powerful and powerful and versatile mechanism for policy-based routing.
versatile mechanism for policy-based routing.
BGP enhances the AS_PATH attribute to include sets of autonomous BGP enhances the AS_PATH attribute to include sets of autonomous
systems as well as lists via the AS_SET attribute. This extended systems as well as lists via the AS_SET attribute. This extended
format allows generated aggregate routes to carry path information format allows generated aggregate routes to carry path information
from the more specific routes used to generate the aggregate. It from the more specific routes used to generate the aggregate. It
should be noted however, that as of this writing, AS_SETs are should be noted, however, that as of this writing, AS_SETs are rarely
rarely used in the Internet [ROUTEVIEWS]. used in the Internet [ROUTEVIEWS].
2.2. BGP Algorithms 2.2. BGP Algorithms
BGP uses an algorithm that is neither a pure distance vector BGP uses an algorithm that is neither a pure distance vector
algorithm or a pure link state algorithm. It is instead a algorithm or a pure link state algorithm. Instead, it uses a
modified distance vector algorithm referred to as a "Path modified distance vector algorithm, referred to as a "Path Vector"
Vector" algorithm that uses path information to avoid algorithm. This algorithm uses path information to avoid traditional
traditional distance vector problems. Each route within BGP distance vector problems. Each route within BGP pairs information
pairs destination with path information to that about the destination with path information to that destination.
destination. Path information (also known as AS_PATH Path information (also known as AS_PATH information) is stored within
information) is stored within the AS_PATH attribute in the AS_PATH attribute in BGP. The path information assists BGP in
BGP. The path information assists BGP in detecting AS loops detecting AS loops, thereby allowing BGP speakers to select loop-free
thereby allowing BGP speakers select loop free routes. routes.
BGP uses an incremental update strategy in order to conserve BGP uses an incremental update strategy to conserve bandwidth and
bandwidth and processing power. That is, after initial processing power. That is, after initial exchange of complete
exchange of complete routing information, a pair of BGP routing information, a pair of BGP routers exchanges only the changes
routers exchanges only changes to that information. Such an to that information. Such an incremental update design requires
incremental update design requires reliable transport between reliable transport between a pair of BGP routers in order to function
a pair of BGP routers to function correctly. BGP solves this correctly. BGP solves this problem by using TCP for reliable
problem by using TCP for reliable transport. transport.
In addition to incremental updates, BGP has added the concept In addition to incremental updates, BGP has added the concept of
of route aggregation so that information about groups of route aggregation so that information about groups of destinations
destinations
that use hierarchical address assignment (e.g., CIDR) may be that use hierarchical address assignment (e.g., CIDR) may be
aggregated and sent as a single Network Layer Reachability aggregated and sent as a single Network Layer Reachability (NLRI).
(NLRI).
Finally, note that BGP is a self-contained protocol. That is, Finally, note that BGP is a self-contained protocol. That is, BGP
BGP specifies how routing information is exchanged both specifies how routing information is exchanged, both between BGP
between BGP speakers in different autonomous systems, and speakers in different autonomous systems, and between BGP speakers
between BGP speakers within a single autonomous system. within a single autonomous system.
2.3. BGP Finite State Machine (FSM) 2.3. BGP Finite State Machine (FSM)
The BGP FSM is a set of rules that are applied to a BGP The BGP FSM is a set of rules that is applied to a BGP speaker's set
speaker's set of configured peers for the BGP operation. A BGP of configured peers for the BGP operation. A BGP implementation
implementation requires that a BGP speaker must connect to and requires that a BGP speaker must connect to and listen on TCP port
listen on TCP port 179 for accepting any new BGP connections 179 for accepting any new BGP connections from its peers. The BGP
from its peers. The BGP Finite State Machine, or FSM, must be Finite State Machine, or FSM, must be initiated and maintained for
initiated and maintained for each new incoming and outgoing each new incoming and outgoing peer connection. However, in steady
peer connections. However, in steady state operation, there state operation, there will be only one BGP FSM per connection per
will be only one BGP FSM per connection per peer. peer.
There may be a short period during which a BGP peer may have There may be a short period during which a BGP peer may have separate
separate incoming and outgoing connections resulting in the incoming and outgoing connections resulting in the creation of two
creation of two different BGP FSMs relating to a peer (instead different BGP FSMs relating to a peer (instead of one). This can be
of one). This can be resolved by following the BGP connection resolved by following the BGP connection collision rules defined in
collision rules defined in the [BGP4] specification. the [BGP4] specification.
The BGP FSM has the following states associated with each of its The BGP FSM has the following states associated with each of its
peers: peers:
IDLE: State when BGP peer refuses any incoming IDLE: State when BGP peer refuses any incoming connections.
connections.
CONNECT: State in which BGP peer is waiting for CONNECT: State in which BGP peer is waiting for its TCP
its TCP connection to be completed. connection to be completed.
ACTIVE: State in which BGP peer is trying to acquire a ACTIVE: State in which BGP peer is trying to acquire a peer
peer by listening and accepting TCP connection. by listening and accepting TCP connection.
OPENSENT: BGP peer is waiting for OPEN message from its OPENSENT: BGP peer is waiting for OPEN message from its peer.
peer.
OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION
message from its peer. message from its peer.
ESTABLISHED: BGP peer connection is established and exchanges ESTABLISHED: BGP peer connection is established and exchanges
UPDATE, NOTIFICATION, and KEEPALIVE messages with UPDATE, NOTIFICATION, and KEEPALIVE messages with its
its peer. peer.
There are an number of BGP events that operate on above There are a number of BGP events that operate on the above mentioned
mentioned states of the BGP FSM for BGP peers. Support of states of the BGP FSM for BGP peers. Support of these BGP events is
these BGP events are either mandatory or optional. They are either mandatory or optional. These events are triggered by the
triggered by the protocol logic as part of the BGP or using an protocol logic as part of the BGP or by using an operator
operator intervention via a configuration interface to the BGP intervention via a configuration interface to the BGP protocol.
protocol.
These BGP events are of following types: Optional events These BGP events are of following types: Optional events linked to
linked to Optional Session attributes, Administrative Events, Optional Session attributes, Administrative Events, Timer Events, TCP
Timer Events, TCP Connection based Events, and BGP Connection-based Events, and BGP Message-based Events. Both the FSM
Message-based Events. Both the FSM and the BGP events are and the BGP events are explained in detail in [BGP4].
explained in detail in [BGP4].
3. BGP Capabilities 3. BGP Capabilities
The BGP Capability mechanism [RFC2842] provides an easy and flexible The BGP capability mechanism [RFC3392] provides an easy and flexible
way to introduce new features within the protocol. In particular, the way to introduce new features within the protocol. In particular,
BGP capability mechanism allows a BGP speaker to advertise to its the BGP capability mechanism allows a BGP speaker to advertise to its
peers during startup various optional features supported by the peers during startup various optional features supported by the
speaker (and receive similar information from the peers). This allows speaker (and receive similar information from the peers). This
the base BGP protocol to contain only essential functionality, while allows the base BGP to contain only essential functionality, while
at the same time providing a flexible mechanism for signaling providing a flexible mechanism for signaling protocol extensions.
protocol extensions.
4. BGP Persistent Peer Oscillations 4. BGP Persistent Peer Oscillations
Whenever a BGP speaker detects an error in any peer connection, it Whenever a BGP speaker detects an error in a peer connection, it
shuts down the peer and changes its FSM state to IDLE. BGP speaker shuts down the peer and changes its FSM state to IDLE. BGP speaker
requires a Start event to re-initiate its idle peer connection. If requires a Start event to re-initiate an idle peer connection. If
the error remains persistent and BGP speaker generates Start event the error remains persistent and BGP speaker generates a Start event
automatically then it may result in persistent peer flapping. automatically, then it may result in persistent peer flapping.
However, although peer oscillation is found to be wide-spread in BGP Although peer oscillation is found to be wide-spread in BGP
implementations, methods for preventing persistent peer oscillations implementations, methods for preventing persistent peer oscillations
are outside the scope of base BGP protocol specification. are outside the scope of base BGP specification.
5. Implementation Guidelines 5. Implementation Guidelines
A robust BGP implementation is work conserving. This means that if A robust BGP implementation is "work conserving". This means that if
the number of prefixes is bounded, arbitrarily high levels of route the number of prefixes is bounded, arbitrarily high levels of route
change can be tolerated with bounded impact on route convergence for change can be tolerated. High levels can be tolerated with bounded
occasional changes in generally stable routes. impact on route convergence for occasional changes in generally
stable routes.
A robust implementation of BGP should have the following A robust implementation of BGP should have the following
characteristics: characteristics:
1. It is able to operate in almost arbitrarily high levels
of route flap without losing peerings (failing to send
keepalives) or loosing other protocol adjacencies as a
result of BGP load.
2. Instability of a subset of routes should not affect the 1. It is able to operate in almost arbitrarily high levels of
route advertisements or forwarding associated with the set route flap without losing peerings (failing to send
of stable routes. keepalives) or losing other protocol adjacencies as a result
of BGP load.
3. High levels of instability and peers of different CPU speed 2. Instability of a subset of routes should not affect the route
or load resulting in faster or slower processing of routes advertisements or forwarding associated with the set of stable
should not cause instability and should have a bounded routes.
impact on the convergence time for generally stable routes.
3. Instability should not be caused by peers with high levels of
instability or with different CPU speed or load that result in
faster or slower processing of routes. These instable peers
should have a bounded impact on the convergence time for
generally stable routes.
Numerous robust BGP implementations exist. Producing a robust Numerous robust BGP implementations exist. Producing a robust
implementation is not a trivial matter but clearly achievable. implementation is not a trivial matter, but is clearly achievable.
6. BGP Performance characteristics and Scalability 6. BGP Performance Characteristics and Scalability
In this section, we provide "order of magnitude" answers to the In this section, we provide "order of magnitude" answers to the
questions of how much link bandwidth, router memory and router CPU questions of how much link bandwidth, router memory and router CPU
cycles the BGP protocol will consume under normal conditions. In cycles BGP will consume under normal conditions. In particular, we
particular, we will address the scalability of BGP and its will address the scalability of BGP and its limitations.
limitations.
6.1. Link bandwidth and CPU utilization 6.1. Link Bandwidth and CPU Utilization
Immediately after the initial BGP connection setup, BGP peers Immediately after the initial BGP connection setup, BGP peers
exchange complete set of routing information. If we denote the total exchange complete sets of routing information. If we denote the
number of routes in the Internet by N, the total path attributes (for total number of routes in the Internet as N, the total path
all N routes) received from a peer as A, and assume that the networks attributes (for all N routes) received from a peer as A, and assume
are uniformly distributed among the autonomous systems, then the that the networks are uniformly distributed among the autonomous
worst case amount of bandwidth consumed during the initial exchange systems, then the worst-case amount of bandwidth consumed during the
between a pair of BGP speakers (P) is initial exchange between a pair of BGP speakers (P) is
BW = O((N + A) * P) BW = O((N + A) * P)
BGP-4 was created specifically to reduce the size of the set BGP-4 was created specifically to reduce the size of the set of NLRI
of NLRI entries which have to be carried and exchanged by entries, which has to be carried and exchanged by border routers.
border routers. The aggregation scheme, defined in [RFC1519], The aggregation scheme, defined in [RFC1519], describes the
describes the provider-based aggregation scheme in use in provider-based aggregation scheme in use in today's Internet.
today's Internet.
Due to the advantages of advertising a few large aggregate blocks Due to the advantages of advertising a few large aggregate blocks
instead of many smaller class-based individual networks, it is (instead of many smaller class-based individual networks), it is
difficult to estimate the actual reduction in bandwidth and difficult to estimate the actual reduction in bandwidth and
processing that BGP-4 has provided over BGP-3. If we simply processing that BGP-4 has provided over BGP-3. If we simply
enumerate all aggregate blocks into their individual class-based enumerate all aggregate blocks into their individual, class-based
networks, we would not take into account "dead" space that has been networks, we would not take into account "dead" space that has been
reserved for future expansion. The best metric for determining the reserved for future expansion. The best metric for determining the
success of BGP's aggregation is to sample the number NLRI entries in success of BGP's aggregation is to sample the number NLRI entries in
the globally connected Internet today and compare it to projected the globally-connected Internet today, and compare it to growth rates
growth rates before BGP was deployed. that were projected before BGP was deployed.
At the time of this writing, the full set of exterior routes carried At the time of this writing, the full set of exterior routes carried
by BGP is approximately 134,000 network entries [ROUTEVIEWS]. by BGP is approximately 134,000 network entries [ROUTEVIEWS].
6.1.1. CPU utilization 6.1.1. CPU Utilization
An important and fundamental feature of BGP is that BGP's CPU An important and fundamental feature of BGP is that BGP's CPU
utilization depends only on the stability of its network which utilization depends only on the stability of its network which
relates to BGP in terms of BGP UPDATE message announcements. If the relates to BGP in terms of BGP UPDATE message announcements. If the
BGP network is stable: all the BGP routers within its network are in BGP network is stable, all the BGP routers within its network are in
the steady state; then the only link bandwidth and router CPU cycles the steady state. Thus, the only link bandwidth and router CPU
consumed by BGP are due to the exchange of the BGP KEEPALIVE cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE
messages. The KEEPALIVE messages are exchanged only between peers. messages. The KEEPALIVE messages are exchanged only between peers.
The suggested frequency of the exchange is 30 seconds. The KEEPALIVE The suggested frequency of the exchange is 30 seconds. The KEEPALIVE
messages are quite short (19 octets), and require virtually no messages are quite short (19 octets) and require virtually no
processing. As a result, the bandwidth consumed by the KEEPALIVE processing. As a result, the bandwidth consumed by the KEEPALIVE
messages is about 5 bits/sec. Operational experience confirms that messages is about 5 bits/sec. Operational experience confirms that
the overhead (in terms of bandwidth and CPU) associated with the the overhead (in terms of bandwidth and CPU) associated with the
KEEPALIVE messages should be viewed as negligible. KEEPALIVE messages should be viewed as negligible.
During periods of network instability, BGP routers within the network During periods of network instability, BGP routers within the network
are generating routing updates that are exchanged using the BGP are generating routing updates that are exchanged using the BGP
UPDATE messages. The greatest overhead per UPDATE message occurs UPDATE messages. The greatest overhead per UPDATE message occurs
when each UPDATE message contains only a single network. It should be when each UPDATE message contains only a single network. It should
pointed out that in practice routing changes exhibit strong locality be pointed out that, in practice, routing changes exhibit strong
with respect to the route attributes. That is, routes that change locality with respect to the route attributes. That is, routes that
are likely to have common route attributes. In this case, multiple change are likely to have common route attributes. In this case,
networks can be grouped into a single UPDATE message, thus multiple networks can be grouped into a single UPDATE message, thus
significantly reducing the amount of bandwidth required (see also significantly reducing the amount of bandwidth required (see also
Appendix F.1 of [BGP4]). Appendix F.1 of [BGP4]).
6.1.2. Memory requirements 6.1.2. Memory Requirements
To quantify the worst case memory requirements for BGP, we denote the To quantify the worst-case memory requirements for BGP, we denote the
total number of networks in the Internet by N, the mean AS distance total number of networks in the Internet as N, the mean AS distance
of the Internet by M (distance at the level of an autonomous system, of the Internet as M (distance at the level of an autonomous system,
expressed in terms of the number of autonomous systems), the total expressed in terms of the number of autonomous systems), the total
number of unique AS paths as A. Then the worst case memory number of unique AS paths as A. Then the worst-case memory
requirements (MR) can be expressed as requirements (MR) can be expressed as
MR = O(N + (M * A)) MR = O(N + (M * A))
Since a mean AS distance M is a slow moving function of the Because a mean AS distance M is a slow moving function of the
interconnectivity ("meshiness") of the Internet, for all practical interconnectivity ("meshiness") of the Internet, for all practical
purposes the worst case router memory requirements are on the order purposes the worst-case router memory requirements are on the order
of the total number of networks in the Internet times the number of of the total number of networks in the Internet multiplied by the
peers the local system is peering with. We expect that the total number of peers that the local system is peering with. We expect
number of networks in the Internet will grow much faster than the that the total number of networks in the Internet will grow much
average number of peers per router. As a result, BGP's memory faster than the average number of peers per router. As a result,
scaling properties are linearly related to the total number of BGP's memory-scaling properties are linearly related to the total
networks in the Internet. number of networks in the Internet.
The following table illustrates typical memory requirements of a The following table illustrates typical memory requirements of a
router running BGP. We denote average number of routes advertised by router running BGP. We denote the average number of routes
each peer as N, the total number of unique AS paths as A, the mean AS advertised by each peer as N, the total number of unique AS paths as
distance of the Internet as M (distance at the level of an autonomous A, the mean AS distance of the Internet as M (distance at the level
system, expressed in terms of the number of autonomous systems), of an autonomous system, expressed in terms of the number of
number of octets required to store a network as R, and number of autonomous systems), the number of octets required to store a network
bytes required to store one AS in an AS path as P. It is assumed as R, and the number of bytes required to store one AS in an AS path
that each network is encoded as four bytes, each AS is encoded as two as P. It is assumed that each network is encoded as four bytes, each
bytes, and each networks is reachable via some fraction of all of the AS is encoded as two bytes, and each networks is reachable via some
peers (# BGP peers/per net). For purposes of the estimates here, we fraction of all the peers (# BGP peers/per net). For purposes of the
will calculate MR = (((N * R) + (M * A) * P) * S). estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S).
# Networks Mean AS Distance # AS's # BGP peers/per net Memory Req # Networks Mean AS Distance # ASes # BGP peers/per net Memory Req
(N) (M) (A) (P) (MR) (N) (M) (A) (P) (MR)
---------- ---------------- ------ ------------------- -------------- ---------- ---------------- ------ ------------------- -------------
100,000 20 3,000 20 10,400,000 100,000 20 3,000 20 10,400,000
100,000 20 15,000 20 20,000,000 100,000 20 15,000 20 20,000,000
120,000 10 15,000 100 78,000,000 120,000 10 15,000 100 78,000,000
140,000 15 20,000 100 116,000,000 140,000 15 20,000 100 116,000,000
In analyzing BGP's memory requirements, we focus on the size of the In analyzing BGP's memory requirements, we focus on the size of the
BGP RIB table (ignoring implementation details). In particular, we BGP RIB table (ignoring implementation details). In particular, we
derive upper bounds for the size of the BGP RIB table. For example, derive upper bounds for the size of the BGP RIB table. For example,
at the time of this writing, the BGP RIB tables of a typical backbone at the time of this writing, the BGP RIB tables of a typical backbone
router carry on the order of 120,000 entries. Given this number, one router carry on the order of 120,000 entries. Given this number, one
might ask whether it would be possible to have a functional router might ask whether it would be possible to have a functional router
with a table that will have 1,000,000 entries. Clearly the answer to with a table containing 1,000,000 entries. Clearly, the answer to
this question is more related to how BGP is implemented. A robust BGP this question is more related to how BGP is implemented. A robust
implementation with a reasonable CPU and memory should not have BGP implementation with a reasonable CPU and memory should not have
issues scaling to such limits. issues scaling to such limits.
7. BGP Policy Expressiveness and its Implications 7. BGP Policy Expressiveness and its Implications
BGP is unique among deployed IP routing protocols in that routing is BGP is unique among deployed IP routing protocols in that routing is
determined using semantically rich routing policies. Although determined using semantically rich routing policies. Although
routing policies are usually the first thing that comes to a network routing policies are usually the first BGP issue that comes to a
operator's mind concerning BGP, it is important to note that the network operator's mind, it is important to note that the languages
languages and techniques for specifying BGP routing policies are not and techniques for specifying BGP routing policies are not part of
actually a part of the protocol specification ([RFC2622] for an the protocol specification (see [RFC2622] for an example of such a
example of such a policy language). In addition, the BGP policy language). In addition, the BGP specification contains few
specification contains few restrictions, either explicitly or restrictions, explicit or implicit, on routing policy languages.
implicitly, on routing policy languages. These languages have These languages have typically been developed by vendors and have
typically been developed by vendors and have evolved through evolved through interactions with network engineers in an environment
interactions with network engineers in an environment lacking lacking vendor-independent standards.
vendor-independent standards.
The complexity of typical BGP configurations, at least in provider The complexity of typical BGP configurations, at least in provider
networks, has been steadily increasing. Router vendors typically networks, has been steadily increasing. Router vendors typically
provide hundreds of special commands for use in the configuration of provide hundreds of special commands for use in the configuration of
BGP, and this command set is continually expanding. For example, BGP BGP, and this command set is continually expanding. For example, BGP
communities [RFC1997] allow policy writers to selectively attach tags communities [RFC1997] allow policy writers to selectively attach tags
to routes and use these to signal policy information to other to routes and to use these to signal policy information to other
BGP-speaking routers. Many providers allow customers, and BGP-speaking routers. Many providers allow customers, and sometimes
sometimes peers, to send communities that determine the scope peers, to send communities that determine the scope and preference of
and preference of their routes. These developments have their routes. Due to these developments, the task of writing BGP
increasingly given the task of writing BGP configurations configurations has increasingly more aspects associated with open-
aspects associated with open-ended programming. This has ended programming. This has allowed network operators to encode
allowed network operators to encode complex policies in order complex policies in order to address many unforeseen situations, and
to address many unforeseen situations, and has opened the door has opened the door for a great deal of creativity and
for a great deal of creativity and experimentation in routing experimentation in routing policies. This policy flexibility is one
policies. This policy flexibility is one of the main reasons of the main reasons why BGP is so well suited to the commercial
why BGP is so well suited to the commercial environment of the environment of the current Internet.
current Internet.
However, this rich policy expressiveness has come with a cost However, this rich policy expressiveness has come with a cost that is
that is often not recognized. In particular, it is possible often not recognized. In particular, it is possible to construct
to construct locally defined routing policies that can lead to locally defined routing policies that can lead to protocol divergence
unexpected global routing anomalies such as (unintended) and unexpected global routing anomalies such as (unintended) non-
non-determinism and to protocol divergence. If the determinism. If the interacting policies causing such anomalies are
interacting policies causing such anomalies are defined in defined in different autonomous systems, then these problems can be
different autonomous systems, then these problems can be very very difficult to debug and correct. In the following sections, we
difficult to debug and correct. In the following sections, we describe two such cases relating to the existence (or lack thereof)
describe two such cases relating to the existence (or lack of stable routings.
thereof) of stable routings.
7.1. Existence of Unique Stable Routings 7.1. Existence of Unique Stable Routings
One can easily construct sets of policies for which BGP can not One can easily construct sets of policies for which BGP can not
guarantee that stable routings are unique. This can be illustrated guarantee that stable routings are unique. This is illustrated by
by the following simple example. Consider the example of four the following simple example. Consider four Autonomous Systems, AS1,
Autonomous Systems, AS1, AS2, AS3, and AS4. AS1 and AS2 are peers, AS2, AS3, and AS4. AS1 and AS2 are peers, and they provide transit
and they provide transit for AS3 and AS4 respectively, Suppose for AS3 and AS4, respectively. Suppose AS3 provides transit for AS4
further that AS3 provides transit for AS4 (in this case AS3 is a (in this case AS3 is a customer of AS1, and AS4 is a multihomed
customer of AS1, and AS4 is a multihomed customer of both AS3 and customer of both AS3 and AS2). AS4 may want to use the link to AS3
AS2). AS4 may want to use the link to AS3 as a "backup" link, and as a "backup" link, and sends AS3 a community value that AS3 has
sends AS3 a community value that AS3 has configured to lower the configured to lower the preference of AS4's routes to a level below
preference of AS4's routes to a level below that of its upstream that of its upstream provider, AS1. The intended "backup routing" to
provider, AS1. The intended "backup routing" to AS4 is illustrated AS4 is illustrated here:
here:
AS1 ------> AS2 AS1 ------> AS2
/|\ | /|\ |
| | | |
| | | |
| \|/ | \|/
AS3 ------- AS4 AS3 ------- AS4
That is, the AS3-AS4 link is intended to be used only when the
AS2-AS4 link is down (for outbound traffic, AS4 simply gives routes That is, the AS3-AS4 link is intended to be used only when the AS2-
from AS2 a higher local preference). This is a common scenario in AS4 link is down (for outbound traffic, AS4 simply gives routes from
today's Internet. But note that this configuration has another AS2 a higher local preference). This is a common scenario in today's
stable solution: Internet. But note that this configuration has another stable
solution:
AS1 ------- AS2 AS1 ------- AS2
| | | |
| | | |
| | | |
\|/ \|/ \|/ \|/
AS3 ------> AS4 AS3 ------> AS4
In this case, AS3 does not translate the "depref my route" community In this case, AS3 does not translate the "depref my route" community
received from AS4 into a "depref my route" community for AS1, and so received from AS4 into a "depref my route" community for AS1.
if AS1 hears the route to AS4 that transits AS3 it will prefer that Therefore, if AS1 hears the route to AS4 that transits AS3, it will
route (since AS3 is a customer). This state could be reached, for prefer that route (because AS3 is a customer). This state could be
example, by starting in the "correct" backup routing shown first, reached, for example, by starting in the "correct" backup routing
bringing down the AS2-AS4 BGP session, and then bringing it back up. shown first, bringing down the AS2-AS4 BGP session, and then bringing
In general, BGP has no way to prefer the "intended" solution over the it back up. In general, BGP has no way to prefer the "intended"
anomalous one, and which is picked will depend on the unpredictable solution over the anomalous one. The solution picked will depend on
order of BGP messages. the unpredictable order of BGP messages.
While this example is relatively simple, many operators may fail to While this example is relatively simple, many operators may fail to
recognize that the true source of the problem is that the BGP recognize that the true source of the problem is that the BGP
policies of ASes can interact in unexpected ways, and that these policies of ASes can interact in unexpected ways, and that these
interactions can result in multiple stable routings. One can imagine interactions can result in multiple stable routings. One can imagine
that the interactions could be much more complex in the real that the interactions could be much more complex in the real
Internet. We suspect that such anomalies will only become more Internet. We suspect that such anomalies will only become more
common as BGP continues to evolve with richer policy expressiveness. common as BGP continues to evolve with richer policy expressiveness.
For example, extended communities provide an even more flexible means For example, extended communities provide an even more flexible means
of signaling information within and between autonomous systems than of signaling information within and between autonomous systems than
is possible with [RFC1997] communities. At the same time, is possible with [RFC1997] communities. At the same time,
applications of communities by network operators are evolving to applications of communities by network operators are evolving to
address complex issues of inter-domain traffic engineering. address complex issues of inter-domain traffic engineering.
7.2. Existence of Stable Routings 7.2. Existence of Stable Routings
One can also construct a set of policies for which BGP can not One can also construct a set of policies for which BGP can not
guarantee that a stable routing exists (or worse, that a stable guarantee that a stable routing exists (or, worse, that a stable
routing will ever be found). For example, [RFC3345] documents routing will ever be found). For example, [RFC3345] documents
several scenarios that lead to route oscillations associated several scenarios that lead to route oscillations associated with the
with the use of the Multi-Exit Discriminator or MED, use of the Multi-Exit Discriminator (MED) attribute. Route
attribute. Route
oscillation will happen in BGP when a set of policies has no oscillation will happen in BGP when a set of policies has no
solution. That is, when there is no stable routing that satisfies solution. That is, when there is no stable routing that satisfies
the constraints imposed by policy, then BGP has no choice by to keep the constraints imposed by policy, BGP has no choice but to keep
trying. In addition, BGP configurations can have a stable routing, trying. In addition, even if BGP configurations can have a stable
yet the protocol may not be able to find it; BGP can "get trapped" routing, the protocol may not be able to find it; BGP can "get
down a blind alley that has no solution. trapped" down a blind alley that has no solution.
Protocol divergence is not, however, a problem associated solely with Protocol divergence is not, however, a problem associated solely with
use of the MED attribute. This potential exists in BGP even without use of the MED attribute. This potential exists in BGP even without
the use of the MED attribute. Hence, like the unintended the use of the MED attribute. Hence, like the unintended
nondeterminism described in the previous section, this type of nondeterminism described in the previous section, this type of
protocol divergence is an unintended consequence of the unconstrained protocol divergence is an unintended consequence of the unconstrained
nature of BGP policy languages. nature of BGP policy languages.
8. Applicability 8. Applicability
In this section we identify the environments for which BGP well In this section we identify the environments for which BGP is well
suited, and for which environments it is not suitable. This question suited, and the environments for which it is not suitable. This
is partially answered in Section 2 of BGP [BGP4], which states: question is partially answered in Section 2 of BGP [BGP4], which
states:
"To characterize the set of policy decisions that can be "To characterize the set of policy decisions that can be enforced
enforced using BGP, one must focus on the rule that an AS using BGP, one must focus on the rule that an AS advertises to its
advertises to its neighbor ASs only those routes that it neighbor ASes only those routes that it itself uses. This rule
itself uses. This rule reflects the "hop-by-hop" routing reflects the "hop-by-hop" routing paradigm generally used
paradigm generally used throughout the current Internet. throughout the current Internet. Note that some policies cannot
Note that some policies cannot be supported by the be supported by the "hop-by-hop" routing paradigm and thus require
"hop-by-hop" routing paradigm and thus require techniques techniques such as source routing to enforce. For example, BGP
such as source routing to enforce. For example, BGP does does not enable one AS to send traffic to a neighbor AS intending
not enable one AS to send traffic to a neighbor AS that the traffic take a different route from that taken by traffic
intending that the traffic take a different route from originating in the neighbor AS. On the other hand, BGP can
that taken by traffic originating in the neighbor AS. On support any policy conforming to the "hop-by-hop" routing
the other hand, BGP can support any policy conforming to paradigm. Since the current Internet uses only the "hop-by-hop"
the "hop-by-hop" routing paradigm. Since the current routing paradigm and since BGP can support any policy that
Internet uses only the "hop-by-hop" routing paradigm and conforms to that paradigm, BGP is highly applicable as an inter-AS
since BGP can support any policy that conforms to that routing protocol for the current Internet."
paradigm, BGP is highly applicable as an inter-AS routing
protocol for the current Internet."
One of the important points here is that the BGP protocol contains One of the important points here is that BGP contains only essential
only the functionality that is essential, while at the same time functionality, while at the same time providing a flexible mechanism
providing a flexible mechanism within the protocol that allows us to within the protocol that allows us to extend its functionality. For
extend its functionality. For example, BGP capabilities provide an example, BGP capabilities provide an easy and flexible way to
easy and flexible way to introduce new features within the protocol. introduce new features within the protocol. Finally, because BGP was
Finally, since BGP was designed with flexibility and designed to be flexible and extensible, new and/or evolving
extensibility in mind, new and/or evolving requirements can be requirements can be addressed via existing mechanisms.
addressed via existing mechanisms.
To summarize, BGP is well suited as an inter-autonomous system To summarize, BGP is well suited as an inter-autonomous system
routing protocol for any internet that is based on IP [RFC791] routing protocol for any internet that is based on IP [RFC791] as the
as the internet protocol and "hop-by-hop" routing paradigm. internet protocol and the "hop-by-hop" routing paradigm.
9. Acknowledgments 9. Acknowledgements
We would like to thank Paul Traina for authoring previous We would like to thank Paul Traina for authoring previous versions of
versions of this document. Elwyn Davies, Tim Griffin, Randy this document. Elwyn Davies, Tim Griffin, Randy Presuhn, Curtis
Presuhn, Curtis Villamizar and Atanu Ghosh also provided many Villamizar and Atanu Ghosh also provided many insightful comments on
insightful comments on earlier versions of this document. earlier versions of this document.
10. Security Considerations 10. Security Considerations
BGP provides flexible mechanisms with varying levels of complexity BGP provides flexible mechanisms with varying levels of complexity
for security purposes. BGP sessions are authenticated using BGP for security purposes. BGP sessions are authenticated using BGP
session addresses and the assigned AS number. Since BGP session addresses and the assigned AS number. Because BGP sessions
sessions use TCP (and IP) for reliable transport, BGP sessions use TCP (and IP) for reliable transport, BGP sessions are further
are further authenticated and secured by any authentication authenticated and secured by any authentication and security
and security mechanisms used by TCP and IP. mechanisms used by TCP and IP.
BGP uses TCP MD5 option for validating data and protecting against BGP uses TCP MD5 option for validating data and protecting against
spoofing of TCP segments exchanged between its sessions. The usage spoofing of TCP segments exchanged between its sessions. The usage
of TCP MD5 option for BGP is described at length in [RFC 2385]. The of TCP MD5 option for BGP is described at length in [RFC 2385]. The
TCP MD5 Key management is discussed in [RFC 3562]. BGP data TCP MD5 Key management is discussed in [RFC 3562]. BGP data
encryption is provided using IPsec mechanism which encrypts the IP encryption is provided using the IPsec mechanism, which encrypts the
payload data (including TCP and BGP data). The IPsec mechanism can IP payload data (including TCP and BGP data). The IPsec mechanism
be used in both, the transport mode as well as the tunnel mode. The can be used in both the transport mode and the tunnel mode. The
IPsec mechanism is described in [RFC 2406]. Both, the TCP MD5 option IPsec mechanism is described in [RFC2406]. Both the TCP MD5 option
and the IPsec mechanism are not widely deployed security mechanisms and the IPsec mechanism are not widely deployed security mechanisms
for BGP in today's Internet and hence it is difficult to gauge their for BGP in today's Internet. Hence, it is difficult to gauge their
real performance impact when using with BGP. However, since both the real performance impact when using with BGP. However, because both
mechanisms are TCP and IP based security mechanisms, the Link the mechanisms are TCP- and IP-based security mechanisms, the Link
Bandwidth, CPU utilization and router memory consumed by BGP protocol Bandwidth, CPU utilization and router memory consumed by BGP would be
using it would be same as any other TCP and IP based protocols. the same as any other TCP- and IP-based protocols.
BGP uses IP TTL value to protect its External BGP (EBGP) sessions BGP uses the IP TTL value to protect its External BGP (EBGP) sessions
from any TCP (or IP) based CPU intensive attacks. It is a simple from any TCP- or IP-based CPU-intensive attacks. It is a simple
mechanism which suggests the use of filtering BGP (TCP) segments mechanism that suggests the use of filtering BGP (TCP) segments,
using the IP TTL value carried within the IP header of BGP (TCP) using the IP TTL value carried within the IP header of BGP (TCP)
segments exchanged between the EBGP sessions. The BGP TTL mechanism segments that are exchanged between the EBGP sessions. The BGP TTL
is described in [RFC3682]. Usage of [RFC3682] impacts performance in mechanism is described in [RFC3682]. Usage of [RFC3682] impacts
a similar way as using any ACL policies for BGP. performance in a similar way as using any access control list (ACL)
policies for BGP.
Such flexible TCP and IP based security mechanisms, allow BGP to Such flexible TCP- and IP-based security mechanisms, allow BGP to
prevent insertion/deletion/modification of BGP data, any snooping of prevent insertion/deletion/modification of BGP data, any snooping of
the data, session stealing, etc. However, BGP is vulnerable to the the data, session stealing, etc. However, BGP is vulnerable to the
same security attacks that are present in TCP. The [BGP-VUL] same security attacks that are present in TCP. The [BGP-VULN]
explains in depth about the BGP security vulnerability. At the time explains in depth about the BGP security vulnerability. At the time
of this writing, several efforts are underway for creating and of this writing, several efforts are underway for creating and
defining an appropriate security infrastructure within the BGP defining an appropriate security infrastructure within the BGP
protocol to provide authentication and security for its routing protocol to provide authentication and security for its routing
information; some of which include [SBGP] and [SOBGP]. information; these efforts include [SBGP] and [SOBGP].
11. IANA Considerations
This document presents an analysis of the BGP protocol and hence
presents no new IANA considerations.
12. References
12.1. Normative References 11. References
[BGP4] Rekhter, Y., T. Li., and S. Hares, Editors, "A 11.1. Normative References
Border Gateway Protocol 4 (BGP-4)",
draft-ietf-idr-bgp4-2.txt. Work in progress.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, [BGP4] Rekhter, Y., Li., T., and S. Hares, Eds., "A Border
"Classless Inter-Domain Routing (CIDR): an Address Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
Assignment and Aggregation Strategy", RFC 1519,
September, 1993.
[RFC791] "INTERNET PROTOCOL", DARPA INTERNET PROGRAM [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
PROTOCOL SPECIFICATION, RFC 791, September, Inter-Domain Routing (CIDR): an Address Assignment and
1981. Aggregation Strategy", RFC 1519, September 1993.
[RFC1997] Chandra. R, and T. Li, "BGP Communities [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
Attribute", RFC 1997, August, 1996. September 1981.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
the TCP MD5 Signature Option", RFC 2385, Attribute", RFC 1997, August 1996.
August, 1998.
[RFC2842] Chandra, R. and J. Scudder, "Capabilities [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
Advertisement with BGP-4", RFC 2842, May 2000. MD5 Signature Option", RFC 2385, August 1998.
[RFC3345] McPherson, D., Gill, V., Walton, D., and [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana,
A. Retana, "Border Gateway Protocol (BGP) Persistent "Border Gateway Protocol (BGP) Persistent Route
Route Oscillation Condition", RFC 3345, Oscillation Condition", RFC 3345, August 2002.
August, 2002.
[RFC3562] Leech, M., "Key Management Considerations for [RFC3562] Leech, M., "Key Management Considerations for the TCP
the TCP MD5 Signature Option", RFC 3562, MD5 Signature Option", RFC 3562, July 2003.
July, 2003.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized
Generalized TTL Security Mechanism (GTSM)", RFC TTL Security Mechanism (GTSM)", RFC 3682, February
3682, February, 2004. 2004.
[SOBGP] White, R., "Architecture and Deployment
Considerations for Secure Origin BGP (soBGP)",
draft-white-sobgp-architecture-00.txt. Work in
Progress.
[BGP_VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
draft-ietf-idr-bgp-vuln-01.txt. Work in progress with BGP-4", RFC 3392, November 2002.
[SBGP] Lynn, C., Mikkelson, J., and K. Seo, "Secure BGP S-BGP", [BGP-VULN] Murphy, S., "BGP Security Vulnerabilities Analysis",
Internet-Draft, Work in Progress. RFC 4272, January 2006.
12.2. Informative References [SBGP] Seo, K., S. Kent and C. Lynn, "Secure Border Gateway
Protocol (Secure-BGP)", IEEE Journal on Selected Areas
in Communications Vol. 18, No. 4, April 2000, pp. 582-
592.
[RFC854] Postel, J. and J. Reynolds, "TELNET PROTOCOL 11.2. Informative References
SPECIFICATION", RFC 854, May, 1983.
[RFC1105] Lougheed, K., and Y. Rekhter, "Border Gateway [RFC854] Postel, J. and J. Reynolds, "Telnet Protocol
Protocol BGP", RFC 1105, June 1989. Specification", STD 8, RFC 854, May 1983.
[RFC1163] Lougheed, K., and Rekhter, Y, "Border Gateway [RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
Protocol BGP", RFC 1105, June 1990. (BGP)", RFC 1105, June 1989.
[RFC1264] Hinden, R., "Internet Routing Protocol [RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
Standardization Criteria", RFC 1264, October 1991. (BGP)", RFC 1163, June 1990.
[RFC1267] Lougheed, K., and Rekhter, Y, "Border Gateway [RFC1264] Hinden, R., "Internet Routing Protocol Standardization
Protocol 3 (BGP-3)", RFC 1105, October 1991. Criteria", RFC 1264, October 1991.
[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway [RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3
Protocol 4 (BGP-4)", RFC 1771, March 1995. (BGP-3)", RFC 1267, October 1991.
[RFC1772] Rekhter, Y., and P. Gross, Editors, "Application [RFC1772] Rekhter, Y., and P. Gross, Editors, "Application
of the Border Gateway Protocol in the Internet", of the Border Gateway Protocol in the Internet", RFC
RFC 1772, March 1995. 1772, March 1995.
[RFC1774] Traina, P., "BGP-4 protocol analysis", [RFC1774] Traina, P., "BGP-4 Protocol Analysis", RFC 1774, March
RFC 1774, March, 1995. 1995.
[RFC2622] Alaettinoglu, C., et. al., "Routing Policy [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens,
Specification Language (RPSL)" RFC 2622, May, D., Meyer, D., Bates, T., Karrenberg, D., and M.
1998. Terpstra, "Routing Policy Specification Language
(RPSL)", RFC 2622, June 1999.
[RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November, 1998. Payload (ESP)", RFC 2406, November 1998.
[ROUTEVIEWS] Meyer, D., "The Route Views Project", [ROUTEVIEWS] Meyer, D., "The Route Views Project",
http://www.routeviews.org http://www.routeviews.org.
13. Author's Addresses [SOBGP] White, R., "Architecture and Deployment Considerations
for Secure Origin BGP (soBGP)", Work in Progress, May
2005.
Authors' Addresses
David Meyer David Meyer
Email: dmm@1-4-5.net
EMail: dmm@1-4-5.net
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
Email: keyupate@cisco.com
Intellectual Property Statement EMail: keyupate@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 19, line 44 skipping to change at page 16, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 117 change blocks. 
470 lines changed or deleted 425 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/