--- 1/draft-ietf-idr-bgp4-05.txt 2006-02-04 23:30:01.000000000 +0100 +++ 2/draft-ietf-idr-bgp4-06.txt 2006-02-04 23:30:01.000000000 +0100 @@ -1,17 +1,17 @@ Network Working Group Y. Rekhter INTERNET DRAFT cisco Systems -Expire in six months T. Li + T. Li Juniper Networks Editors - January 1997 + June 1997 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 @@ -51,21 +51,22 @@ 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, - Paul Traina, and Curtis Villamizar for their comments. + John Stewart III, 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]. @@ -650,21 +652,21 @@ be used by a BGP speaker's decision process to discriminate among multiple exit points to a neighboring autonomous system. Its usage is defined in 5.1.4. e) LOCAL_PREF (Type Code 5): LOCAL_PREF is a well-known mandatory attribute that is a four octet non-negative integer. It is used by a BGP speaker - to inform other internal peers of the originating speaker's + to inform other internal peers of the advertising speaker's degree of preference for an advertised route. Usage of this attribute is described in 5.1.5. f) ATOMIC_AGGREGATE (Type Code 6) ATOMIC_AGGREGATE is a well-known discretionary attribute of length 0. It is used by a BGP speaker to inform other BGP speakers that the local system selected a less specific route without selecting a more specific route which is included in it. Usage of this attribute is described in @@ -1162,24 +1164,20 @@ If one of the Optional Parameters in the OPEN message is not recognized, then the Error Subcode is set to Unsupported Optional Parameters. If the OPEN message carries Authentication Information (as an Optional Parameter), then the corresponding authentication procedure is invoked. If the authentication procedure (based on Authentication Code and Authentication Data) fails, then the Error Subcode is set to Authentication Failure. - If the OPEN message carries any other Optional Parameter (other than - Authentication Information), and the local system doesn't recognize - the Parameter, the Parameter shall be ignored. - 6.3 UPDATE message error handling. All errors detected while processing the UPDATE message are indicated by sending the NOTIFICATION message with Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error. Error checking of an UPDATE message begins by examining the path attributes. If the Unfeasible Routes Length or Total Attribute Length is too large (i.e., if Unfeasible Routes Length + Total @@ -1242,20 +1240,23 @@ discarded, and the Error Subcode is set to Optional Attribute Error. The Data field contains the attribute (type, length and value). If any attribute appears more than once in the UPDATE message, then the Error Subcode is set to Malformed Attribute List. The NLRI field in the UPDATE message is checked for syntactic validity. If the field is syntactically incorrect, then the Error Subcode is set to Invalid Network Field. + An UPDATE message that contains correct path attributes, but no NLRI + shall be treated as a valid UPDATE message. + 6.4 NOTIFICATION message error handling. If a peer sends a NOTIFICATION message, and there is an error in that message, there is unfortunately no means of reporting this error via a subsequent NOTIFICATION message. Any such error, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the administration of the peer. The means to do this, however, lies outside the scope of this document. @@ -1625,23 +1626,23 @@ applying the policies in the local Policy Information Base (PIB) to the routes stored in its Adj-RIB-In. The output of the Decision Process is the set of routes that will be advertised to all peers; the selected routes will be stored in the local speaker's Adj-RIB- Out. The selection process is formalized by defining a function that takes the attribute of a given route as an argument and returns a non- negative integer denoting the degree of preference for the route. The function that calculates the degree of preference for a given - route shall not use as its inputs any of the following: the - existence of other routes, the non-existence of other routes, or the - path attributes of other routes. Route selection then consists of + route shall not use as its inputs any of the following: the existence + of other routes, the non-existence of other routes, or the path + attributes of other routes. Route selection then consists of individual application of the degree of preference function to each feasible route, followed by the choice of the one with the highest degree of preference. The Decision Process operates on routes contained in each Adj-RIB-In, and is responsible for: - selection of routes to be advertised to internal peers - selection of routes to be advertised to external peers @@ -1663,22 +1664,22 @@ c) Phase 3 is invoked after the Loc-RIB has been modified. It is responsible for disseminating routes in the Loc-RIB to each external peer, according to the policies contained in the PIB. Route aggregation and information reduction can optionally be performed within this phase. 9.1.1 Phase 1: Calculation of Degree of Preference The Phase 1 decision function shall be invoked whenever the local BGP - speaker receives from an external peer an UPDATE message that - advertises a new route, a replacement route, or a withdrawn route. + speaker receives from a peer an UPDATE message that advertises a new + route, a replacement route, or a withdrawn route. The Phase 1 decision function is a separate process which completes when it has no further work to do. The Phase 1 decision function shall lock an Adj-RIB-In prior to operating on any route contained within it, and shall unlock it after operating on all new or unfeasible routes contained within it. For each newly received or replacement feasible route, the local BGP speaker shall determine a degree of preference. If the route is @@ -2189,21 +2191,21 @@ 9.3 Route Selection Criteria Generally speaking, additional rules for comparing routes among several alternatives are outside the scope of this document. There are two exceptions: - If the local AS appears in the AS path of the new route being considered, then that new route cannot be viewed as better than any other route. If such a route were ever used, a routing loop - would result. + could result (see Section 6.3). - In order to achieve successful distributed operation, only routes with a likelihood of stability can be chosen. Thus, an AS must avoid using unstable routes, and it must not make rapid spontaneous changes to its choice of route. Quantifying the terms "unstable" and "rapid" in the previous sentence will require experience, but the principle is clear. 9.4 Originating BGP routes