As per Relevance of the word document, we have this rfc below:
Network Working Group P.
Request for Comments: 1773 cisco
Obsoletes: 1656 March 1995
Category:
Experience with the BGP-4
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The purpose of this memo is to document how the requirements
advancing a routing protocol to Draft Standard have been satisfied
Border Gateway Protocol version 4 (BGP-4). This report
experience with BGP. This is the second of two reports on the
protocol. As required by the Internet Architecure Board (IAB)
the Internet Engineering Steering Group (IESG), the first report
present a performance analysis of the BGP protocol
The remaining sections of this memo document how BGP
General Requirements specified in Section 3.0, as well
Requirements for Draft Standard specified in Section 5.0 of
"Internet Routing Protocol Standardization Criteria" document [1].
This report is based on the initial work of Peter Lothberg (Ebone),
Andrew Partan (Alternet), and several others. Details of their
were presented at the Twenty-fifth IETF meeting and are
from the IETF proceedings
Please send comments to iwg@ans.net
The BGP protocol has been developed by the IDR (formerly BGP)
Group of the Internet Engineering Task Force. I would like
express deepest thanks to Yakov Rekhter and Sue Hares, co-chairs
the IDR working group. I'd also like to explicitly thank
Rekhter and Tony Li for the review of this document as well
constructive and valuable comments
Traina [Page 1]
RFC 1773 Experience with the BGP-4 Protocol March 1995
BGP is an inter-autonomous system routing protocol designed
TCP/IP internets. Version 1 of the BGP protocol was published in
1105. Since then BGP Versions 2, 3, and 4 have been developed
Version 2 was documented in RFC 1163. Version 3 is documented in
1267. The changes between versions 1, 2 and 3 are explained
Appendix 2 of [2]. All of the functionality that was present in
previous versions is present in version 4.
BGP version 2 removed from the protocol the concept of "up", "down",
and "horizontal" relations between autonomous systems that
present in version 1. BGP version 2 introduced the concept of
attributes. In addition, BGP version 2 clarified parts of
protocol that were "under-specified".
BGP version 3 lifted some of the restrictions on the use of
NEXT_HOP path attribute, and added the BGP Identifier field to
BGP OPEN message. It also clarifies the procedure for
BGP routes between the BGP speakers within an autonomous system
BGP version 4 redefines the (previously class-based) network
reachability portion of the updates to specify prefixes of
length in order to represent multiple classful networks in a
entry as discussed in [5]. BGP version 4 has also modified the AS
PATH attribute so that sets of autonomous systems, as well
individual ASs may be described. In addition, BGP version for
redescribed the INTER-AS METRIC attribute as the MULTI-
DISCRIMINATOR and added new LOCAL-PREFERENCE and
attributes
Possible applications of BGP in the Internet are documented in [3].
The BGP protocol was developed by the IDR Working Group of
Internet Engineering Task Force. This Working Group has a
list, iwg@ans.net, where discussions of protocol features
operation are held. The IDR Working Group meets regularly during
quarterly Internet Engineering Task Force conferences. Reports
these meetings are published in the IETF's Proceedings
A BGP-4 Management Information Base has been published [4]. The
was written by Steve Willis (Wellfleet), John Burruss (Wellfleet),
and John Chu (IBM).
Apart from a few system variables, the BGP MIB is broken into
tables: the BGP Peer Table and the BGP Received Path Attribute Table
Traina [Page 2]
RFC 1773 Experience with the BGP-4 Protocol March 1995
The Peer Table reflects information about BGP peer connections,
as their state and current activity. The Received Path
Table contains all attributes received from all peers before
routing policy has been applied. The actual attributes used
determining a route are a subset of the received attribute table
Security
BGP provides flexible and extendible mechanism for authentication
security. The mechanism allows to support schemes with
degree of complexity. All BGP sessions are authenticated based
the BGP Identifier of a peer. In addition, all BGP sessions
authenticated based on the autonomous system number advertised by
peer. As part of the BGP authentication mechanism, the
allows to carry encrypted digital signature in every BGP message
All authentication failures result in sending the
messages and immediate termination of the BGP connection
Since BGP runs over TCP and IP, BGP's authentication scheme may
augmented by any authentication or security mechanism provided
either TCP or IP
However, since BGP runs over TCP and IP, BGP is vulnerable to
same denial of service or authentication attacks that are present
any other TCP based protocol
There are multiple independent interoperable implementations of
currently available. This section gives a brief overview of
implementations that are currently used in the operational Internet
They are
- cisco
- gated
- 3
- Bay Networks (Wellfleet
-
To facilitate efficient BGP implementations, and avoid commonly
mistakes, the implementation experience with BGP-4 in with cisco'
implementation was documented as part of RFC 1656 [4].
Implementors are strongly encouraged to follow the
suggestions outlined in that document and in the appendix of [2].
Traina [Page 3]
RFC 1773 Experience with the BGP-4 Protocol March 1995
Experience with implementing BGP-4 showed that the protocol
relatively simple to implement. On the average BGP-4
takes about 2 man/months effort, not including any restructuring
may be needed to support CIDR
Note that, as required by the IAB/IESG for Draft Standard status
there are multiple interoperable completely
implementations
Operational
This section discusses operational experience with BGP and BGP-4.
BGP has been used in the production environment since 1989, BGP-4
since 1993. This use involves at least two of the
listed above. Production use of BGP includes utilization of
significant features of the protocol. The present
environment, where BGP is used as the inter-autonomous system
protocol, is highly heterogeneous. In terms of the link bandwidth
varies from 28 Kbits/sec to 150 Mbits/sec. In terms of the
routes that run BGP it ranges from a relatively slow
PC/RT to a very high performance RISC based CPUs, and includes
the special purpose routers and the general purpose
running UNIX
In terms of the actual topologies it varies from a very
(spanning tree of ICM) to a quite dense (NSFNET backbone).
At the time of this writing BGP-4 is used as an inter-
system routing protocol between ALL significant autonomous systems
including, but by all means not limited to: Alternet, ANS, Ebone
ICM, IIJ, MCI, NSFNET, and Sprint. The smallest know
consists of one router, whereas the largest contains nearly 90
speakers. All together, there are several hundred known BGP
routers
BGP is used both for the exchange of routing information between
transit and a stub autonomous system, and for the exchange of
information between multiple transit autonomous systems. There is
distinction between sites historically considered backbones
"regional" networks
Within most transit networks, BGP is used as the exclusive carrier
the exterior routing information. At the time of this writing
a few sites use BGP in conjunction with an interior routing
to carry exterior routing information
Traina [Page 4]
RFC 1773 Experience with the BGP-4 Protocol March 1995
The full set of exterior routes that is carried by BGP is well
20,000 aggregate entries representing several times that number
connected networks
Operational experience described above involved multi-
deployment (cisco, and "gated").
Specific details of the operational experience with BGP in Alternet
ICM and Ebone were presented at the Twenty-fifth IETF
(Toronto, Canada) by Peter Lothberg (Ebone), Andrew Partan (Alternet
and Paul Traina (cisco).
Operational experience with BGP exercised all basic features of
protocol, including authentication, routing loop suppression and
new features of BGP-4, enhanced metrics and route aggregation
Bandwidth consumed by BGP has been measured at the
points between CA*Net and T1 NSFNET Backbone. The results of
measurements were presented by Dennis Ferguson during the Twenty
first IETF, and are available from the IETF Proceedings.
results showed clear superiority of BGP as compared with EGP in
area of bandwidth consumed by the protocol. Observations on
CA*Net by Dennis Ferguson, and on the T1 NSFNET Backbone by
Hares confirmed clear superiority of the BGP protocol family
compared with EGP in the area of CPU requirements
Migration to BGP version 4
On multiple occasions some members of IETF expressed concern
the migration path from classful protocols to classless
such as BGP-4.
BGP-4 was rushed into production use on the Internet because of
exponential growth of routing tables and the increase of memory
CPU utilization required by BGP. As such, migration issues
normally would have stalled deployment were cast aside in favor
pragmatic and intelligent deployment of BGP-4 by network operators
There was much discussion about creating "route exploders"
would enumerate individual class-based networks of CIDR
to BGP-3 speaking routers, however a cursory examination showed
this would vastly hasten the requirement for more CPU and
resources for these older implementations. There would be no
internal to BGP to differentiate between known used networks and
unused portions of the CIDR allocation
The migration path chosen by the majority of the operators was
as "CIDR, default, or die!"
Traina [Page 5]
RFC 1773 Experience with the BGP-4 Protocol March 1995
To test BGP-4 operation, a virtual "shadow" Internet was created
linking Alternet, Ebone, ICM, and cisco over GRE based tunnels
Experimentation was done with actual live routing information
establishing BGP version 3 connections with the production
at those sites. This allowed extensive regression testing
deploying BGP-4 on production equipment
After testing on the shadow network, BGP-4 implementations
deployed on the production equipment at those sites. BGP-4
routers negotiated BGP-4 connections and interoperated with
sites by speaking BGP-3. Several test aggregate routes were
into this network in addition to class-based networks
compatibility with BGP-3 speakers
At this point, the shadow-Internet was re-chartered as
"operational experience" network. tunnel connections
established with most major transit service operators so
operators could gain some understanding of how the introduction
aggregate networks would affect routing
After being satisfied with the initial deployment of BGP-4, a
of sites chose to withdraw their class-based advertisements and
only on their CIDR aggregate advertisements. This
motivation for transit providers who had not migrated to either
so, accept a default route, or lose connectivity to several
destinations
BGP version 4 re-defined the old INTER-AS metric as a MULTI-EXIT
DISCRIMINATOR. This value may be used in the tie breaking
when selecting a preferred path to a given address space. The MED
meant to only be used when comparing paths received from
external peers in the same AS to indicate the preference of
originating AS
The MED was purposely designed to be a "weak" metric that would
be used late in the best-path decision process. The BGP
group was concerned that any metric specified by a remote
would only affect routing in a local AS if no other preference
specified. A paramount goal of the design of the MED was insure
peers could not "shed" or "absorb" traffic for networks that
advertise
The LOCAL-PREFERENCE attribute was added so a local operator
easily configure a policy that overrode the standard best
determination mechanism without configuring local preference on
router
Traina [Page 6]
RFC 1773 Experience with the BGP-4 Protocol March 1995
One shortcoming in the BGP4 specification was a suggestion for
default value of LOCAL-PREF to be assumed if none was provided
Defaults of 0 or the maximum value each have range limitations, so
common default would aid in the interoperation of multi-
routers in the same AS (since LOCAL-PREF is a local
knob, there is no interoperability drawback across AS boundaries).
Another area where more exploration is required is a method
an originating AS may influence the best path selection process.
example, a dual-connected site may select one AS as a primary
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
third provider, the real decision is performed by the third
and there is no mechanism for indicating a preference should
third provider wish to respect that preference
A general purpose suggestion that has been brought up is
possibility of carrying an optional vector corresponding to the AS
PATH where each transit AS may indicate a preference value for
given route. Cooperating ASs may then chose traffic based
comparison of "interesting" portions of this vector according
routing policy
While protecting a given ASs routing policy is of paramount concern
avoiding extensive hand configuration of routing policies needs to
examined more carefully in future BGP-like protocols
Internal BGP in large autonomous
While not strictly a protocol issue, one other concern has
raised by network operators who need to maintain autonomous
with a large number of peers. Each speaker peering with an
router is responsible for propagating reachability and
information to all other transit and border routers within that AS
This is typically done by establishing internal BGP connections
all transit and border routers in the local AS
In a large AS, this leads to an n^2 mesh of TCP connections and
method of configuring and maintaining those connections. BGP
not specify how this information is to be propagated,
alternatives, such as injecting BGP attribute information into
local IGP have been suggested. Also, there is effort underway
develop internal BGP "route reflectors" or a reliable
Traina [Page 7]
RFC 1773 Experience with the BGP-4 Protocol March 1995
transport of IBGP information which would reduce configuration
memory and CPU requirements of conveying information to all
internal BGP peers
Internet
As discussed in [7], the driving force in CPU and
utilization is the dynamic nature of routing in the Internet. As
net has grown, the number of changes per second has increased.
automatically get some level of damping when more specific NLRI
aggregated into larger blocks, however this isn't sufficient.
Appendix 6 of [2] are descriptions of dampening techniques
should be applied to advertisements. In future specifications
BGP-like protocols, damping methods should be considered
mandatory inclusion in compliant implementations
The BGP-4 protocol has been developed by the IDR/BGP Working Group
the Internet Engineering Task Force. I would like to express
to Yakov Rekhter for providing RFC 1266. I'd also like to
thank Yakov Rekhter and Tony Li for their review of this document
well as their constructive and valuable comments
Author's
Paul
cisco Systems, Inc
170 W. Tasman Dr
San Jose, CA 95134
EMail: pst@cisco.
[1] Hinden, R., "Internet Routing Protocol Standardization Criteria",
RFC 1264, BBN, October 1991.
[2] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems
March 1995.
[3] Rekhter, Y., and P. Gross, Editors, "Application of the
Gateway Protocol in the Internet", RFC 1772, T.J. Watson
Center, IBM Corp., MCI, March 1995.
Traina [Page 8]
RFC 1773 Experience with the BGP-4 Protocol March 1995
[4] Willis, S., Burruss, J., and J. Chu, "Definitions of
Objects for the Fourth Version of the Border Gateway
(BGP-4) using SMIv2", RFC 1657, Wellfleet Communications Inc.,
IBM Corp., July 1994.
[5] Fuller V., Li. T., Yu J., and K. Varadhan, "Classless Inter
Domain Routing (CIDR): an Address Assignment and
Strategy", RFC 1519, BARRNet, cisco, MERIT, OARnet,
1993.
[6] Traina P., "BGP-4 Protocol Document Roadmap and
Experience", RFC 1656, cisco Systems, July 1994.
[7] Traina P., "BGP Version 4 Protocol Analysis", RFC 1774,
Systems, March 1995.
Traina [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
