draft-ietf-idr-bgp4-05.txt   draft-ietf-idr-bgp4-06.txt 
Network Working Group Y. Rekhter Network Working Group Y. Rekhter
INTERNET DRAFT cisco Systems INTERNET DRAFT cisco Systems
Expire in six months T. Li T. Li
Juniper Networks Juniper Networks
Editors Editors
<draft-ietf-idr-bgp4-05.txt> January 1997 <draft-ietf-idr-bgp4-06.txt> June 1997
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 line 61 skipping to change at page 2, line 20
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 and to Charles Kunzinger who was 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 the IDRP editor within that group. We would also like to thank Mike
Craren, Dimitry Haskin, John Krawczyk, David LeRoy, John Scudder, 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 We would like to specially acknowledge numerous contributions by
Dennis Ferguson. 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].
skipping to change at line 660 skipping to change at page 15, line 40
be used by a BGP speaker's decision process to discriminate be used by a BGP speaker's decision process to discriminate
among multiple exit points to a neighboring autonomous among multiple exit points to a neighboring autonomous
system. system.
Its usage is defined in 5.1.4. Its usage is defined in 5.1.4.
e) LOCAL_PREF (Type Code 5): e) LOCAL_PREF (Type Code 5):
LOCAL_PREF is a well-known mandatory attribute that is a LOCAL_PREF is a well-known mandatory attribute that is a
four octet non-negative integer. It is used by a BGP speaker 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 degree of preference for an advertised route. Usage of this
attribute is described in 5.1.5. attribute is described in 5.1.5.
f) ATOMIC_AGGREGATE (Type Code 6) f) ATOMIC_AGGREGATE (Type Code 6)
ATOMIC_AGGREGATE is a well-known discretionary attribute of ATOMIC_AGGREGATE is a well-known discretionary attribute of
length 0. It is used by a BGP speaker to inform other BGP length 0. It is used by a BGP speaker to inform other BGP
speakers that the local system selected a less specific speakers that the local system selected a less specific
route without selecting a more specific route which is route without selecting a more specific route which is
included in it. Usage of this attribute is described in included in it. Usage of this attribute is described in
skipping to change at line 1172 skipping to change at page 27, line 13
If one of the Optional Parameters in the OPEN message is not If one of the Optional Parameters in the OPEN message is not
recognized, then the Error Subcode is set to Unsupported Optional recognized, then the Error Subcode is set to Unsupported Optional
Parameters. Parameters.
If the OPEN message carries Authentication Information (as an If the OPEN message carries Authentication Information (as an
Optional Parameter), then the corresponding authentication procedure Optional Parameter), then the corresponding authentication procedure
is invoked. If the authentication procedure (based on Authentication is invoked. If the authentication procedure (based on Authentication
Code and Authentication Data) fails, then the Error Subcode is set to Code and Authentication Data) fails, then the Error Subcode is set to
Authentication Failure. 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. 6.3 UPDATE message error handling.
All errors detected while processing the UPDATE message are indicated All errors detected while processing the UPDATE message are indicated
by sending the NOTIFICATION message with Error Code UPDATE Message by sending the NOTIFICATION message with Error Code UPDATE Message
Error. The error subcode elaborates on the specific nature of the Error. The error subcode elaborates on the specific nature of the
error. error.
Error checking of an UPDATE message begins by examining the path Error checking of an UPDATE message begins by examining the path
attributes. If the Unfeasible Routes Length or Total Attribute attributes. If the Unfeasible Routes Length or Total Attribute
Length is too large (i.e., if Unfeasible Routes Length + Total Length is too large (i.e., if Unfeasible Routes Length + Total
skipping to change at line 1252 skipping to change at page 28, line 45
discarded, and the Error Subcode is set to Optional Attribute Error. discarded, and the Error Subcode is set to Optional Attribute Error.
The Data field contains the attribute (type, length and value). The Data field contains the attribute (type, length and value).
If any attribute appears more than once in the UPDATE message, then If any attribute appears more than once in the UPDATE message, then
the Error Subcode is set to Malformed Attribute List. the Error Subcode is set to Malformed Attribute List.
The NLRI field in the UPDATE message is checked for syntactic The NLRI field in the UPDATE message is checked for syntactic
validity. If the field is syntactically incorrect, then the Error validity. If the field is syntactically incorrect, then the Error
Subcode is set to Invalid Network Field. 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. 6.4 NOTIFICATION message error handling.
If a peer sends a NOTIFICATION message, and there is an error in that 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 message, there is unfortunately no means of reporting this error via
a subsequent NOTIFICATION message. Any such error, such as an a subsequent NOTIFICATION message. Any such error, such as an
unrecognized Error Code or Error Subcode, should be noticed, logged unrecognized Error Code or Error Subcode, should be noticed, logged
locally, and brought to the attention of the administration of the locally, and brought to the attention of the administration of the
peer. The means to do this, however, lies outside the scope of this peer. The means to do this, however, lies outside the scope of this
document. document.
skipping to change at line 1635 skipping to change at page 37, line 18
applying the policies in the local Policy Information Base (PIB) to applying the policies in the local Policy Information Base (PIB) to
the routes stored in its Adj-RIB-In. The output of the Decision 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; 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- the selected routes will be stored in the local speaker's Adj-RIB-
Out. Out.
The selection process is formalized by defining a function that takes The selection process is formalized by defining a function that takes
the attribute of a given route as an argument and returns a non- the attribute of a given route as an argument and returns a non-
negative integer denoting the degree of preference for the route. negative integer denoting the degree of preference for the route.
The function that calculates the degree of preference for a given The function that calculates the degree of preference for a given
route shall not use as its inputs any of the following: the route shall not use as its inputs any of the following: the existence
existence of other routes, the non-existence of other routes, or the of other routes, the non-existence of other routes, or the path
path attributes of other routes. Route selection then consists of attributes of other routes. Route selection then consists of
individual application of the degree of preference function to each individual application of the degree of preference function to each
feasible route, followed by the choice of the one with the highest feasible route, followed by the choice of the one with the highest
degree of preference. degree of preference.
The Decision Process operates on routes contained in each Adj-RIB-In, The Decision Process operates on routes contained in each Adj-RIB-In,
and is responsible for: and is responsible for:
- selection of routes to be advertised to internal peers - selection of routes to be advertised to internal peers
- selection of routes to be advertised to external peers - selection of routes to be advertised to external peers
skipping to change at line 1673 skipping to change at page 38, line 8
c) Phase 3 is invoked after the Loc-RIB has been modified. It is c) Phase 3 is invoked after the Loc-RIB has been modified. It is
responsible for disseminating routes in the Loc-RIB to each responsible for disseminating routes in the Loc-RIB to each
external peer, according to the policies contained in the PIB. external peer, according to the policies contained in the PIB.
Route aggregation and information reduction can optionally be Route aggregation and information reduction can optionally be
performed within this phase. performed within this phase.
9.1.1 Phase 1: Calculation of Degree of Preference 9.1.1 Phase 1: Calculation of Degree of Preference
The Phase 1 decision function shall be invoked whenever the local BGP The Phase 1 decision function shall be invoked whenever the local BGP
speaker receives from an external peer an UPDATE message that speaker receives from a peer an UPDATE message that advertises a new
advertises a new route, a replacement route, or a withdrawn route. route, a replacement route, or a withdrawn route.
The Phase 1 decision function is a separate process which completes The Phase 1 decision function is a separate process which completes
when it has no further work to do. when it has no further work to do.
The Phase 1 decision function shall lock an Adj-RIB-In prior to 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 any route contained within it, and shall unlock it after
operating on all new or unfeasible routes contained within it. operating on all new or unfeasible routes contained within it.
For each newly received or replacement feasible route, the local BGP For each newly received or replacement feasible route, the local BGP
speaker shall determine a degree of preference. If the route is speaker shall determine a degree of preference. If the route is
skipping to change at line 2199 skipping to change at page 49, line 38
9.3 Route Selection Criteria 9.3 Route Selection Criteria
Generally speaking, additional rules for comparing routes among Generally speaking, additional rules for comparing routes among
several alternatives are outside the scope of this document. There several alternatives are outside the scope of this document. There
are two exceptions: are two exceptions:
- If the local AS appears in the AS path of the new route being - 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 considered, then that new route cannot be viewed as better than
any other route. If such a route were ever used, a routing loop 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 - In order to achieve successful distributed operation, only
routes with a likelihood of stability can be chosen. Thus, an AS routes with a likelihood of stability can be chosen. Thus, an AS
must avoid using unstable routes, and it must not make rapid must avoid using unstable routes, and it must not make rapid
spontaneous changes to its choice of route. Quantifying the terms spontaneous changes to its choice of route. Quantifying the terms
"unstable" and "rapid" in the previous sentence will require "unstable" and "rapid" in the previous sentence will require
experience, but the principle is clear. experience, but the principle is clear.
9.4 Originating BGP routes 9.4 Originating BGP routes
 End of changes. 

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