--- 1/draft-ietf-idr-bgp4-02.txt 2006-02-04 23:29:57.000000000 +0100 +++ 2/draft-ietf-idr-bgp4-03.txt 2006-02-04 23:29:57.000000000 +0100 @@ -1,17 +1,17 @@ Network Working Group Y. Rekhter INTERNET DRAFT cisco Systems T.Li - cisco Systems + Juniper Editors - January 1996 + August 1996 A Border Gateway Protocol 4 (BGP-4) Status of this Memo This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter- autonomous system routing protocol for the Internet. This document specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please @@ -26,51 +26,49 @@ Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by 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 draft" or "work in progress". 1. Acknowledgements This document was originally published as RFC 1267 in October 1991, - jointly authored by Kirk Lougheed (cisco Systems) and Yakov Rekhter - (cisco Systems). + jointly authored by Kirk Lougheed and Yakov Rekhter. - We would like to express our thanks to Guy Almes (ANS), Len Bosack - (XKL Systems), and Jeffrey C. Honig (Cornell University) for their - contributions to the earlier version of this document. + 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 (ISI) for the review of the - earlier version of this document as well as his constructive and - valuable comments. + 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. 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 (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 (Bay - Networks, Inc.), John Krawczyk (Bay Networks, Inc.), and Paul Traina - (cisco Systems) for their insightful comments. + 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, and Paul Traina for their + insightful comments. We would like to specially acknowledge numerous contributions by - Dennis Ferguson (MCI). + 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 @@ -1724,21 +1722,23 @@ The following tie-breaking procedure assumes that for each candidate route all the BGP speakers within an autonomous system can ascertain 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 the following algorithm: a) If the local system is configured to take into account MULTI_EXIT_DISC, and the candidate routes differ in their 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 distance) to the entity depicted by the NEXT_HOP attribute of the route. If there are several routes with the same cost, then the tie-breaking shall be broken as follows: - if at least one of the candidate routes was advertised by the BGP speaker in a neighboring autonomous system, select the route that was advertised by the BGP speaker in a neighboring autonomous system whose BGP Identifier has the lowest value @@ -1924,24 +1926,26 @@ 9.2.1.1 Breaking Ties (Internal Updates) If a local BGP speaker has connections to several BGP speakers in neighboring autonomous systems, there will be multiple Adj-RIBs-In associated with these peers. These Adj-RIBs-In might contain several equally preferable routes to the same destination, all of which were advertised by BGP speakers located in neighboring autonomous systems. The local BGP speaker shall select one of these routes according to 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 - take into account MULTI_EXIT_DISC attribute, select the routes - that has the lowest value of the MULTI_EXIT_DISC attribute. + take into account the MULTI_EXIT_DISC attribute, select the route + 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 entity depicted by the NEXT_HOP attribute of the candidate route, select the route with the lowest cost. c) In all other cases, select the route that was advertised by the BGP speaker whose BGP Identifier has the lowest value. 9.2.2 External Updates @@ -2584,14 +2588,15 @@ Editors' Addresses Yakov Rekhter cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 email: yakov@cisco.com Tony Li - cisco Systems, Inc. - 170 W. Tasman Dr. - San Jose, CA 95134 - email: tli@cisco.com + Juniper Networks, Inc. + 3260 Jay St. + Santa Clara, CA 95051 + (408) 327-1906 + email: tli@jnx.com