draft-ietf-idr-bgp4-experience-protocol-03.txt   draft-ietf-idr-bgp4-experience-protocol-04.txt 
INTERNET-DRAFT Danny McPherson INTERNET-DRAFT Danny McPherson
Arbor Networks Arbor Networks
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
Category Informational Category Informational
Expires: March 2004 September 2003 Expires: November 2004 May 2004
Experience with the BGP-4 Protocol Experience with the BGP-4 Protocol
<draft-ietf-idr-bgp4-experience-protocol-03.txt> <draft-ietf-idr-bgp4-experience-protocol-04.txt>
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 43
The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
This document is a product of an individual. Comments are solicited This document is a product of an individual. Comments are solicited
and should be addressed to the author(s). and should be addressed to the author(s).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
=0C
Abstract Abstract
The purpose of this memo is to document how the requirements for The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4). have 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 RFC 1264. In order to fulfill the described in Section 6.0 of RFC 1264. In order to fulfill the
requirement, this report augments RFC 1773 and describes additional requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for protocol was made a Draft Standard and when it was submitted for
Standard. Standard.
=0C
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4 2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4
3. Management Information Base (MIB). . . . . . . . . . . . . . . 5 3. Management Information Base (MIB). . . . . . . . . . . . . . . 5
4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 5 4. Implementation Information . . . . . . . . . . . . . . . . . . 5
5. Operational Experience . . . . . . . . . . . . . . . . . . . . 5 5. Operational Experience . . . . . . . . . . . . . . . . . . . . 5
6. TCP Awareness. . . . . . . . . . . . . . . . . . . . . . . . . 6 6. TCP Awareness. . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 7 7.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 7
7.1.1. MEDs and Potatoes. . . . . . . . . . . . . . . . . . . . 8 7.1.1. MEDs and Potatoes. . . . . . . . . . . . . . . . . . . . 8
7.1.2. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 8 7.1.2. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 8
7.1.3. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 9 7.1.3. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 9
7.1.4. MEDs and Temporal Route Selection. . . . . . . . . . . . 9 7.1.4. MEDs and Temporal Route Selection. . . . . . . . . . . . 9
8. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Local Preference . . . . . . . . . . . . . . . . . . . . . . . 9
9. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 10 9. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 10
10. Internet Dynamics . . . . . . . . . . . . . . . . . . . . . . 11 10. Internet Dynamics . . . . . . . . . . . . . . . . . . . . . . 11
11. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 12 11. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 12
12. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 12 12. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 12
13. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13 13. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13
13.1. Consideration of TCP Characteristics . . . . . . . . . . . 13 13.1. Consideration of TCP Characteristics . . . . . . . . . . . 14
14. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14 14. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14
15. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 15 15. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 15
16. Control over Version Negotiation. . . . . . . . . . . . . . . 15 16. Control over Version Negotiation. . . . . . . . . . . . . . . 15
17. Security Considerations . . . . . . . . . . . . . . . . . . . 15 17. Security Considerations . . . . . . . . . . . . . . . . . . . 15
17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 15 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 16
17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 16 17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 16
17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 16 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 17
17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 17 17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 17
17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 17 17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 17
17.6. Regional Internet Registries (RIRs) and IRRs, 17.6. Regional Internet Registries (RIRs) and IRRs,
A Bit of History . . . . . . . . . . . . . . . . . . . . . . . . 17 A Bit of History . . . . . . . . . . . . . . . . . . . . . . . . 18
17.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19 17.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19
18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 20 18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 20
19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 21 19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 21
20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 22 20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 22
=0C
1. Introduction 1. Introduction
The purpose of this memo is to document how the requirements for The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4). have 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 RFC 1264. In order to fulfill the described in Section 6.0 of RFC 1264. In order to fulfill the
requirement, this report augments RFC 1773 and describes additional requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the knowledge and understanding gained in the time between when the
skipping to change at page 5, line 5 skipping to change at page 5, line 5
Appendix N of [BGP4]. Appendix N of [BGP4].
2.1. A Border Gateway Protocol 2.1. A Border Gateway Protocol
The Initial Version of BGP [RFC 1105]. BGP version 2 is defined in The Initial Version of BGP [RFC 1105]. BGP version 2 is defined in
[RFC 1163]. BGP version 3 is defined in [RFC 1267]. BGP version 4 [RFC 1163]. BGP version 3 is defined in [RFC 1267]. BGP version 4
is defined in [RFC 1771] and [BGP4]. Appendices A, B, C, and D of is defined in [RFC 1771] and [BGP4]. Appendices A, B, C, and D of
[BGP4] provide summaries of the changes between each iteration of the [BGP4] provide summaries of the changes between each iteration of the
BGP specification. BGP specification.
=0C
3. Management Information Base (MIB) 3. Management Information Base (MIB)
The BGP-4 Management Information Base (MIB) has been published [BGP- The BGP-4 Management Information Base (MIB) has been published [BGP-
MIB]. The MIB was updated from previous versions documented in [RFC MIB]. The MIB was updated from previous versions documented in [RFC
1657] and [RFC 1269], respectively. 1657] and [RFC 1269], respectively.
Apart from a few system variables, the BGP MIB is broken into two Apart from a few system variables, the BGP MIB is broken into two
tables: the BGP Peer Table and the BGP Received Path Attribute Table. tables: the BGP Peer Table and the BGP Received Path Attribute Table.
The Peer Table reflects information about BGP peer connections, such The Peer Table reflects information about BGP peer connections, such
as their state and current activity. The Received Path Attribute as their state and current activity. The Received Path Attribute
Table contains all attributes received from all peers before local Table contains all attributes received from all peers before local
routing policy has been applied. The actual attributes used in routing policy has been applied. The actual attributes used in
determining a route are a subset of the received attribute table. determining a route are a subset of the received attribute table.
4. Implementations 4. Implementation Information
There are numerous independent interoperable implementations of BGP There are numerous independent interoperable implementations of BGP
currently available. Although the previous version of this report currently available. Although the previous version of this report
provided an overview of the implementations currently used in the provided an overview of the implementations currently used in the
operational Internet, at this time it has been suggested that a operational Internet, at this time it has been suggested that a
separate BGP Implementation Report [BGP-IMPL] be generated. separate BGP Implementation Report [BGP-IMPL] be generated.
It should be noted that implementation experience with Cisco's BGP-4 It should be noted that implementation experience with Cisco's BGP-4
implementation was documented as part of [RFC 1656]. implementation was documented as part of [RFC 1656].
skipping to change at page 6, line 4 skipping to change at page 6, line 4
This section discusses operational experience with BGP and BGP-4. This section discusses operational experience with BGP and BGP-4.
BGP has been used in the production environment since 1989, BGP-4 BGP has been used in the production environment since 1989, BGP-4
since 1993. Production use of BGP includes utilization of all since 1993. Production use of BGP includes utilization of all
significant features of the protocol. The present production significant features of the protocol. The present production
environment, where BGP is used as the inter-autonomous system routing environment, where BGP is used as the inter-autonomous system routing
protocol, is highly heterogeneous. In terms of the link bandwidth it protocol, is highly heterogeneous. In terms of the link bandwidth it
varies from 56 Kbps to 10 Gbps. In terms of the actual routers that varies from 56 Kbps to 10 Gbps. In terms of the actual routers that
run BGP, it ranges from a relatively slow performance general purpose run BGP, it ranges from a relatively slow performance general purpose
CPUs to very high performance RISC network processors, and includes CPUs to very high performance RISC network processors, and includes
=0C
both special purpose routers and the general purpose workstations both special purpose routers and the general purpose workstations
running various UNIX derivatives and other operating systems. running various UNIX derivatives and other operating systems.
In terms of the actual topologies it varies from very sparse to quite In terms of the actual topologies it varies from very sparse to quite
dense. The requirement for full-mesh IBGP topologies has been dense. The requirement for full-mesh IBGP topologies has been
largely remedied by BGP Route Reflection, Autonomous System largely remedied by BGP Route Reflection, Autonomous System
Confederations for BGP, and perhaps some mix of the two. BGP Route Confederations for BGP, and often some mix of the two. BGP Route
Reflection was initially defined in [RFC 1966] and subsequently Reflection was initially defined in [RFC 1966] and subsequently
updated in [RFC 2796]. Autonomous System Confederations for BGP were updated in [RFC 2796]. Autonomous System Confederations for BGP were
initially defined in [RFC 1965] and subsequently updated in [RFC initially defined in [RFC 1965] and subsequently updated in [RFC
3065]. 3065].
At the time of this writing BGP-4 is used as an inter-autonomous At the time of this writing BGP-4 is used as an inter-autonomous
system routing protocol between all Internet-attached autonomous system routing protocol between all Internet-attached autonomous
systems, with nearly 15k active autonomous systems in the global systems, with nearly 15k active autonomous systems in the global
Internet routing table. Internet routing table.
BGP is used both for the exchange of routing information between a BGP is used both for the exchange of routing information between a
transit and a stub autonomous system, and for the exchange of routing transit and a stub autonomous system, and for the exchange of routing
information between multiple transit autonomous systems. There is no information between multiple transit autonomous systems. There is no
protocol distinction between sites historically considered protocol distinction between sites historically considered
"backbones" versus "regional" or "edge" networks. "backbones" versus "regional" or "edge" networks.
The full set of exterior routes that is carried by BGP is well over The full set of exterior routes that is carried by BGP is well over
120,000 aggregate entries, representing several times that number of 134,000 aggregate entries, representing several times that number of
connected networks. The number of active paths in some service connected networks. The number of active paths in some service
provider core routers exceeds 2.5 million. Native AS_PATH lengths provider core routers exceeds 2.5 million. Native AS path lengths
are as long as 10 for some routes, and "padded" path lengths of 25 or are as long as 10 for some routes, and "padded" path lengths of 25 or
more ASs exist. more autonomous systems exist.
6. TCP Awareness 6. TCP Awareness
BGP employs TCP [RFC 793] as it's Transport Layer protocol. As such, BGP employs TCP [RFC 793] as it's Transport Layer protocol. As such,
all characteristics inherent to TCP are inherited by BGP. all characteristics inherent to TCP are inherited by BGP.
For example, due to TCP's behavior, bandwidth capabilities may not be For example, due to TCP's behavior, bandwidth capabilities may not be
realized due to TCP's slow start algorithms, and slow-start restarts realized due to TCP's slow start algorithms, and slow-start restarts
of connections, etc.. of connections, etc..
7. Metrics 7. Metrics
This section discusses different metrics used within the BGP This section discusses different metrics used within the BGP
=0C
protocol. BGP has a separate metric parameter for IBGP and EBGP. This protocol. BGP has a separate metric parameter for IBGP and EBGP. This
allows policy based metrics to overwrite the distance based metrics; allows policy based metrics to overwrite the distance based metrics;
allowing each autonomous systems to define their independent policies allowing each autonomous systems to define their independent policies
in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED) in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED)
is used as a metric by EBGP peers while BGP Local Preference is used is used as a metric by EBGP peers (i.e., inter-domain) while Local
by IBGP peers. Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain).
7.1. MULTI_EXIT_DISC (MED) 7.1. MULTI_EXIT_DISC (MED)
BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_ BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_
DISC (MED). This value may be used in the tie-breaking process when DISC (MED). This value may be used in the tie-breaking process when
selecting a preferred path to a given address space, and provides BGP selecting a preferred path to a given address space, and provides BGP
speakers with the capability to convey to a peer AS the optimal entry speakers with the capability to convey to a peer AS the optimal entry
point into the local AS. point into the local AS.
Although the MED was meant to only be used when comparing paths Although the MED was meant to only be used when comparing paths
received from different external peers in the same AS, many received from different external peers in the same AS, many
implementations provide the capability to compare MEDs between implementations provide the capability to compare MEDs between
different ASs as well. different autonomous systems as well.
Though this may seem a fine idea for some configurations, care must Though this may seem a fine idea for some configurations, care must
be taken when comparing MEDs between different autonomous systems. be taken when comparing MEDs between different autonomous systems.
BGP speakers often derive MED values by obtaining the IGP metric BGP speakers often derive MED values by obtaining the IGP metric
associated with reaching a given BGP NEXT_HOP within the local AS. associated with reaching a given BGP NEXT_HOP within the local AS.
This allows MEDs to reasonably reflect IGP topologies when This allows MEDs to reasonably reflect IGP topologies when
advertising routes to peers. While this is fine when comparing MEDs advertising routes to peers. While this is fine when comparing MEDs
between multiple paths learned from a single AS, it can result in between multiple paths learned from a single adjacent AS, it can
potentially bad decisions when comparing MEDs between different result in potentially bad decisions when comparing MEDs between
automomous systems. This is most typically the case when the different automomous systems. This is most typically the case when
autonomous systems use different mechanisms to derive IGP metrics, the autonomous systems use different mechanisms to derive IGP
BGP MEDs, or perhaps even use different IGP procotols with vastly metrics, BGP MEDs, or perhaps even use different IGP procotols with
contrasting metric spaces. vastly contrasting metric spaces.
Another MED deployment consideration involves the impact of Another MED deployment consideration involves the impact of
aggregation of BGP routing information on MEDs. Aggregates are often aggregation of BGP routing information on MEDs. Aggregates are often
generated from multiple locations in an AS in order to accommodate generated from multiple locations in an AS in order to accommodate
stability, redundancy and other network design goals. When MEDs are stability, redundancy and other network design goals. When MEDs are
derived from IGP metrics associated with said aggregates the MED derived from IGP metrics associated with said aggregates the MED
value advertised to peers can result in very suboptimal routing. value advertised to peers can result in very suboptimal routing.
The MED was purposely designed to be a "weak" metric that would only The MED was purposely designed to be a "weak" metric that would only
be used late in the best-path decision process. The BGP working be used late in the best-path decision process. The BGP working
group was concerned that any metric specified by a remote operator group was concerned that any metric specified by a remote operator
would only affect routing in a local AS if no other preference was would only affect routing in a local AS if no other preference was
specified. A paramount goal of the design of the MED was to ensure specified. A paramount goal of the design of the MED was to ensure
=0C
that peers could not "shed" or "absorb" traffic for networks that that peers could not "shed" or "absorb" traffic for networks that
they advertise. they advertise.
7.1.1. MEDs and Potatoes 7.1.1. MEDs and Potatoes
In a situation where traffic flows between a pair of destinations, In a situation where traffic flows between a pair of destinations,
each connected to two transit networks, each of the transit networks each connected to two transit networks, each of the transit networks
has the choice of either sending the traffic to the closest peering has the choice of either sending the traffic to the closest peering
to other transit provider or passing traffic to the peering which to other transit provider or passing traffic to the peering which
advertises the least cost through the other provider. The former advertises the least cost through the other provider. The former
skipping to change at page 8, line 39 skipping to change at page 8, line 41
of cold potatoe routing was the NSF funded NSFNET backbone and NSF of cold potatoe routing was the NSF funded NSFNET backbone and NSF
funded regional networks in the mid 1990s. funded regional networks in the mid 1990s.
In some cases a provider may use hot potatoe routing for some In some cases a provider may use hot potatoe routing for some
destinations for a given peer AS and cold potatoe routing for others. destinations for a given peer AS and cold potatoe routing for others.
An example of this is the different treatment of commercial and An example of this is the different treatment of commercial and
research traffic in the NSFNET in the mid 1990s. Then again, this research traffic in the NSFNET in the mid 1990s. Then again, this
might best be described as 'mashed potatoe routing', a term which might best be described as 'mashed potatoe routing', a term which
reflects the complexity of router configurations in use at the time. reflects the complexity of router configurations in use at the time.
Seemingly more intuitive references that fall outside the vegetable
kingdom refer to cold potatoe routing as "best exit routing", and hot
potatoe routing as "closest exit routing", though vegetable.
7.1.2. Sending MEDs to BGP Peers 7.1.2. Sending MEDs to BGP Peers
[BGP4] allows MEDs received from any EBGP peers by a BGP speaker to [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to
=0C
be passed to its IBGP peers. Although advertising MEDs to IBGP peers be passed to its IBGP peers. Although advertising MEDs to IBGP peers
is not a required behavior, it is a common default. MEDs received is not a required behavior, it is a common default. MEDs received
from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP
peers. peers.
Note that many implementations provide a mechanism to derive MED Note that many implementations provide a mechanism to derive MED
values from IGP metrics in order to allow BGP MED information to values from IGP metrics in order to allow BGP MED information to
reflect the IGP topologies and metrics of the network when reflect the IGP topologies and metrics of the network when
propagating information to adjacent autonomous systems. propagating information to adjacent autonomous systems.
7.1.3. MED of Zero Versus No MED 7.1.3. MED of Zero Versus No MED
An implementation MUST provide a mechanism that allows for MED to be [BGP4] requires that an implementation must provide a mechanism that
removed. Previously, implementations did not consider a missing MED allows for MED to be removed. Previously, implementations did not
value to be the same as a MED of zero. No MED value should now be consider a missing MED value to be the same as a MED of zero. [BGP4]
equal to a value of zero. now requires that no MED value be equal to a value of zero.
Note that many implementations provide an mechanism to explicitly Note that many implementations provide a mechanism to explicitly
define a missing MED value as "worst" or less preferable than zero or define a missing MED value as "worst" or less preferable than zero or
larger values. larger values.
7.1.4. MEDs and Temporal Route Selection 7.1.4. MEDs and Temporal Route Selection
Some implementations have hooks to apply temporal behavior in MED- Some implementations have hooks to apply temporal behavior in MED-
based best path selection. That is, all other things being equal up based best path selection. That is, all other things being equal up
to MED consideration, preference would be applied to the "oldest" to MED consideration, preference would be applied to the "oldest"
path, without preferring the lower MED value. The reasoning for this path, without preferring the lower MED value. The reasoning for this
is that "older" paths are presumably more stable, and thus more is that "older" paths are presumably more stable, and thus more
preferable. However, temporal behavior in route selection results in preferable. However, temporal behavior in route selection results in
non-deterministic behavior, and as such, is often undesirable. non-deterministic behavior, and as such, may often be undesirable.
8. LOCAL_PREF 8. Local Preference
The LOCAL_PREF attribute was added so a network operator could easily The LOCAL_PREF attribute was added so a network operator could easily
configure a policy that overrode the standard best path determination configure a policy that overrode the standard best path determination
mechanism without independently configuring local preference policy mechanism without independently configuring local preference policy
on each router. on each router.
One shortcoming in the BGP-4 specification was a suggestion for a One shortcoming in the BGP-4 specification was a suggestion for a
default value of LOCAL-PREF to be assumed if none was provided.
=0C
default value of LOCAL_PREF to be assumed if none was provided.
Defaults of 0 or the maximum value each have range limitations, so a Defaults of 0 or the maximum value each have range limitations, so a
common default would aid in the interoperation of multi-vendor common default would aid in the interoperation of multi-vendor
routers in the same AS (since LOCAL_PREF is a local administration routers in the same AS (since LOCAL_PREF is a local administration
knob, there is no interoperability drawback across AS boundaries). attribute, there is no interoperability drawback across AS
boundaries).
The LOCAL_PREF MUST be sent to IBGP Peers. The LOCAL_PREF Attribute [BGP4] requires that LOCAL_PREF be sent to IBGP Peers and must not be
MUST NOT be sent to EBGP Peers. Although no default value for sent to EBGP Peers. Although no default value for LOCAL_PREF is
LOCAL_PREF is defined, the common default value is 100. defined, the common default value is 100.
Another area where more exploration is required is a method whereby Another area where more exploration is required is a method whereby
an originating AS may influence the best path selection process. For an originating AS may influence the best path selection process. For
example, a dual-connected site may select one AS as a primary transit example, a dual-connected site may select one AS as a primary transit
service provider and have one as a backup. service provider and have one as a backup.
/---- transit B ----\ /---- transit B ----\
end-customer transit A---- end-customer transit A----
/---- transit C ----\ /---- transit C ----\
In a topology where the two transit service providers connect to a In a topology where the two transit service providers connect to a
third provider, the real decision is performed by the third provider third provider, the real decision is performed by the third provider
and there is no mechanism for indicating a preference should the and there is no mechanism for indicating a preference should the
third provider wish to respect that preference. third provider wish to respect that preference.
A general purpose suggestion that has been brought up is the A general purpose suggestion that has been brought up is the
possibility of carrying an optional vector corresponding to the AS- possibility of carrying an optional vector corresponding to the AS_
PATH where each transit AS may indicate a preference value for a PATH where each transit AS may indicate a preference value for a
given route. Cooperating ASs may then chose traffic based upon given route. Cooperating autonomous systems may then chose traffic
comparison of "interesting" portions of this vector according to based upon comparison of "interesting" portions of this vector
routing policy. according to routing policy.
While protecting a given ASs routing policy is of paramount concern, While protecting a given autonoumous systems routing policy is of
avoiding extensive hand configuration of routing policies needs to be paramount concern, avoiding extensive hand configuration of routing
examined more carefully in future BGP-like protocols. policies needs to be examined more carefully in future BGP-like
protocols.
9. Internal BGP In Large Autonomous Systems 9. Internal BGP In Large Autonomous Systems
While not strictly a protocol issue, one other concern has been While not strictly a protocol issue, one other concern has been
raised by network operators who need to maintain autonomous systems raised by network operators who need to maintain autonomous systems
with a large number of peers. Each speaker peering with an external with a large number of peers. Each speaker peering with an external
router is responsible for propagating reachability and path router is responsible for propagating reachability and path
=0C
information to all other transit and border routers within that AS. information to all other transit and border routers within that AS.
This is typically done by establishing internal BGP connections to This is typically done by establishing internal BGP connections to
all transit and border routers in the local AS. all transit and border routers in the local AS.
Note that the number of BGP peers that can be fully meshed depends on Note that the number of BGP peers that can be fully meshed depends on
a number of factors, to include number of prefixes in the routing a number of factors, to include number of prefixes in the routing
system, stability of the system, and perhaps most importantly, system, number of unique path, stability of the system, and perhaps
implementation ifficiency. As a result, although it's difficult to most importantly, implementation efficiency. As a result, although
define "a large number of peers", there is always some practical it's difficult to define "a large number of peers", there is always
limit. some practical limit.
In a large AS, this leads to a full mesh of TCP connections (n * In a large AS, this leads to a full mesh of TCP connections (n *
(n-1)) and some method of configuring and maintaining those (n-1)) and some method of configuring and maintaining those
connections. BGP does not specify how this information is to be connections. BGP does not specify how this information is to be
propagated, so alternatives, such as injecting BGP routing propagated, so alternatives, such as injecting BGP routing
information into the local IGP have been attempted, though it turned information into the local IGP have been attempted, though it turned
out to be a non-practical alternative (to say the least). out to be a non-practical alternative (to say the least).
Several alternatives to a full mesh IBGP have been defined, to Several alternatives to a full mesh IBGP have been defined, to
include BGP Route Reflection [RFC 2796] and AS Confederations for BGP include BGP Route Reflection [RFC 2796] and AS Confederations for BGP
[RFC 3065], in order to alleviate the the need for "full mesh" IBGP. [RFC 3065], in order to alleviate the the need for "full mesh" IBGP.
10. Internet Dynamics 10. Internet Dynamics
As discussed in [BGP4-ANALYSIS], the driving force in CPU and As discussed in [BGP4-ANALYSIS], the driving force in CPU and
bandwidth utilization is the dynamic nature of routing in the bandwidth utilization is the dynamic nature of routing in the
Internet. As the net has grown, the number of route changes per Internet. As the Internet has grown, the frequency of route changes
second has increased. per second has increased.
We automatically get some level of damping when more specific NLRI is We automatically get some level of damping when more specific NLRI is
aggregated into larger blocks, however, this isn't sufficient. In aggregated into larger blocks, however, this isn't sufficient. In
Appendix F of [BGP4] are descriptions of damping techniques that Appendix F of [BGP4] are descriptions of damping techniques that
should be applied to advertisements. In future specifications of should be applied to advertisements. In future specifications of
BGP-like protocols, damping methods should be considered for BGP-like protocols, damping methods should be considered for
mandatory inclusion in compliant implementations. mandatory inclusion in compliant implementations.
BGP Route Flap Damping is defined in [RFC 2439]. BGP Route Flap BGP Route Flap Damping is defined in [RFC 2439]. BGP Route Flap
Damping defines a mechanism to help reduce the amount of routing Damping defines a mechanism to help reduce the amount of routing
information passed between BGP peers, and subsequently, the load on information passed between BGP peers, and subsequently, the load on
these peers, without adversely affecting route convergence time for these peers, without adversely affecting route convergence time for
relatively stable routes. relatively stable routes.
None of the current implementations of BGP Route Flap Damping store None of the current implementations of BGP Route Flap Damping store
route history by unique NRLI and AS Path although it is listed as route history by unique NRLI and AS Path although it is listed as
manditory in RFC 2439. A potential result of failure to consider mandatory in RFC 2439. A potential result of failure to consider
=0C
each AS Path separately is an overly aggressive suppression of each AS Path separately is an overly aggressive suppression of
destinations in a densely meshed network, with the most severe destinations in a densely meshed network, with the most severe
consequence being suppression of a destination after a single consequence being suppression of a destination after a single
failure. Because the top tier autonomous systems in the Internet are failure. Because the top tier autonomous systems in the Internet are
densely meshed, these adverse consequences are observed. densely meshed, these adverse consequences are observed.
Route changes are announced using BGP UPDATE messages. The greatest Route changes are announced using BGP UPDATE messages. The greatest
overhead in advertising UPDATE messages happens whenever route overhead in advertising UPDATE messages happens whenever route
changes to be announced are inefficiently packed. As previously changes to be announced are inefficiently packed. As discussed in a
discussed, announcing routing changes sharing common attributes in a later section, announcing routing changes sharing common attributes
single BGP UPDATE message helps save considerable bandwidth and lower in a single BGP UPDATE message helps save considerable bandwidth and
processing overhead. lower processing overhead.
Persistent BGP errors may cause BGP peers to flap persistently if Persistent BGP errors may cause BGP peers to flap persistently if
peer dampening is not implemented. This would result in significant peer dampening is not implemented. This would result in significant
CPU utilization. Implementors may find it useful to implement peer CPU utilization. Implementors may find it useful to implement peer
dampening to avoid such persistent peer flapping [BGP4]. dampening to avoid such persistent peer flapping [BGP4].
11. BGP Routing Information Bases (RIBs) 11. BGP Routing Information Bases (RIBs)
[BGP4] states "Any local policy which results in routes being added [BGP4] states "Any local policy which results in routes being added
to an Adj-RIB-Out without also being added to the local BGP speaker's to an Adj-RIB-Out without also being added to the local BGP speaker's
skipping to change at page 12, line 38 skipping to change at page 13, line 4
It may be desirable for an implementation to provide a knob that It may be desirable for an implementation to provide a knob that
permits advertisement of "inactive" BGP routes. permits advertisement of "inactive" BGP routes.
It may be also desirable for an implementation to provide a knob that It may be also desirable for an implementation to provide a knob that
allows a BGP speaker to advertise BGP routes that were not selected allows a BGP speaker to advertise BGP routes that were not selected
by decision process. by decision process.
12. Update Packing 12. Update Packing
Multiple unfeasible routes can be advertised in a single BGP Update Multiple unfeasible routes can be advertised in a single BGP Update
=0C
message. In addition, one or more feasible routes can be advertised message. In addition, one or more feasible routes can be advertised
in a single Update message so long as all prefixes share a common in a single Update message so long as all prefixes share a common
attribute set. attribute set.
The BGP4 protocol permits advertisement of multiple prefixes with a The BGP4 protocol permits advertisement of multiple prefixes with a
common set of path attributes to be advertised in a single update common set of path attributes to be advertised in a single update
message, this is commonly referred to as "update packing". When message, this is commonly referred to as "update packing". When
possible, update packing is recommended as it provides a mechanism possible, update packing is recommended as it provides a mechanism
for more efficient behavior in a number of areas, to include: for more efficient behavior in a number of areas, to include:
skipping to change at page 13, line 37 skipping to change at page 14, line 5
parameter that determines the minimum time that must be elapse parameter that determines the minimum time that must be elapse
between the advertisement of routes to a particular destination from between the advertisement of routes to a particular destination from
a single BGP speaker. This value is set on a per BGP peer basis. a single BGP speaker. This value is set on a per BGP peer basis.
Due to the fact that BGP relies on TCP as the Transport protocol, TCP Due to the fact that BGP relies on TCP as the Transport protocol, TCP
can prevent transmission of data due to empty windows. As a result, can prevent transmission of data due to empty windows. As a result,
multiple Updates may be spaced closer together than orginally queued. multiple Updates may be spaced closer together than orginally queued.
Although this is not a common occurrence, implementations should be Although this is not a common occurrence, implementations should be
aware of this. aware of this.
=0C
13.1. Consideration of TCP Characteristics 13.1. Consideration of TCP Characteristics
If a TCP receiver is processing input more slowly than the sender or If a TCP receiver is processing input more slowly than the sender or
if the TCP connection rate is the limiting factor, a form of if the TCP connection rate is the limiting factor, a form of
backpressure is observed by the TCP sending application. When the backpressure is observed by the TCP sending application. When the
TCP buffer fills, the sending application will either block on the TCP buffer fills, the sending application will either block on the
write or receive an error on the write. Common errors in either write or receive an error on the write. Common errors in either
early implementations or an occasional naive new implementation are early implementations or an occasional naive new implementation are
to either set options to block on the write or set options for non- to either set options to block on the write or set options for non-
blocking writes and then treat the errors due to a full buffer as blocking writes and then treat the errors due to a full buffer as
fatal. fatal.
Having recognized that full write buffers are to be expected Having recognized that full write buffers are to be expected
additional implementation pitfalls exist. The application should not additional implementation pitfalls exist. The application should not
attempt to store the TCP stream within the application itself. If attempt to store the TCP stream within the application itself. If
the receiver or the TCP connection is persistently slow, then the the receiver or the TCP connection is persistently slow, then the
buffer can grow until memory is exhausted. A BGP implementation must buffer can grow until memory is exhausted. A BGP implementation is
send changes to all peers for which the TCP connection is not blocked required to send changes to all peers for which the TCP connection is
and must remember to send those changes to the remaining peers when not blocked and is required to remember to send those changes to the
the connection becomes unblocked. remaining peers when the connection becomes unblocked.
If the preferred route for a given NLRI changes multiple times while If the preferred route for a given NLRI changes multiple times while
writes to one or more peers is blocked, only the most recent best writes to one or more peers is blocked, only the most recent best
route needs to be sent. In this way BGP is work conserving. In route needs to be sent. In this way BGP is work conserving. In
times of extremely high route change, a higher volume of route change times of extremely high route change, a higher volume of route change
is sent to those peers which are able to process it more quickly and is sent to those peers which are able to process it more quickly and
a lower volume of route change is sent to those peers not able to a lower volume of route change is sent to those peers not able to
process the changes as quickly. process the changes as quickly.
For implentations which handle differing peer capacity to absorb For implentations which handle differing peer capacity to absorb
skipping to change at page 14, line 41 skipping to change at page 15, line 5
instability. instability.
14. Ordering of Path Attributes 14. Ordering of Path Attributes
The BGP protocol suggests that BGP speakers sending multiple prefixes The BGP protocol suggests that BGP speakers sending multiple prefixes
per an UPDATE message should sort and order path attributes according per an UPDATE message should sort and order path attributes according
to Type Codes. This would help their peers to quickly identify sets to Type Codes. This would help their peers to quickly identify sets
of attributes from different update messages which are semantically of attributes from different update messages which are semantically
different. different.
=0C
Implementers may find it useful to order path attributes according to Implementers may find it useful to order path attributes according to
Type Code so that sets of attributes with identical semantics can be Type Code so that sets of attributes with identical semantics can be
more quickly identified. more quickly identified.
15. AS_SET Sorting 15. AS_SET Sorting
AS_SETs are commonly used in BGP route aggregation. They reduce the AS_SETs are commonly used in BGP route aggregation. They reduce the
size of AS_PATH information by listing AS numbers only once size of AS_PATH information by listing AS numbers only once
regardless of any number of times it might appear in process of regardless of any number of times it might appear in process of
aggregation. AS_SETs are usually sorted in increasing order to aggregation. AS_SETs are usually sorted in increasing order to
facilitate efficient lookups of AS numbers within them. This facilitate efficient lookups of AS numbers within them. This
optimization is entirely optional. optimization is entirely optional.
16. Control over Version Negotiation 16. Control over Version Negotiation
Because pre-BGP-4 route aggregation can't be supported by earlier Because pre-BGP-4 route aggregation can't be supported by earlier
version of BGP, an implementation that supports versions in addition version of BGP, an implementation that supports versions in addition
to BGP-4 should provide the version support on a per-peer basis. to BGP-4 should provide the version support on a per-peer basis. At
the time of this writing all BGP speakers on the Internet are thought
to be running BGP version 4.
17. Security Considerations 17. Security Considerations
BGP a provides flexible and extendable mechanism for authentication BGP a provides flexible and extendable mechanism for authentication
and security. The mechanism allows to support schemes with various and security. The mechanism allows to support schemes with various
degree of complexity. BGP sessions are authenticated based on the IP degree of complexity. BGP sessions are authenticated based on the IP
address of a peer. In addition, all BGP sessions are authenticated address of a peer. In addition, all BGP sessions are authenticated
based on the autonomous system number advertised by a peer. based on the autonomous system number advertised by a peer.
Since BGP runs over TCP and IP, BGP's authentication scheme may be Since BGP runs over TCP and IP, BGP's authentication scheme may be
augmented by any authentication or security mechanism provided by augmented by any authentication or security mechanism provided by
either TCP or IP. either TCP or IP.
=0C
17.1. TCP MD5 Signature Option 17.1. TCP MD5 Signature Option
[RFC 2385] defines a way in which the TCP MD5 signature option can be [RFC 2385] defines a way in which the TCP MD5 signature option can be
used to validate information transmitted between two peers. This used to validate information transmitted between two peers. This
method prevents any third party from injecting information (e.g., a method prevents any third party from injecting information (e.g., a
TCP Reset) into the datastream, or modifying the routing information TCP Reset) into the datastream, or modifying the routing information
carried between two BGP peers. carried between two BGP peers.
TCP MD5 is not ubiquitously deployed at the moment, especially in TCP MD5 is not ubiquitously deployed at the moment, especially in
inter- domain scenarios, largely because of key distribution issues. inter- domain scenarios, largely because of key distribution issues.
Most key distribution mechanisms are considered to be too "heavy" at Most key distribution mechanisms are considered to be too "heavy" at
this point. this point.
It was naively assumed by many for some time that in order to inject
a data segement or reset a TCP transport connection between two BGP
peers an attacker must correctly guess the exact TCP sequence number
(of course, in addition to source and destination ports and IP
addresses). However, it has recently been observed and openly
discussed that the malicous data only needs to fall within the TCP
receive window, which may be quite large, thereby significantly
lowering the complexity of such an attack.
As such, it is recommended that the MD5 TCP Signature Option be
employed to protect BGP from session resets and malicious data
injection.
17.2. BGP Over IPSEC 17.2. BGP Over IPSEC
BGP can run over IPSEC, either in a tunnel, or in transport mode, BGP can run over IPSEC, either in a tunnel, or in transport mode,
where the TCP portion of the IP packet is encrypted. This not only where the TCP portion of the IP packet is encrypted. This not only
prevents random insertion of information into the data stream between prevents random insertion of information into the data stream between
two BGP peers, it also prevents an attacker from learning the data two BGP peers, it also prevents an attacker from learning the data
which is being exchanged between the peers. which is being exchanged between the peers.
IPSEC does, however, offer several options for exchanging session IPSEC does, however, offer several options for exchanging session
keys, which may be useful on inter-domain configurations. These keys, which may be useful on inter-domain configurations. These
options are being explored in many deployments, although no options are being explored in many deployments, although no
definitive solution has been reached on the issue of key exchange for definitive solution has been reached on the issue of key exchange for
BGP in IPSEC. BGP in IPSEC.
It should be noted that since BGP runs over TCP and IP, BGP is It should be noted that since BGP runs over TCP and IP, BGP is
vulnerable to the same denial of service or authentication attacks vulnerable to the same denial of service or authentication attacks
that are present in any other TCP based protocol. that are present in any other TCP based protocol.
=0C
17.3. Miscellaneous 17.3. Miscellaneous
Another issue any routing protocol faces is providing evidence of the Another issue any routing protocol faces is providing evidence of the
validity and authority of the routing information carried within the validity and authority of the routing information carried within the
routing system. This is currently the focus of several efforts at routing system. This is currently the focus of several efforts at
the moment, including efforts to define the threats which can be used the moment, including efforts to define the threats which can be used
against this routing information in BGP [draft-murphy, attack tree], against this routing information in BGP [draft-murphy, attack tree],
and efforts at developing a means to provide validation and authority and efforts at developing a means to provide validation and authority
for routing information carried within BGP [SBGP] [soBGP]. for routing information carried within BGP [SBGP] [soBGP].
skipping to change at page 17, line 29 skipping to change at page 18, line 4
It is the intent that this work within GROW will result in feedback It is the intent that this work within GROW will result in feedback
to BGPv4 and future enhancements to the protocol as necessary. to BGPv4 and future enhancements to the protocol as necessary.
17.5. Internet Routing Registries (IRRs) 17.5. Internet Routing Registries (IRRs)
Many organizations register their routing policy and prefix Many organizations register their routing policy and prefix
origination in the various distributed databases of the Internet origination in the various distributed databases of the Internet
Routing Registry. These databases provide access to the information Routing Registry. These databases provide access to the information
using the RPSL language as defined in [RFC 2622]. While registered using the RPSL language as defined in [RFC 2622]. While registered
=0C
information may be maintained and correct for certain providers, the information may be maintained and correct for certain providers, the
lack of timely or correct data in the various IRR databases has lack of timely or correct data in the various IRR databases has
prevented wide-spread use of this resource. prevented wide-spread use of this resource.
17.6. Regional Internet Registries (RIRs) and IRRs, A Bit of History 17.6. Regional Internet Registries (RIRs) and IRRs, A Bit of History
The NSFNET program used EGP and then BGP to provide external routing The NSFNET program used EGP and then BGP to provide external routing
information. It was the NSF policy of offering differing pricing and information. It was the NSF policy of offering differing pricing and
providing a different level of support to the Research and Education providing a different level of support to the Research and Education
(RE) networks and the Commercial (CO) networks that led to BGP's (RE) networks and the Commercial (CO) networks that led to BGP's
skipping to change at page 18, line 32 skipping to change at page 19, line 4
networking community had long seen the PRDB as too US centric. networking community had long seen the PRDB as too US centric.
Through Reseaux IP Europeens (RIPE) the Europeans had created an open Through Reseaux IP Europeens (RIPE) the Europeans had created an open
format in RIPE-181 and had been maintaining an open database used for format in RIPE-181 and had been maintaining an open database used for
address and AS registry more than policy. The initial conversion of address and AS registry more than policy. The initial conversion of
the PRDB was to RIPE-181 format and tools were converted to make use the PRDB was to RIPE-181 format and tools were converted to make use
of this format. The collection of databases was termed the Internet of this format. The collection of databases was termed the Internet
Routing Registry, with the RIPE database and US NSF funded Routing Routing Registry, with the RIPE database and US NSF funded Routing
Arbitrator (RA) being the inital components of the IRR. Arbitrator (RA) being the inital components of the IRR.
A need to extend RIPE-181 was recognized and RIPE agreed to allow the A need to extend RIPE-181 was recognized and RIPE agreed to allow the
=0C
extensions to be defined within the IETF in the RPS WG. The result extensions to be defined within the IETF in the RPS WG. The result
was the RPSL language. Other work products of the RPS WG provided an was the RPSL language. Other work products of the RPS WG provided an
authentication framework and means to widely distribute the database authentication framework and means to widely distribute the database
in a controlled manner and synchronize the many repositories. Freely in a controlled manner and synchronize the many repositories. Freely
available tools were provided primarily by RIPE, Merit, and ISI, the available tools were provided primarily by RIPE, Merit, and ISI, the
most comprehensive set from ISI. The efforts of the IRR participants most comprehensive set from ISI. The efforts of the IRR participants
has been severely hampered by providers unwilling to keep information has been severely hampered by providers unwilling to keep information
in the IRR up to date. The larger of these providers have been in the IRR up to date. The larger of these providers have been
vocal, claiming that the database entry, simple as it may be, are an vocal, claiming that the database entry, simple as it may be, are an
administrative burden and some acknowledge that doing so provides a administrative burden and some acknowledge that doing so provides a
skipping to change at page 20, line 5 skipping to change at page 20, line 5
We would like to thank Paul Traina and Yakov Rekhter for authoring We would like to thank Paul Traina and Yakov Rekhter for authoring
previous versions of this document and providing valuable input on previous versions of this document and providing valuable input on
this update as well. We would also like to explicitly acknowledge this update as well. We would also like to explicitly acknowledge
Curtis Villamizar for providing both text and thorough reviews. Curtis Villamizar for providing both text and thorough reviews.
Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich
and Jude Ballard for supplying their usual keen eye. and Jude Ballard for supplying their usual keen eye.
Finally, we'd like to think the IDR WG for general and specific input Finally, we'd like to think the IDR WG for general and specific input
that contributed to this document. that contributed to this document.
=0C
18. References 18. References
[RFC 793] Postel, J., "Transmission Control Protocol", RFC 793, [RFC 793] Postel, J., "Transmission Control Protocol", RFC 793,
September 1981. September 1981.
[RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol [RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
BGP", RFC 1105, June 1989. BGP", RFC 1105, June 1989.
[RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol [RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
BGP", RFC 1105, June 1990. BGP", RFC 1105, June 1990.
skipping to change at page 21, line 4 skipping to change at page 21, line 4
Border Gateway Protocol in the Internet", RFC 1772, March Border Gateway Protocol in the Internet", RFC 1772, March
1995. 1995.
[RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC [RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC
1773, March 1995. 1773, March 1995.
[RFC 1966] Bates, T., Chandra, R., "BGP Route Reflection: An [RFC 1966] Bates, T., Chandra, R., "BGP Route Reflection: An
alternative to full mesh IBGP", RFC 1966, June 1996. alternative to full mesh IBGP", RFC 1966, June 1996.
[RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP [RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP
=0C
MD5 Signature Option", RFC 2385, August 1998. MD5 Signature Option", RFC 2385, August 1998.
[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping", [RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",
RFC 2439, November 1998. RFC 2439, November 1998.
[RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification [RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification
Language", RFC 2622, June 1999. Language", RFC 2622, June 1999.
[RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection - [RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection -
An Alternative to Full Mesh IBGP", RFC 2796, April 2000. An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous [RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous
System Confederations for BGP", RFC 3065, Febuary 2001. System Confederations for BGP", RFC 3065, Febuary 2001.
[RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP [RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP
Persistent Route Oscillation Condition", RFC 3345, Persistent Route Oscillation Condition", RFC 3345,
August 2002. August 2002.
[BGP4-ANALYSIS] Work in Progress. [BGP4-ANALYSIS] "BGP-4 Protocol Analysis", Internet-Draft, Work in
Progress.
[BGP4-IMPL] Work in Progress. [BGP4-IMPL] "BGP 4 Implementation Report ", Internet-Draft, Work
in Progress.
[BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border
Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress. Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress.
[SBGP] [SBGP] "Secure BGP", Internet-Draft, Work in Progress.
[soBGP] [soBGP] "Secure Origin BGP", Internet-Draft, Work in Progress.
19. Authors' Addresses 19. Authors' Addresses
Danny McPherson Danny McPherson
Arbor Networks Arbor Networks
Email: danny@arbor.net Email: danny@arbor.net
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
Email: keyupate@cisco.com Email: keyupate@cisco.com
=0C
20. Full Copyright Statement 20. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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