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