One document matched: draft-ietf-idr-bgp4-experience-protocol-01.txt
Differences from draft-ietf-idr-bgp4-experience-protocol-00.txt
INTERNET-DRAFT Danny McPherson
draft-ietf-idr-bgp4-experience-protocol-01.txtArbor Networks
Keyur Patel
Cisco Systems
Category Informational
Expires: February 2004 August 2003
Experience with the BGP-4 Protocol
<draft-ietf-idr-bgp4-experience-protocol-01.txt>
Status of this Document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
This document is a product of an individual. Comments are solicited
and should be addressed to the author(s).
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
McPherson, Patel [Page 1]
INTERNET-DRAFT Expires: February 2004 August 2003
Abstract
The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as
described in Section 6.0 of RFC 1264. In order to fulfill the
requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for
Standard.
McPherson, Patel [Page 2]
INTERNET-DRAFT Expires: February 2004 August 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4
3. Management Information Base (MIB). . . . . . . . . . . . . . . 5
4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Operational Experience . . . . . . . . . . . . . . . . . . . . 5
6. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 7
6.1.1. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 7
6.1.2. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 8
6.1.3. MEDs and Temporal Route Selection. . . . . . . . . . . . 8
7. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 9
9. Internet Dynamics. . . . . . . . . . . . . . . . . . . . . . . 10
10. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 11
11. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 11
12. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 12
13. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 12
14. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 12
15. Control over Version Negotiation. . . . . . . . . . . . . . . 13
16. Security Considerations . . . . . . . . . . . . . . . . . . . 13
16.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 13
16.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 13
16.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 14
16.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 14
16.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 15
16.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 15
17. References. . . . . . . . . . . . . . . . . . . . . . . . . . 16
18. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 17
19. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 17
McPherson, Patel [Page 3]
INTERNET-DRAFT Expires: February 2004 August 2003
1. Introduction
The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as
described in Section 6.0 of RFC 1264. In order to fulfill the
requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for
Standard.
2. BGP-4 Overview
BGP is an inter-autonomous system routing protocol designed for
TCP/IP internets. The primary function of a BGP speaking system is
to exchange network reachability information with other BGP systems.
This network reachability information includes information on the
list of Autonomous Systems (ASs) that reachability information
traverses. This information is sufficient to construct a graph of AS
connectivity for this reachability from which routing loops may be
pruned and some policy decisions at the AS level may be enforced.
The initial version of the BGP protocol was published in RFC 1105.
Since then BGP Versions 2, 3, and 4 have been developed and are
specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively.
Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in
Appendix N of [BGP4].
2.1. A Border Gateway Protocol
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
is defined in [RFC 1771] and [BGP4]. Appendices A, B, C and D of
[BGP4] provide summaries of the changes between each iteriation of
the BGP specification.
McPherson, Patel Section 2.1. [Page 4]
INTERNET-DRAFT Expires: February 2004 August 2003
3. Management Information Base (MIB)
The BGP-4 Management Information Base (MIB) has been published [BGP-
MIB]. The MIB was updated from previous versions documented in [RFC
1657] and [RFC 1269], respectively.
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.
The Peer Table reflects information about BGP peer connections, such
as their state and current activity. The Received Path Attribute
Table contains all attributes received from all peers before local
routing policy has been applied. The actual attributes used in
determining a route are a subset of the received attribute table.
4. Implementations
There are numerous independent interoperable implementations of BGP
currently available. Although the previous version of this report
provided an overview of the implementations currently used in the
operational Internet, at this time it has been suggested that a
separate BGP Implementation Report [BGP-IMPL] be generated.
It should be noted that implementation experience with Cisco's BGP-4
implementation was documented as part of [RFC 1656].
For all additional implementation information please reference [BGP-
IMPL].
5. Operational Experience
This section discusses operational experience with BGP and BGP-4.
BGP has been used in the production environment since 1989, BGP-4
since 1993. Production use of BGP includes utilization of all
significant features of the protocol. The present production
environment, where BGP is used as the inter-autonomous system routing
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
run BGP it ranges from a relatively slow performance Pentium to a
very high performance RISC-based CPUs, and includes both the special
McPherson, Patel Section 5. [Page 5]
INTERNET-DRAFT Expires: February 2004 August 2003
purpose routers and the general purpose workstations running various
UNIX derivatives and other operating systems.
In terms of the actual topologies it varies from very sparse to quite
dense. The requirement for full-mesh IBGP topologies has been
largely remedied by BGP Route Reflection, Autonomous System
Confederations for BGP, and perhaps some mix of the two. BGP Route
Reflection was initially defined in [RFC 1966] and subsequently
updated in [RFC 2796]. Autonomous System Confederations for BGP were
initially defined in [RFC 1965] and subsequently updated in [RFC
3065].
At the time of this writing BGP-4 is used as an inter-autonomous
system routing protocol between all Internet-attached autonomous
systems, with nearly 15k active autonomous systems in the global
Internet routing table.
BGP is used both for the exchange of routing information between a
transit and a stub autonomous system, and for the exchange of routing
information between multiple transit autonomous systems. There is no
protocol distinction between sites historically considered
"backbones" versus "regional" or "edge" networks.
The full set of exterior routes that is carried by BGP is well over
120,000 aggregate entries, representing several times that number of
connected networks. The number of active paths in some service
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
more ASs exist.
6. Metrics
This section discusses different metrics used within the BGP
protocol. BGP has a seperate metric parameter for IBGP and EBGP. This
allows policy based metrics to overwrite the distance based metrics;
allowing each autonomous systems to define their independent policies
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
by IBGP peers.
McPherson, Patel Section 6. [Page 6]
INTERNET-DRAFT Expires: February 2004 August 2003
6.1. MULTI_EXIT_DISC (MED)
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
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
point into the local AS.
Although the MED was meant to only be used when comparing paths
received from different external peers in the same AS, many
implementations provide the capability to compare MEDs between
different ASs as well.
Though this may seem a fine idea for some configurations, care must
be taken when comparing MEDs between different autonomous systems.
BGP speakers often derive MED values by obtaining the IGP metric
associated with reaching a given BGP NEXT_HOP within the local AS.
This allows MEDs to reasonably reflect IGP topologies when
advertising routes to peers. While this is fine when comparing MEDs
between multiple paths learned from a single AS, it can result in
potentially bad decisions when comparing MEDs between difference
automomous systems. This is most typically the case when the
autonomous systems use different mechanisms to derive IGP metrics,
BGP MEDs, or perhaps even use different IGP procotols with vastly
contrasting metric spaces.
Another MED deployment consideration involves the impact of
aggregation of BGP routing information on MEDs. Aggregates are often
generated from multiple locations in an AS in order to accommodate
stability, redundancy and other network design goals. When MEDs are
derived from IGP metrics associated with said aggregates the MED
value advertised to peers can result in very suboptimal routing.
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
group was concerned that any metric specified by a remote operator
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
that peers could not "shed" or "absorb" traffic for networks that
they advertise.
6.1.1. Sending MEDs to BGP Peers
[BGP4] allows MEDs received from any EBGP peers by a BGP speaker to
McPherson, Patel Section 6.1.1. [Page 7]
INTERNET-DRAFT Expires: February 2004 August 2003
be passed to its IBGP peers. Although advertising MEDs to IBGP peers
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
peers.
Note that many implementations provide a mechanism to derive MED
values from IGP metrics in order to allow BGP MED information to
reflect the IGP topologies and metrics of the network when
propagating information to adjacent autonomous systems.
6.1.2. MED of Zero Versus No MED
An implementation MUST provide a mechanism that allows for MED to be
removed. Previously, implementations did not consider a missing MED
value to be the same as a MED of zero. No MED value should now be
equal to a value of zero.
Note that many implementations provide an mechanism to explicitly
define a missing MED value as "worst" or less preferable than zero or
larger values.
6.1.3. MEDs and Temporal Route Selection
Some implementations have hooks to apply temporal behavior in MED-
based best path selection. That is, all other things being equal up
to MED consideration, preference would be applied to the "oldest"
path, without preferring the lower MED value. The reasoning for this
is that "older" paths are presumably more stable, and thus more
preferable. However, temporal behavior in route slection results in
non-deterministic behavior, and as such, is often undesirable.
7. LOCAL_PREF
The LOCAL_PREF attribute was added so a network operator could easily
configure a policy that overrode the standard best path determination
mechanism without independently configuring local preference policy
on each router.
One shortcoming in the BGP-4 specification was a suggestion for a
McPherson, Patel Section 7. [Page 8]
INTERNET-DRAFT Expires: February 2004 August 2003
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
common default would aid in the interoperation of multi-vendor
routers in the same AS (since LOCAL_PREF is a local administration
knob, there is no interoperability drawback across AS boundaries).
The LOCAL_PREF MUST be sent to IBGP Peers. The LOCAL_PREF Attribute
MUST NOT be sent to EBGP Peers. Although no default value for
LOCAL_PREF is defined, the common default value is 100.
Another area where more exploration is required is a method whereby
an originating AS may influence the best path selection process. For
example, a dual-connected site may select one AS as a primary transit
service provider and have one as a backup.
/---- transit B ----\
end-customer transit A----
/---- transit C ----\
In a topology where the two transit service providers connect to a
third provider, the real decision is performed by the third provider
and there is no mechanism for indicating a preference should the
third provider wish to respect that preference.
A general purpose suggestion that has been brought up is the
possibility of carrying an optional vector corresponding to the AS-
PATH where each transit AS may indicate a preference value for a
given route. Cooperating ASs may then chose traffic based upon
comparison of "interesting" portions of this vector according to
routing policy.
While protecting a given ASs routing policy is of paramount concern,
avoiding extensive hand configuration of routing policies needs to be
examined more carefully in future BGP-like protocols.
8. Internal BGP In Large Autonomous Systems
While not strictly a protocol issue, one other concern has been
raised by network operators who need to maintain autonomous systems
with a large number of peers. Each speaker peering with an external
router is responsible for propagating reachability and path
information to all other transit and border routers within that AS.
This is typically done by establishing internal BGP connections to
McPherson, Patel Section 8. [Page 9]
INTERNET-DRAFT Expires: February 2004 August 2003
all transit and border routers in the local AS.
In a large AS, this leads to a full mesh of TCP connections (n *
(n-1)) and some method of configuring and maintaining those
connections. BGP does not specify how this information is to be
propagated, so alternatives, such as injecting BGP routing
information into the local IGP have been attempted, though it turned
out to be a non-practical alternative (to say the least).
Several alternatives to a full mesh IBGP have been defined, to
include BGP Route Reflection [RFC 2796] and AS Confederations for BGP
[RFC 2065], in order to alleviate the the need for "full mesh" IBGP.
9. Internet Dynamics
As discussed in [BGP4-ANALYSIS], the driving force in CPU and
bandwidth utilization is the dynamic nature of routing in the
Internet. As the net has grown, the number of route changes per
second has increased.
We automatically get some level of damping when more specific NLRI is
aggregated into larger blocks, however, this isn't sufficient. In
Appendix F of [BGP4] are descriptions of damping techniques that
should be applied to advertisements. In future specifications of
BGP-like protocols, damping methods should be considered for
mandatory inclusion in compliant implementations.
BGP Route Flap Damping is defined in [RFC 2439]. BGP Route Flap
Damping defines a mechanism to help reduce the amount of routing
information passed between BGP peers, and subsequently, the load on
these peers, without adversely affecting route convergence time for
relatively stable routes.
Route changes are announced using BGP UPDATE messages. The greatest
overhead in advertising UPDATE messages happens whenever route
changes to be announced are inefficiently packed. As previously
discussed, announcing routing changes sharing common attributes in a
single BGP UPDATE message helps save considerable bandwidth and lower
processing overhead.
Persistent BGP errors may cause BGP peers to flap persistently if
peer dampening is not implemented. This would result in significant
CPU utilization. Implementors may find it useful to implement peer
dampening to avoid such persistent peer flapping [BGP4].
McPherson, Patel Section 9. [Page 10]
INTERNET-DRAFT Expires: February 2004 August 2003
10. BGP Routing Information Bases (RIBs)
[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
forwarding table, is outside the scope of this document".
However, several well-known implementations do not confirm that Loc-
RIB entries were used to populate the forwarding table before
installing them in the Adj-RIB-Out. The most common occurrence of
this is when routes for a given prefix are presented by more than one
protocol and the preferences for the BGP learned route is lower than
that of another protocol. As such, the route learned via the other
protocol is used to populate the forwarding table.
It may be desirable for an implementation to provide a knob that
permits advertisement of "inactive" BGP routes.
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
by descision process.
11. Update Packing
Multiple unfeasible routes can be advertised in a single BGP Update
message. In addition, one or more feasible routes can be advertised
in a single Update message so long as all prefixes share a common
attribute set.
The BGP4 protocol permits advertisement of multiple prefixes with a
common set of path attributes to be advertised in a single update
message, this is commonly referred to as "update packing". When
possible, update packing is recommended as it provides a mechanism
for more efficient behavior in a number of areas, to include:
o Reduction in system overhead due to generation or receipt of
fewer Update messages.
o Reduction in network overhead as a result of less packets
and lower bandwidth consumption.
o Allows you to process path attributes and look for matching
sets in your AS_PATH database (if you have one) less
frequently. Consistent ordering of the path attributes
allows for ease of matching in the database as you don't have
McPherson, Patel Section 11. [Page 11]
INTERNET-DRAFT Expires: February 2004 August 2003
different representations of the same data.
The BGP protocol suggests that withdrawal information should be
packed in the begining of Update message, followed by information
about more or less specific reachable routes in a single UPDATE
message. This helps alleviate excessive route flapping in BGP.
12. Limit Rate Updates
The BGP protocol defines different mechanisms to rate limit the
Updates. The BGP protocol defines MinRouteAdvertisementInterval
parameter that determines the minimum time that must be elsape
between the advertisement of routes to a particular destination from
a single BGP speaker. This value is set on a per BGP peer basis.
13. Ordering of Path Attributes
The BGP protocol suggests that BGP speakers sending multiple prefixes
per an UPDATE message should sort and order path attributes according
to Type Codes. This would help their peers to quickly identify sets
of attributes from different update messages which are semantically
different.
Implementers may find it useful to order path attributes according to
Type Code so that sets of attributes with identical semantics can be
more quickly identified.
14. AS_SET Sorting
AS_SETs are commonly used in BGP route aggregation. They reduce the
size of AS_PATH information by listing AS numbers only once
regardless of any number of times it might appear in process of
aggregation. AS_SETs are usually sorted in increasing order to
facilitate efficient lookups of AS numbers within them. This
optimization is entirely optional.
McPherson, Patel Section 14. [Page 12]
INTERNET-DRAFT Expires: February 2004 August 2003
15. Control over Version Negotiation
Because pre-BGP-4 route aggregation can't be supported by earlier
version of BGP, an implementation that supports versions in addition
to BGP-4 should provide the version support on a per-peer basis.
16. Security Considerations
BGP provides flexible and extendable mechanism for authentication and
security. The mechanism allows to support schemes with various
degree of complexity. BGP sessions are authenticated based on the IP
address of a peer. In addition, all BGP sessions are authenticated
based on the autonomous system number advertised by a peer.
Since BGP runs over TCP and IP, BGP's authentication scheme may be
augmented by any authentication or security mechanism provided by
either TCP or IP.
16.1. TCP MD5 Signature Option
RFC 2385 defines a way in which the TCP MD5 signature option can be
used to valid information transmitted between two peers. This method
prevents any third party from injecting information (e.g., a TCP RST)
into the datastream, or modifying the routing information carried
between two BGP peers. RFC ???? provides suggestions for choosing
passwords to be used with MD5.
TCP MD5 is not ubiquitously deployed at the moment, especially in
inter- domain scenarios, largely because of key distribution issues.
Most key distribution mechanisms are considered to be too "heavy" at
this point.
16.2. BGP Over IPSEC
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
McPherson, Patel Section 16.2. [Page 13]
INTERNET-DRAFT Expires: February 2004 August 2003
prevents random insertion of information into the data stream between
two BGP peers, it also prevents an attacker from learning the data
which is being exchanged between the peers.
IPSEC does, however, offer several options for exchanging session
keys, which may be useful on inter-domain configurations. These
options are being explored in many deployments, although no
definitive solution has been reach on the issue of key exchange for
BGP in IPSEC.
It should be noted that since BGP runs over TCP and IP, BGP is
vulnerable to the same denial of service or authentication attacks
that are present in any other TCP based protocol.
16.3. Miscellaneous
Another issue any routing protocol faces is providing evidence of the
validity and authority of the routing information carried within the
routing system. This is currently the focus of several efforts at
the moment, including efforts to define the threats which can be used
against this routing information in BGP [draft-murphy, attack tree],
and efforts at developing a means to provide validation and authority
for routing information carried within BGP [SBGP] [soBGP].
In addition, the Routing Protocol Security Requirements (RPSEC)
working group has been chartered within the Routing Area of the IETF
in order to discuss and assist in addressing issues surrounding
routing protocol security. It is the intent that this work within
RPSEC will result in feedback to BGPv4 and future enhancements to the
protocol where appropriate.
16.4. PTOMAINE and GROW
The Prefix Taxonomy (PTOMAINE) working group, recently replaced by
the Global Routing Operations (GROW) working group, is chartered to
consider and measure the problem of routing table growth, the effects
of the interactions between interior and exterior routing protocols,
and the effect of address allocation policies and practices on the
global routing system. Finally, where appropriate, GROW will also
document the operational aspects of measurement, policy, security and
VPN infrastructures.
McPherson, Patel Section 16.4. [Page 14]
INTERNET-DRAFT Expires: February 2004 August 2003
One such item GROW is currently studying is the effects of route
aggregation and the inability to aggregate over multiple provider
boundaries due to inadequate provider coordination.
It is the intent that this work within GROW will result in feedback
to BGPv4 and future enhancements to the protocol as necessary.
16.5. Internet Routing Registries (IRRs)
Many organizations register their routing policy and prefix
origination in the various distributed databases of the Internet
Routing Registry. These databases provide access to the information
using the RPSL language as defined in [RFC 2622]. While registered
information may be maintained and correct for certain providers, the
lack of timely or correct data in the various IRR databases has
prevented wide-spread use of this resource.
16.6. Acknowledgements
We would like to thank Paul Traina and Yakov Rekhter for authoring
previous versions of this document. We would also like to
acknowledge Russ White, Jeffrey Haas and Curtis Villamizar for
valuable feedback on this document.
McPherson, Patel Section 16.6. [Page 15]
INTERNET-DRAFT Expires: February 2004 August 2003
17. References
[RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
BGP", RFC 1105, June 1989.
[RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
BGP", RFC 1105, June 1990.
[RFC 1264] Hinden, R., "Internet Routing Protocol Standardization
Criteria", RFC 1264, October 1991.
[RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3
(BGP-3)", RFC 1105, October 1991.
[RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and
Implementation Experience", RFC 1656, July 1994.
[RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the
Border Gateway Protocol in the Internet", RFC 1772, March
1995.
[RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC
1773, March 1995.
[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",
RFC 2439, November 1998.
[RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification
Language", RFC 2622, June 1999.
[RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection -
An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous
System Confederations for BGP", RFC 3065, Febuary 2001.
[RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP
Persistent Route Oscillation Condition", RFC 3345,
August 2002.
McPherson, Patel Section 17. [Page 16]
INTERNET-DRAFT Expires: February 2004 August 2003
[BGP4-ANALYSIS] Work in Progress.
[BGP4-IMPL] Work in Progress.
[BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border
Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress.
18. Authors' Addresses
Danny McPherson
Arbor Networks
Email: danny@arbor.net
Keyur Patel
Cisco Systems
Email: keyupate@cisco.com
19. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
McPherson, Patel Section 19. [Page 17]
INTERNET-DRAFT Expires: February 2004 August 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
McPherson, Patel Section 19. [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-21 20:54:52 |