draft-ietf-idr-bgp4-op-experience-00.txt   draft-ietf-idr-bgp4-op-experience-01.txt 
Inter-Domain Routing Working Group Paul Traina Inter-Domain Routing Working Group Paul Traina
INTERNET DRAFT cisco Systems INTERNET DRAFT cisco Systems
<draft-ietf-idr-bgp4-op-experience-00.txt> October 1995 <draft-ietf-idr-bgp4-op-experience-01.txt> October 31, 1995
Operational Experience with the BGP-4 protocol Operational Experience with the BGP-4 protocol
Status of this Memo Status of this Memo
This memo provides information for the Internet community. It does This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is not specify an Internet standard. Distribution of this memo is
unlimited. unlimited.
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
skipping to change at page 1, line 31 skipping to change at page 1, line 31
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working Drafts as reference material or to cite them other than as a "working
draft" or "work in progress". draft" or "work in progress".
Introduction 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 to Full Standard have been satisfied by advancing a routing protocol to Full Standard have been satisfied by
Border Gateway Protocol version 4 (BGP-4). This report documents Border Gateway Protocol version 4 (BGP-4). This report documents
experience with BGP. This is the second of two reports on the BGP experience with BGP. It is the second of two reports on the BGP
protocol. As required by the Internet Activities Board (IAB) and the protocol.
Internet Engineering Steering Group (IESG), the first report will
present a performance analysis of the BGP protocol.
The remaining sections of this memo document how BGP satisfies The remaining sections of this memo document how BGP satisfies
General Requirements specified in Section 3.0, as well as General Requirements specified in Section 3.0, as well as the
Requirements for Draft Standard specified in Section 6.0 of the Requirements for Full Standard as specified in Section 6.0 of the
"Internet Routing Protocol Standardization Criteria" document [1]. "Internet Routing Protocol Standardization Criteria" document [1].
This report is based on the initial work of Peter Lothberg (STUPI),
Andrew Partan (UUNET), and several others.
Please send comments to bgp@ans.net. Please send comments to bgp@ans.net.
Acknowledgments
The BGP protocol has been developed by the IDR (formerly BGP) Working
Group of the Internet Engineering Task Force. I would like to
express deepest thanks to Yakov Rekhter and Sue Hares, co-chairs of
the IDR working group. I'd also like to explicitly thank Yakov
Rekhter and Tony Li for the review of this document as well as
constructive and valuable comments.
Documentation Documentation
BGP is an inter-autonomous system routing protocol designed for BGP is an inter-autonomous system routing protocol designed for
TCP/IP internets. Version 1 of the BGP protocol was published in RFC TCP/IP networks. Version 1 of the BGP protocol was published in RFC
1105. Since then BGP Versions 2, 3, and 4 have been developed. 1105. Since then BGP Versions 2, 3, and 4 have been developed.
Version 2 was documented in RFC 1163. Version 3 is documented in RFC Version 2 was documented in RFC 1163. Version 3 is documented in RFC
1267. The changes between versions 1, 2 and 3 are explained in 1267. The changes between versions 1, 2 and 3 are explained in
Appendix 2 of [2]. All of the functionality that was present in the Appendix 2 of [2]. All of the functionality that was present in the
previous versions is present in version 4. previous versions is present in version 4.
BGP version 2 removed from the protocol the concept of "up", "down", BGP version 2 removed from the protocol the concept of "up", "down",
and "horizontal" relations between autonomous systems that were and "horizontal" relations between autonomous systems that were
present in version 1. BGP version 2 introduced the concept of path present in version 1. BGP version 2 introduced the concept of path
attributes. In addition, BGP version 2 clarified parts of the attributes. In addition, BGP version 2 clarified parts of the
skipping to change at page 2, line 40 skipping to change at page 2, line 23
BGP version 3 lifted some of the restrictions on the use of the BGP version 3 lifted some of the restrictions on the use of the
NEXT_HOP path attribute, and added the BGP Identifier field to the NEXT_HOP path attribute, and added the BGP Identifier field to the
BGP OPEN message. It also clarifies the procedure for distributing BGP OPEN message. It also clarifies the procedure for distributing
BGP routes between the BGP speakers within an autonomous system. BGP routes between the BGP speakers within an autonomous system.
BGP version 4 redefines the (previously class-based) network layer BGP version 4 redefines the (previously class-based) network layer
reachability portion of the updates to specify prefixes of arbitrary reachability portion of the updates to specify prefixes of arbitrary
length in order to represent multiple classful networks in a single length in order to represent multiple classful networks in a single
entry as discussed in [5]. BGP version 4 has also modified the AS- entry as discussed in [5]. BGP version 4 has also modified the AS-
PATH attribute so that sets of autonomous systems, as well as PATH attribute so that sets of autonomous systems, as well as
individual ASs may be described. In addition, BGP version for has individual ASs may be described. In addition, BGP version 4 has re-
redescribed the INTER-AS METRIC attribute as the MULTI-EXIT described the INTER-AS METRIC attribute as the MULTI-EXIT
DISCRIMINATOR and added new LOCAL-PREFERENCE and AGGREGATOR DISCRIMINATOR and added new LOCAL-PREFERENCE and AGGREGATOR
attributes. attributes.
Possible applications of BGP in the Internet are documented in [3]. Possible applications of BGP in the Internet are documented in [3].
The BGP protocol was developed by the IDR Working Group of the The BGP protocol was developed by the IDR Working Group of the
Internet Engineering Task Force. This Working Group has a mailing Internet Engineering Task Force. This Working Group has a mailing
list, iwg@ans.net, where discussions of protocol features and list, bgp@ans.net, where discussions of protocol features and
operation are held. The IDR Working Group meets regularly during the operation are held. The IDR Working Group meets regularly during the
quarterly Internet Engineering Task Force conferences. Reports of quarterly Internet Engineering Task Force conferences. Reports of
these meetings are published in the IETF's Proceedings. these meetings are published in the IETF's Proceedings.
MIB MIB
A BGP-4 Management Information Base has been published [4]. The MIB A BGP-4 Management Information Base has been published [4]. The MIB
was written by Steve Willis (Wellfleet), John Burruss (Wellfleet), was written by Steve Willis (Bay), John Burruss (Bay), and John Chu
and John Chu (IBM). (IBM).
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.
Security Considerations Security Considerations
BGP provides flexible and extendible mechanism for authentication and BGP provides flexible and extendible mechanism for authentication and
security. The mechanism allows to support schemes with various security. The mechanism allows the support of schemes with various
degree of complexity. All BGP sessions are authenticated based on degree of complexity. All BGP sessions are authenticated based on
the BGP Identifier of a peer. In addition, all BGP sessions are the BGP Identifier of a peer. In addition, all BGP sessions are
authenticated based on the autonomous system number advertised by a authenticated based on the autonomous system number advertised by a
peer. As part of the BGP authentication mechanism, the protocol peer. As part of the BGP authentication mechanism, the protocol
allows to carry encrypted digital signature in every BGP message. allows the carriage of an encrypted digital signature in every BGP
All authentication failures result in sending the NOTIFICATION message. All authentication failures result in the sending of a
messages and immediate termination of the BGP connection. NOTIFICATION message and immediate termination of the BGP connection.
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.
However, since BGP runs over TCP and IP, BGP is vulnerable to the However, since BGP runs over TCP and IP, BGP is vulnerable to the
same denial of service or authentication attacks that are present in same denial of service or authentication attacks that are present in
any other TCP based protocol. any other TCP based protocol.
One method for improving the security of TCP connections for use with One method for improving the security of TCP connections for use with
BGP has been documented in [7]. BGP has been documented in [7].
Operational experience Operational experience
This section discusses operational experience with BGP and BGP-4. This section discusses operational experience with BGP-4, which has
involved the use of several independent implementations of BGP.
BGP has been used in the production environment since 1989, BGP-4 BGP has been used in the Internet since 1989, BGP-4 since 1993. This
since 1993. This use involves at least two of the implementations use has involved at least three independant implementations.
listed above. Production use of BGP includes utilization of all Production use of BGP has included utilization of all significant
significant features of the protocol. The present production features of the protocol. The present production environment, where
environment, where BGP is used as the inter-autonomous system routing BGP is used as the inter-autonomous system routing protocol, is
protocol, is highly heterogeneous. In terms of the link bandwidth it highly heterogeneous.
varies from 28 Kbits/sec to 150 Mbits/sec. In terms of the actual
routes that run BGP it ranges from a relatively slow performance
PC/RT to a very high performance RISC based CPUs, and includes both
the special purpose routers and the general purpose workstations
running UNIX.
In terms of the actual topologies it varies from a very sparse This environment includes link bandwidths which vary from from 28
(spanning tree of ICM) to a quite dense (NSFNET backbone). Kbits/sec to 150 Mbits/sec.
Routers which run BGP range from relatively low-performanced IBM
PC/RTs to those equiped with high performance RISC based CPUs, and
includes both the special purpose routers and the general purpose
workstations running UNIX.
Topologies in the production environment vary from the very sparse
(e.g. the spanning tree of the ICM network) to quite dense (e.g.
Sprintlink, Alternet, and MCI backbones).
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 significant autonomous systems, system routing protocol between all significant autonomous systems,
including, but by all means not limited to: Alternet, ANS, Ebone, including, but by all means not limited to: Alternet, ANS, Ebone,
ICM, IIJ, MCI, NSFNET, and Sprint. The smallest know backbone ICM, IIJ, MCI, and Sprint. The smallest know backbone consists of
consists of one router, whereas the largest contains nearly 90 BGP one BGP speaker, whereas the largest contains nearly 120 BGP
speakers. All together, there are several hundred known BGP speaking speakers. All together, there are several thousand known BGP
routers. speaking routers.
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
distinction between sites historically considered backbones vs distinction between sites historically considered backbones vs those
"regional" networks. considered "local" networks.
Within most transit networks, BGP is used as the exclusive carrier of Within most transit networks, BGP is used as the exclusive carrier of
the exterior routing information. At the time of this writing within exterior routing information. At the time of this writing, few sites
a few sites use BGP in conjunction with an interior routing protocol propogate all exterior routing information into their interior
to carry exterior routing information. routing protocols.
The full set of exterior routes that is carried by BGP is well over
30,000 aggregate entries representing several times that number of
connected networks.
Operational experience described above involved multi-vendor The full set of exterior routes that is carried by BGP in the
deployment (cisco, and "gated"). production Internet is well over 30,000 distinct classless prefixes
representing several times that number of connected networks.
Operational experience with BGP exercised all basic features of the Operational experience with BGP-4 has exercised all basic features of
protocol, including authentication, routing loop suppression and the the protocol, including authentication, routing loop suppression and
new features of BGP-4, enhanced metrics and route aggregation. the new features of BGP-4: enhanced metrics and route aggregation.
Bandwidth consumed by BGP has been measured at the interconnection Bandwidth consumed by BGP has been measured at the interconnection
points between CA*Net and T1 NSFNET Backbone. The results of these points between CA*Net and T1 NSFNET Backbone. The results of these
measurements were presented by Dennis Ferguson during the Twentifirst measurements were presented by Dennis Ferguson during the Twenty-
IETF, and are available from the IETF Proceedings. These results first IETF, and are available from the IETF Proceedings. These
showed clear superiority of BGP as compared with EGP in the area of results showed clear superiority of BGP over EGP when protocol
bandwidth consumed by the protocol. Observations on the CA*Net by bandwidth consumption is compared. Observations on the CA*Net by
Dennis Ferguson, and on the T1 NSFNET Backbone by Susan Hares Dennis Ferguson, and on the T1 NSFNET Backbone by Susan Hares
confirmed clear superiority of the BGP protocol family as compared confirmed clear superiority of the BGP protocol family as compared
with EGP in the area of CPU requirements. with EGP in the area of CPU requirements.
Migration to BGP version 4 Migration to BGP version 4
On multiple occasions some members of IETF expressed concern about On multiple occasions some members of IETF expressed concern about
the migration path from classful protocols to classless protocols the migration path from classful protocols to classless protocols
such as BGP-4. such as BGP-4.
BGP-4 was rushed into production use on the Internet because of the BGP-4 was rushed into production use on the Internet because of the
exponential growth of routing tables and the increase of memory and exponential growth of routing tables and the increase of memory and
CPU utilization required by BGP. As such, migration issues that CPU utilization required by BGP. As such, migration issues that
normally would have stalled deployment were cast aside in favor of normally would have stalled deployment were cast aside in favor of
pragmatic and intelligent deployment of BGP-4 by network operators. pragmatic and intelligent deployment of BGP-4 by network operators.
There was much discussion about creating "route exploders" which There was much discussion about creating "prefix exploders" which
would enumerate individual class-based networks of CIDR allocations would enumerate individual class-based networks of CIDR allocations
to BGP-3 speaking routers, however a cursory examination showed that to BGP-3 speaking routers, however a cursory examination showed that
this would vastly hasten the requirement for more CPU and memory this would vastly hasten the requirement for more CPU and memory
resources for these older implementations. There would be no way resources for these older implementations. There would be no way
internal to BGP to differentiate between known used destinations and internal to BGP to differentiate between known used destinations and
the unused portions of the CIDR allocation. the unused portions of advertised CIDR allocations.
The migration path chosen by the majority of the operators was known The migration path chosen by the operators was known as "CIDR,
as "CIDR, default, or die!" default, or die."
To test BGP-4 operation, a virtual "shadow" Internet was created by To test BGP-4 operation, a virtual "shadow" Internet was created by
linking Alternet, Ebone, ICM, and cisco over GRE based tunnels. linking Alternet, Ebone, ICM, and cisco over GRE based tunnels.
Experimentation was done with actual live routing information by Experimentation was done with actual live routing information by
establishing BGP version 3 connections with the production networks establishing BGP version 3 connections with the production networks
at those sites. This allowed extensive regression testing before at those sites. This allowed extensive regression testing before
deploying BGP-4 on production equipment. deploying BGP-4 on production equipment.
After testing on the shadow network, BGP-4 implementations were After testing using the shadow network, BGP-4 implementations were
deployed on the production equipment at those sites. BGP-4 capable deployed on production transit networks at those sites. BGP-4
routers negotiated BGP-4 connections and interoperated with other capable routers negotiated BGP-4 connections and inter-operated with
sites by speaking BGP-3. Several test aggregate routes were injected other sites by speaking BGP-3. Several test aggregate routes were
into this network in addition to classfull destinations for injected into this network in addition to classful destinations for
compatibility with BGP-3 speakers. compatibility with BGP-3 speakers.
At this point, the shadow-Internet was re-chartered as an At this point, the shadow-Internet was re-chartered as an
"operational experience" network. tunnel connections were "operational experience" network. Tunnel connections were
established with most major transit service operators so that established with most major transit service operators so that
operators could gain some understanding of how the introduction of operators could gain some understanding of how the introduction of
aggregate destinations would affect routing. aggregate destinations would affect routing.
After being satisfied with the initial deployment of BGP-4, a number After being satisfied with the initial deployment of BGP-4, a number
of sites chose to withdraw their class-based advertisements and rely of sites chose to withdraw their class-based advertisements and rely
only on their CIDR aggregate advertisements. This provided only on their CIDR aggregate advertisements. This supplied
motivation for transit providers who had not migrated to either do motivation for transit providers who had not migrated to either do
so, accept a default route, or lose connectivity to several popular so, accept a default route, or lose connectivity to several popular
destinations. destinations.
Currently, BGP-4 is the default choice for carrying exterior routing
information in the production Internet.
Metrics Metrics
BGP version 4 re-defined the old INTER-AS metric as a MULTI-EXIT- BGP version 4 re-defined the INTER-AS metric as a MULTI-EXIT-
DISCRIMINATOR. This value may be used in the tie breaking process DISCRIMINATOR. This value may be used in the tie breaking process
when selecting a preferred path to a given address space. The MED is when selecting a preferred path to a given address space. The "MED"
meant to only be used when comparing paths received from different is intended to be used only when comparing paths received from
external peers in the same AS to indicate the preference of the different external peers in the same AS to indicate the preference of
originating AS. the originating AS. The MED was purposely designed to be a "weak"
metric that would only be used late in the best-path decision
process.
The MED was purposely designed to be a "weak" metric that would only The IDR working wanted to insure that any metric specified by a
be used late in the best-path decision process. The BGP working remote operator would only affect routing in a local AS if no other
group was concerned that any metric specified by a remote operator preference was specified. A paramount goal of the design of the MED
would only affect routing in a local AS if no other preference was was insure that neighboring autonomous systems could not "shed" or
specified. A paramount goal of the design of the MED was insure that "absorb" traffic for destinations that they advertise.
peers could not "shed" or "absorb" traffic for destinations that they
advertise.
The LOCAL-PREFERENCE attribute was added so a local operator could The LOCAL-PREFERENCE attribute was added so a local operator could
easily configure a policy that overrode the standard best path easily configure a policy that overrode the standard best path
determination mechanism without configuring local preference on each determination mechanism without requiring the manual configuration on
router. every router in the AS.
One shortcoming in the BGP4 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. default value of LOCAL-PREFERENCE 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 have aided in the interoperation of different
routers in the same AS (since LOCAL-PREF is a local administration BGP implementations in the same AS (since LOCAL-PREFERENCE is a local
knob, there is no interoperability drawback across AS boundaries). administration knob, there is no interoperability drawback across AS
boundaries).
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 or remote AS may influence the best path selection
example, a dual-connected site may select one AS as a primary transit process. For example, a dual-connected site may select one AS as a
service provider and have one as a backup. primary transit service provider and have one as a backup.
/---- transit B ----end-customer transit A---- In a topology where the multiple transit service providers connect to
---- transit C ----/ additional autonomous systems, there is no formal mechanism for
In a topology where the two transit service providers connect to a indicating a path selection preference should a remote autonomous
third provider, the real decision is performed by the third provider system wish to respect that preference.
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 In BGP implementations where the total length of the sequence
possibility of carrying an optional vector corresponding to the AS- portions of the AS path attribute may be used as part of the path
PATH where each transit AS may indicate a preference value for a selection criteria, one practice in use today is to prepend
given route. Cooperating ASs may then chose traffic based upon additional copies of the originator's autonomous system number to the
comparison of "interesting" portions of this vector according to AS path.
routing policy.
While protecting a given ASs routing policy is of paramount concern, /--- transit A ---\
avoiding extensive hand configuration of routing policies needs to be / \
examined more carefully in future BGP-like protocols. end-customer transit C----
109 \ /
\--- transit B ---/
Using the example above, if the "end customer" advertises routes
originating in its autonomous system as having an AS path of "109" to
transit A, and a path of "109 109" to transit B, transit provider C
may be influenced by the difference in AS sequence lengths and prefer
the path via transit A.
There has been some discussion of the creation of an optional
transitive attribute which would represent a sequence of (AS,
preference) entries to indicate a preference value for a given path.
Cooperating ASs would chose traffic based upon comparison of
"interesting" portions of this sequence according to local routing
policy.
Additional suggestions have been made suggesting a less flexible
"destination provider selection" attribute to indicate desired
preferences.
While protecting a given autonomous system's routing policy is of
paramount concern, avoiding extensive hand configuration of routing
policies needs to be examined more carefully in future protocol
varients.
Internal BGP in large autonomous systems 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
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.
In a large AS, this leads to an n^2 mesh of TCP connections and some This practice leads to an O(n^2) mesh of TCP connections and requires
method of configuring and maintaining those connections. BGP does some method of configuring and maintaining those connections. BGP
not specify how this information is to be propagated, so does not regulate how this information is to be propagated, so
alternatives, such as injecting BGP attribute information into the alternatives, such as injecting BGP attribute information into the
local IGP have been suggested. Also, there is effort underway to local IGP have been suggested. Also, internal BGP "route
develop internal BGP "route reflectors" or a reliable multicast reflectors", and "autonomous system confederation" mechanisms have
transport of IBGP information which would reduce configuration, been implemented and demonstrate a significant improvement in
memory and CPU requirements of conveying information to all other configuration, memory and CPU requirements necessary to convey
internal BGP peers. information to all other BGP peers in an autonomous system.
Internet Dynamics Internet Dynamics
As discussed in [7], the driving force in CPU and bandwidth As discussed in [7], the driving force in CPU and bandwidth
utilization is the dynamic nature of routing in the Internet. As the utilization is the dynamic nature of routing in the Internet. As the
net has grown, the number of changes per second has increased. We net has grown, the number of changes per second has increased. We
automaticly get some level of damping when more specific NLRI is receive some level of damping when more specific reachability
aggregated into larger blocks, however this isn't sufficient. information is aggregated into larger blocks, however this isn't
sufficient.
At least one current implementation of BGP provides route update At least one current implementation of BGP provides route update
dampening that includes routing hysterisis. This allows fast dampening that includes routing hysteresis. This allows fast
convergence for routes that flap relatively infrequently while convergence for routes that flap relatively infrequently while
suppressing instabilities caused by frequently flapping paths. suppressing instabilities caused by frequently flapping paths.
Operational experience in the Internet shows that large-scale Operational experience in the Internet shows that large-scale
deployment of this dampening technique proves to be highly beneficial deployment of this dampening technique has proven to be highly
for the stability of the Internet routing system. beneficial for the stability of the routing system.
Acknowledgments Acknowledgments
The BGP-4 protocol has been developed by the IDR/BGP Working Group of The BGP-4 protocol has been developed by the IDR/BGP Working Group of
the Internet Engineering Task Force. I would like to express thanks the Internet Engineering Task Force. I would like to express thanks
to Yakov Rekhter for providing RFC 1266. I'd also like to explicitly to Yakov Rekhter for providing RFC 1266 from which this document is
thank Yakov Rekhter and Tony Li for their review of this document as based. I'd like to thank Yakov Rekhter, John Hawkinson, and Vince
well as their constructive and valuable comments. Fuller for the review of this document as well as constructive and
valuable comments. This report is based on the initial work of Peter
Lothberg (STUPI), Andrew Partan (UUNET), and several others.
Author's Address: Author's Address:
Paul Traina Paul Traina
cisco Systems, Inc. cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
pst@cisco.com pst@cisco.com
References References
[1] RFC1264 [1] RFC1264
Hinden, R., "Internet Routing Protocol Standardization Criteria", Hinden, R., "Internet Routing Protocol Standardization Criteria",
October 1991. October 1991.
[2] draft-ietf-idr-bgp4-11.txt [2] draft-ietf-idr-bgp4-01.txt
Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", June
October 1995. 1995.
[3] RFC1655 [3] RFC1772
Rekhter, Y., and P. Gross, Editors, "Application of the Border Rekhter, Y., and P. Gross, Editors, "Application of the Border
Gateway Protocol in the Internet", July 1994. Gateway Protocol in the Internet", March 1995.
[4] RFC1657 [4] RFC1657
S. Willis, J. Burruss, J. Chu, "Definitions of Managed Objects for S. Willis, J. Burruss, J. Chu, "Definitions of Managed Objects for
the Fourth Version of the Border Gateway Protocol (BGP-4) using the Fourth Version of the Border Gateway Protocol (BGP-4) using
SMIv2", July 1994. SMIv2", July 1994.
[5] RFC1519 [5] RFC1519
Fuller V.; Li. T; Yu J.; Varadhan, K., "Classless Inter-Domain Fuller V.; Li. T; Yu J.; Varadhan, K., "Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy", Routing (CIDR): an Address Assignment and Aggregation Strategy",
September 1993. September 1993.
[6] RFC1656 Traina P., "BGP-4 Protocol Document Roadmap and [6] RFC1773
Implementation Experience", July 1994. Traina P., "Experience with the BGP-4 protocol." March 1995.
[7] RFC1774 [7] RFC1774
Traina P., "BGP Version 4 Protocol Analysis", March 1995. Traina P., "BGP Version 4 Protocol Analysis", March 1995.
 End of changes. 

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