Network Working Group Y. Rekhter, Editor
Request for Comments: 1266 T.J. Watson Research Center, IBM Corp.
Experience with the BGP Protocol
1. Status of this Memo.
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
The purpose of this memo is to document how the requirements for
advancing a routing protocol to Draft Standard have been satisfied by
Border Gateway Protocol (BGP). This report documents experience with
BGP. This is the second of two reports on the BGP protocol. As
required by the Internet Activities Board (IAB) and the Internet
Engineering Steering Group (IESG), the first report will present a
performance analysis of the BGP protocol.
The remaining sections of this memo document how BGP satisfies
General Requirements specified in Section 3.0, as well as
Requirements for Draft Standard specified in Section 5.0 of the
"Internet Routing Protocol Standardization Criteria" document .
This report is based on the work of Dennis Ferguson (University of
Toronto), Susan Hares (MERIT/NSFNET), and Jessica Yu (MERIT/NSFNET).
Details of their work were presented at the Twentieth IETF meeting
(March 11-15, 1991, St. Louis) and are available from the IETF
Please send comments to email@example.com.
The BGP protocol has been developed by the IWG/BGP Working Group of
the Internet Engineering Task Force. We would like to express our
deepest thanks to Guy Almes (Rice University) who was the previous
chairman of the IWG Working Group. We also like to explicitly thank
Bob Hinden (BBN) for the review of this document as well as his
constructive and valuable comments.
BGP Working Group [Page 1]RFC 1266 Experience with the BGP Protocol October 19914. Documentation.
BGP is an inter-autonomous system routing protocol designed for the
TCP/IP internets. Version 1 of the BGP protocol was published in RFC
1105. Since then BGP Versions 2 and 3 have been developed. Version 2
was documented in RFC 1163. Version 3 is documented in . The
changes between versions 1, 2 and 3 are explained in Appendix 3 of
. Most of the functionality that was present in the Version 1 is
present in the Version 2 and 3. Changes between Version 1 and
Version 2 affect mostly the format of the BGP messages. Changes
between Version 2 and Version 3 are quite minor.
BGP Version 2 removed from the protocol the concept of "up", "down",
and "horizontal" relations between autonomous systems that were
present in the Version 1. BGP Version 2 introduced the concept of
path attributes. In addition, BGP Version 2 clarified parts of the
protocol that were "underspecified". BGP Version 3 lifted some of
the restrictions on the use of the NEXT_HOP path attribute, and added
the BGP Identifier field to the BGP OPEN message. It also clarifies
the procedure for distributing BGP routes between the BGP speakers
within an autonomous system. Possible applications of BGP in the
Internet are documented in .
The BGP protocol was developed by the IWG/BGP Working Group of the
Internet Engineering Task Force. This Working Group has a mailing
list, firstname.lastname@example.org, where discussions of protocol features and
operation are held. The IWG/BGP Working Group meets regularly during
the quarterly Internet Engineering Task Force conferences. Reports of
these meetings are published in the IETF's Proceedings.
A BGP Management Information Base has been published . The MIB
was written by Steve Willis (email@example.com) and John Burruss
Apart from a few system variables, the BGP MIB is broken into two
tables: the BGP Peer Table and the BGP Received Path Attribute Table.
The Peer Table reflects information about BGP peer connections, such
as their state and current activity. The Received Path Attribute
Table contains all attributes received from all peers before local
routing policy has been applied. The actual attributes used in
determining a route are a subset of the received attribute table.
The BGP MIB is quite small. It contains total of 27 objects.
BGP Working Group [Page 2]RFC 1266 Experience with the BGP Protocol October 19916. Security architecture.