home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1655 < prev    next >
Text File  |  1994-07-20  |  44KB  |  1,068 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         Y. Rekhter
  8. Request for Comments: 1655        T.J. Watson Research Center, IBM Corp.
  9. Obsoletes: 1268                                                 P. Gross
  10. Category: Standards Track                                            MCI
  11.                                                                  Editors
  12.                                                                July 1994
  13.  
  14.  
  15.        Application of the Border Gateway Protocol in the Internet
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25. Abstract
  26.  
  27.    This document, together with its companion document, "A Border
  28.    Gateway Protocol 4 (BGP-4)", define an inter-autonomous system
  29.    routing protocol for the Internet.  "A Border Gateway Protocol 4
  30.    (BGP-4)" defines the BGP protocol specification, and this document
  31.    describes the usage of the BGP in the Internet.
  32.  
  33.    Information about the progress of BGP can be monitored and/or
  34.    reported on the BGP mailing list (bgp@ans.net).
  35.  
  36. Acknowledgements
  37.  
  38.    This document was originally published as RFC 1164 in June 1990,
  39.    jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz
  40.    (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu
  41.    (MERIT).
  42.  
  43.    The following also made key contributions to RFC 1164 -- Guy Almes
  44.    (ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans-
  45.    Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT).
  46.  
  47.    We like to explicitly thank Bob Braden (ISI) for the review of the
  48.    previous version of this document.
  49.  
  50.    This updated version of the document is the product of the IETF BGP
  51.    Working Group with Phill Gross (MCI) and Yakov Rekhter (IBM) as
  52.    editors.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Rekhter & Gross                                                 [Page 1]
  59.  
  60. RFC 1655                   BGP-4 Application                   July 1994
  61.  
  62.  
  63.    John Moy (Proteon) contributed Section 7 "Required set of supported
  64.    routing policies".
  65.  
  66.    Scott Brim (Cornell University) contributed the basis for Section 8
  67.    "Interaction with other exterior routing protocols".
  68.  
  69.    Most of the text in Section 9 was contributed by Gerry Meyer
  70.    (Spider).
  71.  
  72.    Parts of the Introduction were taken almost verbatim from [3].
  73.  
  74.    We would like to acknowledge Dan Long (NEARNET) and Tony Li (cisco
  75.    Systems) for their review and comments on the current version of the
  76.    document.
  77.  
  78. 1. Introduction
  79.  
  80.    This memo describes the use of the Border Gateway Protocol (BGP) [1]
  81.    in the Internet environment. BGP is an inter-Autonomous System
  82.    routing protocol. The network reachability information exchanged via
  83.    BGP provides sufficient information to detect routing loops and
  84.    enforce routing decisions based on performance preference and policy
  85.    constraints as outlined in RFC 1104 [2]. In particular, BGP exchanges
  86.    routing information containing full AS paths and enforces routing
  87.    policies based on configuration information.
  88.  
  89.    As the Internet has evolved and grown over in recent years, it has
  90.    become painfully evident that it is soon to face several serious
  91.    scaling problems. These include:
  92.  
  93.        - Exhaustion of the class-B network address space. One
  94.          fundamental cause of this problem is the lack of a network
  95.          class of a size which is appropriate for mid-sized
  96.          organization; class-C, with a maximum of 254 host addresses, is
  97.          too small while class-B, which allows up to 65534 addresses, is
  98.          too large to be densely populated.
  99.  
  100.        - Growth of routing tables in Internet routers are beyond the
  101.          ability of current software (and people) to effectively manage.
  102.  
  103.        - Eventual exhaustion of the 32-bit IP address space.
  104.  
  105.    It has become clear that the first two of these problems are likely
  106.    to become critical within the next one to three years.  Classless
  107.    inter-domain routing (CIDR) attempts to deal with these problems by
  108.    proposing a mechanism to slow the growth of the routing table and the
  109.    need for allocating new IP network numbers. It does not attempt to
  110.    solve the third problem, which is of a more long-term nature, but
  111.  
  112.  
  113.  
  114. Rekhter & Gross                                                 [Page 2]
  115.  
  116. RFC 1655                   BGP-4 Application                   July 1994
  117.  
  118.  
  119.    instead endeavors to ease enough of the short to mid-term
  120.    difficulties to allow the Internet to continue to function
  121.    efficiently while progress is made on a longer- term solution.
  122.  
  123.    BGP-4 is an extension of BGP-3 that provides support for routing
  124.    information aggregation and reduction based on the Classless inter-
  125.    domain routing architecture (CIDR) [3].  This memo describes the
  126.    usage of BGP-4 in the Internet.
  127.  
  128.    All of the discussions in this paper are based on the assumption that
  129.    the Internet is a collection of arbitrarily connected Autonomous
  130.    Systems. That is, the Internet will be modeled as a general graph
  131.    whose nodes are AS's and whose edges are connections between pairs of
  132.    AS's.
  133.  
  134.    The classic definition of an Autonomous System is a set of routers
  135.    under a single technical administration, using an interior gateway
  136.    protocol and common metrics to route packets within the AS and using
  137.    an exterior gateway protocol to route packets to other AS's. Since
  138.    this classic definition was developed, it has become common for a
  139.    single AS to use several interior gateway protocols and sometimes
  140.    several sets of metrics within an AS. The use of the term Autonomous
  141.    System here stresses the fact that, even when multiple IGPs and
  142.    metrics are used, the administration of an AS appears to other AS's
  143.    to have a single coherent interior routing plan and presents a
  144.    consistent picture of which networks are reachable through it.
  145.  
  146.    AS's are assumed to be administered by a single administrative
  147.    entity, at least for the purposes of representation of routing
  148.    information to systems outside of the AS.
  149.  
  150. 2. BGP Topological Model
  151.  
  152.    When we say that a connection exists between two AS's, we mean two
  153.    things:
  154.  
  155.       Physical connection:  There is a shared network between the two
  156.       AS's, and on this shared network each AS has at least one border
  157.       gateway belonging to that AS. Thus the border gateway of each AS
  158.       can forward packets to the border gateway of the other AS without
  159.       resorting to Inter-AS or Intra-AS routing.
  160.  
  161.       BGP connection:  There is a BGP session between BGP speakers in
  162.       each of the AS's, and this session communicates those routes that
  163.       can be used for specific networks via the advertising AS.
  164.       Throughout this document we place an additional restriction on the
  165.       BGP speakers that form the BGP connection: they must themselves
  166.       share the same network that their border gateways share. Thus, a
  167.  
  168.  
  169.  
  170. Rekhter & Gross                                                 [Page 3]
  171.  
  172. RFC 1655                   BGP-4 Application                   July 1994
  173.  
  174.  
  175.       BGP session between adjacent AS's requires no support from either
  176.       Inter-AS or Intra-AS routing. Cases that do not conform to this
  177.       restriction fall outside the scope of this document.
  178.  
  179.    Thus, at each connection, each AS has one or more BGP speakers and
  180.    one or more border gateways, and these BGP speakers and border
  181.    gateways are all located on a shared network. Note that BGP speakers
  182.    do not need to be a border gateway, and vice versa. Paths announced
  183.    by a BGP speaker of one AS on a given connection are taken to be
  184.    feasible for each of the border gateways of the other AS on the same
  185.    shared network, i.e. indirect neighbors are allowed.
  186.  
  187.    Much of the traffic carried within an AS either originates or
  188.    terminates at that AS (i.e., either the source IP address or the
  189.    destination IP address of the IP packet identifies a host on a
  190.    network internal to that AS).  Traffic that fits this description is
  191.    called "local traffic". Traffic that does not fit this description is
  192.    called "transit traffic". A major goal of BGP usage is to control the
  193.    flow of transit traffic.
  194.  
  195.    Based on how a particular AS deals with transit traffic, the AS may
  196.    now be placed into one of the following categories:
  197.  
  198.       stub AS: an AS that has only a single connection to one other AS.
  199.       Naturally, a stub AS only carries local traffic.
  200.  
  201.       multihomed AS: an AS that has connections to more than one other
  202.       AS, but refuses to carry transit traffic.
  203.  
  204.       transit AS: an AS that has connections to more than one other AS,
  205.       and is designed (under certain policy restrictions) to carry both
  206.       transit and local traffic.
  207.  
  208.    Since a full AS path provides an efficient and straightforward way of
  209.    suppressing routing loops and eliminates the "count-to-infinity"
  210.    problem associated with some distance vector algorithms, BGP imposes
  211.    no topological restrictions on the interconnection of AS's.
  212.  
  213. 3. BGP in the Internet
  214.  
  215. 3.1 Topology Considerations
  216.  
  217.    The overall Internet topology may be viewed as an arbitrary
  218.    interconnection of transit, multihomed, and stub AS's.  In order to
  219.    minimize the impact on the current Internet infrastructure, stub and
  220.    multihomed AS's need not use BGP.  These AS's may run other protocols
  221.    (e.g., EGP) to exchange reachability information with transit AS's.
  222.    Transit AS's using BGP will tag this information as having been
  223.  
  224.  
  225.  
  226. Rekhter & Gross                                                 [Page 4]
  227.  
  228. RFC 1655                   BGP-4 Application                   July 1994
  229.  
  230.  
  231.    learned by some method other than BGP. The fact that BGP need not run
  232.    on stub or multihomed AS's has no negative impact on the overall
  233.    quality of inter-AS routing for traffic that either destined to or
  234.    originated from the stub or multihomed AS's in question.
  235.  
  236.    However, it is recommended that BGP be used for stub and multihomed
  237.    AS's as well. In these situations, BGP will provide an advantage in
  238.    bandwidth and performance over some of the currently used protocols
  239.    (such as EGP).  In addition, this would reduce the need for the use
  240.    of default routes and in better choices of Inter-AS routes for
  241.    multihomed AS's.
  242.  
  243. 3.2 Global Nature of BGP
  244.  
  245.    At a global level, BGP is used to distribute routing information
  246.    among multiple Autonomous Systems. The information flows can be
  247.    represented as follows:
  248.  
  249.  
  250.                     +-------+         +-------+
  251.               BGP   |  BGP  |   BGP   |  BGP  |   BGP
  252.            ---------+       +---------+       +---------
  253.                     |  IGP  |         |  IGP  |
  254.                     +-------+         +-------+
  255.  
  256.                     <-AS A-->         <--AS B->
  257.  
  258.    This diagram points out that, while BGP alone carries information
  259.    between AS's, both BGP and an IGP may carry information across an AS.
  260.    Ensuring consistency of routing information between BGP and an IGP
  261.    within an AS is a significant issue and is discussed at length later
  262.    in Appendix A.
  263.  
  264. 3.3 BGP Neighbor Relationships
  265.  
  266.    The Internet is viewed as a set of arbitrarily connected AS's. BGP
  267.    speakers in each AS communicate with each other to exchange network
  268.    reachability information based on a set of policies established
  269.    within each AS. Routers that communicate directly with each other via
  270.    BGP are known as BGP neighbors. BGP neighbors can be located within
  271.    the same AS or in different AS's. For the sake of discussion, BGP
  272.    communications with neighbors in different AS's will be referred to
  273.    as External BGP, and with neighbors in the same AS as Internal BGP.
  274.  
  275.    There can be as many BGP speakers as deemed necessary within an AS.
  276.    Usually, if an AS has multiple connections to other AS's, multiple
  277.    BGP speakers are needed. All BGP speakers representing the same AS
  278.    must give a consistent image of the AS to the outside. This requires
  279.  
  280.  
  281.  
  282. Rekhter & Gross                                                 [Page 5]
  283.  
  284. RFC 1655                   BGP-4 Application                   July 1994
  285.  
  286.  
  287.    that the BGP speakers have consistent routing information among them.
  288.    These gateways can communicate with each other via BGP or by other
  289.    means. The policy constraints applied to all BGP speakers within an
  290.    AS must be consistent. Techniques such as using a tagged IGP (see
  291.    A.2.2) may be employed to detect possible inconsistencies.
  292.  
  293.    In the case of External BGP, the BGP neighbors must belong to
  294.    different AS's, but share a common network. This common network
  295.    should be used to carry the BGP messages between them. The use of BGP
  296.    across an intervening AS invalidates the AS path information. An
  297.    Autonomous System number must be used with BGP to specify which
  298.    Autonomous System the BGP speaker belongs to.
  299.  
  300. 4. Requirements for Route Aggregation
  301.  
  302.    A conformant BGP-4 implementation is required to have the ability to
  303.    specify when an aggregated route may be generated out of partial
  304.    routing information. For example, a BGP speaker at the border of an
  305.    autonomous system (or group of autonomous systems) must be able to
  306.    generate an aggregated route for a whole set of destination IP
  307.    addresses (in BGP-4 terminology such a set is called the Network
  308.    Layer Reachability Information or NLRI) over which it has
  309.    administrative control (including those addresses it has delegated),
  310.    even when not all of them are reachable at the same time.
  311.  
  312.    A conformant implementation may provide the capability to specify
  313.    when an aggregated NLRI may be generated.
  314.  
  315.    A conformant implementation is required to have the ability to
  316.    specify how NLRI may be de-aggregated.
  317.  
  318.    A conformant implementation is required to support the following
  319.    options when dealing with overlapping routes:
  320.  
  321.        - Install both the less and the more specific routes
  322.  
  323.        - Install the more specific route only
  324.  
  325.        - Install the less specific route only
  326.  
  327.        - Install neither route
  328.  
  329.    By default a BGP speaker should aggregate NLRI representing subnets
  330.    to the corresponding network.
  331.  
  332.    Injecting NLRI representing arbitrary subnets into BGP without
  333.    aggregation to the corresponding network shall be controlled via
  334.    configuration parameters.
  335.  
  336.  
  337.  
  338. Rekhter & Gross                                                 [Page 6]
  339.  
  340. RFC 1655                   BGP-4 Application                   July 1994
  341.  
  342.  
  343.    Certain routing policies may depend on the NLRI (e.g., "research"
  344.    versus "commercial"). Therefore, a BGP speaker that performs route
  345.    aggregation should be cognizant, if possible, of potential
  346.    implications on routing policies when aggregating NLRI.
  347.  
  348. 5. Policy Making with BGP
  349.  
  350.    BGP provides the capability for enforcing policies based on various
  351.    routing preferences and constraints. Policies are not directly
  352.    encoded in the protocol. Rather, policies are provided to BGP in the
  353.    form of configuration information.
  354.  
  355.    BGP enforces policies by affecting the selection of paths from
  356.    multiple alternatives and by controlling the redistribution of
  357.    routing information.  Policies are determined by the AS
  358.    administration.
  359.  
  360.    Routing policies are related to political, security, or economic
  361.    considerations. For example, if an AS is unwilling to carry traffic
  362.    to another AS, it can enforce a policy prohibiting this. The
  363.    following are examples of routing policies that can be enforced with
  364.    the use of BGP:
  365.  
  366.      1.  A multihomed AS can refuse to act as a transit AS for other
  367.          AS's.  (It does so by only advertising routes to networks
  368.          internal to the AS.)
  369.  
  370.      2.  A multihomed AS can become a transit AS for a restricted set of
  371.          adjacent AS's, i.e., some, but not all, AS's can use the
  372.          multihomed AS as a transit AS. (It does so by advertising its
  373.          routing information to this set of AS's.)
  374.  
  375.      3.  An AS can favor or disfavor the use of certain AS's for
  376.          carrying transit traffic from itself.
  377.  
  378.    A number of performance-related criteria can be controlled with the
  379.    use of BGP:
  380.  
  381.      1.  An AS can minimize the number of transit AS's. (Shorter AS
  382.          paths can be preferred over longer ones.)
  383.  
  384.      2.  The quality of transit AS's. If an AS determines that two or
  385.          more AS paths can be used to reach a given destination, that AS
  386.          can use a variety of means to decide which of the candidate AS
  387.          paths it will use. The quality of an AS can be measured by such
  388.          things as diameter, link speed, capacity, tendency to become
  389.          congested, and quality of operation. Information about these
  390.          qualities might be determined by means other than BGP.
  391.  
  392.  
  393.  
  394. Rekhter & Gross                                                 [Page 7]
  395.  
  396. RFC 1655                   BGP-4 Application                   July 1994
  397.  
  398.  
  399.      3.  Preference of internal routes over external routes.
  400.  
  401.    For consistency within an AS, equal cost paths, resulting from
  402.    combinations of policies and/or normal route selection procedures,
  403.    must be resolved in a consistent fashion.
  404.  
  405.    Fundamental to BGP is the rule that an AS advertises to its
  406.    neighboring AS's only those routes that it uses. This rule reflects
  407.    the "hop-by-hop" routing paradigm generally used by the current
  408.    Internet.
  409.  
  410. 6. Path Selection with BGP
  411.  
  412.    One of the major tasks of a BGP speaker is to evaluate different
  413.    paths to a destination network from its border gateways at that
  414.    network, select the best one, apply appropriate policy constraints,
  415.    and then advertise it to all of its BGP neighbors. The key issue is
  416.    how different paths are evaluated and compared.  In traditional
  417.    distance vector protocols (e.g., RIP) there is only one metric (e.g.,
  418.    hop count) associated with a path. As such, comparison of different
  419.    paths is reduced to simply comparing two numbers. A complication in
  420.    Inter-AS routing arises from the lack of a universally agreed-upon
  421.    metric among AS's that can be used to evaluate external paths.
  422.    Rather, each AS may have its own set of criteria for path evaluation.
  423.  
  424.    A BGP speaker builds a routing database consisting of the set of all
  425.    feasible paths and the list of networks reachable through each path.
  426.    For purposes of precise discussion, it's useful to consider the set
  427.    of feasible paths for a given destination network. In most cases, we
  428.    would expect to find only one feasible path. However, when this is
  429.    not the case, all feasible paths should be maintained, and their
  430.    maintenance speeds adaptation to the loss of the primary path. Only
  431.    the primary path at any given time will ever be advertised.
  432.  
  433.    The path selection process can be formalized by defining a complete
  434.    order over the set of all feasible paths to a given destination
  435.    network. One way to define this complete order is to define a
  436.    function that maps each full AS path to a non-negative integer that
  437.    denotes the path's degree of preference. Path selection is then
  438.    reduced to applying this function to all feasible paths and choosing
  439.    the one with the highest degree of preference.
  440.  
  441.    In actual BGP implementations, the criteria for assigning degree of
  442.    preferences to a path are specified as configuration information.
  443.  
  444.    The process of assigning a degree of preference to a path can be
  445.    based on several sources of information:
  446.  
  447.  
  448.  
  449.  
  450. Rekhter & Gross                                                 [Page 8]
  451.  
  452. RFC 1655                   BGP-4 Application                   July 1994
  453.  
  454.  
  455.      1.  Information explicitly present in the full AS path.
  456.  
  457.      2.  A combination of information that can be derived from the full
  458.          AS path and information outside the scope of BGP (e.g., policy
  459.          routing constraints provided as configuration information).
  460.  
  461.    Possible criteria for assigning a degree of preference to a path are:
  462.  
  463.        - AS count. Paths with a smaller AS count are generally better.
  464.  
  465.        - Policy considerations. BGP supports policy-based routing based
  466.          on the controlled distribution of routing information.  A BGP
  467.          speaker may be aware of some policy constraints (both within
  468.          and outside of its own AS) and do appropriate path selection.
  469.          Paths that do not comply with policy requirements are not
  470.          considered further.
  471.  
  472.        - Presence or absence of a certain AS or AS's in the path. By
  473.          means of information outside the scope of BGP, an AS may know
  474.          some performance characteristics (e.g., bandwidth, MTU, intra-
  475.          AS diameter) of certain AS's and may try to avoid or prefer
  476.          them.
  477.  
  478.        - Path origin. A path learned entirely from BGP (i.e., whose
  479.          endpoint is internal to the last AS on the path) is generally
  480.          better than one for which part of the path was learned via EGP
  481.          or some other means.
  482.  
  483.        - AS path subsets. An AS path that is a subset of a longer AS
  484.          path to the same destination should be preferred over the
  485.          longer path.  Any problem in the shorter path (such as an
  486.          outage) will also be a problem in the longer path.
  487.  
  488.        - Link dynamics. Stable paths should be preferred over unstable
  489.          ones. Note that this criterion must be used in a very careful
  490.          way to avoid causing unnecessary route fluctuation. Generally,
  491.          any criteria that depend on dynamic information might cause
  492.          routing instability and should be treated very carefully.
  493.  
  494. 7. Required set of supported routing policies
  495.  
  496.    Policies are provided to BGP in the form of configuration
  497.    information.  This information is not directly encoded in the
  498.    protocol. Therefore, BGP can provide support for very complex routing
  499.    policies. However, it is not required that all BGP implementations
  500.    support such policies.
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Rekhter & Gross                                                 [Page 9]
  507.  
  508. RFC 1655                   BGP-4 Application                   July 1994
  509.  
  510.  
  511.    We are not attempting to standardize the routing policies that must
  512.    be supported in every BGP implementation; we strongly encourage all
  513.    implementors to support the following set of routing policies:
  514.  
  515.      1.  BGP implementations should allow an AS to control announcements
  516.          of BGP-learned routes to adjacent AS's.  Implementations should
  517.          also support such control with at least the granularity of a
  518.          single network.  Implementations should also support such
  519.          control with the granularity of an autonomous system, where the
  520.          autonomous system may be either the autonomous system that
  521.          originated the route, or the autonomous system that advertised
  522.          the route to the local system (adjacent autonomous system).
  523.          Care must be taken when a BGP speaker selects a new route that
  524.          can't be announced to a particular external peer, while the
  525.          previously selected route was announced to that peer.
  526.          Specifically, the local system must explicitly indicate to the
  527.          peer that the previous route is now infeasible.
  528.  
  529.      2.  BGP implementations should allow an AS to prefer a particular
  530.          path to a destination (when more than one path is available).
  531.          At the minimum an implementation shall support this
  532.          functionality by allowing to administratively assign a degree
  533.          of preference to a route based solely on the IP address of the
  534.          neighbor the route is received from. The allowed range of the
  535.          assigned degree of preference shall be between 0 and 2^(31) -
  536.          1.
  537.  
  538.      3.  BGP implementations should allow an AS to ignore routes with
  539.          certain AS's in the AS_PATH path attribute.  Such function can
  540.          be implemented by using the technique outlined in [2], and by
  541.          assigning "infinity" as "weights" for such AS's. The route
  542.          selection process must ignore routes that have "weight" equal
  543.          to "infinity".
  544.  
  545. 8. Interaction with other exterior routing protocols
  546.  
  547.    The guidelines suggested in this section are consistent with the
  548.    guidelines presented in [3].
  549.  
  550.    An AS should advertise a minimal aggregate for its internal networks
  551.    with respect to the amount of address space that it is actually
  552.    using.  This can be used by administrators of non-BGP 4 AS's to
  553.    determine how many routes to explode from a single aggregate.
  554.  
  555.    A route that carries the ATOMIC_AGGREGATE path attribute shall not be
  556.    exported into either BGP-3 or EGP2, unless such an exportation can be
  557.    accomplished without exploding the NLRI of the route.
  558.  
  559.  
  560.  
  561.  
  562. Rekhter & Gross                                                [Page 10]
  563.  
  564. RFC 1655                   BGP-4 Application                   July 1994
  565.  
  566.  
  567. 8.1 Exchanging information with EGP2
  568.  
  569.    This document suggests the following guidelines for exchanging
  570.    routing information between BGP-4 and EGP2.
  571.  
  572.    To provide for graceful migration, a BGP speaker may participate in
  573.    EGP2, as well as in BGP-4. Thus, a BGP speaker may receive IP
  574.    reachability information by means of EGP2 as well as by means of
  575.    BGP-4.  The information received by EGP2 can be injected into BGP-4
  576.    with the ORIGIN path attribute set to 1.  Likewise,  the information
  577.    received via BGP-4 can be injected into EGP2 as well. In the latter
  578.    case, however, one needs to be aware of the potential information
  579.    explosion when a given IP prefix received from BGP-4 denotes a set of
  580.    consecutive A/B/C class networks.  Injection of BGP-4 received NLRI
  581.    that denotes IP subnets requires the BGP speaker to inject the
  582.    corresponding network into EGP2.  The local system shall provide
  583.    mechanisms to control the exchange of reachability information
  584.    between EGP2 and BGP-4.  Specifically, a conformant implementation is
  585.    required to support all of the following options when injecting BGP-4
  586.    received reachability information into EGP2:
  587.  
  588.        - inject default only (0.0.0.0); no export of any other NLRI
  589.  
  590.        - allow controlled deaggregation, but only of specific routes;
  591.          allow export of non-aggregated NLRI
  592.  
  593.        - allow export of only non-aggregated NLRI
  594.  
  595.    The exchange of routing information via EGP2 between a BGP speaker
  596.    participating in BGP-4 and a pure EGP2 speaker may occur  only at the
  597.    domain (autonomous system) boundaries.
  598.  
  599. 8.2 Exchanging information with BGP-3
  600.  
  601.    This document suggests the following guidelines for exchanging
  602.    routing information between BGP-4 and BGP-3.
  603.  
  604.    To provide for graceful migration, a BGP speaker may participate in
  605.    BGP-3, as well as in BGP-4. Thus, a BGP speaker may receive IP
  606.    reachability information by means of BGP-3, as well as by means of
  607.    BGP-4.
  608.  
  609.    A BGP speaker may inject the information received by BGP-4 into BGP-3
  610.    as follows.
  611.  
  612.    If an AS_PATH attribute of a BGP-4 route carries AS_SET path
  613.    segments, then the AS_PATH attribute of the BGP-3 route shall be
  614.    constructed by treating the AS_SET segments as AS_SEQUENCE segments,
  615.  
  616.  
  617.  
  618. Rekhter & Gross                                                [Page 11]
  619.  
  620. RFC 1655                   BGP-4 Application                   July 1994
  621.  
  622.  
  623.    with the resulting AS_PATH being a single AS_SEQUENCE. While this
  624.    procedure loses set/sequence information, it doesn't affect
  625.    protection for routing loops suppression, but may affect policies, if
  626.    the policies are based on the content or ordering of the AS_PATH
  627.    attribute.
  628.  
  629.    While injecting BGP-4 derived NLRI into BGP-3, one needs to be aware
  630.    of the potential information explosion when a given IP prefix denotes
  631.    a set of consecutive A/B/C class networks. Injection of BGP-4 derived
  632.    NLRI that denotes IP subnets requires the BGP speaker to inject the
  633.    corresponding network into BGP-3. The local system shall provide
  634.    mechanisms to control the exchange of routing information between
  635.    BGP-3 and BGP-4.  Specifically, a conformant implementation is
  636.    required to support all of the following options when injecting BGP-4
  637.    received routing information into BGP-3:
  638.  
  639.        - inject default only (0.0.0.0), no export of any other NLRI
  640.  
  641.        - allow controlled deaggregation, but only of specific routes;
  642.          allow export of non-aggregated NLRI
  643.  
  644.        - allow export of only non-aggregated NLRI
  645.  
  646.    The exchange of routing information via BGP-3 between a BGP speaker
  647.    participating in BGP-4 and a pure BGP-3 speaker may occur  only at
  648.    the autonomous system boundaries. Within a single autonomous system
  649.    BGP conversations between all the BGP speakers of that autonomous
  650.    system have to be either BGP-3 or BGP-4, but not a mixture.
  651.  
  652. 9. Operations over Switched Virtual Circuits
  653.  
  654.    When using BGP over Switched Virtual Circuit (SVC) subnetworks it may
  655.    be desirable to minimize traffic generated by BGP. Specifically, it
  656.    may be desirable to eliminate traffic associated with periodic
  657.    KEEPALIVE messages.  BGP includes a mechanism for operation over
  658.    switched virtual circuit (SVC) services which avoids keeping SVCs
  659.    permanently open and allows it to eliminates periodic sending of
  660.    KEEPALIVE messages.
  661.  
  662.    This section describes how to operate without periodic KEEPALIVE
  663.    messages to minimise SVC usage when using an intelligent SVC circuit
  664.    manager.  The proposed scheme may also be used on "permanent"
  665.    circuits, which support a feature like link quality monitoring or
  666.    echo request to determine the status of link connectivity.
  667.  
  668.    The mechanism described in this section is suitable only between the
  669.    BGP speakers that are directly connected over a common virtual
  670.    circuit.
  671.  
  672.  
  673.  
  674. Rekhter & Gross                                                [Page 12]
  675.  
  676. RFC 1655                   BGP-4 Application                   July 1994
  677.  
  678.  
  679. 9.1 Establishing a BGP Connection
  680.  
  681.    The feature is selected by specifying zero Hold Time in the OPEN
  682.    message.
  683.  
  684. 9.2 Circuit Manager Properties
  685.  
  686.    The circuit manager must have sufficient functionality to be able to
  687.    compensate for the lack of periodic KEEPALIVE messages:
  688.  
  689.        - It must be able to determine link layer unreachability in a
  690.          predictable finite period of a failure occurring.
  691.  
  692.        - On determining unreachability it should:
  693.  
  694.                 - start a configurable dead timer (comparable to a
  695.                   typical Hold timer value).
  696.  
  697.                 - attempt to re-establish the Link Layer connection.
  698.  
  699.        - If the dead timer expires it should:
  700.  
  701.                 - send an internal circuit DEAD indication to TCP.
  702.  
  703.        - If the connection is re-established it should:
  704.  
  705.                 - cancel the dead timer.
  706.  
  707.                 - send an internal circuit UP indication to TCP.
  708.  
  709. 9.3 TCP Properties
  710.  
  711.    A small modification must be made to TCP to process internal
  712.    notifications from the circuit manager:
  713.  
  714.        - DEAD: Flush transmit queue and abort TCP connection.
  715.  
  716.        - UP: Transmit any queued data or allow an outgoing TCP call to
  717.          proceed.
  718.  
  719. 9.4 Combined Properties
  720.  
  721.    Some implementations may not be able to guarantee that the BGP
  722.    process and the circuit manager will operate as a single entity; i.e.
  723.    they can have a separate existence when the other has been stopped or
  724.    has crashed.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Rekhter & Gross                                                [Page 13]
  731.  
  732. RFC 1655                   BGP-4 Application                   July 1994
  733.  
  734.  
  735.    If this is the case, a periodic two-way poll between the BGP process
  736.    and the circuit manager should be implemented.  If the BGP process
  737.    discovers the circuit manager has gone away it should close all
  738.    relevant TCP connections.  If the circuit manager discovers the BGP
  739.    process has gone away it should close all its connections associated
  740.    with the BGP process and reject any further incoming connections.
  741.  
  742. 10. Conclusion
  743.  
  744.    The BGP protocol provides a high degree of control and flexibility
  745.    for doing interdomain routing while enforcing policy and performance
  746.    constraints and avoiding routing loops. The guidelines presented here
  747.    will provide a starting point for using BGP to provide more
  748.    sophisticated and manageable routing in the Internet as it grows.
  749.  
  750. Appendix A. The Interaction of BGP and an IGP
  751.  
  752.    This section outlines methods by which BGP can exchange routing
  753.    information with an IGP. The methods outlined here are not proposed
  754.    as part of the standard BGP usage at this time.  These methods are
  755.    outlined for information purposes only.  Implementors may want to
  756.    consider these methods when importing IGP information.
  757.  
  758.    This is general information that applies to any generic IGP.
  759.  
  760.    Interaction between BGP and any specific IGP is outside the scope of
  761.    this section.  Methods for specific IGP's should be proposed in
  762.    separate documents.  Methods for specific IGP's could be proposed for
  763.    standard usage in the future.
  764.  
  765. Overview
  766.  
  767.    By definition, all transit AS's must be able to carry traffic which
  768.    originates from and/or is destined to locations outside of that AS.
  769.    This requires a certain degree of interaction and coordination
  770.    between BGP and the Interior Gateway Protocol (IGP) used by that
  771.    particular AS. In general, traffic originating outside of a given AS
  772.    is going to pass through both interior gateways (gateways that
  773.    support the IGP only) and border gateways (gateways that support both
  774.    the IGP and BGP). All interior gateways receive information about
  775.    external routes from one or more of the border gateways of the AS via
  776.    the IGP.
  777.  
  778.    Depending on the mechanism used to propagate BGP information within a
  779.    given AS, special care must be taken to ensure consistency between
  780.    BGP and the IGP, since changes in state are likely to propagate at
  781.    different rates across the AS. There may be a time window between the
  782.    moment when some border gateway (A) receives new BGP routing
  783.  
  784.  
  785.  
  786. Rekhter & Gross                                                [Page 14]
  787.  
  788. RFC 1655                   BGP-4 Application                   July 1994
  789.  
  790.  
  791.    information which was originated from another border gateway (B)
  792.    within the same AS, and the moment the IGP within this AS is capable
  793.    of routing transit traffic to that border gateway (B). During that
  794.    time window, either incorrect routing or "black holes" can occur.
  795.  
  796.    In order to minimize such routing problems, border gateway (A) should
  797.    not advertise a route to some exterior network X via border gateway
  798.    (B) to all of its BGP neighbors in other AS's until all the interior
  799.    gateways within the AS are ready to route traffic destined to X via
  800.    the correct exit border gateway (B). In other words, interior routing
  801.    should converge on the proper exit gateway before/advertising routes
  802.    via that exit gateway to other AS's.
  803.  
  804. A.2 Methods for Achieving Stable Interactions
  805.  
  806.    The following discussion outlines several techniques capable of
  807.    achieving stable interactions between BGP and the IGP within an
  808.    Autonomous System.
  809.  
  810. A.2.1 Propagation of BGP Information via the IGP
  811.  
  812.    While BGP can provide its own mechanism for carrying BGP information
  813.    within an AS, one can also use an IGP to transport this information,
  814.    as long as the IGP supports complete flooding of routing information
  815.    (providing the mechanism to distribute the BGP information) and one
  816.    pass convergence (making the mechanism effectively atomic). If an IGP
  817.    is used to carry BGP information, then the period of
  818.    desynchronization described earlier does not occur at all, since BGP
  819.    information propagates within the AS synchronously with the IGP, and
  820.    the IGP converges more or less simultaneously with the arrival of the
  821.    new routing information. Note that the IGP only carries BGP
  822.    information and should not interpret or process this information.
  823.  
  824. A.2.2  Tagged Interior Gateway Protocol
  825.  
  826.    Certain IGPs can tag routes exterior to an AS with the identity of
  827.    their exit points while propagating them within the AS. Each border
  828.    gateway should use identical tags for announcing exterior routing
  829.    information (received via BGP) both into the IGP and into Internal
  830.    BGP when propagating this information to other border gateways within
  831.    the same AS. Tags generated by a border gateway must uniquely
  832.    identify that particular border gateway--different border gateways
  833.    must use different tags.
  834.  
  835.    All Border Gateways within a single AS must observe the following two
  836.    rules:
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Rekhter & Gross                                                [Page 15]
  843.  
  844. RFC 1655                   BGP-4 Application                   July 1994
  845.  
  846.  
  847.      1.  Information received via Internal BGP by a border gateway A
  848.          declaring a network to be unreachable must immediately be
  849.          propagated to all of the External BGP neighbors of A.
  850.  
  851.      2.  Information received via Internal BGP by a border gateway A
  852.          about a reachable network X cannot be propagated to any of the
  853.          External BGP neighbors of A unless/until A has an IGP route to
  854.          X and both the IGP and the BGP routing information have
  855.          identical tags.
  856.  
  857.    These rules guarantee that no routing information is announced
  858.    externally unless the IGP is capable of correctly supporting it. It
  859.    also avoids some causes of "black holes".
  860.  
  861.    One possible method for tagging BGP and IGP routes within an AS is to
  862.    use the IP address of the exit border gateway announcing the exterior
  863.    route into the AS. In this case the "gateway" field in the BGP UPDATE
  864.    message is used as the tag.
  865.  
  866.    An alternate method for tagging BGP and IGP routes is to have BGP and
  867.    the IGP agree on a router ID.  In this case, the router ID is
  868.    available to all BGP (version 3 or higher) speakers.  Since this ID
  869.    is already unique it can be used directly as the tag in the IGP.
  870.  
  871. A.2.3 Encapsulation
  872.  
  873.    Encapsulation provides the simplest (in terms of the interaction
  874.    between the IGP and BGP) mechanism for carrying transit traffic
  875.    across the AS. In this approach, transit traffic is encapsulated
  876.    within an IP datagram addressed to the exit gateway. The only
  877.    requirement imposed on the IGP by this approach is that it should be
  878.    capable of supporting routing between border gateways within the same
  879.    AS.
  880.  
  881.    The address of the exit gateway A for some exterior network X is
  882.    specified in the BGP identifier field of the BGP OPEN message
  883.    received from gateway A via Internal BGP by all other border gateways
  884.    within the same AS. In order to route traffic to network X, each
  885.    border gateway within the AS encapsulates it in datagrams addressed
  886.    to gateway A. Gateway A then performs decapsulation and forwards the
  887.    original packet to the proper gateway in another AS.
  888.  
  889.    Since encapsulation does not rely on the IGP to carry exterior
  890.    routing information, no synchronization between BGP and the IGP is
  891.    required.
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Rekhter & Gross                                                [Page 16]
  899.  
  900. RFC 1655                   BGP-4 Application                   July 1994
  901.  
  902.  
  903.    Some means of identifying datagrams containing encapsulated IP, such
  904.    as an IP protocol type code, must be defined if this method is to be
  905.    used.
  906.  
  907.    Note that, if a packet to be encapsulated has length that is very
  908.    close to the MTU, that packet would be fragmented at the gateway that
  909.    performs encapsulation.
  910.  
  911. A.2.4  Pervasive BGP
  912.  
  913.    If all routers in an AS are BGP speakers, then there is no need to
  914.    have any interaction between BGP and an IGP.  In such cases, all
  915.    routers in the AS already have full information of all BGP routes.
  916.    The IGP is then only used for routing within the AS, and no BGP
  917.    routes are imported into the IGP.
  918.  
  919.    For routers to operate in this fashion, they must be able to perform
  920.    a recursive lookup in their routing table.  The first lookup will use
  921.    a BGP route to establish the exit router, while the second lookup
  922.    will determine the IGP path to the exit router.
  923.  
  924.    Since the IGP carries no external information in this scenario, all
  925.    routers in the AS will have converged as soon as all BGP speakers
  926.    have new information about this route.  Since there is no need to
  927.    delay for the IGP to converge, an implementation may advertise these
  928.    routes without further delay due to the IGP.
  929.  
  930. A.2.5  Other Cases
  931.  
  932.    There may be AS's with IGPs which can neither carry BGP information
  933.    nor tag exterior routes (e.g., RIP). In addition, encapsulation may
  934.    be either infeasible or undesirable. In such situations, the
  935.    following two rules must be observed:
  936.  
  937.      1.  Information received via Internal BGP by a border gateway A
  938.          declaring a network to be unreachable must immediately be
  939.          propagated to all of the External BGP neighbors of A.
  940.  
  941.      2.  Information received via Internal BGP by a border gateway A
  942.          about a reachable network X cannot be propagated to any of the
  943.          External BGP neighbors of A unless A has an IGP route to X and
  944.          sufficient time has passed for the IGP routes to have
  945.          converged.
  946.  
  947.    The above rules present necessary (but not sufficient) conditions for
  948.    propagating BGP routing information to other AS's. In contrast to
  949.    tagged IGPs, these rules cannot ensure that interior routes to the
  950.    proper exit gateways are in place before propagating the routes to
  951.  
  952.  
  953.  
  954. Rekhter & Gross                                                [Page 17]
  955.  
  956. RFC 1655                   BGP-4 Application                   July 1994
  957.  
  958.  
  959.    other AS's.
  960.  
  961.    If the convergence time of an IGP is less than some small value X,
  962.    then the time window during which the IGP and BGP are unsynchronized
  963.    is less than X as well, and the whole issue can be ignored at the
  964.    cost of transient periods (of less than length X) of routing
  965.    instability. A reasonable value for X is a matter for further study,
  966.    but X should probably be less than one second.
  967.  
  968.    If the convergence time of an IGP cannot be ignored, a different
  969.    approach is needed. Mechanisms and techniques which might be
  970.    appropriate in this situation are subjects for further study.
  971.  
  972. References
  973.  
  974.    [1] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4), RFC
  975.        1654, cisco Systems, T.J. Watson Research Center, IBM Corp., July
  976.        1994.
  977.  
  978.    [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
  979.        Merit/NSFNET, July 1989.
  980.  
  981.    [3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:  an
  982.        Address Assignment and Aggregation Strategy", RFC 1519, BARRNet,
  983.        cisco, MERIT, OARnet, September 1993.
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Rekhter & Gross                                                [Page 18]
  1011.  
  1012. RFC 1655                   BGP-4 Application                   July 1994
  1013.  
  1014.  
  1015. Security Considerations
  1016.  
  1017.    Security issues are not discussed in this memo.
  1018.  
  1019. Authors' Addresses
  1020.  
  1021.    Yakov Rekhter
  1022.    T.J. Watson Research Center IBM Corporation
  1023.    P.O. Box 218
  1024.    Yorktown Heights, NY 10598
  1025.  
  1026.    Phone:  (914) 945-3896
  1027.    EMail: yakov@watson.ibm.com
  1028.  
  1029.  
  1030.    Phill Gross
  1031.    Director of Broadband Engineering
  1032.    MCI Data Services Division
  1033.    2100 Reston Parkway, Room 6001
  1034.    Reston, VA 22091
  1035.  
  1036.    Phone: +1 703 715 7432
  1037.    Fax: +1 703 715 7436
  1038.    EMail: 0006423401@mcimail.com
  1039.  
  1040.    IETF BGP WG mailing list: bgp@ans.net
  1041.    To be added: bgp-request@ans.net
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Rekhter & Gross                                                [Page 19]
  1067.  
  1068.