A Border Gateway Protocol 4 (BGP-4)
RFC 1654
Document | Type |
RFC - Proposed Standard
(July 1994; No errata)
Obsoleted by RFC 1771
Was draft-ietf-bgp-bgp4 (idr WG)
|
|
---|---|---|---|
Authors | Yakov Rekhter , Tony Li | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1654 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group Y. Rekhter Request for Comments: 1654 T.J. Watson Research Center, IBM Corp. Category: Standards Track T. Li cisco Systems Editors July 1994 A Border Gateway Protocol 4 (BGP-4) Status of this Memo 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. 1. Acknowledgements This document was originally published as RFC 1267 in October 1991, jointly authored by Kirk Lougheed (cisco Systems) and Yakov Rekhter (IBM). We would like to express our thanks to Guy Almes (Rice University), Len Bosack (cisco Systems), and Jeffrey C. Honig (Cornell University) for their contributions to the earlier version of this document. We like to explicitly thank Bob Braden (ISI) for the review of the earlier version of this document as well as his constructive and valuable comments. 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 BGP 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 (BBN) and to Charles Kunzinger (IBM Corp.) who was the IDRP editor within that group. We would also like to thank Mike Craren (Proteon, Inc.), Dimitry Haskin (Wellfleet), John Krawczyk (Wellfleet), and Paul Traina (cisco) for Rekhter & Li [Page 1] RFC 1654 BGP-4 July 1994 their insightful comments. We would like to specially acknowledge numerous contributions by Dennis Ferguson (ANS). 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 rule 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 toShow full document text