draft-ietf-idr-bgp4-14.txt   draft-ietf-idr-bgp4-15.txt 
Network Working Group Y. Rekhter Network Working Group Y. Rekhter
INTERNET DRAFT Juniper Networks INTERNET DRAFT Juniper Networks
T. Li T. Li
Procket Networks, Inc. Procket Networks, Inc.
Editors Editors
A Border Gateway Protocol 4 (BGP-4) A Border Gateway Protocol 4 (BGP-4)
<draft-ietf-idr-bgp4-14.txt> <draft-ietf-idr-bgp4-15.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 4, line 21 skipping to change at page 4, line 21
They exchange messages to open and confirm the connection parameters. They exchange messages to open and confirm the connection parameters.
The initial data flow is the portion of the BGP routing table that is The initial data flow is the portion of the BGP routing table that is
allowed by the export policy, called the Adj-Ribs-Out (see 3.2). allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
Incremental updates are sent as the routing tables change. BGP does Incremental updates are sent as the routing tables change. BGP does
not require periodic refresh of the routing table. Therefore, A BGP not require periodic refresh of the routing table. Therefore, A BGP
speaker must retain the current version of the routes advertised by speaker must retain the current version of the routes advertised by
all of its peers for the duration of the connection. If the all of its peers for the duration of the connection. If the
implementation decides to not store the routes that have been implementation decides to not store the routes that have been
received from a peer, but have been filtered out according to received from a peer, but have been filtered out according to
configured local policy, the BGP Route Refresh option [12] may be configured local policy, the BGP Route Refresh extension [12] may be
used to request the full set of routes from a peer without resetting used to request the full set of routes from a peer without resetting
the BGP session when the local policy configuration changes. the BGP session when the local policy configuration changes.
KEEPALIVE messages are sent periodically to ensure the liveness of KEEPALIVE messages are sent periodically to ensure the liveness of
the connection. NOTIFICATION messages are sent in response to errors the connection. NOTIFICATION messages are sent in response to errors
or special conditions. If a connection encounters an error condition, or special conditions. If a connection encounters an error condition,
a NOTIFICATION message is sent and the connection is closed. a NOTIFICATION message is sent and the connection is closed.
The hosts executing the Border Gateway Protocol need not be routers. The hosts executing the Border Gateway Protocol need not be routers.
A non-routing host could exchange routing information with routers A non-routing host could exchange routing information with routers
skipping to change at page 5, line 17 skipping to change at page 5, line 17
discussion, it is assumed that BGP information is passed within an AS discussion, it is assumed that BGP information is passed within an AS
using IBGP. Care must be taken to ensure that the interior routers using IBGP. Care must be taken to ensure that the interior routers
have all been updated with transit information before the EBGP have all been updated with transit information before the EBGP
speakers announce to other ASs that transit service is being speakers announce to other ASs that transit service is being
provided. provided.
3.1 Routes: Advertisement and Storage 3.1 Routes: Advertisement and Storage
For purposes of this protocol a route is defined as a unit of For purposes of this protocol a route is defined as a unit of
information that pairs a destination with the attributes of a path to information that pairs a destination with the attributes of a path to
that destination: that destination, where the destination is the systems whose IP
addresses are reported in the Network Layer Reachability Information
(NLRI) field, and the path is the information reported in the path
attributes fields of the same UPDATE message.
- Routes are advertised between BGP speakers in UPDATE messages. Routes are advertised between BGP speakers in UPDATE messages.
The destination is the systems whose IP addresses are reported in
the Network Layer Reachability Information (NLRI) field, and the
path is the information reported in the path attributes fields of
the same UPDATE message.
- Routes are stored in the Routing Information Bases (RIBs): Routes are stored in the Routing Information Bases (RIBs): namely,
namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes that will
that will be advertised to other BGP speakers must be present in be advertised to other BGP speakers must be present in the Adj-RIB-
the Adj-RIB-Out. Routes that will be used by the local BGP Out. Routes that will be used by the local BGP speaker must be
speaker must be present in the Loc-RIB, and the next hop for each present in the Loc-RIB, and the next hop for each of these routes
of these routes must be present in the local BGP speaker's Routing must be present in the local BGP speaker's Routing Table. Routes
Table. Routes that are received from other BGP speakers are that are received from other BGP speakers are present in the Adj-
present in the Adj-RIBs-In. RIBs-In.
If a BGP speaker chooses to advertise the route, it may add to or If a BGP speaker chooses to advertise the route, it may add to or
modify the path attributes of the route before advertising it to a modify the path attributes of the route before advertising it to a
peer. peer.
BGP provides mechanisms by which a BGP speaker can inform its peer BGP provides mechanisms by which a BGP speaker can inform its peer
that a previously advertised route is no longer available for use. that a previously advertised route is no longer available for use.
There are three methods by which a given BGP speaker can indicate There are three methods by which a given BGP speaker can indicate
that a route has been withdrawn from service: that a route has been withdrawn from service:
skipping to change at page 18, line 12 skipping to change at page 18, line 4
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
messages MUST NOT be sent. messages MUST NOT be sent.
KEEPALIVE message consists of only message header and has a length of KEEPALIVE message consists of only message header and has a length of
19 octets. 19 octets.
4.5 NOTIFICATION Message Format 4.5 NOTIFICATION Message Format
A NOTIFICATION message is sent when an error condition is detected. A NOTIFICATION message is sent when an error condition is detected.
The BGP connection is closed immediately after sending it. The BGP connection is closed immediately after sending it.
In addition to the fixed-size BGP header, the NOTIFICATION message In addition to the fixed-size BGP header, the NOTIFICATION message
contains the following fields: contains the following fields:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code | Error subcode | Data | | Error code | Error subcode | Data (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code: Error Code:
This 1-octet unsigned integer indicates the type of This 1-octet unsigned integer indicates the type of
NOTIFICATION. The following Error Codes have been defined: NOTIFICATION. The following Error Codes have been defined:
Error Code Symbolic Name Reference Error Code Symbolic Name Reference
1 Message Header Error Section 6.1 1 Message Header Error Section 6.1
skipping to change at page 22, line 28 skipping to change at page 22, line 16
peer, the advertising speaker shall not modify the AS_PATH peer, the advertising speaker shall not modify the AS_PATH
attribute associated with the route. attribute associated with the route.
b) When a given BGP speaker advertises the route to an external b) When a given BGP speaker advertises the route to an external
peer, then the advertising speaker shall update the AS_PATH peer, then the advertising speaker shall update the AS_PATH
attribute as follows: attribute as follows:
1) if the first path segment of the AS_PATH is of type 1) if the first path segment of the AS_PATH is of type
AS_SEQUENCE, the local system shall prepend its own AS number AS_SEQUENCE, the local system shall prepend its own AS number
as the last element of the sequence (put it in the leftmost as the last element of the sequence (put it in the leftmost
position) position). If the act of prepending will cause an overflow in
the AS_PATH segment, i.e. more than 255 elements, it shall be
legal to prepend a new segment of type AS_SEQUENCE and prepend
its own AS number to this new segment.
2) if the first path segment of the AS_PATH is of type AS_SET, 2) if the first path segment of the AS_PATH is of type AS_SET,
the local system shall prepend a new path segment of type the local system shall prepend a new path segment of type
AS_SEQUENCE to the AS_PATH, including its own AS number in that AS_SEQUENCE to the AS_PATH, including its own AS number in that
segment. segment.
When a BGP speaker originates a route then: When a BGP speaker originates a route then:
a) the originating speaker shall include its own AS number in a a) the originating speaker shall include its own AS number in a
path segment of type AS_SEQUENCE in the AS_PATH attribute of all path segment of type AS_SEQUENCE in the AS_PATH attribute of all
skipping to change at page 23, line 25 skipping to change at page 23, line 18
should not modify the NEXT_HOP attribute, unless it has been should not modify the NEXT_HOP attribute, unless it has been
explicitly configured to announce its own IP address as the explicitly configured to announce its own IP address as the
NEXT_HOP. NEXT_HOP.
2) When sending a message to an external peer X, and the peer is 2) When sending a message to an external peer X, and the peer is
one IP hop away from the speaker: one IP hop away from the speaker:
- If the route being announced was learned from an internal - If the route being announced was learned from an internal
peer or is locally originated, the BGP speaker can use for the peer or is locally originated, the BGP speaker can use for the
NEXT_HOP attribute an interface address of the internal peer NEXT_HOP attribute an interface address of the internal peer
router through which the announced network is reachable for the router (or the internal router) through which the announced
speaker, provided that peer X shares a common subnet with this network is reachable for the speaker, provided that peer X
address. This is a form of "third party" NEXT_HOP attribute. shares a common subnet with this address. This is a form of
"third party" NEXT_HOP attribute.
- If the route being announced was learned from an external - If the route being announced was learned from an external
peer, the speaker can use in the NEXT_HOP attribute an IP peer, the speaker can use in the NEXT_HOP attribute an IP
address of any adjacent router (known from the received address of any adjacent router (known from the received
NEXT_HOP attribute) that the speaker itself uses for local NEXT_HOP attribute) that the speaker itself uses for local
route calculation, provided that peer X shares a common subnet route calculation, provided that peer X shares a common subnet
with this address. This is a second form of "third party" with this address. This is a second form of "third party"
NEXT_HOP attribute. NEXT_HOP attribute.
- If the external peer to which the route is being advertised - If the external peer to which the route is being advertised
skipping to change at page 25, line 38 skipping to change at page 25, line 30
via LOCAL_PREF in its decision process (see section 9.1.1). via LOCAL_PREF in its decision process (see section 9.1.1).
A BGP speaker MUST NOT include this attribute in UPDATE messages that A BGP speaker MUST NOT include this attribute in UPDATE messages that
it sends to external peers, except for the case of BGP Confederations it sends to external peers, except for the case of BGP Confederations
[13]. If it is contained in an UPDATE message that is received from [13]. If it is contained in an UPDATE message that is received from
an external peer, then this attribute MUST be ignored by the an external peer, then this attribute MUST be ignored by the
receiving speaker, except for the case of BGP Confederations [13]. receiving speaker, except for the case of BGP Confederations [13].
5.1.6 ATOMIC_AGGREGATE 5.1.6 ATOMIC_AGGREGATE
ATOMIC_AGGREGATE is a well-known discretionary attribute. There are ATOMIC_AGGREGATE is a well-known discretionary attribute.
two cases where the ATOMIC_AGGREGATE attribute is used:
- a speaker receives both more and less specific routes, these
routes have the same NEXT_HOP, the AS_PATH attribute of the more
specific route is different from the AS_PATH attribute of the less
specific route, and the speaker installs in its Loc-RIB only the
less specific route. In this case the speaker should advertise
this route with the ATOMIC_AGGREGATE attribute to all neighbors
(subject to the outbound route filtering).
- a speaker receives both more and less specific routes the When a router aggregates several routes for the purpose of
AS_PATH attribute of the more specific route is different from the advertisement to a particular peer, and the AS_PATH of the aggregated
AS_PATH attribute of the less specific route, the speaker installs route excludes at least some of the AS numbers present in the AS_PATH
in its Loc-RIB both routes, but the speaker advertises to a of the routes that are aggregated, the aggregated route, when
particular neighbor only the less specific route. In this case the advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
advertisement MUST carry the ATOMIC_AGGREGATE attribute.
A BGP speaker that receives a route with the ATOMIC_AGGREGATE A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute MUST NOT remove the attribute from the route when attribute MUST NOT remove the attribute from the route when
propagating it to other speakers. propagating it to other speakers.
A BGP speaker that receives a route with the ATOMIC_AGGREGATE A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute MUST NOT make any NLRI of that route more specific (as attribute MUST NOT make any NLRI of that route more specific (as
defined in 9.1.4) when advertising this route to other BGP speakers. defined in 9.1.4) when advertising this route to other BGP speakers.
A BGP speaker that receives a route with the ATOMIC_AGGREGATE A BGP speaker that receives a route with the ATOMIC_AGGREGATE
skipping to change at page 27, line 22 skipping to change at page 27, line 6
All errors detected while processing the Message Header are indicated All errors detected while processing the Message Header are indicated
by sending the NOTIFICATION message with Error Code Message Header by sending the NOTIFICATION message with Error Code Message Header
Error. The Error Subcode elaborates on the specific nature of the Error. The Error Subcode elaborates on the specific nature of the
error. error.
The expected value of the Marker field of the message header is all The expected value of the Marker field of the message header is all
ones if the message type is OPEN. The expected value of the Marker ones if the message type is OPEN. The expected value of the Marker
field for all other types of BGP messages determined based on the field for all other types of BGP messages determined based on the
presence of the Authentication Information Optional Parameter in the presence of the Authentication Information Optional Parameter in the
BGP OPEN message and the actual authentication mechanism (if the BGP OPEN message and the actual authentication mechanism (if the
Authentication Information in the BGP OPEN message is present). If Authentication Information in the BGP OPEN message is present). The
the Marker field of the message header is not the expected one, then Marker field should be all ones if the OPEN message carried no
a synchronization error has occurred and the Error Subcode is set to authentication information. If the Marker field of the message header
Connection Not Synchronized. is not the expected one, then a synchronization error has occurred
and the Error Subcode is set to Connection Not Synchronized.
If the Length field of the message header is less than 19 or greater If the Length field of the message header is less than 19 or greater
than 4096, or if the Length field of an OPEN message is less than the than 4096, or if the Length field of an OPEN message is less than the
minimum length of the OPEN message, or if the Length field of an minimum length of the OPEN message, or if the Length field of an
UPDATE message is less than the minimum length of the UPDATE message, UPDATE message is less than the minimum length of the UPDATE message,
or if the Length field of a KEEPALIVE message is not equal to 19, or or if the Length field of a KEEPALIVE message is not equal to 19, or
if the Length field of a NOTIFICATION message is less than the if the Length field of a NOTIFICATION message is less than the
minimum length of the NOTIFICATION message, then the Error Subcode is minimum length of the NOTIFICATION message, then the Error Subcode is
set to Bad Message Length. The Data field contains the erroneous set to Bad Message Length. The Data field contains the erroneous
Length field. Length field.
skipping to change at page 28, line 7 skipping to change at page 27, line 35
6.2 OPEN message error handling. 6.2 OPEN message error handling.
All errors detected while processing the OPEN message are indicated All errors detected while processing the OPEN message are indicated
by sending the NOTIFICATION message with Error Code OPEN Message by sending the NOTIFICATION message with Error Code OPEN 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.
If the version number contained in the Version field of the received If the version number contained in the Version field of the received
OPEN message is not supported, then the Error Subcode is set to OPEN message is not supported, then the Error Subcode is set to
Unsupported Version Number. The Data field is a 1-octet unsigned Unsupported Version Number. The Data field is a 2-octets unsigned
integer, which indicates the largest locally supported version number integer, which indicates the largest locally supported version number
less than the version the remote BGP peer bid (as indicated in the less than the version the remote BGP peer bid (as indicated in the
received OPEN message). received OPEN message).
If the Autonomous System field of the OPEN message is unacceptable, If the Autonomous System field of the OPEN message is unacceptable,
then the Error Subcode is set to Bad Peer AS. The determination of then the Error Subcode is set to Bad Peer AS. The determination of
acceptable Autonomous System numbers is outside the scope of this acceptable Autonomous System numbers is outside the scope of this
protocol. protocol.
If the Hold Time field of the OPEN message is unacceptable, then the If the Hold Time field of the OPEN message is unacceptable, then the
Error Subcode MUST be set to Unacceptable Hold Time. An Error Subcode MUST be set to Unacceptable Hold Time. An
implementation MUST reject Hold Time values of one or two seconds. An implementation MUST reject Hold Time values of one or two seconds.
implementation MAY reject any proposed Hold Time. An implementation An implementation MAY reject any proposed Hold Time. An
which accepts a Hold Time MUST use the negotiated value for the Hold implementation which accepts a Hold Time MUST use the negotiated
Time. value for the Hold Time.
If the BGP Identifier field of the OPEN message is syntactically If the BGP Identifier field of the OPEN message is syntactically
incorrect, then the Error Subcode is set to Bad BGP Identifier. incorrect, then the Error Subcode is set to Bad BGP Identifier.
Syntactic correctness means that the BGP Identifier field represents Syntactic correctness means that the BGP Identifier field represents
a valid IP host address. a valid IP host address.
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 one of the Optional Parameters in the OPEN message is recognized,
but is malformed, then the Error Subcode is set to 0 (Unspecific).
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.
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
skipping to change at page 31, line 25 skipping to change at page 31, line 17
In absence of any fatal errors (that are indicated in this section), In absence of any fatal errors (that are indicated in this section),
a BGP peer may choose at any given time to close its BGP connection a BGP peer may choose at any given time to close its BGP connection
by sending the NOTIFICATION message with Error Code Cease. However, by sending the NOTIFICATION message with Error Code Cease. However,
the Cease NOTIFICATION message must not be used when a fatal error the Cease NOTIFICATION message must not be used when a fatal error
indicated by this section does exist. indicated by this section does exist.
A BGP speaker may support the ability to impose an (locally A BGP speaker may support the ability to impose an (locally
configured) upper bound on the number of address prefixes the speaker configured) upper bound on the number of address prefixes the speaker
is willing to accept from a neighbor. When the upper bound is is willing to accept from a neighbor. When the upper bound is
reached, the speaker (under control of local configuration) may reached, the speaker (under control of local configuration) may
either (a) stop accepting new address prefixes from the neighbor, or either (a) discard new address prefixes from the neighbor, or (b)
(b) terminate the BGP peering with the neighbor. If the BGP speaker terminate the BGP peering with the neighbor. If the BGP speaker
decides to terminate its peering with a neighbor because the number decides to terminate its peering with a neighbor because the number
of address prefixes received from the neighbor exceeds the locally of address prefixes received from the neighbor exceeds the locally
configured upper bound, then the speaker must send to the neighbor a configured upper bound, then the speaker must send to the neighbor a
NOTIFICATION message with the Error Code Cease. NOTIFICATION message with the Error Code Cease.
6.8 Connection collision detection. 6.8 Connection collision detection.
If a pair of BGP speakers try simultaneously to establish a TCP If a pair of BGP speakers try simultaneously to establish a TCP
connection to each other, then two parallel connections between this connection to each other, then two parallel connections between this
pair of speakers might well be formed. We refer to this situation as pair of speakers might well be formed. We refer to this situation as
skipping to change at page 39, line 25 skipping to change at page 39, line 16
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 existence 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 of other routes, the non-existence of other routes, or the 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 the Adj-RIB-In,
and is responsible for: and is responsible for:
- selection of routes to be used locally by the speaker - selection of routes to be used locally by the speaker
- 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
- route aggregation and route information reduction - route aggregation and route information reduction
The Decision Process takes place in three distinct phases, each The Decision Process takes place in three distinct phases, each
triggered by a different event: triggered by a different event:
a) Phase 1 is responsible for calculating the degree of preference a) Phase 1 is responsible for calculating the degree of preference
for each route received from an external peer, and MAY also for each route received from a peer, and MAY also advertise to all
advertise to all the internal peers the routes from external peers the internal peers the routes from external peers that have the
that have the highest degree of preference for each distinct highest degree of preference for each distinct destination.
destination.
b) Phase 2 is invoked on completion of phase 1. It is responsible b) Phase 2 is invoked on completion of phase 1. It is responsible
for choosing the best route out of all those available for each for choosing the best route out of all those available for each
distinct destination, and for installing each chosen route into distinct destination, and for installing each chosen route into
the appropriate Loc-RIB. the Loc-RIB.
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
skipping to change at page 42, line 43 skipping to change at page 42, line 33
Note that a BGP route is considered unresolvable not only in Note that a BGP route is considered unresolvable not only in
situations where the router's Routing Table contains no route situations where the router's Routing Table contains no route
matching the BGP route's NEXT_HOP. Mutually recursive routes (routes matching the BGP route's NEXT_HOP. Mutually recursive routes (routes
resolving each other or themselves), also fail the resolvability resolving each other or themselves), also fail the resolvability
check. check.
It is also important that implementations do not consider feasible It is also important that implementations do not consider feasible
routes that would become unresolvable if they were installed in the routes that would become unresolvable if they were installed in the
Routing Table even if their NEXT_HOPs are resolvable using the Routing Table even if their NEXT_HOPs are resolvable using the
current contents of the Routing Table. This check ensures that a BGP current contents of the Routing Table (an example of such routes
would be mutually recursive routes). This check ensures that a BGP
speaker does not install in the Routing Table routes that will be speaker does not install in the Routing Table routes that will be
removed and not used by the speaker. Therefore, in addition to local removed and not used by the speaker. Therefore, in addition to local
Routing Table stability, this check also improves behavior of the Routing Table stability, this check also improves behavior of the
protocol in the network. protocol in the network.
Whenever a BGP speaker identifies a route that fails the Whenever a BGP speaker identifies a route that fails the
resolvability check because of mutual recursion, an error message resolvability check because of mutual recursion, an error message
should be logged. should be logged.
9.1.2.2 Breaking Ties (Phase 2) 9.1.2.2 Breaking Ties (Phase 2)
skipping to change at page 47, line 42 skipping to change at page 47, line 28
unfeasible route (in form of IP prefixes) in the WITHDRAWN unfeasible route (in form of IP prefixes) in the WITHDRAWN
ROUTES field of an UPDATE message, and shall send this message ROUTES field of an UPDATE message, and shall send this message
to each peer to whom it had previously advertised the to each peer to whom it had previously advertised the
corresponding feasible route. corresponding feasible route.
All feasible routes which are advertised shall be placed in the All feasible routes which are advertised shall be placed in the
appropriate Adj-RIBs-Out, and all unfeasible routes which are appropriate Adj-RIBs-Out, and all unfeasible routes which are
advertised shall be removed from the Adj-RIBs-Out after the advertised shall be removed from the Adj-RIBs-Out after the
corresponding update messages have been sent. corresponding update messages have been sent.
9.2.1.1 Breaking Ties (Internal Updates)
If a local BGP speaker has connections to several external peers,
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 external peers.
The local BGP speaker shall select one of these routes according to
the following rules:
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 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 9.2.2 External Updates
The external update process is concerned with the distribution of The external update process is concerned with the distribution of
routing information to external peers. As part of Phase 3 route routing information to external peers. As part of Phase 3 route
selection process, the BGP speaker has updated its Adj-RIBs-Out and selection process, the BGP speaker has updated its Adj-RIBs-Out and
its Routing Table. All newly installed routes and all newly its Routing Table. All newly installed routes and all newly
unfeasible routes for which there is no replacement route shall be unfeasible routes for which there is no replacement route shall be
advertised to external peers by means of UPDATE message. advertised to external peers by means of UPDATE message.
Any routes in the Loc-RIB marked as unfeasible shall be removed. Any routes in the Loc-RIB marked as unfeasible shall be removed.
skipping to change at page 51, line 38 skipping to change at page 50, line 48
together. Path attributes of the same type code may be aggregated, together. Path attributes of the same type code may be aggregated,
according to the following rules: according to the following rules:
ORIGIN attribute: If at least one route among routes that are ORIGIN attribute: If at least one route among routes that are
aggregated has ORIGIN with the value INCOMPLETE, then the aggregated has ORIGIN with the value INCOMPLETE, then the
aggregated route must have the ORIGIN attribute with the value aggregated route must have the ORIGIN attribute with the value
INCOMPLETE. Otherwise, if at least one route among routes that are INCOMPLETE. Otherwise, if at least one route among routes that are
aggregated has ORIGIN with the value EGP, then the aggregated aggregated has ORIGIN with the value EGP, then the aggregated
route must have the origin attribute with the value EGP. In all route must have the origin attribute with the value EGP. In all
other case the value of the ORIGIN attribute of the aggregated other case the value of the ORIGIN attribute of the aggregated
route is INTERNAL. route is IGP.
AS_PATH attribute: If routes to be aggregated have identical AS_PATH attribute: If routes to be aggregated have identical
AS_PATH attributes, then the aggregated route has the same AS_PATH AS_PATH attributes, then the aggregated route has the same AS_PATH
attribute as each individual route. attribute as each individual route.
For the purpose of aggregating AS_PATH attributes we model each AS For the purpose of aggregating AS_PATH attributes we model each AS
within the AS_PATH attribute as a tuple <type, value>, where within the AS_PATH attribute as a tuple <type, value>, where
"type" identifies a type of the path segment the AS belongs to "type" identifies a type of the path segment the AS belongs to
(e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the (e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the
routes to be aggregated have different AS_PATH attributes, then routes to be aggregated have different AS_PATH attributes, then
the aggregated AS_PATH attribute shall satisfy all of the the aggregated AS_PATH attribute shall satisfy all of the
following conditions: following conditions:
- all tuples of the type AS_SEQUENCE in the aggregated AS_PATH - all tuples of type AS_SEQUENCE in the aggregated AS_PATH
shall appear in all of the AS_PATH in the initial set of routes shall appear in all of the AS_PATH in the initial set of routes
to be aggregated. to be aggregated.
- all tuples of the type AS_SET in the aggregated AS_PATH shall - all tuples of type AS_SET in the aggregated AS_PATH shall
appear in at least one of the AS_PATH in the initial set (they appear in at least one of the AS_PATH in the initial set (they
may appear as either AS_SET or AS_SEQUENCE types). may appear as either AS_SET or AS_SEQUENCE types).
- for any tuple X of the type AS_SEQUENCE in the aggregated - for any tuple X of type AS_SEQUENCE in the aggregated AS_PATH
AS_PATH which precedes tuple Y in the aggregated AS_PATH, X which precedes tuple Y in the aggregated AS_PATH, X precedes Y
precedes Y in each AS_PATH in the initial set which contains Y, in each AS_PATH in the initial set which contains Y, regardless
regardless of the type of Y. of the type of Y.
- No tuple with the same value shall appear more than once in - No tuple of type AS_SET with the same value shall appear more
the aggregated AS_PATH, regardless of the tuple's type. than once in the aggregated AS_PATH.
- Multiple tuples of type AS_SEQUENCE with the same value may
appear in the aggregated AS_PATH only when adjacent to another
tuple of the same type and value.
An implementation may choose any algorithm which conforms to these An implementation may choose any algorithm which conforms to these
rules. At a minimum a conformant implementation shall be able to rules. At a minimum a conformant implementation shall be able to
perform the following algorithm that meets all of the above perform the following algorithm that meets all of the above
conditions: conditions:
- determine the longest leading sequence of tuples (as defined - determine the longest leading sequence of tuples (as defined
above) common to all the AS_PATH attributes of the routes to be above) common to all the AS_PATH attributes of the routes to be
aggregated. Make this sequence the leading sequence of the aggregated. Make this sequence the leading sequence of the
aggregated AS_PATH attribute. aggregated AS_PATH attribute.
skipping to change at page 56, line 25 skipping to change at page 55, line 40
If a local system TCP user interface supports TCP PUSH function, then If a local system TCP user interface supports TCP PUSH function, then
each BGP message should be transmitted with PUSH flag set. Setting each BGP message should be transmitted with PUSH flag set. Setting
PUSH flag forces BGP messages to be transmitted promptly to the PUSH flag forces BGP messages to be transmitted promptly to the
receiver. receiver.
If a local system TCP user interface supports setting precedence for If a local system TCP user interface supports setting precedence for
TCP connection, then the BGP transport connection should be opened TCP connection, then the BGP transport connection should be opened
with precedence set to Internetwork Control (110) value (see also with precedence set to Internetwork Control (110) value (see also
[6]). [6]).
A local system may protect its BGP sessions by using the TCP MD5
Signature Option [10].
Appendix 6. Implementation Recommendations Appendix 6. Implementation Recommendations
This section presents some implementation recommendations. This section presents some implementation recommendations.
6.1 Multiple Networks Per Message 6.1 Multiple Networks Per Message
The BGP protocol allows for multiple address prefixes with the same The BGP protocol allows for multiple address prefixes with the same
path attributes to be specified in one message. Making use of this path attributes to be specified in one message. Making use of this
capability is highly recommended. With one address prefix per message capability is highly recommended. With one address prefix per message
there is a substantial increase in overhead in the receiver. Not only there is a substantial increase in overhead in the receiver. Not only
skipping to change at page 58, line 17 skipping to change at page 57, line 30
To avoid excessive route flapping a BGP speaker which needs to To avoid excessive route flapping a BGP speaker which needs to
withdraw a destination and send an update about a more specific or withdraw a destination and send an update about a more specific or
less specific route SHOULD combine them into the same UPDATE message. less specific route SHOULD combine them into the same UPDATE message.
6.4 BGP Timers 6.4 BGP Timers
BGP employs five timers: ConnectRetry, Hold Time, KeepAlive, BGP employs five timers: ConnectRetry, Hold Time, KeepAlive,
MinASOriginationInterval, and MinRouteAdvertisementInterval The MinASOriginationInterval, and MinRouteAdvertisementInterval The
suggested value for the ConnectRetry timer is 120 seconds. The suggested value for the ConnectRetry timer is 120 seconds. The
suggested value for the Hold Time is 90 seconds. The suggested value suggested value for the Hold Time is 90 seconds. The suggested value
for the KeepAlive timer is 30 seconds. The suggested value for the for the KeepAlive timer is 1/3 of the Hold Time. The suggested value
MinASOriginationInterval is 15 seconds. The suggested value for the for the MinASOriginationInterval is 15 seconds. The suggested value
MinRouteAdvertisementInterval is 30 seconds. for the MinRouteAdvertisementInterval is 30 seconds.
An implementation of BGP MUST allow these timers to be configurable. An implementation of BGP MUST allow the Hold Time timer to be
configurable, and MAY allow the other timers to be configurable.
6.5 Path attribute ordering 6.5 Path attribute ordering
Implementations which combine update messages as described above in Implementations which combine update messages as described above in
6.1 may prefer to see all path attributes presented in a known order. 6.1 may prefer to see all path attributes presented in a known order.
This permits them to quickly identify sets of attributes from This permits them to quickly identify sets of attributes from
different update messages which are semantically identical. To different update messages which are semantically identical. To
facilitate this, it is a useful optimization to order the path facilitate this, it is a useful optimization to order the path
attributes according to type code. This optimization is entirely attributes according to type code. This optimization is entirely
optional. optional.
 End of changes. 

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