draft-ietf-idr-bgp4-02.txt   draft-ietf-idr-bgp4-03.txt 
Network Working Group Y. Rekhter Network Working Group Y. Rekhter
INTERNET DRAFT cisco Systems INTERNET DRAFT cisco Systems
T.Li T.Li
cisco Systems Juniper
Editors Editors
<draft-ietf-idr-bgp4-02.txt> January 1996 <draft-ietf-idr-bgp4-03.txt> August 1996
A Border Gateway Protocol 4 (BGP-4) A Border Gateway Protocol 4 (BGP-4)
Status of this Memo Status of this Memo
This document, together with its companion document, "Application of This document, together with its companion document, "Application of
the Border Gateway Protocol in the Internet", define an inter- the Border Gateway Protocol in the Internet", define an inter-
autonomous system routing protocol for the Internet. This document autonomous system routing protocol for the Internet. This document
specifies an IAB standards track protocol for the Internet community, specifies an IAB standards track protocol for the Internet community,
and requests discussion and suggestions for improvements. Please and requests discussion and suggestions for improvements. Please
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working Drafts as reference material or to cite them other than as a "working
draft" or "work in progress". draft" or "work in progress".
1. Acknowledgements 1. Acknowledgements
This document was originally published as RFC 1267 in October 1991, This document was originally published as RFC 1267 in October 1991,
jointly authored by Kirk Lougheed (cisco Systems) and Yakov Rekhter jointly authored by Kirk Lougheed and Yakov Rekhter.
(cisco Systems).
We would like to express our thanks to Guy Almes (ANS), Len Bosack We would like to express our thanks to Guy Almes, Len Bosack, and
(XKL Systems), and Jeffrey C. Honig (Cornell University) for their Jeffrey C. Honig for their contributions to the earlier version of
contributions to the earlier version of this document. this document.
We like to explicitly thank Bob Braden (ISI) for the review of the We like to explicitly thank Bob Braden for the review of the earlier
earlier version of this document as well as his constructive and version of this document as well as his constructive and valuable
valuable comments. comments.
We would also like to thank Bob Hinden, Director for Routing of the We would also like to thank Bob Hinden, Director for Routing of the
Internet Engineering Steering Group, and the team of reviewers he Internet Engineering Steering Group, and the team of reviewers he
assembled to review the previous version (BGP-2) of this document. assembled to review the previous version (BGP-2) of this document.
This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia
Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted
with a strong combination of toughness, professionalism, and with a strong combination of toughness, professionalism, and
courtesy. courtesy.
This updated version of the document is the product of the IETF IDR This updated version of the document is the product of the IETF IDR
Working Group with Yakov Rekhter and Tony Li as editors. Certain Working Group with Yakov Rekhter and Tony Li as editors. Certain
sections of the document borrowed heavily from IDRP [7], which is the 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 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 X3S3.3 group chaired by Lyman Chapin and to Charles Kunzinger who was
(IBM Corp.) who was the IDRP editor within that group. We would also the IDRP editor within that group. We would also like to thank Mike
like to thank Mike Craren (Proteon, Inc.), Dimitry Haskin (Bay Craren, Dimitry Haskin, John Krawczyk, and Paul Traina for their
Networks, Inc.), John Krawczyk (Bay Networks, Inc.), and Paul Traina insightful comments.
(cisco Systems) for their insightful comments.
We would like to specially acknowledge numerous contributions by We would like to specially acknowledge numerous contributions by
Dennis Ferguson (MCI). Dennis Ferguson.
2. Introduction 2. Introduction
The Border Gateway Protocol (BGP) is an inter-Autonomous System The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol. It is built on experience gained with EGP as routing protocol. It is built on experience gained with EGP as
defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
described in RFC 1092 [2] and RFC 1093 [3]. described in RFC 1092 [2] and RFC 1093 [3].
The primary function of a BGP speaking system is to exchange network The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network reachability information with other BGP systems. This network
skipping to change at page 39, line 25 skipping to change at page 39, line 25
The following tie-breaking procedure assumes that for each candidate The following tie-breaking procedure assumes that for each candidate
route all the BGP speakers within an autonomous system can ascertain route all the BGP speakers within an autonomous system can ascertain
the cost of a path (interior distance) to the address depicted by the the cost of a path (interior distance) to the address depicted by the
NEXT_HOP attribute of the route. Ties shall be broken according to NEXT_HOP attribute of the route. Ties shall be broken according to
the following algorithm: the following algorithm:
a) If the local system is configured to take into account a) If the local system is configured to take into account
MULTI_EXIT_DISC, and the candidate routes differ in their MULTI_EXIT_DISC, and the candidate routes differ in their
MULTI_EXIT_DISC attribute, select the route that has the lowest MULTI_EXIT_DISC attribute, select the route that has the lowest
value of the MULTI_EXIT_DISC attribute. value of the MULTI_EXIT_DISC attribute. A route with
MULTI_EXIT_DISC shall be preferred to a route without
MULTI_EXIT_DIST.
b) Otherwise, select the route that has the lowest cost (interior b) Otherwise, select the route that has the lowest cost (interior
distance) to the entity depicted by the NEXT_HOP attribute of the distance) to the entity depicted by the NEXT_HOP attribute of the
route. If there are several routes with the same cost, then the route. If there are several routes with the same cost, then the
tie-breaking shall be broken as follows: tie-breaking shall be broken as follows:
- if at least one of the candidate routes was advertised by the - if at least one of the candidate routes was advertised by the
BGP speaker in a neighboring autonomous system, select the BGP speaker in a neighboring autonomous system, select the
route that was advertised by the BGP speaker in a neighboring route that was advertised by the BGP speaker in a neighboring
autonomous system whose BGP Identifier has the lowest value autonomous system whose BGP Identifier has the lowest value
skipping to change at page 43, line 46 skipping to change at page 43, line 48
9.2.1.1 Breaking Ties (Internal Updates) 9.2.1.1 Breaking Ties (Internal Updates)
If a local BGP speaker has connections to several BGP speakers in If a local BGP speaker has connections to several BGP speakers in
neighboring autonomous systems, there will be multiple Adj-RIBs-In neighboring autonomous systems, there will be multiple Adj-RIBs-In
associated with these peers. These Adj-RIBs-In might contain several associated with these peers. These Adj-RIBs-In might contain several
equally preferable routes to the same destination, all of which were equally preferable routes to the same destination, all of which were
advertised by BGP speakers located in neighboring autonomous systems. advertised by BGP speakers located in neighboring autonomous systems.
The local BGP speaker shall select one of these routes according to The local BGP speaker shall select one of these routes according to
the following rules: the following rules:
a) If the candidate route differ only in their NEXT_HOP and a) If the candidate routes differ only in their NEXT_HOP and
MULTI_EXIT_DISC attributes, and the local system is configured to MULTI_EXIT_DISC attributes, and the local system is configured to
take into account MULTI_EXIT_DISC attribute, select the routes take into account the MULTI_EXIT_DISC attribute, select the route
that has the lowest value of the MULTI_EXIT_DISC attribute. that has the lowest value of the MULTI_EXIT_DISC attribute. A
route with the MULTI_EXIT_DISC attribute shall be preferred to a
route without the MULTI_EXIT_DISC attribute.
b) If the local system can ascertain the cost of a path to the b) If the local system can ascertain the cost of a path to the
entity depicted by the NEXT_HOP attribute of the candidate route, entity depicted by the NEXT_HOP attribute of the candidate route,
select the route with the lowest cost. select the route with the lowest cost.
c) In all other cases, select the route that was advertised by the c) In all other cases, select the route that was advertised by the
BGP speaker whose BGP Identifier has the lowest value. BGP speaker whose BGP Identifier has the lowest value.
9.2.2 External Updates 9.2.2 External Updates
skipping to change at page 59, line 14 skipping to change at page 59, line 18
Editors' Addresses Editors' Addresses
Yakov Rekhter Yakov Rekhter
cisco Systems, Inc. cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
email: yakov@cisco.com email: yakov@cisco.com
Tony Li Tony Li
cisco Systems, Inc. Juniper Networks, Inc.
170 W. Tasman Dr. 3260 Jay St.
San Jose, CA 95134 Santa Clara, CA 95051
email: tli@cisco.com (408) 327-1906
email: tli@jnx.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/