home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-idr-op-bgp4-experience-00.txt < prev    next >
Text File  |  1995-10-25  |  19KB  |  504 lines
  1.  
  2.  
  3. Inter-Domain Routing Working Group                           Paul Traina
  4. INTERNET DRAFT                                             cisco Systems
  5. <draft-ietf-idr-bgp4-op-experience-01.txt>                  October 1995
  6.  
  7.  
  8.              Operational Experience with the BGP-4 protocol
  9.  
  10.                           Status of this Memo
  11.  
  12.    This memo provides information for the Internet community.  It does
  13.    not specify an Internet standard.  Distribution of this memo is
  14.    unlimited.
  15.  
  16.    This document is an Internet Draft. Internet Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its Areas,
  18.    and its Working Groups. Note that other groups may also distribute
  19.    working documents as Internet Drafts.
  20.  
  21.    Internet Drafts are draft documents valid for a maximum of six
  22.    months. Internet Drafts may be updated, replaced, or obsoleted by
  23.    other documents at any time. It is not appropriate to use Internet
  24.    Drafts as reference material or to cite them other than as a "working
  25.    draft" or "work in progress".
  26.  
  27.  
  28. Introduction
  29.  
  30.    The purpose of this memo is to document how the requirements for
  31.    advancing a routing protocol to Full Standard have been satisfied by
  32.    Border Gateway Protocol version 4 (BGP-4).  This report documents
  33.    experience with BGP.  This is the second of two reports on the BGP
  34.    protocol.  As required by the Internet Activities Board (IAB) and the
  35.    Internet Engineering Steering Group (IESG), the first report will
  36.    present a performance analysis of the BGP protocol.
  37.  
  38.    The remaining sections of this memo document how BGP satisfies
  39.    General Requirements specified in Section 3.0, as well as
  40.    Requirements for Draft Standard specified in Section 6.0 of the
  41.    "Internet Routing Protocol Standardization Criteria" document [1].
  42.  
  43.    This report is based on the initial work of Peter Lothberg (STUPI),
  44.    Andrew Partan (UUNET), and several others.
  45.  
  46.    Please send comments to bgp@ans.net.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Expiration Date March 1995                                      [Page 1]
  55.  
  56. INTERNET DRAFT                                            December, 1994
  57.  
  58.  
  59. Acknowledgments
  60.  
  61.    The BGP protocol has been developed by the IDR (formerly BGP) Working
  62.    Group of the Internet Engineering Task Force.  I would like to
  63.    express deepest thanks to Yakov Rekhter and Sue Hares, co-chairs of
  64.    the IDR working group.  I'd also like to explicitly thank Yakov
  65.    Rekhter and Tony Li for the review of this document as well as
  66.    constructive and valuable comments.
  67.  
  68.  
  69.  
  70. Documentation
  71.  
  72.    BGP is an inter-autonomous system routing protocol designed for
  73.    TCP/IP internets.  Version 1 of the BGP protocol was published in RFC
  74.    1105. Since then BGP Versions 2, 3, and 4 have been developed.
  75.    Version 2 was documented in RFC 1163. Version 3 is documented in RFC
  76.    1267.  The changes between versions 1, 2 and 3 are explained in
  77.    Appendix 2 of [2].  All of the functionality that was present in the
  78.    previous versions is present in version 4.
  79.  
  80.    BGP version 2 removed from the protocol the concept of "up", "down",
  81.    and "horizontal" relations between autonomous systems that were
  82.    present in version 1.  BGP version 2 introduced the concept of path
  83.    attributes.  In addition, BGP version 2 clarified parts of the
  84.    protocol that were "under-specified".
  85.  
  86.    BGP version 3 lifted some of the restrictions on the use of the
  87.    NEXT_HOP path attribute, and added the BGP Identifier field to the
  88.    BGP OPEN message.  It also clarifies the procedure for distributing
  89.    BGP routes between the BGP speakers within an autonomous system.
  90.  
  91.    BGP version 4 redefines the (previously class-based) network layer
  92.    reachability portion of the updates to specify prefixes of arbitrary
  93.    length in order to represent multiple classful networks in a single
  94.    entry as discussed in [5].  BGP version 4 has also modified the AS-
  95.    PATH attribute so that sets of autonomous systems, as well as
  96.    individual ASs may be described.  In addition, BGP version for has
  97.    redescribed the INTER-AS METRIC attribute as the MULTI-EXIT
  98.    DISCRIMINATOR and added new LOCAL-PREFERENCE and AGGREGATOR
  99.    attributes.
  100.  
  101.    Possible applications of BGP in the Internet are documented in [3].
  102.  
  103.    The BGP protocol was developed by the IDR Working Group of the
  104.    Internet Engineering Task Force. This Working Group has a mailing
  105.    list, iwg@ans.net, where discussions of protocol features and
  106.    operation are held. The IDR Working Group meets regularly during the
  107.  
  108.  
  109.  
  110. Expiration Date March 1995                                      [Page 2]
  111.  
  112. INTERNET DRAFT                                            December, 1994
  113.  
  114.  
  115.    quarterly Internet Engineering Task Force conferences. Reports of
  116.    these meetings are published in the IETF's Proceedings.
  117.  
  118.  
  119. MIB
  120.  
  121.    A BGP-4 Management Information Base has been published [4].  The MIB
  122.    was written by Steve Willis (Wellfleet), John Burruss (Wellfleet),
  123.    and John Chu (IBM).
  124.  
  125.    Apart from a few system variables, the BGP MIB is broken into two
  126.    tables: the BGP Peer Table and the BGP Received Path Attribute Table.
  127.    The Peer Table reflects information about BGP peer connections, such
  128.    as their state and current activity. The Received Path Attribute
  129.    Table contains all attributes received from all peers before local
  130.    routing policy has been applied. The actual attributes used in
  131.    determining a route are a subset of the received attribute table.
  132.  
  133.  
  134.  
  135. Security Considerations
  136.  
  137.    BGP provides flexible and extendible mechanism for authentication and
  138.    security.  The mechanism allows to support schemes with various
  139.    degree of complexity.  All BGP sessions are authenticated based on
  140.    the BGP Identifier of a peer.  In addition, all BGP sessions are
  141.    authenticated based on the autonomous system number advertised by a
  142.    peer.  As part of the BGP authentication mechanism, the protocol
  143.    allows to carry encrypted digital signature in every BGP message.
  144.    All authentication failures result in sending the NOTIFICATION
  145.    messages and immediate termination of the BGP connection.
  146.  
  147.    Since BGP runs over TCP and IP, BGP's authentication scheme may be
  148.    augmented by any authentication or security mechanism provided by
  149.    either TCP or IP.
  150.  
  151.    However, since BGP runs over TCP and IP, BGP is vulnerable to the
  152.    same denial of service or authentication attacks that are present in
  153.    any other TCP based protocol.
  154.  
  155.    One method for improving the security of TCP connections for use with
  156.    BGP has been documented in [7].
  157.  
  158.  
  159. Operational experience
  160.  
  161.    This section discusses operational experience with BGP and BGP-4.
  162.  
  163.  
  164.  
  165.  
  166. Expiration Date March 1995                                      [Page 3]
  167.  
  168. INTERNET DRAFT                                            December, 1994
  169.  
  170.  
  171.    BGP has been used in the production environment since 1989, BGP-4
  172.    since 1993.  This use involves at least two of the implementations
  173.    listed above.  Production use of BGP includes utilization of all
  174.    significant features of the protocol.  The present production
  175.    environment, where BGP is used as the inter-autonomous system routing
  176.    protocol, is highly heterogeneous.  In terms of the link bandwidth it
  177.    varies from 28 Kbits/sec to 150 Mbits/sec.  In terms of the actual
  178.    routes that run BGP it ranges from a relatively slow performance
  179.    PC/RT to a very high performance RISC based CPUs, and includes both
  180.    the special purpose routers and the general purpose workstations
  181.    running UNIX.
  182.  
  183.    In terms of the actual topologies it varies from a very sparse
  184.    (spanning tree of ICM) to a quite dense (NSFNET backbone).
  185.  
  186.    At the time of this writing BGP-4 is used as an inter-autonomous
  187.    system routing protocol between ALL significant autonomous systems,
  188.    including, but by all means not limited to: Alternet, ANS, Ebone,
  189.    ICM, IIJ, MCI, NSFNET, and Sprint.  The smallest know backbone
  190.    consists of one router, whereas the largest contains nearly 90 BGP
  191.    speakers.  All together, there are several hundred known BGP speaking
  192.    routers.
  193.  
  194.    BGP is used both for the exchange of routing information between a
  195.    transit and a stub autonomous system, and for the exchange of routing
  196.    information between multiple transit autonomous systems.  There is no
  197.    distinction between sites historically considered backbones vs
  198.    "regional" networks.
  199.  
  200.    Within most transit networks, BGP is used as the exclusive carrier of
  201.    the exterior routing information.  At the time of this writing within
  202.    a few sites use BGP in conjunction with an interior routing protocol
  203.    to carry exterior routing information.
  204.  
  205.    The full set of exterior routes that is carried by BGP is well over
  206.    30,000 aggregate entries representing several times that number of
  207.    connected networks.
  208.  
  209.    Operational experience described above involved multi-vendor
  210.    deployment (cisco, and "gated").
  211.  
  212.    Operational experience with BGP exercised all basic features of the
  213.    protocol, including authentication, routing loop suppression and the
  214.    new features of BGP-4, enhanced metrics and route aggregation.
  215.  
  216.    Bandwidth consumed by BGP has been measured at the interconnection
  217.    points between CA*Net and T1 NSFNET Backbone. The results of these
  218.    measurements were presented by Dennis Ferguson during the Twentifirst
  219.  
  220.  
  221.  
  222. Expiration Date March 1995                                      [Page 4]
  223.  
  224. INTERNET DRAFT                                            December, 1994
  225.  
  226.  
  227.    IETF, and are available from the IETF Proceedings. These results
  228.    showed clear superiority of BGP as compared with EGP in the area of
  229.    bandwidth consumed by the protocol. Observations on the CA*Net by
  230.    Dennis Ferguson, and on the T1 NSFNET Backbone by Susan Hares
  231.    confirmed clear superiority of the BGP protocol family as compared
  232.    with EGP in the area of CPU requirements.
  233.  
  234.  
  235. Migration to BGP version 4
  236.  
  237.    On multiple occasions some members of IETF expressed concern about
  238.    the migration path from classful protocols to classless protocols
  239.    such as BGP-4.
  240.  
  241.    BGP-4 was rushed into production use on the Internet because of the
  242.    exponential growth of routing tables and the increase of memory and
  243.    CPU utilization required by BGP.  As such,  migration issues that
  244.    normally would have stalled deployment were cast aside in favor of
  245.    pragmatic and intelligent deployment of BGP-4 by network operators.
  246.  
  247.    There was much discussion about creating "route exploders" which
  248.    would enumerate individual class-based networks of CIDR allocations
  249.    to BGP-3 speaking routers,  however a cursory examination showed that
  250.    this would vastly hasten the requirement for more CPU and memory
  251.    resources for these older implementations.  There would be no way
  252.    internal to BGP to differentiate between known used destinations and
  253.    the unused portions of the CIDR allocation.
  254.  
  255.    The migration path chosen by the majority of the operators was known
  256.    as "CIDR, default, or die!"
  257.  
  258.    To test BGP-4 operation, a virtual "shadow" Internet was created by
  259.    linking Alternet, Ebone, ICM, and cisco over GRE based tunnels.
  260.    Experimentation was done with actual live routing information by
  261.    establishing BGP version 3 connections with the production networks
  262.    at those sites.  This allowed extensive regression testing before
  263.    deploying BGP-4 on production equipment.
  264.  
  265.    After testing on the shadow network, BGP-4 implementations were
  266.    deployed on the production equipment at those sites.  BGP-4 capable
  267.    routers negotiated BGP-4 connections and interoperated with other
  268.    sites by speaking BGP-3.  Several test aggregate routes were injected
  269.    into this network in addition to classfull destinations for
  270.    compatibility with BGP-3 speakers.
  271.  
  272.    At this point, the shadow-Internet was re-chartered as an
  273.    "operational experience" network.  tunnel connections were
  274.    established with most major transit service operators so that
  275.  
  276.  
  277.  
  278. Expiration Date March 1995                                      [Page 5]
  279.  
  280. INTERNET DRAFT                                            December, 1994
  281.  
  282.  
  283.    operators could gain some understanding of how the introduction of
  284.    aggregate destinations would affect routing.
  285.  
  286.    After being satisfied with the initial deployment of BGP-4,  a number
  287.    of sites chose to withdraw their class-based advertisements and rely
  288.    only on their CIDR aggregate advertisements.  This provided
  289.    motivation for transit providers who had not migrated to either do
  290.    so, accept a default route, or lose connectivity to several popular
  291.    destinations.
  292.  
  293.  
  294. Metrics
  295.  
  296.    BGP version 4 re-defined the old INTER-AS metric as a MULTI-EXIT-
  297.    DISCRIMINATOR.  This value may be used in the tie breaking process
  298.    when selecting a preferred path to a given address space.  The MED is
  299.    meant to only be used when comparing paths received from different
  300.    external peers in the same AS to indicate the preference of the
  301.    originating AS.
  302.  
  303.    The MED was purposely designed to be a "weak" metric that would only
  304.    be used late in the best-path decision process.  The BGP working
  305.    group was concerned that any metric specified by a remote operator
  306.    would only affect routing in a local AS if no other preference was
  307.    specified.  A paramount goal of the design of the MED was insure that
  308.    peers could not "shed" or "absorb" traffic for destinations that they
  309.    advertise.
  310.  
  311.    The LOCAL-PREFERENCE attribute was added so a local operator could
  312.    easily configure a policy that overrode the standard best path
  313.    determination mechanism without configuring local preference on each
  314.    router.
  315.  
  316.    One shortcoming in the BGP4 specification was a suggestion for a
  317.    default value of LOCAL-PREF to be assumed if none was provided.
  318.    Defaults of 0 or the maximum value each have range limitations, so a
  319.    common default would aid in the interoperation of multi-vendor
  320.    routers in the same AS (since LOCAL-PREF is a local administration
  321.    knob, there is no interoperability drawback across AS boundaries).
  322.  
  323.    Another area where more exploration is required is a method whereby
  324.    an originating AS may influence the best path selection process.  For
  325.    example, a dual-connected site may select one AS as a primary transit
  326.    service provider and have one as a backup.
  327.  
  328.                /---- transit B ----end-customer                     transit A----
  329.                ---- transit C ----/
  330.  
  331.  
  332.  
  333.  
  334. Expiration Date March 1995                                      [Page 6]
  335.  
  336. INTERNET DRAFT                                            December, 1994
  337.  
  338.  
  339.    In a topology where the two transit service providers connect to a
  340.    third provider,  the real decision is performed by the third provider
  341.    and there is no mechanism for indicating a preference should the
  342.    third provider wish to respect that preference.
  343.  
  344.    A general purpose suggestion that has been brought up is the
  345.    possibility of carrying an optional vector corresponding to the AS-
  346.    PATH where each transit AS may indicate a preference value for a
  347.    given route.  Cooperating ASs may then chose traffic based upon
  348.    comparison of "interesting" portions of this vector according to
  349.    routing policy.
  350.  
  351.    While protecting a given ASs routing policy is of paramount concern,
  352.    avoiding extensive hand configuration of routing policies needs to be
  353.    examined more carefully in future BGP-like protocols.
  354.  
  355.  
  356. Internal BGP in large autonomous systems
  357.  
  358.    While not strictly a protocol issue, one other concern has been
  359.    raised by network operators who need to maintain autonomous systems
  360.    with a large number of peers.  Each speaker peering with an external
  361.    router is responsible for propagating reachability and path
  362.    information to all other transit and border routers within that AS.
  363.    This is typically done by establishing internal BGP connections to
  364.    all transit and border routers in the local AS.
  365.  
  366.    In a large AS, this leads to an n^2 mesh of TCP connections and some
  367.    method of configuring and maintaining those connections.  BGP does
  368.    not specify how this information is to be propagated,  so
  369.    alternatives, such as injecting BGP attribute information into the
  370.    local IGP have been suggested.  Also, there is effort underway to
  371.    develop internal BGP "route reflectors" or a reliable multicast
  372.    transport of IBGP information which would reduce configuration,
  373.    memory and CPU requirements of conveying information to all other
  374.    internal BGP peers.
  375.  
  376.  
  377. Internet Dynamics
  378.  
  379.    As discussed in [7], the driving force in CPU and bandwidth
  380.    utilization is the dynamic nature of routing in the Internet.  As the
  381.    net has grown, the number of changes per second has increased.  We
  382.    automaticly get some level of damping when more specific NLRI is
  383.    aggregated into larger blocks, however this isn't sufficient.
  384.  
  385.    At least one current implementation of BGP provides route update
  386.    dampening that includes routing hysterisis.  This allows fast
  387.  
  388.  
  389.  
  390. Expiration Date March 1995                                      [Page 7]
  391.  
  392. INTERNET DRAFT                                            December, 1994
  393.  
  394.  
  395.    convergence for routes that flap relatively infrequently while
  396.    suppressing instabilities caused by frequently flapping paths.
  397.    Operational experience in the Internet shows that large-scale
  398.    deployment of this dampening technique proves to be highly beneficial
  399.    for the stability of the Internet routing system.
  400.  
  401.  
  402. Acknowledgments
  403.  
  404.    The BGP-4 protocol has been developed by the IDR/BGP Working Group of
  405.    the Internet Engineering Task Force.  I would like to express thanks
  406.    to Yakov Rekhter for providing RFC 1266.  I'd also like to explicitly
  407.    thank Yakov Rekhter and Tony Li for their review of this document as
  408.    well as their constructive and valuable comments.
  409.  
  410.  
  411. Author's  Address:
  412.  
  413.    Paul Traina
  414.    cisco Systems, Inc.
  415.    170 W. Tasman Dr.
  416.    San Jose, CA 95134
  417.    pst@cisco.com
  418.  
  419.  
  420. References
  421.  
  422. [1] RFC1264
  423.    Hinden, R., "Internet Routing Protocol Standardization Criteria",
  424.    October 1991.
  425.  
  426. [2] draft-ietf-idr-bgp4-11.txt
  427.    Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
  428.    October 1995.
  429.  
  430. [3] RFC1655
  431.    Rekhter, Y., and P. Gross, Editors, "Application of the Border
  432.    Gateway Protocol in the Internet", July 1994.
  433.  
  434. [4] RFC1657
  435.    S. Willis, J. Burruss, J. Chu, "Definitions of Managed Objects for
  436.    the Fourth Version of the Border Gateway Protocol (BGP-4) using
  437.    SMIv2", July 1994.
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446. Expiration Date March 1995                                      [Page 8]
  447.  
  448. INTERNET DRAFT                                            December, 1994
  449.  
  450.  
  451. [5] RFC1519
  452.    Fuller V.; Li. T; Yu J.; Varadhan, K., "Classless Inter-Domain
  453.    Routing (CIDR): an Address Assignment and Aggregation Strategy",
  454.    September 1993.
  455.  
  456. [6] RFC1656 Traina P., "BGP-4 Protocol Document Roadmap and
  457. Implementation Experience", July 1994.
  458.  
  459. [7] RFC1774
  460.    Traina P., "BGP Version 4 Protocol Analysis", March 1995.
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502. Expiration Date March 1995                                      [Page 9]
  503.  
  504.