doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc1773.txt b/doc/rfc/rfc1773.txt
new file mode 100644
index 0000000..4e22b11
--- /dev/null
+++ b/doc/rfc/rfc1773.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                          P. Traina
+Request for Comments: 1773                                 cisco Systems
+Obsoletes: 1656                                               March 1995
+Category: Informational
+
+
+                   Experience with the BGP-4 protocol
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Introduction
+
+   The purpose of this memo is to document how the requirements for
+   advancing a routing protocol to Draft Standard have been satisfied by
+   Border Gateway Protocol version 4 (BGP-4).  This report documents
+   experience with BGP.  This is the second of two reports on the BGP
+   protocol.  As required by the Internet Architecure Board (IAB) and
+   the 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
+   General Requirements specified in Section 3.0, as well as
+   Requirements for Draft Standard specified in Section 5.0 of the
+   "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 work
+   were presented at the Twenty-fifth IETF meeting and are available
+   from the IETF proceedings.
+
+   Please send comments to iwg@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.
+
+
+
+
+
+
+
+Traina                                                          [Page 1]
+
+RFC 1773           Experience with the BGP-4 Protocol         March 1995
+
+
+Documentation
+
+   BGP is an inter-autonomous system routing protocol designed for
+   TCP/IP internets.  Version 1 of the BGP protocol was published in RFC
+   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
+   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
+   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 were
+   present in version 1.  BGP version 2 introduced the concept of path
+   attributes.  In addition, BGP version 2 clarified parts of the
+   protocol that were "under-specified".
+
+   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
+   BGP OPEN message.  It also clarifies the procedure for distributing
+   BGP routes between the BGP speakers within an autonomous system.
+
+   BGP version 4 redefines the (previously class-based) network layer
+   reachability portion of the updates to specify prefixes of arbitrary
+   length in order to represent multiple classful networks in a single
+   entry as discussed in [5].  BGP version 4 has also modified the AS-
+   PATH attribute so that sets of autonomous systems, as well as
+   individual ASs may be described.  In addition, BGP version for has
+   redescribed the INTER-AS METRIC attribute as the MULTI-EXIT
+   DISCRIMINATOR and added new LOCAL-PREFERENCE and AGGREGATOR
+   attributes.
+
+   Possible applications of BGP in the Internet are documented in [3].
+
+   The BGP protocol was developed by the IDR Working Group of the
+   Internet Engineering Task Force. This Working Group has a mailing
+   list, iwg@ans.net, where discussions of protocol features and
+   operation are held. The IDR Working Group meets regularly during the
+   quarterly Internet Engineering Task Force conferences. Reports of
+   these meetings are published in the IETF's Proceedings.
+
+MIB
+
+   A BGP-4 Management Information Base has been published [4].  The MIB
+   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 two
+   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, 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.
+
+Security Considerations
+
+   BGP provides flexible and extendible mechanism for authentication and
+   security.  The mechanism allows to support schemes with various
+   degree of complexity.  All BGP sessions are authenticated based on
+   the BGP Identifier of a peer.  In addition, all BGP sessions are
+   authenticated based on the autonomous system number advertised by a
+   peer.  As part of the BGP authentication mechanism, the protocol
+   allows to carry encrypted digital signature in every BGP message.
+   All authentication failures result in sending the NOTIFICATION
+   messages and immediate termination of the BGP connection.
+
+   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.
+
+   However, 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.
+
+Implementations
+
+   There are multiple independent interoperable implementations of BGP
+   currently available.  This section gives a brief overview of the
+   implementations that are currently used in the operational Internet.
+   They are:
+
+         - cisco Systems
+         - gated consortium
+         - 3COM
+         - Bay Networks (Wellfleet)
+         - Proteon
+
+   To facilitate efficient BGP implementations, and avoid commonly made
+   mistakes, the implementation experience with BGP-4 in with cisco's
+   implementation was documented as part of RFC 1656 [4].
+
+   Implementors are strongly encouraged to follow the implementation
+   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 is
+   relatively simple to implement. On the average BGP-4 implementation
+   takes about 2 man/months effort, not including any restructuring that
+   may be needed to support CIDR.
+
+   Note that, as required by the IAB/IESG for Draft Standard status,
+   there are multiple interoperable completely independent
+   implementations.
+
+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.  This use involves at least two of the implementations
+   listed above.  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 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
+   (spanning tree of ICM) to a quite dense (NSFNET backbone).
+
+   At the time of this writing BGP-4 is used as an inter-autonomous
+   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 backbone
+   consists of one router, whereas the largest contains nearly 90 BGP
+   speakers.  All together, there are several hundred known BGP speaking
+   routers.
+
+   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
+   distinction between sites historically considered backbones vs
+   "regional" networks.
+
+   Within most transit networks, BGP is used as the exclusive carrier of
+   the exterior routing information.  At the time of this writing within
+   a few sites use BGP in conjunction with an interior routing protocol
+   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 over
+   20,000 aggregate entries representing several times that number of
+   connected networks.
+
+   Operational experience described above involved multi-vendor
+   deployment (cisco, and "gated").
+
+   Specific details of the operational experience with BGP in Alternet,
+   ICM and Ebone were presented at the Twenty-fifth IETF meeting
+   (Toronto, Canada) by Peter Lothberg (Ebone), Andrew Partan (Alternet)
+   and Paul Traina (cisco).
+
+   Operational experience with BGP exercised all basic features of the
+   protocol, including authentication, routing loop suppression and the
+   new features of BGP-4, enhanced metrics and route aggregation.
+
+   Bandwidth consumed by BGP has been measured at the interconnection
+   points between CA*Net and T1 NSFNET Backbone. The results of these
+   measurements were presented by Dennis Ferguson during the Twenty-
+   first IETF, and are available from the IETF Proceedings. These
+   results showed clear superiority of BGP as compared with EGP in the
+   area of bandwidth consumed by the protocol. Observations on the
+   CA*Net by Dennis Ferguson, and on the T1 NSFNET Backbone by Susan
+   Hares confirmed clear superiority of the BGP protocol family as
+   compared with EGP in the area of CPU requirements.
+
+Migration to BGP version 4
+
+   On multiple occasions some members of IETF expressed concern about
+   the migration path from classful protocols to classless protocols
+   such as BGP-4.
+
+   BGP-4 was rushed into production use on the Internet because of the
+   exponential growth of routing tables and the increase of memory and
+   CPU utilization required by BGP.  As such,  migration issues that
+   normally would have stalled deployment were cast aside in favor of
+   pragmatic and intelligent deployment of BGP-4 by network operators.
+
+   There was much discussion about creating "route exploders" which
+   would enumerate individual class-based networks of CIDR allocations
+   to BGP-3 speaking routers,  however a cursory examination showed that
+   this would vastly hasten the requirement for more CPU and memory
+   resources for these older implementations.  There would be no way
+   internal to BGP to differentiate between known used networks and the
+   unused portions of the CIDR allocation.
+
+   The migration path chosen by the majority of the operators was known
+   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 by
+   linking Alternet, Ebone, ICM, and cisco over GRE based tunnels.
+   Experimentation was done with actual live routing information by
+   establishing BGP version 3 connections with the production networks
+   at those sites.  This allowed extensive regression testing before
+   deploying BGP-4 on production equipment.
+
+   After testing on the shadow network, BGP-4 implementations were
+   deployed on the production equipment at those sites.  BGP-4 capable
+   routers negotiated BGP-4 connections and interoperated with other
+   sites by speaking BGP-3.  Several test aggregate routes were injected
+   into this network in addition to class-based networks for
+   compatibility with BGP-3 speakers.
+
+   At this point, the shadow-Internet was re-chartered as an
+   "operational experience" network.  tunnel connections were
+   established with most major transit service operators so that
+   operators could gain some understanding of how the introduction of
+   aggregate networks would affect routing.
+
+   After being satisfied with the initial deployment of BGP-4, a number
+   of sites chose to withdraw their class-based advertisements and rely
+   only on their CIDR aggregate advertisements.  This provided
+   motivation for transit providers who had not migrated to either do
+   so, accept a default route, or lose connectivity to several popular
+   destinations.
+
+Metrics
+
+   BGP version 4 re-defined the old INTER-AS metric as a MULTI-EXIT-
+   DISCRIMINATOR.  This value may be used in the tie breaking process
+   when selecting a preferred path to a given address space.  The MED is
+   meant to only be used when comparing paths received from different
+   external peers in the same AS to indicate the preference of 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 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 insure that
+   peers could not "shed" or "absorb" traffic for networks that they
+   advertise.
+
+   The LOCAL-PREFERENCE attribute was added so a local operator could
+   easily configure a policy that overrode the standard best path
+   determination mechanism without configuring local preference on each
+   router.
+
+
+
+Traina                                                          [Page 6]
+
+RFC 1773           Experience with the BGP-4 Protocol         March 1995
+
+
+   One shortcoming in the BGP4 specification was a suggestion for a
+   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).
+
+   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.
+
+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
+   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
+   method of configuring and maintaining those connections.  BGP does
+   not specify how this information is to be propagated,  so
+   alternatives, such as injecting BGP attribute information into the
+   local IGP have been suggested.  Also, there is effort underway to
+   develop internal BGP "route reflectors" or a reliable multicast
+
+
+
+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 other
+   internal BGP peers.
+
+Internet Dynamics
+
+   As discussed in [7], 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 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 6 of [2] are descriptions of dampening 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.
+
+Acknowledgments
+
+   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
+   to Yakov Rekhter for providing RFC 1266.  I'd also like to explicitly
+   thank Yakov Rekhter and Tony Li for their review of this document as
+   well as their constructive and valuable comments.
+
+Author's Address
+
+   Paul Traina
+   cisco Systems, Inc.
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+
+   EMail: pst@cisco.com
+
+References
+
+   [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 Border
+       Gateway Protocol in the Internet", RFC 1772, T.J. Watson Research
+       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 Managed
+       Objects for the Fourth Version of the Border Gateway Protocol
+       (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 Aggregation
+       Strategy", RFC 1519, BARRNet, cisco, MERIT, OARnet, September
+       1993.
+
+   [6] Traina P., "BGP-4 Protocol Document Roadmap and Implementation
+       Experience", RFC 1656, cisco Systems, July 1994.
+
+   [7] Traina P., "BGP Version 4 Protocol Analysis", RFC 1774, cisco
+       Systems, March 1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Traina                                                          [Page 9]
+