Network Working Group                                      Y. RekhterINTERNET DRAFT                                          cisco Systems                                                                T. Li                                               Procket Networks, Inc.                                                              Editors                  A Border Gateway Protocol 4 (BGP-4)                      <draft-ietf-idr-bgp4-10.txt>Status of this Memo   This document is an Internet-Draft and is in full conformance with   all provisions of Section 10 of RFC2026.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF), its areas, and its working groups.  Note that   other groups may also distribute working documents as Internet-   Drafts.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time.  It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as ``work in progress.''   The list of current Internet-Drafts can be accessed at   http://www.ietf.org/ietf/1id-abstracts.txt   The list of Internet-Draft Shadow Directories can be accessed at   http://www.ietf.org/shadow.html.1. Acknowledgments   This document was originally published as RFC 1267 in October 1991,   jointly authored by Kirk Lougheed and Yakov Rekhter.   We would like to express our thanks to Guy Almes, Len Bosack, and   Jeffrey C. Honig for their contributions to the earlier version of   this document.   We like to explicitly thank Bob Braden for the review of the earlier   version of this document as well as his constructive and valuable   comments.Expiration Date October 2000                                    [Page 1]RFC DRAFT                                                     April 2000   We would also like to thank Bob Hinden, Director for Routing of the   Internet Engineering Steering Group, and the team of reviewers he   assembled to review the previous version (BGP-2) of this document.   This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia   Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted   with a strong combination of toughness, professionalism, and   courtesy.   This updated version of the document is the product of the IETF IDR   Working Group with Yakov Rekhter and Tony Li as editors. Certain   sections of the document borrowed heavily from IDRP [7], which is the   OSI counterpart of BGP. For this credit should be given to the ANSI   X3S3.3 group chaired by Lyman Chapin and to Charles Kunzinger who was   the IDRP editor within that group.  We would also like to thank Mike   Craren, Dimitry Haskin, John Krawczyk, David LeRoy, John Scudder,   John Stewart III, Dave Thaler, Paul Traina, and Curtis Villamizar for   their comments.   We would like to specially acknowledge numerous contributions by   Dennis Ferguson.2.  Introduction   The Border Gateway Protocol (BGP) is an inter-Autonomous System   routing protocol.  It is built on experience gained with EGP as   defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as   described in RFC 1092 [2] and RFC 1093 [3].   The primary function of a BGP speaking system is to exchange network   reachability information with other BGP systems.  This network   reachability information includes information on the list of   Autonomous Systems (ASs) that reachability information traverses.   This information is sufficient to construct a graph of AS   connectivity from which routing loops may be pruned and some policy   decisions at the AS level may be enforced.   BGP-4 provides a new set of mechanisms for supporting classless   interdomain routing.  These mechanisms include support for   advertising an IP prefix and eliminates the concept of network   "class" within BGP.  BGP-4 also introduces mechanisms which allow   aggregation of routes, including aggregation of AS paths.  These   changes provide support for the proposed supernetting scheme [8, 9].   To characterize the set of policy decisions that can be enforced   using BGP, one must focus on the rule that a BGP speaker advertise to   its peers (other BGP speakers which it communicates with) in   neighboring ASs only those routes that it itself uses.  This ruleExpiration Date October 2000                                    [Page 2]RFC DRAFT                                                     April 2000   reflects the "hop-by-hop" routing paradigm generally used throughout   the current Internet.  Note that some policies cannot be supported by   the "hop-by-hop" routing paradigm and thus require techniques such as   source routing to enforce.  For example, BGP does not enable one AS   to send traffic to a neighboring AS intending that the traffic take a   different route from that taken by traffic originating in the   neighboring AS.  On the other hand, BGP can support any policy   conforming to the "hop-by-hop" routing paradigm.  Since the current   Internet uses only the "hop-by-hop" routing paradigm and since BGP   can support any policy that conforms to that paradigm, BGP is highly   applicable as an inter-AS routing protocol for the current Internet.   A more complete discussion of what policies can and cannot be   enforced with BGP is outside the scope of this document (but refer to   the companion document discussing BGP usage [5]).   BGP runs over a reliable transport protocol.  This eliminates the   need to implement explicit update fragmentation, retransmission,   acknowledgment, and sequencing.  Any authentication scheme used by   the transport protocol may be used in addition to BGP's own   authentication mechanisms.  The error notification mechanism used in   BGP assumes that the transport protocol supports a "graceful" close,   i.e., that all outstanding data will be delivered before the   connection is closed.   BGP uses TCP [4] as its transport protocol.  TCP meets BGP's   transport requirements and is present in virtually all commercial   routers and hosts.  In the following descriptions the phrase   "transport protocol connection" can be understood to refer to a TCP   connection.  BGP uses TCP port 179 for establishing its connections.   This document uses the term `Autonomous System' (AS) throughout.  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 ASs.  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 ASs to have a   single coherent interior routing plan and presents a consistent   picture of what destinations are reachable through it.   The planned use of BGP in the Internet environment, including such   issues as topology, the interaction between BGP and IGPs, and the   enforcement of routing policy rules is presented in a companion   document [5].  This document is the first of a series of documentsExpiration Date October 2000                                    [Page 3]RFC DRAFT                                                     April 2000   planned to explore various aspects of BGP application.  Please send   comments to the BGP mailing list (bgp@ans.net).3.  Summary of Operation   Two systems form a transport protocol connection between one another.   They exchange messages to open and confirm the connection parameters.   The initial data flow is the entire BGP routing table.  Incremental   updates are sent as the routing tables change.  BGP does not require   periodic refresh of the entire BGP routing table.  Therefore, a BGP   speaker must retain the current version of the entire BGP routing   tables of all of its peers for the duration of the connection.   KEEPALIVE messages are sent periodically to ensure the liveness of   the connection.  NOTIFICATION messages are sent in response to errors   or special conditions.  If a connection encounters an error   condition, a NOTIFICATION message is sent and the connection is   closed.   The hosts executing the Border Gateway Protocol need not be routers.   A non-routing host could exchange routing information with routers   via EGP or even an interior routing protocol.  That non-routing host   could then use BGP to exchange routing information with a border   router in another Autonomous System.  The implications and   applications of this architecture are for further study.   Connections between BGP speakers of different ASs are referred to as   "external" links.  BGP connections between BGP speakers within the   same AS are referred to as "internal" links.  Similarly, a peer in a   different AS is referred to as an external peer, while a peer in the   same AS may be described as an internal peer.  Internal BGP and   external BGP are commonly abbreviated IBGP and EBGP.   If a particular AS has multiple BGP speakers and is providing transit   service for other ASs, then care must be taken to ensure a consistent   view of routing within the AS.  A consistent view of the interior   routes of the AS is provided by the interior routing protocol.  A   consistent view of the routes exterior to the AS can be provided by   having all BGP speakers within the AS maintain direct IBGP   connections with each other.  Alternately the interior routing   protocol can pass BGP information among routers within an AS, taking   care not to lose BGP attributes that will be needed by EBGP speakers   if transit connectivity is being provided.  For the purpose of   discussion, it is assumed that BGP information is passed within an AS   using IBGP.  Care must be taken to ensure that the interior routers   have all been updated with transit information before the EBGP   speakers announce to other ASs that transit service is being   provided.Expiration Date October 2000                                    [Page 4]RFC DRAFT                                                     April 20003.1 Routes: Advertisement and Storage   For purposes of this protocol a route is defined as a unit of   information that pairs a destination with the attributes of a path to   that destination:      - Routes are advertised between a pair of BGP speakers in UPDATE      messages:  the destination is the systems whose IP addresses are      reported in the Network Layer Reachability Information (NLRI)      field, and the the path is the information reported in the path      attributes fields of the same UPDATE message.      - Routes are stored in the Routing Information Bases (RIBs):      namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes      that will be advertised to other BGP speakers must be present in      the Adj-RIB-Out; routes that will be used by the local BGP speaker      must be present in the Loc-RIB, and the next hop for each of these      routes must be present in the local BGP speaker's forwarding      information base; and routes that are received from other BGP      speakers are present in the Adj-RIBs-In.   If a BGP speaker chooses to advertise the route, it may add to or   modify the path attributes of the route before advertising it to a   peer.   BGP provides mechanisms by which a BGP speaker can inform its peer   that a previously advertised route is no longer available for use.   There are three methods by which a given BGP speaker can indicate   that a route has been withdrawn from service:      a) the IP prefix that expresses destinations for a previously      advertised route can be advertised in the WITHDRAWN ROUTES field      in the UPDATE message, thus marking the associated route as being      no longer available for use      b) a replacement route with the same Network Layer Reachability      Information can be advertised, or      c) the BGP speaker - BGP speaker connection can be closed, which      implicitly removes from service all routes which the pair of      speakers had advertised to each other.Expiration Date October 2000                                    [Page 5]RFC DRAFT                                                     April 20003.2 Routing Information Bases   The Routing Information Base (RIB) within a BGP speaker consists of   three distinct parts:      a) Adj-RIBs-In: The Adj-RIBs-In store routing information that has      been learned from inbound UPDATE messages. Their contents      represent routes that are available as an input to the Decision      Process.      b) Loc-RIB: The Loc-RIB contains the local routing information      that the BGP speaker has selected by applying its local policies      to the routing information contained in its Adj-RIBs-In.      c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the      local BGP speaker has selected for advertisement to its peers. The      routing information stored in the Adj-RIBs-Out will be carried in      the local BGP speaker's UPDATE messages and advertised to its      peers.   In summary, the Adj-RIBs-In contain unprocessed routing information   that has been advertised to the local BGP speaker by its peers; the   Loc-RIB contains the routes that have been selected by the local BGP   speaker's Decision Process; and the Adj-RIBs-Out organize the routes   for advertisement to specific peers by means of the local speaker's   UPDATE messages.   Although the conceptual model distinguishes between Adj-RIBs-In,   Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an   implementation must maintain three separate copies of the routing   information. The choice of implementation (for example, 3 copies of   the information vs 1 copy with pointers) is not constrained by the   protocol.4.  Message Formats   This section describes message formats used by BGP.   Messages are sent over a reliable transport protocol connection.  A   message is processed only after it is entirely received.  The maximum   message size is 4096 octets.  All implementations are required to   support this maximum message size.  The smallest message that may be   sent consists of a BGP header without a data portion, or 19 octets.