rfc1773.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 508 行 · 第 1/2 页

   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: [e-mail]

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]