home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1772.txt < prev    next >
Text File  |  1996-05-07  |  45KB  |  551 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         Y. Rekhter Request for Comments: 1772        T.J. Watson Research Center, IBM Corp. Obsoletes: 1655                                                 P. Gross Category: Standards Track                                            MCI                                                                  Editors                                                               March 1995 
  8.  
  9.         Application of the Border Gateway Protocol in the Internet 
  10.  
  11. Status of this Memo 
  12.  
  13.    This document specifies an Internet standards track protocol for the    Internet community, and requests discussion and suggestions for    improvements.  Please refer to the current edition of the "Internet    Official Protocol Standards" (STD 1) for the standardization state    and status of this protocol.  Distribution of this memo is unlimited. 
  14.  
  15. Abstract 
  16.  
  17.    This document, together with its companion document, "A Border    Gateway Protocol 4 (BGP-4)", define an inter-autonomous system    routing protocol for the Internet.  "A Border Gateway Protocol 4    (BGP-4)" defines the BGP protocol specification, and this document    describes the usage of the BGP in the Internet. 
  18.  
  19.    Information about the progress of BGP can be monitored and/or    reported on the BGP mailing list (bgp@ans.net). 
  20.  
  21. Acknowledgements 
  22.  
  23.    This document was originally published as RFC 1164 in June 1990,    jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz    (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu    (MERIT). 
  24.  
  25.    The following also made key contributions to RFC 1164 -- Guy Almes    (ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans-    Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT). 
  26.  
  27.    We like to explicitly thank Bob Braden (ISI) for the review of the    previous version of this document. 
  28.  
  29.    This updated version of the document is the product of the IETF BGP    Working Group with Phill Gross (MCI) and Yakov Rekhter (IBM) as    editors. 
  30.  
  31.  
  32.  
  33.  
  34.  
  35. Rekhter & Gross                                                 [Page 1] 
  36.  RFC 1772                   BGP-4 Application                  March 1995 
  37.  
  38.     John Moy (Proteon) contributed Section 7 "Required set of supported    routing policies". 
  39.  
  40.    Scott Brim (Cornell University) contributed the basis for Section 8    "Interaction with other exterior routing protocols". 
  41.  
  42.    Most of the text in Section 9 was contributed by Gerry Meyer    (Spider). 
  43.  
  44.    Parts of the Introduction were taken almost verbatim from [3]. 
  45.  
  46.    We would like to acknowledge Dan Long (NEARNET) and Tony Li (cisco    Systems) for their review and comments on the current version of the    document. 
  47.  
  48.    The work of Yakov Rekhter was supported in part by the National    Science Foundation under Grant Number NCR-9219216. 
  49.  
  50. 1. Introduction 
  51.  
  52.    This memo describes the use of the Border Gateway Protocol (BGP) [1]    in the Internet environment. BGP is an inter-Autonomous System    routing protocol. The network reachability information exchanged via    BGP provides sufficient information to detect routing loops and    enforce routing decisions based on performance preference and policy    constraints as outlined in RFC 1104 [2]. In particular, BGP exchanges    routing information containing full AS paths and enforces routing    policies based on configuration information. 
  53.  
  54.    As the Internet has evolved and grown over in recent years, it has    become painfully evident that it is soon to face several serious    scaling problems. These include: 
  55.  
  56.        - Exhaustion of the class-B network address space. One          fundamental cause of this problem is the lack of a network          class of a size which is appropriate for mid-sized          organization; class-C, with a maximum of 254 host addresses, is          too small while class-B, which allows up to 65534 addresses, is          too large to be densely populated. 
  57.  
  58.        - Growth of routing tables in Internet routers are beyond the          ability of current software (and people) to effectively manage. 
  59.  
  60.        - Eventual exhaustion of the 32-bit IP address space. 
  61.  
  62.    It has become clear that the first two of these problems are likely    to become critical within the next one to three years.  Classless    inter-domain routing (CIDR) attempts to deal with these problems by 
  63.  
  64.  
  65.  
  66. Rekhter & Gross                                                 [Page 2] 
  67.  RFC 1772                   BGP-4 Application                  March 1995 
  68.  
  69.     proposing a mechanism to slow the growth of the routing table and the    need for allocating new IP network numbers. It does not attempt to    solve the third problem, which is of a more long-term nature, but    instead endeavors to ease enough of the short to mid-term    difficulties to allow the Internet to continue to function    efficiently while progress is made on a longer-term solution. 
  70.  
  71.    BGP-4 is an extension of BGP-3 that provides support for routing    information aggregation and reduction based on the Classless inter-    domain routing architecture (CIDR) [3].  This memo describes the    usage of BGP-4 in the Internet. 
  72.  
  73.    All of the discussions in this paper are based on the assumption that    the Internet is a collection of arbitrarily connected Autonomous    Systems. That is, the Internet will be modeled as a general graph    whose nodes are AS's and whose edges are connections between pairs of    AS's. 
  74.  
  75.    The classic definition of an Autonomous System is a set of routers    under a single technical administration, using an interior gateway    protocol and common metrics to route packets within the AS and using    an exterior gateway protocol to route packets to other AS's. Since    this classic definition was developed, it has become common for a    single AS to use several interior gateway protocols and sometimes    several sets of metrics within an AS. The use of the term Autonomous    System here stresses the fact that, even when multiple IGPs and    metrics are used, the administration of an AS appears to other AS's    to have a single coherent interior routing plan and presents a    consistent picture of which destinations are reachable through it. 
  76.  
  77.    AS's are assumed to be administered by a single administrative    entity, at least for the purposes of representation of routing    information to systems outside of the AS. 
  78.  
  79. 2. BGP Topological Model 
  80.  
  81.    When we say that a connection exists between two AS's, we mean two    things: 
  82.  
  83.       Physical connection:  There is a shared Data Link subnetwork       between the two AS's, and on this shared subnetwork each AS has at       least one border gateway belonging to that AS. Thus the border       gateway of each AS can forward packets to the border gateway of       the other AS without resorting to Inter-AS or Intra-AS routing. 
  84.  
  85.       BGP connection:  There is a BGP session between BGP speakers in       each of the AS's, and this session communicates those routes that       can be used for specific destinations via the advertising AS. 
  86.  
  87.  
  88.  
  89. Rekhter & Gross                                                 [Page 3] 
  90.  RFC 1772                   BGP-4 Application                  March 1995 
  91.  
  92.        Throughout this document we place an additional restriction on the       BGP speakers that form the BGP connection: they must themselves       share the same Data Link subnetwork that their border gateways       share. Thus, a BGP session between adjacent AS's requires no       support from either Inter-AS or Intra-AS routing. Cases that do       not conform to this restriction fall outside the scope of this       document. 
  93.  
  94.    Thus, at each connection, each AS has one or more BGP speakers and    one or more border gateways, and these BGP speakers and border    gateways are all located on a shared Data Link subnetwork. Note that    BGP speakers do not need to be a border gateway, and vice versa.    Paths announced by a BGP speaker of one AS on a given connection are    taken to be feasible for each of the border gateways of the other AS    on the same shared subnetwork, i.e. indirect neighbors are allowed. 
  95.  
  96.    Much of the traffic carried within an AS either originates or    terminates at that AS (i.e., either the source IP address or the    destination IP address of the IP packet identifies a host internal to    that AS).  Traffic that fits this description is called "local    traffic". Traffic that does not fit this description is called    "transit traffic". A major goal of BGP usage is to control the flow    of transit traffic. 
  97.  
  98.    Based on how a particular AS deals with transit traffic, the AS may    now be placed into one of the following categories: 
  99.  
  100.       stub AS: an AS that has only a single connection to one other AS.       Naturally, a stub AS only carries local traffic. 
  101.  
  102.       multihomed AS: an AS that has connections to more than one other       AS, but refuses to carry transit traffic. 
  103.  
  104.       transit AS: an AS that has connections to more than one other AS,       and is designed (under certain policy restrictions) to carry both       transit and local traffic. 
  105.  
  106.    Since a full AS path provides an efficient and straightforward way of    suppressing routing loops and eliminates the "count-to-infinity"    problem associated with some distance vector algorithms, BGP imposes    no topological restrictions on the interconnection of AS's. 
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  Rekhter & Gross                                                 [Page 4] 
  117.  RFC 1772                   BGP-4 Application                  March 1995 
  118.  
  119.  3. BGP in the Internet 
  120.  
  121. 3.1 Topology Considerations 
  122.  
  123.    The overall Internet topology may be viewed as an arbitrary    interconnection of transit, multihomed, and stub AS's.  In order to    minimize the impact on the current Internet infrastructure, stub and    multihomed AS's need not use BGP.  These AS's may run other protocols    (e.g., EGP) to exchange reachability information with transit AS's.    Transit AS's using BGP will tag this information as having been    learned by some method other than BGP. The fact that BGP need not run    on stub or multihomed AS's has no negative impact on the overall    quality of inter-AS routing for traffic that either destined to or    originated from the stub or multihomed AS's in question. 
  124.  
  125.    However, it is recommended that BGP be used for stub and multihomed    AS's as well. In these situations, BGP will provide an advantage in    bandwidth and performance over some of the currently used protocols    (such as EGP).  In addition, this would reduce the need for the use    of default routes and in better choices of Inter-AS routes for    multihomed AS's. 
  126.  
  127. 3.2 Global Nature of BGP 
  128.  
  129.    At a global level, BGP is used to distribute routing information    among multiple Autonomous Systems. The information flows can be    represented as follows: 
  130.  
  131.                     +-------+         +-------+               BGP   |  BGP  |   BGP   |  BGP  |   BGP            ---------+       +---------+       +---------                     |  IGP  |         |  IGP  |                     +-------+         +-------+ 
  132.  
  133.                     <-AS A-->         <--AS B-> 
  134.  
  135.    This diagram points out that, while BGP alone carries information    between AS's, both BGP and an IGP may carry information across an AS.    Ensuring consistency of routing information between BGP and an IGP    within an AS is a significant issue and is discussed at length later    in Appendix A. 
  136.  
  137. 3.3 BGP Neighbor Relationships 
  138.  
  139.    The Internet is viewed as a set of arbitrarily connected AS's.    Routers that communicate directly with each other via BGP are known    as BGP speakers. BGP speakers can be located within the same AS or in    different AS's.  BGP speakers in each AS communicate with each other 
  140.  
  141.  
  142.  
  143. Rekhter & Gross                                                 [Page 5] 
  144.  RFC 1772                   BGP-4 Application                  March 1995 
  145.  
  146.     to exchange network reachability information based on a set of    policies established within each AS.  For a given BGP speaker, some    other BGP speaker with which the given speaker communicates is    referred to as an external peer if the other speaker is in a    different AS, while if the other speaker is in the same AS it is    referred to as an internal peer. 
  147.  
  148.    There can be as many BGP speakers as deemed necessary within an AS.    Usually, if an AS has multiple connections to other AS's, multiple    BGP speakers are needed. All BGP speakers representing the same AS    must give a consistent image of the AS to the outside. This requires    that the BGP speakers have consistent routing information among them.    These gateways can communicate with each other via BGP or by other    means. The policy constraints applied to all BGP speakers within an    AS must be consistent. Techniques such as using a tagged IGP (see    A.2.2) may be employed to detect possible inconsistencies. 
  149.  
  150.    In the case of external peers, the peers must belong to different    AS's, but share a common Data Link subnetwork. This common subnetwork    should be used to carry the BGP messages between them. The use of BGP    across an intervening AS invalidates the AS path information. An    Autonomous System number must be used with BGP to specify which    Autonomous System the BGP speaker belongs to. 
  151.  
  152. 4. Requirements for Route Aggregation 
  153.  
  154.    A conformant BGP-4 implementation is required to have the ability to    specify when an aggregated route may be generated out of partial    routing information. For example, a BGP speaker at the border of an    autonomous system (or group of autonomous systems) must be able to    generate an aggregated route for a whole set of destination IP    addresses (in BGP-4 terminology such a set is called the Network    Layer Reachability Information or NLRI) over which it has    administrative control (including those addresses it has delegated),    even when not all of them are reachable at the same time. 
  155.  
  156.    A conformant implementation may provide the capability to specify    when an aggregated NLRI may be generated. 
  157.  
  158.    A conformant implementation is required to have the ability to    specify how NLRI may be de-aggregated. 
  159.  
  160.    A conformant implementation is required to support the following    options when dealing with overlapping routes: 
  161.  
  162.        - Install both the less and the more specific routes 
  163.  
  164.        - Install the more specific route only 
  165.  
  166.  
  167.  
  168. Rekhter & Gross                                                 [Page 6] 
  169.  RFC 1772                   BGP-4 Application                  March 1995 
  170.  
  171.         - Install the less specific route only 
  172.  
  173.        - Install neither route 
  174.  
  175.    Certain routing policies may depend on the NLRI (e.g. "research"    versus "commercial"). Therefore, a BGP speaker that performs route    aggregation should be cognizant, if possible, of potential    implications on routing policies when aggregating NLRI. 
  176.  
  177. 5. Policy Making with BGP 
  178.  
  179.    BGP provides the capability for enforcing policies based on various    routing preferences and constraints. Policies are not directly    encoded in the protocol. Rather, policies are provided to BGP in the    form of configuration information. 
  180.  
  181.    BGP enforces policies by affecting the selection of paths from    multiple alternatives and by controlling the redistribution of    routing information.  Policies are determined by the AS    administration. 
  182.  
  183.    Routing policies are related to political, security, or economic    considerations. For example, if an AS is unwilling to carry traffic    to another AS, it can enforce a policy prohibiting this. The    following are examples of routing policies that can be enforced with    the use of BGP: 
  184.  
  185.      1.  A multihomed AS can refuse to act as a transit AS for other          AS's.  (It does so by only advertising routes to destinations          internal to the AS.) 
  186.  
  187.      2.  A multihomed AS can become a transit AS for a restricted set of          adjacent AS's, i.e., some, but not all, AS's can use the          multihomed AS as a transit AS. (It does so by advertising its          routing information to this set of AS's.) 
  188.  
  189.      3.  An AS can favor or disfavor the use of certain AS's for          carrying transit traffic from itself. 
  190.  
  191.    A number of performance-related criteria can be controlled with the    use of BGP: 
  192.  
  193.      1.  An AS can minimize the number of transit AS's. (Shorter AS          paths can be preferred over longer ones.) 
  194.  
  195.      2.  The quality of transit AS's. If an AS determines that two or          more AS paths can be used to reach a given destination, that AS          can use a variety of means to decide which of the candidate AS 
  196.  
  197.  
  198.  
  199. Rekhter & Gross                                                 [Page 7] 
  200.  RFC 1772                   BGP-4 Application                  March 1995 
  201.  
  202.           paths it will use. The quality of an AS can be measured by such          things as diameter, link speed, capacity, tendency to become          congested, and quality of operation. Information about these          qualities might be determined by means other than BGP. 
  203.  
  204.      3.  Preference of internal routes over external routes. 
  205.  
  206.    For consistency within an AS, equal cost paths, resulting from    combinations of policies and/or normal route selection procedures,    must be resolved in a consistent fashion. 
  207.  
  208.    Fundamental to BGP is the rule that an AS advertises to its    neighboring AS's only those routes that it uses. This rule reflects    the "hop-by-hop" routing paradigm generally used by the current    Internet. 
  209.  
  210. 6. Path Selection with BGP 
  211.  
  212.    One of the major tasks of a BGP speaker is to evaluate different    paths from itself to a set of destination covered by an address    prefix, select the best one, apply appropriate policy constraints,    and then advertise it to all of its BGP neighbors. The key issue is    how different paths are evaluated and compared.  In traditional    distance vector protocols (e.g., RIP) there is only one metric (e.g.,    hop count) associated with a path. As such, comparison of different    paths is reduced to simply comparing two numbers. A complication in    Inter-AS routing arises from the lack of a universally agreed-upon    metric among AS's that can be used to evaluate external paths.    Rather, each AS may have its own set of criteria for path evaluation. 
  213.  
  214.    A BGP speaker builds a routing database consisting of the set of all    feasible paths and the list of destinations (expressed as address    prefixes) reachable through each path.  For purposes of precise    discussion, it's useful to consider the set of feasible paths for a    set of destinations associated with a given address prefix. In most    cases, we would expect to find only one feasible path. However, when    this is not the case, all feasible paths should be maintained, and    their maintenance speeds adaptation to the loss of the primary path.    Only the primary path at any given time will ever be advertised. 
  215.  
  216.    The path selection process can be formalized by defining a complete    order over the set of all feasible paths to a set of destinations    associated with a given address prefix.  One way to define this    complete order is to define a function that maps each full AS path to    a non-negative integer that denotes the path's degree of preference.    Path selection is then reduced to applying this function to all    feasible paths and choosing the one with the highest degree of    preference. 
  217.  
  218.  
  219.  
  220. Rekhter & Gross                                                 [Page 8] 
  221.  RFC 1772                   BGP-4 Application                  March 1995 
  222.  
  223.     In actual BGP implementations, the criteria for assigning degree of    preferences to a path are specified as configuration information. 
  224.  
  225.    The process of assigning a degree of preference to a path can be    based on several sources of information: 
  226.  
  227.      1.  Information explicitly present in the full AS path. 
  228.  
  229.      2.  A combination of information that can be derived from the full          AS path and information outside the scope of BGP (e.g., policy          routing constraints provided as configuration information). 
  230.  
  231.    Possible criteria for assigning a degree of preference to a path are: 
  232.  
  233.        - AS count. Paths with a smaller AS count are generally better. 
  234.  
  235.        - Policy considerations. BGP supports policy-based routing based          on the controlled distribution of routing information.  A BGP          speaker may be aware of some policy constraints (both within          and outside of its own AS) and do appropriate path selection.          Paths that do not comply with policy requirements are not          considered further. 
  236.  
  237.        - Presence or absence of a certain AS or AS's in the path. By          means of information outside the scope of BGP, an AS may know          some performance characteristics (e.g., bandwidth, MTU, intra-          AS diameter) of certain AS's and may try to avoid or prefer          them. 
  238.  
  239.        - Path origin. A path learned entirely from BGP (i.e., whose          endpoint is internal to the last AS on the path) is generally          better than one for which part of the path was learned via EGP          or some other means. 
  240.  
  241.        - AS path subsets. An AS path that is a subset of a longer AS          path to the same destination should be preferred over the          longer path.  Any problem in the shorter path (such as an          outage) will also be a problem in the longer path. 
  242.  
  243.        - Link dynamics. Stable paths should be preferred over unstable          ones. Note that this criterion must be used in a very careful          way to avoid causing unnecessary route fluctuation. Generally,          any criteria that depend on dynamic information might cause          routing instability and should be treated very carefully. 
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251. Rekhter & Gross                                                 [Page 9] 
  252.  RFC 1772                   BGP-4 Application                  March 1995 
  253.  
  254.  7. Required set of supported routing policies 
  255.  
  256. Policies are provided to BGP in the form of configuration information.  This information is not directly encoded in the protocol. Therefore, BGP can provide support for very complex routing policies. However, it is not required that all BGP implementations support such policies. 
  257.  
  258. We are not attempting to standardize the routing policies that must be supported in every BGP implementation; we strongly encourage all implementors to support the following set of routing policies: 
  259.  
  260.      1.  BGP implementations should allow an AS to control announcements          of BGP-learned routes to adjacent AS's.  Implementations should          also support such control with at least the granularity of a          single address prefix.  Implementations should also support          such control with the granularity of an autonomous system,          where the autonomous system may be either the autonomous system          that originated the route, or the autonomous system that          advertised the route to the local system (adjacent autonomous          system).  Care must be taken when a BGP speaker selects a new          route that can't be announced to a particular external peer,          while the previously selected route was announced to that peer.          Specifically, the local system must explicitly indicate to the          peer that the previous route is now infeasible. 
  261.  
  262.      2.  BGP implementations should allow an AS to prefer a particular          path to a destination (when more than one path is available).          At the minimum an implementation shall support this          functionality by allowing to administratively assign a degree          of preference to a route based solely on the IP address of the          neighbor the route is received from. The allowed range of the          assigned degree of preference shall be between 0 and 2^(31) -          1. 
  263.  
  264.      3.  BGP implementations should allow an AS to ignore routes with          certain AS's in the AS_PATH path attribute.  Such function can          be implemented by using the technique outlined in [2], and by          assigning "infinity" as "weights" for such AS's. The route          selection process must ignore routes that have "weight" equal          to "infinity". 
  265.  
  266. 8. Interaction with other exterior routing protocols 
  267.  
  268.    The guidelines suggested in this section are consistent with the    guidelines presented in [3]. 
  269.  
  270.  
  271.  
  272.  
  273.  
  274. Rekhter & Gross                                                [Page 10] 
  275.  RFC 1772                   BGP-4 Application                  March 1995 
  276.  
  277.     An AS should advertise a minimal aggregate for its internal    destinations with respect to the amount of address space that it is    actually using.  This can be used by administrators of non-BGP 4 AS's    to determine how many routes to explode from a single aggregate. 
  278.  
  279.    A route that carries the ATOMIC_AGGREGATE path attribute shall not be    exported into either BGP-3 or EGP2, unless such an exportation can be    accomplished without exploding the NLRI of the route. 
  280.  
  281. 8.1 Exchanging information with EGP2 
  282.  
  283.    This document suggests the following guidelines for exchanging    routing information between BGP-4 and EGP2. 
  284.  
  285.    To provide for graceful migration, a BGP speaker may participate in    EGP2, as well as in BGP-4. Thus, a BGP speaker may receive IP    reachability information by means of EGP2 as well as by means of    BGP-4.  The information received by EGP2 can be injected into BGP-4    with the ORIGIN path attribute set to 1.  Likewise,  the information    received via BGP-4 can be injected into EGP2 as well. In the latter    case, however, one needs to be aware of the potential information    explosion when a given IP prefix received from BGP-4 denotes a set of    consecutive A/B/C class networks.  Injection of BGP-4 received NLRI    that denotes IP subnets requires the BGP speaker to inject the    corresponding network into EGP2.  The local system shall provide    mechanisms to control the exchange of reachability information    between EGP2 and BGP-4.  Specifically, a conformant implementation is    required to support all of the following options when injecting BGP-4    received reachability information into EGP2: 
  286.  
  287.        - inject default only (0.0.0.0); no export of any other NLRI 
  288.  
  289.        - allow controlled deaggregation, but only of specific routes;          allow export of non-aggregated NLRI 
  290.  
  291.        - allow export of only non-aggregated NLRI 
  292.  
  293.    The exchange of routing information via EGP2 between a BGP speaker    participating in BGP-4 and a pure EGP2 speaker may occur  only at the    domain (autonomous system) boundaries. 
  294.  
  295. 8.2 Exchanging information with BGP-3 
  296.  
  297.    This document suggests the following guidelines for exchanging    routing information between BGP-4 and BGP-3. 
  298.  
  299.    To provide for graceful migration, a BGP speaker may participate in    BGP-3, as well as in BGP-4. Thus, a BGP speaker may receive IP 
  300.  
  301.  
  302.  
  303. Rekhter & Gross                                                [Page 11] 
  304.  RFC 1772                   BGP-4 Application                  March 1995 
  305.  
  306.     reachability information by means of BGP-3, as well as by means of    BGP-4. 
  307.  
  308.    A BGP speaker may inject the information received by BGP-4 into BGP-3    as follows. 
  309.  
  310.    If an AS_PATH attribute of a BGP-4 route carries AS_SET path    segments, then the AS_PATH attribute of the BGP-3 route shall be    constructed by treating the AS_SET segments as AS_SEQUENCE segments,    with the resulting AS_PATH being a single AS_SEQUENCE. While this    procedure loses set/sequence information, it doesn't affect    protection for routing loops suppression, but may affect policies, if    the policies are based on the content or ordering of the AS_PATH    attribute. 
  311.  
  312.    While injecting BGP-4 derived NLRI into BGP-3, one needs to be aware    of the potential information explosion when a given IP prefix denotes    a set of consecutive A/B/C class networks. Injection of BGP-4 derived    NLRI that denotes IP subnets requires the BGP speaker to inject the    corresponding network into BGP-3. The local system shall provide    mechanisms to control the exchange of routing information between    BGP-3 and BGP-4.  Specifically, a conformant implementation is    required to support all of the following options when injecting BGP-4    received routing information into BGP-3: 
  313.  
  314.        - inject default only (0.0.0.0), no export of any other NLRI 
  315.  
  316.        - allow controlled deaggregation, but only of specific routes;          allow export of non-aggregated NLRI 
  317.  
  318.        - allow export of only non-aggregated NLRI 
  319.  
  320.    The exchange of routing information via BGP-3 between a BGP speaker    participating in BGP-4 and a pure BGP-3 speaker may occur  only at    the autonomous system boundaries. Within a single autonomous system    BGP conversations between all the BGP speakers of that autonomous    system have to be either BGP-3 or BGP-4, but not a mixture. 
  321.  
  322. 9. Operations over Switched Virtual Circuits 
  323.  
  324.    When using BGP over Switched Virtual Circuit (SVC) subnetworks it may    be desirable to minimize traffic generated by BGP. Specifically, it    may be desirable to eliminate traffic associated with periodic    KEEPALIVE messages.  BGP includes a mechanism for operation over    switched virtual circuit (SVC) services which avoids keeping SVCs    permanently open and allows it to eliminates periodic sending of    KEEPALIVE messages. 
  325.  
  326.  
  327.  
  328.  Rekhter & Gross                                                [Page 12] 
  329.  RFC 1772                   BGP-4 Application                  March 1995 
  330.  
  331.     This section describes how to operate without periodic KEEPALIVE    messages to minimise SVC usage when using an intelligent SVC circuit    manager.  The proposed scheme may also be used on "permanent"    circuits, which support a feature like link quality monitoring or    echo request to determine the status of link connectivity. 
  332.  
  333.    The mechanism described in this section is suitable only between the    BGP speakers that are directly connected over a common virtual    circuit. 
  334.  
  335. 9.1 Establishing a BGP Connection 
  336.  
  337.    The feature is selected by specifying zero Hold Time in the OPEN    message. 
  338.  
  339. 9.2 Circuit Manager Properties 
  340.  
  341.    The circuit manager must have sufficient functionality to be able to    compensate for the lack of periodic KEEPALIVE messages: 
  342.  
  343.        - It must be able to determine link layer unreachability in a          predictable finite period of a failure occurring. 
  344.  
  345.        - On determining unreachability it should: 
  346.  
  347.                 - start a configurable dead timer (comparable to a                   typical Hold timer value). 
  348.  
  349.                 - attempt to re-establish the Link Layer connection. 
  350.  
  351.         - If the dead timer expires it should: 
  352.  
  353.                 - send an internal circuit DEAD indication to TCP. 
  354.  
  355.        - If the connection is re-established it should: 
  356.  
  357.                 - cancel the dead timer. 
  358.  
  359.                 - send an internal circuit UP indication to TCP. 
  360.  
  361. 9.3 TCP Properties 
  362.  
  363.    A small modification must be made to TCP to process internal    notifications from the circuit manager: 
  364.  
  365.        - DEAD: Flush transmit queue and abort TCP connection. 
  366.  
  367.  
  368.  
  369.  Rekhter & Gross                                                [Page 13] 
  370.  RFC 1772                   BGP-4 Application                  March 1995 
  371.  
  372.         - UP: Transmit any queued data or allow an outgoing TCP call to          proceed. 
  373.  
  374. 9.4 Combined Properties 
  375.  
  376.    Some implementations may not be able to guarantee that the BGP    process and the circuit manager will operate as a single entity; i.e.    they can have a separate existence when the other has been stopped or    has crashed. 
  377.  
  378.    If this is the case, a periodic two-way poll between the BGP process    and the circuit manager should be implemented.  If the BGP process    discovers the circuit manager has gone away it should close all    relevant TCP connections.  If the circuit manager discovers the BGP    process has gone away it should close all its connections associated    with the BGP process and reject any further incoming connections. 
  379.  
  380. 10. Conclusion 
  381.  
  382.    The BGP protocol provides a high degree of control and flexibility    for doing interdomain routing while enforcing policy and performance    constraints and avoiding routing loops. The guidelines presented here    will provide a starting point for using BGP to provide more    sophisticated and manageable routing in the Internet as it grows. 
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410. Rekhter & Gross                                                [Page 14] 
  411.  RFC 1772                   BGP-4 Application                  March 1995 
  412.  
  413.  Appendix A. The Interaction of BGP and an IGP 
  414.  
  415.    This section outlines methods by which BGP can exchange routing    information with an IGP. The methods outlined here are not proposed    as part of the standard BGP usage at this time.  These methods are    outlined for information purposes only.  Implementors may want to    consider these methods when importing IGP information. 
  416.  
  417.    This is general information that applies to any generic IGP. 
  418.  
  419.    Interaction between BGP and any specific IGP is outside the scope of    this section.  Methods for specific IGP's should be proposed in    separate documents.  Methods for specific IGP's could be proposed for    standard usage in the future. 
  420.  
  421. Overview 
  422.  
  423.    By definition, all transit AS's must be able to carry traffic which    originates from and/or is destined to locations outside of that AS.    This requires a certain degree of interaction and coordination    between BGP and the Interior Gateway Protocol (IGP) used by that    particular AS. In general, traffic originating outside of a given AS    is going to pass through both interior gateways (gateways that    support the IGP only) and border gateways (gateways that support both    the IGP and BGP). All interior gateways receive information about    external routes from one or more of the border gateways of the AS via    the IGP. 
  424.  
  425.    Depending on the mechanism used to propagate BGP information within a    given AS, special care must be taken to ensure consistency between    BGP and the IGP, since changes in state are likely to propagate at    different rates across the AS. There may be a time window between the    moment when some border gateway (A) receives new BGP routing    information which was originated from another border gateway (B)    within the same AS, and the moment the IGP within this AS is capable    of routing transit traffic to that border gateway (B). During that    time window, either incorrect routing or "black holes" can occur. 
  426.  
  427.    In order to minimize such routing problems, border gateway (A) should    not advertise to any of its external peers a route to some set of    exterior destinations associated with a given address prefix X via    border gateway (B) until all the interior gateways within the AS are    ready to route traffic destined to these destinations via the correct    exit border gateway (B). In other words, interior routing should    converge on the proper exit gateway before/advertising routes via    that exit gateway to external peers. 
  428.  
  429.  
  430.  
  431.  
  432.  
  433. Rekhter & Gross                                                [Page 15] 
  434.  RFC 1772                   BGP-4 Application                  March 1995 
  435.  
  436.  A.2 Methods for Achieving Stable Interactions 
  437.  
  438.    The following discussion outlines several techniques capable of    achieving stable interactions between BGP and the IGP within an    Autonomous System. 
  439.  
  440. A.2.1 Propagation of BGP Information via the IGP 
  441.  
  442.    While BGP can provide its own mechanism for carrying BGP information    within an AS, one can also use an IGP to transport this information,    as long as the IGP supports complete flooding of routing information    (providing the mechanism to distribute the BGP information) and one    pass convergence (making the mechanism effectively atomic). If an IGP    is used to carry BGP information, then the period of    desynchronization described earlier does not occur at all, since BGP    information propagates within the AS synchronously with the IGP, and    the IGP converges more or less simultaneously with the arrival of the    new routing information. Note that the IGP only carries BGP    information and should not interpret or process this information. 
  443.  
  444. A.2.2  Tagged Interior Gateway Protocol 
  445.  
  446.    Certain IGPs can tag routes exterior to an AS with the identity of    their exit points while propagating them within the AS. Each border    gateway should use identical tags for announcing exterior routing    information (received via BGP) both into the IGP and when propagating    this information to other internal peers (peers within the same AS).    Tags generated by a border gateway must uniquely identify that    particular border gateway--different border gateways must use    different tags. 
  447.  
  448.    All Border Gateways within a single AS must observe the following two    rules: 
  449.  
  450.      1.  Information received from an internal peer by a border gateway          A declaring a set of destination associated with a given          address prefix to be unreachable must immediately be propagated          to all of the external peers of A. 
  451.  
  452.      2.  Information received from an internal peer by a border gateway          A about a set of reachable destinations associated with a given          address prefix X cannot be propagated to any of the external          peers of A unless/until A has an IGP route to the set of          destinations covered by X and both the IGP and the BGP routing          information have identical tags. 
  453.  
  454.    These rules guarantee that no routing information is announced    externally unless the IGP is capable of correctly supporting it. It 
  455.  
  456.  
  457.  
  458. Rekhter & Gross                                                [Page 16] 
  459.  RFC 1772                   BGP-4 Application                  March 1995 
  460.  
  461.     also avoids some causes of "black holes". 
  462.  
  463.    One possible method for tagging BGP and IGP routes within an AS is to    use the IP address of the exit border gateway announcing the exterior    route into the AS. In this case the "gateway" field in the BGP UPDATE    message is used as the tag. 
  464.  
  465.    An alternate method for tagging BGP and IGP routes is to have BGP and    the IGP agree on a router ID.  In this case, the router ID is    available to all BGP (version 3 or higher) speakers.  Since this ID    is already unique it can be used directly as the tag in the IGP. 
  466.  
  467. A.2.3 Encapsulation 
  468.  
  469.    Encapsulation provides the simplest (in terms of the interaction    between the IGP and BGP) mechanism for carrying transit traffic    across the AS. In this approach, transit traffic is encapsulated    within an IP datagram addressed to the exit gateway. The only    requirement imposed on the IGP by this approach is that it should be    capable of supporting routing between border gateways within the same    AS. 
  470.  
  471.    The address of the exit gateway A for some exterior destination X is    specified in the BGP identifier field of the BGP OPEN message    received from gateway A (via BGP) by all other border gateways within    the same AS. In order to route traffic to destination X, each border    gateway within the AS encapsulates it in datagrams addressed to    gateway A. Gateway A then performs decapsulation and forwards the    original packet to the proper gateway in another AS. 
  472.  
  473.    Since encapsulation does not rely on the IGP to carry exterior    routing information, no synchronization between BGP and the IGP is    required. 
  474.  
  475.    Some means of identifying datagrams containing encapsulated IP, such    as an IP protocol type code, must be defined if this method is to be    used. 
  476.  
  477.    Note that, if a packet to be encapsulated has length that is very    close to the MTU, that packet would be fragmented at the gateway that    performs encapsulation. 
  478.  
  479. A.2.4  Pervasive BGP 
  480.  
  481.    If all routers in an AS are BGP speakers, then there is no need to    have any interaction between BGP and an IGP.  In such cases, all    routers in the AS already have full information of all BGP routes.    The IGP is then only used for routing within the AS, and no BGP 
  482.  
  483.  
  484.  
  485. Rekhter & Gross                                                [Page 17] 
  486.  RFC 1772                   BGP-4 Application                  March 1995 
  487.  
  488.     routes are imported into the IGP. 
  489.  
  490.    For routers to operate in this fashion, they must be able to perform    a recursive lookup in their routing table.  The first lookup will use    a BGP route to establish the exit router, while the second lookup    will determine the IGP path to the exit router. 
  491.  
  492.    Since the IGP carries no external information in this scenario, all    routers in the AS will have converged as soon as all BGP speakers    have new information about this route.  Since there is no need to    delay for the IGP to converge, an implementation may advertise these    routes without further delay due to the IGP. 
  493.  
  494. A.2.5  Other Cases 
  495.  
  496.    There may be AS's with IGPs which can neither carry BGP information    nor tag exterior routes (e.g., RIP). In addition, encapsulation may    be either infeasible or undesirable. In such situations, the    following two rules must be observed: 
  497.  
  498.      1.  Information received from an internal peer by a border gateway          A declaring a destination to be unreachable must immediately be          propagated to all of the external peers of A. 
  499.  
  500.      2.  Information received from an internal peer by a border gateway          A about a reachable destination X cannot be propagated to any          of the external peers of A unless A has an IGP route to X and          sufficient time has passed for the IGP routes to have          converged. 
  501.  
  502.    The above rules present necessary (but not sufficient) conditions for    propagating BGP routing information to other AS's. In contrast to    tagged IGPs, these rules cannot ensure that interior routes to the    proper exit gateways are in place before propagating the routes to    other AS's. 
  503.  
  504.    If the convergence time of an IGP is less than some small value X,    then the time window during which the IGP and BGP are unsynchronized    is less than X as well, and the whole issue can be ignored at the    cost of transient periods (of less than length X) of routing    instability. A reasonable value for X is a matter for further study,    but X should probably be less than one second. 
  505.  
  506.    If the convergence time of an IGP cannot be ignored, a different    approach is needed. Mechanisms and techniques which might be    appropriate in this situation are subjects for further study. 
  507.  
  508.  
  509.  
  510.  
  511.  
  512. Rekhter & Gross                                                [Page 18] 
  513.  RFC 1772                   BGP-4 Application                  March 1995 
  514.  
  515.  References 
  516.  
  517.    [1] Rekhter Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4), RFC        1771, T.J. Watson Research Center, IBM Corp., cisco Systems,        March 1995. 
  518.  
  519.    [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,        Merit/NSFNET, June 1989. 
  520.  
  521.    [3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:  an        Address Assignment and Aggregation Strategy", RFC1519, BARRNet,        cisco, MERIT, OARnet, September 1993. 
  522.  
  523. Security Considerations 
  524.  
  525.    Security issues are not discussed in this memo. 
  526.  
  527. Authors' Addresses 
  528.  
  529.    Yakov Rekhter    T.J. Watson Research Center IBM Corporation    P.O. Box 704, Office H3-D40    Yorktown Heights, NY 10598 
  530.  
  531.    Phone: +1 914 784 7361    EMail: yakov@watson.ibm.com 
  532.  
  533.     Phill Gross    MCI Data Services Division    2100 Reston Parkway, Room 6001,    Reston, VA 22091 
  534.  
  535.    Phone: +1 703 715 7432    EMail: 0006423401@mcimail.com 
  536.  
  537.     IETF IDR WG mailing list: bgp@ans.net    To be added: bgp-request@ans.net 
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  Rekhter & Gross                                                [Page 19] 
  550.  
  551.