draft-ietf-idr-bgp4-19.txt   draft-ietf-idr-bgp4-20.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.
S. Hares S. Hares
NextHop Technologies, Inc. NextHop Technologies, Inc.
Editors Editors
A Border Gateway Protocol 4 (BGP-4) A Border Gateway Protocol 4 (BGP-4)
<draft-ietf-idr-bgp4-19.txt> <draft-ietf-idr-bgp4-20.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 2, line 5 skipping to change at page 2, line 5
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
TTaabbllee ooff CCoonntteennttss Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Definition of commonly used terms . . . . . . . . . . . . . . 4 1. Definition of commonly used terms . . . . . . . . . . . . . . 4
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
3. Summary of Operation . . . . . . . . . . . . . . . . . . . . . 7 3. Summary of Operation . . . . . . . . . . . . . . . . . . . . . 7
3.1 Routes: Advertisement and Storage . . . . . . . . . . . . . . 9 3.1 Routes: Advertisement and Storage . . . . . . . . . . . . . . 9
3.2 Routing Information Bases . . . . . . . . . . . . . . . . . . 10 3.2 Routing Information Bases . . . . . . . . . . . . . . . . . . 10
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Message Header Format . . . . . . . . . . . . . . . . . . . . 11 4.1 Message Header Format . . . . . . . . . . . . . . . . . . . . 11
4.2 OPEN Message Format . . . . . . . . . . . . . . . . . . . . . 12 4.2 OPEN Message Format . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 2, line 41 skipping to change at page 2, line 41
6.3 UPDATE message error handling . . . . . . . . . . . . . . . . 32 6.3 UPDATE message error handling . . . . . . . . . . . . . . . . 32
6.4 NOTIFICATION message error handling . . . . . . . . . . . . . 34 6.4 NOTIFICATION message error handling . . . . . . . . . . . . . 34
6.5 Hold Timer Expired error handling . . . . . . . . . . . . . . 34 6.5 Hold Timer Expired error handling . . . . . . . . . . . . . . 34
6.6 Finite State Machine error handling . . . . . . . . . . . . . 34 6.6 Finite State Machine error handling . . . . . . . . . . . . . 34
6.7 Cease . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.7 Cease . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.8 BGP connection collision detection . . . . . . . . . . . . . 35 6.8 BGP connection collision detection . . . . . . . . . . . . . 35
7. BGP Version Negotiation . . . . . . . . . . . . . . . . . . . 36 7. BGP Version Negotiation . . . . . . . . . . . . . . . . . . . 36
8. BGP Finite State machine . . . . . . . . . . . . . . . . . . . 36 8. BGP Finite State machine . . . . . . . . . . . . . . . . . . . 36
8.1 Events for the BGP FSM . . . . . . . . . . . . . . . . . . . 37 8.1 Events for the BGP FSM . . . . . . . . . . . . . . . . . . . 37
8.1.1 Administrative Events . . . . . . . . . . . . . . . . . . 37 8.1.1 Administrative Events . . . . . . . . . . . . . . . . . . 37
8.1.2 Timer Events . . . . . . . . . . . . . . . . . . . . . . . 38 8.1.2 Timer Events . . . . . . . . . . . . . . . . . . . . . . . 40
8.1.3 TCP connection based Events . . . . . . . . . . . . . . . . 39 8.1.3 TCP connection based Events . . . . . . . . . . . . . . . . 41
8.1.4 BGP Messages based Events . . . . . . . . . . . . . . . . . 41 8.1.4 BGP Messages based Events . . . . . . . . . . . . . . . . . 43
8.2 Description of FSM . . . . . . . . . . . . . . . . . . . . . 43 8.2 Description of FSM . . . . . . . . . . . . . . . . . . . . . 45
8.2.1 FSM Definition . . . . . . . . . . . . . . . . . . . . . . 43 8.2.1 FSM Definition . . . . . . . . . . . . . . . . . . . . . . 45
8.2.1.1 Terms "active" and "passive" . . . . . . . . . . . . . . 43 8.2.1.1 Terms "active" and "passive" . . . . . . . . . . . . . . 46
8.2.1.2 FSM and collision detection . . . . . . . . . . . . . . . 44 8.2.1.2 FSM and collision detection . . . . . . . . . . . . . . . 46
8.2.2 Finite State Machine . . . . . . . . . . . . . . . . . . . 44 8.2.1.3 FSM and Optional Attributes . . . . . . . . . . . . . . 47
9. UPDATE Message Handling . . . . . . . . . . . . . . . . . . . 57 8.2.1.4 FSM Event numbers . . . . . . . . . . . . . . . . . . . . 47
9.1 Decision Process . . . . . . . . . . . . . . . . . . . . . . 58 8.2.2 Finite State Machine . . . . . . . . . . . . . . . . . . . 47
9.1.1 Phase 1: Calculation of Degree of Preference . . . . . . . 59 9. UPDATE Message Handling . . . . . . . . . . . . . . . . . . . 62
9.1.2 Phase 2: Route Selection . . . . . . . . . . . . . . . . . 60 9.1 Decision Process . . . . . . . . . . . . . . . . . . . . . . 63
9.1.2.1 Route Resolvability Condition . . . . . . . . . . . . . . 61 9.1.1 Phase 1: Calculation of Degree of Preference . . . . . . . 64
9.1.2.2 Breaking Ties (Phase 2) . . . . . . . . . . . . . . . . . 62 9.1.2 Phase 2: Route Selection . . . . . . . . . . . . . . . . . 65
9.1.3 Phase 3: Route Dissemination . . . . . . . . . . . . . . . 64 9.1.2.1 Route Resolvability Condition . . . . . . . . . . . . . . 66
9.1.4 Overlapping Routes . . . . . . . . . . . . . . . . . . . . 65 9.1.2.2 Breaking Ties (Phase 2) . . . . . . . . . . . . . . . . . 67
9.2 Update-Send Process . . . . . . . . . . . . . . . . . . . . . 66 9.1.3 Phase 3: Route Dissemination . . . . . . . . . . . . . . . 69
9.2.1 Controlling Routing Traffic Overhead . . . . . . . . . . . 67 9.1.4 Overlapping Routes . . . . . . . . . . . . . . . . . . . . 70
9.2.1.1 Frequency of Route Advertisement . . . . . . . . . . . . 67 9.2 Update-Send Process . . . . . . . . . . . . . . . . . . . . . 71
9.2.1.2 Frequency of Route Origination . . . . . . . . . . . . . 68 9.2.1 Controlling Routing Traffic Overhead . . . . . . . . . . . 72
9.2.2 Efficient Organization of Routing Information . . . . . . . 68 9.2.1.1 Frequency of Route Advertisement . . . . . . . . . . . . 72
9.2.2.1 Information Reduction . . . . . . . . . . . . . . . . . . 68 9.2.1.2 Frequency of Route Origination . . . . . . . . . . . . . 73
9.2.2.2 Aggregating Routing Information . . . . . . . . . . . . . 69 9.2.2 Efficient Organization of Routing Information . . . . . . . 73
9.3 Route Selection Criteria . . . . . . . . . . . . . . . . . . 72 9.2.2.1 Information Reduction . . . . . . . . . . . . . . . . . . 73
9.4 Originating BGP routes . . . . . . . . . . . . . . . . . . . 72 9.2.2.2 Aggregating Routing Information . . . . . . . . . . . . . 74
10. BGP Timers . . . . . . . . . . . . . . . . . . . . . . . . . 72 9.3 Route Selection Criteria . . . . . . . . . . . . . . . . . . 76
Appendix A. Comparison with RFC1771 . . . . . . . . . . . . . . . 73 9.4 Originating BGP routes . . . . . . . . . . . . . . . . . . . 77
Appendix B. Comparison with RFC1267 . . . . . . . . . . . . . . . 74 10. BGP Timers . . . . . . . . . . . . . . . . . . . . . . . . . 77
Appendix C. Comparison with RFC 1163 . . . . . . . . . . . . . . 75 Appendix A. Comparison with RFC1771 . . . . . . . . . . . . . . . 78
Appendix D. Comparison with RFC 1105 . . . . . . . . . . . . . . 75 Appendix B. Comparison with RFC1267 . . . . . . . . . . . . . . . 79
Appendix E. TCP options that may be used with BGP . . . . . . . . 76 Appendix C. Comparison with RFC 1163 . . . . . . . . . . . . . . 80
Appendix F. Implementation Recommendations . . . . . . . . . . . 76 Appendix D. Comparison with RFC 1105 . . . . . . . . . . . . . . 80
Appendix F.1 Multiple Networks Per Message . . . . . . . . . . . 76 Appendix E. TCP options that may be used with BGP . . . . . . . . 81
Appendix F.2 Reducing route flapping . . . . . . . . . . . . . . 77 Appendix F. Implementation Recommendations . . . . . . . . . . . 81
Appendix F.3 Path attribute ordering . . . . . . . . . . . . . . 77 Appendix F.1 Multiple Networks Per Message . . . . . . . . . . . 81
Appendix F.4 AS_SET sorting . . . . . . . . . . . . . . . . . . . 77 Appendix F.2 Reducing route flapping . . . . . . . . . . . . . . 82
Appendix F.5 Control over version negotiation . . . . . . . . . . 78 Appendix F.3 Path attribute ordering . . . . . . . . . . . . . . 82
Appendix F.6 Complex AS_PATH aggregation . . . . . . . . . . . . 78 Appendix F.4 AS_SET sorting . . . . . . . . . . . . . . . . . . . 82
Security Considerations . . . . . . . . . . . . . . . . . . . . . 79 Appendix F.5 Control over version negotiation . . . . . . . . . . 83
IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 79 Appendix F.6 Complex AS_PATH aggregation . . . . . . . . . . . . 83
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Security Considerations . . . . . . . . . . . . . . . . . . . . . 84
Authors Information . . . . . . . . . . . . . . . . . . . . . . . 80 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 84
Normative References . . . . . . . . . . . . . . . . . . . . . . 84
Non-normative References . . . . . . . . . . . . . . . . . . . . 85
Authors Information . . . . . . . . . . . . . . . . . . . . . . . 86
Abstract Abstract
The Border Gateway Protocol (BGP) is an inter-Autonomous System rout- The Border Gateway Protocol (BGP) is an inter-Autonomous System rout-
ing protocol. ing protocol.
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 reacha- reachability information with other BGP systems. This network reacha-
bility information includes information on the list of Autonomous bility information includes information on the list of Autonomous
Systems (ASs) that reachability information traverses. This informa- Systems (ASs) that reachability information traverses. This informa-
skipping to change at page 4, line 38 skipping to change at page 4, line 38
header of the packet. This, in turn, reflects the set of policy deci- header of the packet. This, in turn, reflects the set of policy deci-
sions that can (and can not) be enforced using BGP. BGP can support sions that can (and can not) be enforced using BGP. BGP can support
only the policies conforming to the destination-based forwarding only the policies conforming to the destination-based forwarding
paradigm. paradigm.
1. Definition of commonly used terms 1. Definition of commonly used terms
This section provides definition for terms that have a specific mean- This section provides definition for terms that have a specific mean-
ing to the BGP protocol and that are used throughout the text. ing to the BGP protocol and that are used throughout the text.
Adj-RIB-In
The Adj-RIBs-In contain unprocessed routing information that has
been advertised to the local BGP speaker by its peers.
Adj-RIB-Out
The Adj-RIBs-Out contains the routes for advertisement to specific
peers by means of the local speaker's UPDATE messages.
Autonomous System (AS) Autonomous System (AS)
The classic definition of an Autonomous System is a set of routers The classic definition of an Autonomous System is a set of routers
under a single technical administration, using an interior gateway under a single technical administration, using an interior gateway
protocol (IGP) and common metrics to determine how to route pack- protocol (IGP) and common metrics to determine how to route pack-
ets within the AS, and using an inter-AS routing protocol to ets within the AS, and using an inter-AS routing protocol to
determine how to route packets to other ASs. Since this classic determine how to route packets to other ASs. Since this classic
definition was developed, it has become common for a single AS to definition was developed, it has become common for a single AS to
use several IGPs and sometimes several sets of metrics within an use several IGPs and sometimes several sets of metrics within an
AS. The use of the term Autonomous System here stresses the fact AS. The use of the term Autonomous System here stresses the fact
that, even when multiple IGPs and metrics are used, the adminis- that, even when multiple IGPs and metrics are used, the adminis-
tration of an AS appears to other ASs to have a single coherent tration of an AS appears to other ASs to have a single coherent
interior routing plan and presents a consistent picture of what interior routing plan and presents a consistent picture of what
destinations are reachable through it. destinations are reachable through it.
BGP speaker
A router that implements BGP.
BGP Identifier BGP Identifier
A 4-octet unsigned integer indicating the BGP Identifier of the A 4-octet unsigned integer indicating the BGP Identifier of the
sender of BGP messages. A given BGP speaker sets the value of its sender of BGP messages. A given BGP speaker sets the value of its
BGP Identifier to an IP address assigned to that BGP speaker. The BGP Identifier to an IP address assigned to that BGP speaker. The
value of the BGP Identifier is determined on startup and is the value of the BGP Identifier is determined on startup and is the
same for every local interface and every BGP peer. same for every local interface and every BGP peer.
Internal peer BGP speaker
Peer that is in the same Autonomous System as the local system. A router that implements BGP.
IBGP EBGP
Internal BGP (BGP connection between internal peers). External BGP (BGP connection between external peers).
External peer External peer
Peer that is in a different Autonomous System than the local sys- Peer that is in a different Autonomous System than the local sys-
tem. tem.
EBGP Feasible route
External BGP (BGP connection between external peers). A route that is available for use.
IBGP
Internal BGP (BGP connection between internal peers).
Internal peer
Peer that is in the same Autonomous System as the local system.
IGP
Interior Gateway Protocol - a routing protocol used to exchange
routing information among routers within a single Autonomous Sys-
tem.
Loc-RIB
The Loc-RIB contains the routes that have been selected by the
local BGP speaker's Decision Process.
NLRI NLRI
Network Layer Reachability Information. Network Layer Reachability Information.
Route Route
A unit of information that pairs a set of destinations with the A unit of information that pairs a set of destinations with the
attributes of a path to those destinations. The set of destina- attributes of a path to those destinations. The set of destina-
tions are systems whose IP addresses are contained in one IP tions are systems whose IP addresses are contained in one IP
address prefix carried in the Network Layer Reachability Informa- address prefix carried in the Network Layer Reachability Informa-
tion (NLRI) field of an UPDATE message. The path is the informa- tion (NLRI) field of an UPDATE message. The path is the informa-
tion reported in the path attributes field of the same UPDATE mes- tion reported in the path attributes field of the same UPDATE mes-
sage. sage.
RIB RIB
Routing Information Base. Routing Information Base.
Adj-RIB-In
The Adj-RIBs-In contain unprocessed routing information that has
been advertised to the local BGP speaker by its peers.
Loc-RIB
The Loc-RIB contains the routes that have been selected by the
local BGP speaker's Decision Process.
Adj-RIB-Out
The Adj-RIBs-Out contains the routes for advertisement to specific
peers by means of the local speaker's UPDATE messages.
IGP
Interior Gateway Protocol - a routing protocol used to exchange
routing information among routers within a single Autonomous Sys-
tem.
Feasible route
A route that is available for use.
Unfeasible route Unfeasible route
A previously advertised feasible route that is no longer available A previously advertised feasible route that is no longer available
for use. for use.
2. Acknowledgments 2. Acknowledgments
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 and Yakov Rekhter. jointly authored by Kirk Lougheed and Yakov Rekhter.
We would like to express our thanks to Guy Almes, Len Bosack, and We would like to express our thanks to Guy Almes, Len Bosack, and
skipping to change at page 36, line 38 skipping to change at page 36, line 38
of BGP MUST retain the format of the OPEN and NOTIFICATION messages. of BGP MUST retain the format of the OPEN and NOTIFICATION messages.
8. BGP Finite State machine 8. BGP Finite State machine
This section specifies the BGP operation in terms of a Finite State This section specifies the BGP operation in terms of a Finite State
Machine (FSM). The section falls into 2 parts: Machine (FSM). The section falls into 2 parts:
1) Description of Events for the State machine (Section 8.1) 1) Description of Events for the State machine (Section 8.1)
2) Description of the FSM (Section 8.2) 2) Description of the FSM (Section 8.2)
Session Attributes required for each connection are; The data structures and FSM described in this document are conceptual
and do not have to be implemented precisely as described here, as
long as the implementations support the described functionality and
their externally visible behavior is the same.
Session Attributes required for each connection are:
1) State 1) State
2) Connect Retry timer 2) Connect Retry timer
3) Hold timer 3) Hold timer
4) Hold time 4) Hold time
5) Keepalive timer 5) Keepalive timer
6) Keepalive time 6) Keepalive time
7) Connect Retry Count 7) Connect Retry Count
8) Connect Retry Initial Value 8) Connect Retry Initial Value
The optional Session attributes are listed below. These optional The optional Session attributes are listed below. These optional
attributes may be supported either per connection or per local sys- attributes may be supported either per connection or per local sys-
tem: tem:
1) Delay Open flag 1) Delay Open flag
2) Open Delay Timer 2) Open Delay Timer
3) Perform automatic start flag 3) Perform automatic start flag
4) Perform automatic stop flag 4) Perform automatic stop flag
5) Passive TCP establishment flag 5) Passive TCP establishment flag
6) Perform BGP peer oscillation damping flag 6) Perform BGP peer oscillation damping flag
skipping to change at page 37, line 42 skipping to change at page 38, line 4
Definition: Local system administrator manually starts peer Definition: Local system administrator manually starts peer
connection. connection.
Status: Mandatory Status: Mandatory
Optional Optional
attributes: Passive TCP establishment flag SHOULD not be set. attributes: Passive TCP establishment flag SHOULD not be set.
Event2: Manual stop Event2: Manual stop
Definition: Local system administrator manually Definition: Local system administrator manually
stops the peer connection. stops the peer connection.
Status: Mandatory Status: Mandatory
Event3: Automatic start Event3: Automatic start
Definition: Local system automatically starts the Definition: Local system automatically starts the
BGP connection. BGP connection.
Status: Optional depending on local system. Status: Optional depending on local system.
Optional Optional
attributes: 1) Perform automatic start flag SHOULD be set. attributes: 1) Perform automatic start flag SHOULD be set
if this event occurs. if this event occurs.
2) if the passive Passive TCP establishment flag 2) if the passive Passive TCP establishment flag
is supported, it SHOULD not be set if this is supported, it SHOULD not be set if this
event occurs. event occurs.
3) if bgp peer oscillation damping is supported, 3) if bgp peer oscillation damping is supported,
the BGP stop_peer_flap flag should not be set the BGP stop_peer_flap flag should not be set
when this event occurs. when this event occurs.
Event4: Manual start with passive TCP flag Event4: Manual start with passive TCP flag
skipping to change at page 38, line 35 skipping to change at page 38, line 40
enabled. The passive TCP establishment flag indicates enabled. The passive TCP establishment flag indicates
that the peer will listen prior to that the peer will listen prior to
establishing the connection. establishing the connection.
Status: Optional depending on local system. Status: Optional depending on local system.
Optional Optional
attributes: 1) Passive TCP Establishment flag SHOULD be set. attributes: 1) Passive TCP Establishment flag SHOULD be set.
if this event occurs. if this event occurs.
2) If bgp peer oscilation damping is supported, the 2) If bgp peer oscilation damping is supported, the
stop_peer_flap falg should not be set when stop_peer_flap flag should not be set when
this event occurs. this event occurs.
Event5: Automatic start with passive TCP flag Event5: Automatic start with passive TCP flag
Definition: Local system automatically starts the Definition: Local system automatically starts the
BGP connection with the passive flag BGP connection with the passive flag
enabled. The passive flag indicates enabled. The passive flag indicates
that the peer will listen prior to that the peer will listen prior to
establishing a connection. establishing a connection.
skipping to change at page 46, line 7 skipping to change at page 46, line 12
8.2 Description of FSM 8.2 Description of FSM
8.2.1 FSM Definition 8.2.1 FSM Definition
BGP MUST maintain a separate FSM for each configured peer, Each BGP BGP MUST maintain a separate FSM for each configured peer, Each BGP
peer paired in a potential connection unless configured to remain in peer paired in a potential connection unless configured to remain in
the idle state, or configured to remain passive, will attempt to to the idle state, or configured to remain passive, will attempt to to
connect to the other. For the purpose of this discussion, the active connect to the other. For the purpose of this discussion, the active
or connect side of the TCP connection (the side of a TCP connection or connect side of the TCP connection (the side of a TCP connection
(the side sending the first TCP SYN packet) is called outgoing. The sending the first TCP SYN packet) is called outgoing. The passive or
passive or listening side (the sender of the first SYN ACK) is called listening side (the sender of the first SYN ACK) is called an incom-
an incoming connection (see Section 8.2.1.1 on the terms active and ing connection (see Section 8.2.1.1 on the terms active and passive
passive below). below).
A BGP implementation MUST connect to and listen on TCP port 179 for A BGP implementation MUST connect to and listen on TCP port 179 for
incoming connections in addition to trying to connect to peers. For incoming connections in addition to trying to connect to peers. For
each incoming connection, a state machine MUST be instantiated. each incoming connection, a state machine MUST be instantiated.
There exists a period in which the identity of the peer on the other There exists a period in which the identity of the peer on the other
end of an incoming connection is known but the BGP identifier is not end of an incoming connection is known but the BGP identifier is not
known. During this time, both an incoming and an outgoing connection known. During this time, both an incoming and an outgoing connection
for the same configured peering may exist. This is referred to as a for the same configured peering may exist. This is referred to as a
connection collision (see Section 6.8). connection collision (see Section 6.8).
skipping to change at page 47, line 15 skipping to change at page 47, line 20
The collision detection identifies the case where there is more than The collision detection identifies the case where there is more than
one connection per peer and provides guidance for which connection to one connection per peer and provides guidance for which connection to
get rid of. When this occurs, the corresponding FSM for the connec- get rid of. When this occurs, the corresponding FSM for the connec-
tion that is closed SHOULD be disposed of. tion that is closed SHOULD be disposed of.
8.2.1.3 FSM and Optional Attributes 8.2.1.3 FSM and Optional Attributes
Optional Attributes specify either flags that augment the normal pro- Optional Attributes specify either flags that augment the normal pro-
cessing of the BGP FSM, or optional timers. If a Optional attribute cessing of the BGP FSM, or optional timers. If a Optional attribute
can be set on a system, the Events and the BGP FSM actions must be can be set on a system, the Events and the BGP FSM actions must be
support. For example, if the following options can be set in a BGP supported. For example, if the following options can be set in a BGP
implementation: AutoStart and Passive TCP connection Establishment implementation: AutoStart and Passive TCP connection Establishment
flag, then the events 3, 4 and 5 must be supported. flag, then the events 3, 4 and 5 must be supported.
If an Optional attribute is cannot be set (that is declared always If an Optional attribute cannot be set (that is declared always off
off logically), the events supporting that set of options do not have logically), the events supporting that set of options do not have to
to be supported. be supported.
8.2.1.4 FSM Event numbers 8.2.1.4 FSM Event numbers
The Event numbers (1-28) utilized in this state machine description The Event numbers (1-28) utilized in this state machine description
aid in specifying the behavior of the BGP state machine. Implementa- aid in specifying the behavior of the BGP state machine. Implementa-
tions MAY use these numbers to provide network management informa- tions MAY use these numbers to provide network management informa-
tion. tion. The exact form of the FSM and the FSM events is specific to
each implementation.
8.2.2 Finite State Machine 8.2.2 Finite State Machine
Idle state: Idle state:
Initially BGP is in the Idle state. Initially BGP is in the Idle state.
In this state BGP refuses all incoming BGP connections. No In this state BGP refuses all incoming BGP connections. No
resources are allocated to the peer. In response to a resources are allocated to the peer. In response to a
manual start event(Event1) or an automatic start manual start event(Event1) or an automatic start
event(Event3), the local system: event(Event3), the local system:
- initializes all BGP resources, - initializes all BGP resources,
- sets ConnectRetryCnt (the connect retry counter) to zero - sets ConnectRetryCnt (the connect retry counter) to zero
- starts the connect retry timer with initial value, - starts the Connect Retry timer with initial value,
- initiates a TCP connection to the other BGP peer, - initiates a TCP connection to the other BGP peer,
- listens for a connection that may be initiated by - listens for a connection that may be initiated by
the remote BGP peer, and the remote BGP peer, and
- changes its state to Connect. - changes its state to Connect.
An manual stop event (Event2) and Auto stop (Event 8) events are The manual stop event (Event2) and Automatic stop event (Event 8)
are ignored in the Idle state. are ignored in the Idle state.
In response to a manual start event with the passive TCP connection In response to a manual start event with the passive TCP connection
flag (Event 4) or automatic start with the passive TCP connection flag (Event 4) or automatic start with the passive TCP connection
flag (Event 5), the local system: flag (Event 5), the local system:
- initializes all BGP resources, - initializes all BGP resources,
- sets ConnectRetryCnt (the connect retry counter) to zero, - sets ConnectRetryCnt (the connect retry counter) to zero,
- starts the connect retry timer with initial value, - starts the Connect Retry timer with initial value,
- listens for a connection that may be initiated by - listens for a connection that may be initiated by
the remote peer, and the remote peer, and
- changes its state to Active. - changes its state to Active.
The exact value of the ConnectRetry timer is a local The exact value of the ConnectRetry timer is a local
matter, but it SHOULD be sufficiently large to allow TCP matter, but it SHOULD be sufficiently large to allow TCP
initialization. initialization.
If the persistent peer oscillation damping function is If the persistent peer oscillation damping function is
enabled, three additional events may occur within Idle state: enabled, three additional events may occur within Idle state:
- Automatic start with peer_stop_flap set [Event6], - Automatic start with peer_stop_flap set [Event6],
- Automatic start with peer_stop_flag set [Event7], - Automatic start with peer_stop_flap set and
passive TCP establishment flag set [Event7],
- Idle Hold Timer expired [Event 13]. - Idle Hold Timer expired [Event 13].
The method of preventing persistent peer oscillation is The method of preventing persistent peer oscillation is
outside the scope of this document. outside the scope of this document.
Any other events [Events 9-12, 15-28] received in the Idle state does Any other events [Events 9-12, 15-28] received in the Idle state
not cause change in the state of the local system. does not cause change in the state of the local system.
Connect State: Connect State:
In this state, BGP is waiting for the TCP connection to In this state, BGP is waiting for the TCP connection to
be completed. be completed.
The start events [Event 1, 3-7] are ignored in connect The start events [Event 1, 3-7] are ignored in connect
state. state.
In response to a manual stop event [Event2], the local system: In response to a manual stop event [Event2], the local system:
- drops the TCP connection, - drops the TCP connection,
- releases all BGP resources, - releases all BGP resources,
- sets ConnectRetryCnt (the connect retry count) to zero - sets ConnectRetryCnt (the connect retry count) to zero
- resets the connect retry timer (sets to zero), and - sets the Connect Retry timer to zero, and
- changes its state to Idle. - changes its state to Idle.
In response to the connect retry timer expires event [Event In response to the Connect Retry timer expires event [Event
9], the local system: 9], the local system:
- drops the TCP connection, - drops the TCP connection,
- restarts the connect retry timer, - restarts the Connect Retry timer,
- stops the Open Delay timer and resets the timer to zero, - stops the Open Delay timer and resets the timer to zero,
- initiates a TCP connection to the other BGP peer, - initiates a TCP connection to the other BGP peer,
- continues to listen for a connection that may be - continues to listen for a connection that may be
initiated by the remote BGP peer, and initiated by the remote BGP peer, and
- stays in Connect state. - stays in Connect state.
If the Open Delay timer expires [Event12] in the connect If the Open Delay timer expires [Event12] in the connect
state, the local system: state, the local system:
- sends an OPEN message to its peer, - sends an OPEN message to its peer,
- sets the hold timer to a large value, and - sets the hold timer to a large value, and
- changes its state to OpenSent. - changes its state to OpenSent.
If the BGP port receives a valid TCP connection indication If the BGP port receives a valid TCP connection indication
[Event 14], the TCP connection is processed and [Event 14], the TCP connection is processed and
the connection remains in the Connect state. the connection remains in the Connect state.
If the TCP connection receives an invalid indication [Event 15]: If the TCP connection receives an invalid indication [Event 15]:
the local system rejects the TCP connection and the connection the local system rejects the TCP connection and the connection
remains in the Connect state. remains in the Connect state.
If the TCP connection succeeds [Event 16 or If the TCP connection succeeds [Event 16 or Event 17],
Event 17], the local system checks the Delay Open flag prior the local system checks the Delay Open flag prior to
to processing. If the Delay Open flag is set, the local system: processing. If the Delay Open flag is set, the local system:
- clears the connect retry timer, - sets the Connect Retry timer to zero,
- set the Open Delay timer to the initial value, and - set the Open Delay timer to the initial value, and
- stays in the Connect state. - stays in the Connect state.
If the Delay Open flag is not set, the local system: If the Delay Open flag is not set, the local system:
- clears the connect retry timer, - sets the Connect Retry timer to zero,
- completes BGP initialization - completes BGP initialization
- sends an OPEN message to its peer, - sends an OPEN message to its peer,
- sets hold timer to a large value, and - sets hold timer to a large value, and
- changes its state to OpenSent. - changes its state to OpenSent.
A hold timer value of 4 minutes is suggested. A hold timer value of 4 minutes is suggested.
If the TCP connection fails [Event18], the local system checks If the TCP connection fails [Event18], the local system checks
the Open Delay Timer. If the Open Delay timer is running, the Open Delay Timer. If the Open Delay timer is running,
the local system: the local system:
- restarts the connect retry time with initial value, - restarts the connect retry time with initial value,
- stops the Open Delay timer and resets value to zero, - stops the Open Delay timer and resets value to zero,
- continues to listen for a connection that may be - continues to listen for a connection that may be
initiated by the remote BGP peer, and initiated by the remote BGP peer, and
- changes its state to Active. - changes its state to Active.
If the open Delay timer is not running, the local system: If the open Delay timer is not running, the local system:
- sets the Connect Retry timer to zero,
- resets the connect retry timer (sets to zero), and - drops the TCP connection,
- Drops the TCP connection, - releases all BGP resources, and
- Releases all BGP resources, - changes its state to Idle.
- and goes to Idle State.
If an OPEN message is received with the Open Delay timer is If an OPEN message is received with the Open Delay timer is
running [Event 20], the local system: running [Event 20], the local system:
- clears the connect retry timer (cleared to zero), - sets the Connect Retry timer to zero,
- completes the BGP initialization, - completes the BGP initialization,
- stops and clears the Open Delay timer, - stops and clears the Open Delay timer (sets the value to zero),
- sends an OPEN message, - sends an OPEN message,
- sends a Keepalive message, - sends a KEEPALIVE message,
- If the hold timer value is non-zero, - If the hold timer value is non-zero,
- start the keepalive timer to inital value, - start the keepalive timer to inital value,
- reset the hold timer to the negotiated value, - reset the hold timer to the negotiated value,
else if hold timer value is zero, else if hold timer value is zero,
- reset the keepalive timer. and - reset the keepalive timer, and
- reset the hold timer value to zero. - reset the hold timer value to zero
- and changes its state to OpenConfirm. - and changes its state to OpenConfirm.
If the value of the autonomous system field is the same as the local If the value of the autonomous system field is the same as the local
Autonomous System number, set the connection status to an internal Autonomous System number, set the connection status to an internal
connection; otherwise it is "external". connection; otherwise it is "external".
If BGP message header checking detects an error [Event 21] or If BGP message header checking detects an error [Event 21] or
OPEN message checking detects an error [Event 22] (see section OPEN message checking detects an error [Event 22] (see section
6.2), the local system: 6.2), the local system:
- (optionally) If the Send Notification without Open flag is set, - (optionally) If the Send Notification without Open flag is set,
then the local system first sends a NOTIFICATION message then the local system first sends a NOTIFICATION message
with the appropriate error code, and then with the appropriate error code, and then
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, - increments the ConnectRetryCnt (connect retry count) by 1,
- [optionally] performs peer oscillation damping, - optionally performs peer oscillation damping,
- and goes to Idle. - and changes its state to Idle.
If a NOTIFICATION message is received with a version If a NOTIFICATION message is received with a version
error[Event24], the local system checks the Open Delay timer. error[Event24], the local system checks the Open Delay timer.
If the Open Delay timer is running, the local system: If the Open Delay timer is running, the local system:
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- stops and reset the Open Delay timer (sets to zero), - stops and reset the Open Delay timer (sets to zero),
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection, and
- changes its state to Idle. - changes its state to Idle.
If the Open Delay timer is not running, the local system: If the Open Delay timer is not running, the local system:
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, - increments the ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
In response to any other events [Events 8,10-11,13,19,23, In response to any other events [Events 8,10-11,13,19,23,
25-28] the local system: 25-28] the local system:
- if the connect retry timer is running, - if the Connect Retry timer is running,
stop and reset the connect retry timer (sets to zero), stop and reset the Connect Retry timer (sets to zero),
- if the Delay Open timer is running, - if the Open Delay timer is running,
stop and reset the Delay Open timer (sets to zero), stop and reset the Open Delay timer (sets to zero),
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, - increments the ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
Active State: Active State:
In this state BGP is trying to acquire a peer by listening In this state BGP is trying to acquire a peer by listening
for and accepting a TCP connection. for and accepting a TCP connection.
The start events [Event1, 3-7] are ignored in the Active The start events [Event1, 3-7] are ignored in the Active
state. state.
A manual stop event[Event2], the local system: In response to a manual stop event[Event2], the local system:
- If the Delay Open timer is running and the - If the Open Delay timer is running and the
Send NOTIFICATION without Open flag is set, Send NOTIFICATION without Open flag is set,
the local system Sends a NOTIFICATION with a Cease, the local system Sends a NOTIFICATION with a Cease,
- releases all BGP resources including - releases all BGP resources including
- stopping the Open delay timer - stopping the Open delay timer
- drops the TCP connection, - drops the TCP connection,
- sets ConnectRetryCnt (connect retry count) to zero - sets ConnectRetryCnt (connect retry count) to zero
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero, and
- changes its state to Idle. - changes its state to Idle.
In response the ConnectRetry timer expires event[Event9], In response the ConnectRetry timer expires event[Event9],
the local system: the local system:
- restarts the connect retry timer (with initial value), - restarts the Connect Retry timer (with initial value),
- initiates a TCP connection to the other BGP peer, - initiates a TCP connection to the other BGP peer,
- Continues to listen for TCP connection that may be - Continues to listen for TCP connection that may be
initiated by remote BGP peer, initiated by remote BGP peer, and
- and changes its state to Connect. - changes its state to Connect.
If the local system has the Open Delay timer expired If the local system has the Open Delay timer expired
[Event12], the local system: [Event12], the local system:
- clears the connect retry timer (set to zero), - sets the Connect Retry timer to zero,
- stops and clears the Open Delay timer (set to zero), - stops and clears the Open Delay timer (set to zero),
- completes the BGP initialization, - completes the BGP initialization,
- sends the OPEN message to it's remote peer, - sends the OPEN message to it's remote peer,
- sets its hold timer to a large value, and - sets its hold timer to a large value, and
- changes its state to OpenSent. - changes its state to OpenSent.
A hold timer value of 4 minutes is also suggested for this A hold timer value of 4 minutes is also suggested for this
state transition. state transition.
If the local system receives a valid TCP indication If the local system receives a valid TCP indication
[Event 14], the local system processes the TCP connection [Event 14], the local system processes the TCP connection
flags, and stays in Active state. flags, and stays in Active state.
If the local system receives an invalid TCP indication [Event 15]: If the local system receives an invalid TCP indication [Event 15]:
the local system rejects the TCP connection, and stays in the local system rejects the TCP connection, and stays in
the Active State. the Active State.
A TCP connection succeeds [Event 16 or Event 17], the In response to a TCP connection succeeds [Event 16 or Event 17], the
local system checks the "Delay Open Flag" prior to local system checks the "Delay Open Flag" prior to
processing. If the Delay Open flag is set, the local system processing. If the Delay Open flag is set, the local system
o clears the connect retry timer, o sets the Connect Retry timer to zero,
o sets the BGP Open Delay timer to the initial value, and o sets the Open Delay timer to the initial value, and
o stays in the Active state. o stays in the Active state.
-If the Delay Open flag is not set, the local system -If the Delay Open flag is not set, the local system
o clears the connect retry timer, o sets the Connect Retry timer to zero,
o completes the BGP initialization, o completes the BGP initialization,
o sends the OPEN message to it's peer, o sends the OPEN message to it's peer,
o sets its hold timer to a large value, and o sets its hold timer to a large value, and
o changes its state to OpenSent. o changes its state to OpenSent.
A hold timer value of 4 minutes is suggested as a "large value" for A hold timer value of 4 minutes is suggested as a "large value" for
the hold timer. the hold timer.
If the local system receives a TCP connection fails event [Event 18], If the local system receives a TCP connection fails event [Event 18],
the local system will: the local system will:
- restart connect retry timer (with initial value), - restart the Connect Retry timer (with initial value),
- stops and clears Open Delay Timer (sets the value to zero), - stops and clears the Open Delay Timer (sets the value to zero),
- release all BGP resources - release all BGP resources
- Acknowledge the drop of TCP connection if - Acknowledge the drop of TCP connection if
TCP disconnect (send a FIN ACK), TCP disconnect (send a FIN ACK),
- Increment ConnectRetryCnt (connect retry count) by 1, and - Increment ConnectRetryCnt (connect retry count) by 1, and
- optionally perform peer oscillation damping, - optionally perform peer oscillation damping, and
- and go to to Idle. - changes its state to Idle.
If an OPEN message is received with the Open Delay timer is If an OPEN message is received with the Open Delay timer is
running [Event 20], the local system running [Event 20], the local system
- clears the connect retry timer (cleared to zero), - sets the Connect Retry timer to zero,
- stops and clears the Open Delay timer - stops and clears the Open Delay timer
- completes the BGP initialization, - completes the BGP initialization,
- sends an OPEN message, - sends an OPEN message,
- send a Keepalive message, and - sends a KEEPALIVE message, and
- if the hold timer value is non-zero, - if the hold timer value is non-zero,
- starts the keepalive timer to initial value, - starts the keepalive timer to initial value,
- resets the hold timer to the negotiated value, - resets the hold timer to the negotiated value,
else if the hold timer is zero else if the hold timer is zero
- resets the keepalive timer (set to zero), - resets the keepalive timer (set to zero),
- resets the hold timer to zero. - resets the hold timer to zero,
- changes its state to OpenConfirm. - and changes its state to OpenConfirm.
If the value of the autonomous system field is the same as the local If the value of the autonomous system field is the same as the local
Autonomous System number, set the connection status to an internal Autonomous System number, set the connection status to an internal
connection; otherwise it is "external". connection; otherwise it is "external".
If BGP message header checking detects an error [Event 21] or OPEN If BGP message header checking detects an error [Event 21] or OPEN
message checking detects an error [Event 22] (see section 6.2), the message checking detects an error [Event 22] (see section 6.2), the
local system: local system:
- (optionally) sends NOTIFICATION message with the - (optionally) sends NOTIFICATION message with the
appropriate error code, appropriate error code,
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, - increments the ConnectRetryCnt (connect retry count) by 1,
- [optionally] performs peer oscillation damping, - optionally performs peer oscillation damping,
- and goes to Idle. - and changes its state to Idle.
If a NOTIFICATION message is received with a version If a NOTIFICATION message is received with a version
error[Event24], the local system checks the Open Delay timer. error[Event24], the local system checks the Open Delay timer.
If the Open Delay timer is running, the local system: If the Open Delay timer is running, the local system:
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- stops and reset the Open Delay timer (sets to zero, - stops and reset the Open Delay timer (sets to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection, and
- changes its state to Idle. - changes its state to Idle.
If the Open Delay timer is not running, the local system: If the Open Delay timer is not running, the local system:
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, - increments the ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle - changes its state to Idle.
In response to any other event [Events 8,10-11,13,19,23,25-28], In response to any other event [Events 8,10-11,13,19,23,25-28],
the local system: the local system:
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- drops the TCP connection,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by one, - increments the ConnectRetryCnt (connect retry count) by one,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
OpenSent: OpenSent:
In this state BGP waits for an OPEN message from its peer. In this state BGP waits for an OPEN message from its peer.
The Start events [Event1, 3-7] are ignored in the OpenSent The Start events [Event1, 3-7] are ignored in the OpenSent
state. state.
If a manual stop event [Event 2] is issued in Open sent If a manual stop event [Event 2] is issued in Open sent
state, the local system: state, the local system:
- sends the NOTIFICATION with a cease, - sends the NOTIFICATION with a cease,
- sets the Connect Retry timer to zero,
- release all BGP resources, - release all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- set ConnectRetryCnt (connect retry count) to zero, - set ConnectRetryCnt (connect retry count) to zero, and
- resets the Connect Retry timer (set to zero), and
- changes its state to Idle. - changes its state to Idle.
If an automatic stop event [Event 8] is issued in OpenSent If an automatic stop event [Event 8] is issued in OpenSent
state, the local system: state, the local system:
- sends the NOTIFICATION with a cease, - sends the NOTIFICATION with a cease,
- sets the Connect Retry timer to zero,
- release all the BGP resources - release all the BGP resources
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, - increments the ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
If the Hold Timer expires[Event 10], the local system: If the Hold Timer expires[Event 10], the local system:
- send a NOTIFICATION message with error code Hold - send a NOTIFICATION message with error code Hold
Timer Expired, Timer Expired,
- reset the connect retry timer (sets to zero), - set the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, and - increments the ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
If a TCP indication is received for valid connection If a TCP indication is received for valid connection
[Event 14] or TCP request aknowledgement [Event 16] [Event 14] or TCP request aknowledgement [Event 16]
is received, or a TCP connect confirm [Event 17] is is received, or a TCP connect confirm [Event 17] is
received a second TCP session may be in progress. This received a second TCP session may be in progress. This
second TCP session is tracked per the Connection Collision second TCP session is tracked per the Connection Collision
processing (Section 6.8) until an OPEN message is received. processing (Section 6.8) until an OPEN message is received.
A TCP connection for an invalid port [Event 15] is ignored. A TCP connection for an invalid port [Event 15] is ignored.
skipping to change at page 55, line 23 skipping to change at page 55, line 35
- closes the BGP connection, - closes the BGP connection,
- restarts the Connect Retry timer, - restarts the Connect Retry timer,
- continues to listen for a connection that may be - continues to listen for a connection that may be
initiated by the remote BGP peer, and initiated by the remote BGP peer, and
- changes its state to Active. - changes its state to Active.
When an OPEN message is received, all fields are checked When an OPEN message is received, all fields are checked
for correctness. If there are no errors in the OPEN message for correctness. If there are no errors in the OPEN message
[Event 19] the local system: [Event 19] the local system:
- resets the Open Delay timer to zero, - resets the Open Delay timer to zero,
- reset BGP Connect Timer to zero, - sets the BGP Connect Retry timer to zero,
- sends a KEEPALIVE message and - sends a KEEPALIVE message and
- sets a KeepAlive timer (via the text below) - sets a KeepAlive timer (via the text below)
- sets the hold timer according to the negotiated value - sets the hold timer according to the negotiated value
(see Section 4.2), and (see Section 4.2), and
- changes its state to OpenConfirm. - changes its state to OpenConfirm.
If the negotiated hold time value is zero, then the Hold and If the negotiated hold time value is zero, then the Hold and
KeepAlive timers are not started. If the value of the Autonomous KeepAlive timers are not started. If the value of the Autonomous
System field is the same as the local Autonomous System number, System field is the same as the local Autonomous System number,
then the connection is an "internal" connection; otherwise, it then the connection is an "internal" connection; otherwise, it
skipping to change at page 55, line 39 skipping to change at page 56, line 4
If the negotiated hold time value is zero, then the Hold and If the negotiated hold time value is zero, then the Hold and
KeepAlive timers are not started. If the value of the Autonomous KeepAlive timers are not started. If the value of the Autonomous
System field is the same as the local Autonomous System number, System field is the same as the local Autonomous System number,
then the connection is an "internal" connection; otherwise, it then the connection is an "internal" connection; otherwise, it
is an "external" connection. (This will impact UPDATE processing is an "external" connection. (This will impact UPDATE processing
as described below.) as described below.)
If the BGP message header checking [Event21] or OPEN message If the BGP message header checking [Event21] or OPEN message
check detects an error (see Section 6.2)[Event22], the local system: check detects an error (see Section 6.2)[Event22], the local system:
- sends a NOTIFICATION message with appropriate error - sends a NOTIFICATION message with appropriate error
code, code,
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection - drops the TCP connection
- increments the ConnectRetryCnt (connect retry cout) by 1, - increments the ConnectRetryCnt (connect retry cout) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
Collision detection mechanisms (Section 6.8) need to be Collision detection mechanisms (Section 6.8) need to be
applied when a valid BGP OPEN message is received [Event 19 or applied when a valid BGP OPEN message is received [Event 19 or
Event 20]. Please refer to Section 6.8 for the details of Event 20]. Please refer to Section 6.8 for the details of
the comparison. An administrative collision detect is when the comparison. An administrative collision detect is when
BGP implementation determines my means outside the scope of BGP implementation determines by means outside the scope of
this document that a connection collision has occurred. this document that a connection collision has occurred.
If a connection in OpenSent is determined to be the If a connection in OpenSent is determined to be the
connection that must be closed, an open collision dump [Event 23] connection that must be closed, an open collision dump [Event 23]
is signaled to the state machine. If such an event is is signaled to the state machine. If such an event is
received in OpenSent, the local system: received in OpenSent, the local system:
- sends a NOTIFICATION with a Cease - sends a NOTIFICATION with a Cease
- resets the connect retry timer, - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments ConnectRetryCnt (connect rery count) by 1, - increments ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
If a NOTIFICATION message is received with a version If a NOTIFICATION message is received with a version
error[Event24], the local system: error[Event24], the local system:
- resets the connect retry timer (sets to zero) - sets the Connect Retry timer to zero
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- changes its state to Idle. - changes its state to Idle.
In response to any other event [Events 9, 11-13,20,25-28], In response to any other event [Events 9, 11-13,20,25-28],
the local system: the local system:
- sends the NOTIFICATION with the Error Code Finite - sends the NOTIFICATION with the Error Code Finite
state machine error, state machine error,
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- releases all BGP resources - releases all BGP resources
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, - increments the ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
OpenConfirm State: OpenConfirm State:
In this state BGP waits for a KEEPALIVE or NOTIFICATION In this state BGP waits for a KEEPALIVE or NOTIFICATION
message. message.
Any start event [Event1, 3-7] is ignored in the OpenConfirm Any start event [Event1, 3-7] is ignored in the OpenConfirm
state. state.
In response to a manual stop event[Event 2] initiated by In response to a manual stop event[Event 2] initiated by
the operator, the local system: the operator, the local system:
- sends the NOTIFICATION message with Cease, - sends the NOTIFICATION message with Cease,
- releases all BGP resources, - releases all BGP resources,
- drop the TCP connection, - drop the TCP connection,
- sets the ConnectRetryCnt (connect retry count) to zero - sets the ConnectRetryCnt (connect retry count) to zero
- sets the connect retry timer to zero, and - sets the Connect Retry timer to zero, and
- changes its state to Idle. - changes its state to Idle.
In response to the Automatic stop event initiated by the In response to the Automatic stop event initiated by the
system[Event 8], the local system: system[Event 8], the local system:
- sends the NOTIFICATION message with Cease, - sends the NOTIFICATION message with Cease,
- connect retry timer reset (set to zero) - sets the Connect Retry timer to zero,
- release all BGP resources, - release all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) - increments the ConnectRetryCnt (connect retry count)
by 1, by 1,
- optionally performs peer oscillation damping, - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
If the Hold Timer expires before a KEEPALIVE message is If the Hold Timer expires before a KEEPALIVE message is
received [Event 10], the local system: received [Event 10], the local system:
- send the NOTIFICATION message with the error code - send the NOTIFICATION message with the error code
set to Hold Time Expired, set to Hold Time Expired,
- resets the connect retry timer (sets the timer to to - sets the Connect Retry timer to zero,
zero),
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) - increments the ConnectRetryCnt (connect retry count) by 1,
by 1, - optionally performs peer oscillation damping, and
- optionally performs peer oscillation damping,
and
- changes its state to Idle. - changes its state to Idle.
If the local system receives a KEEPALIVE timer expires If the local system receives a KEEPALIVE timer expires
event [Event 11], the system: event [Event 11], the system:
- sends a KEEPALIVE message, - sends a KEEPALIVE message,
- restarts the Keepalive timer, and - restarts the Keepalive timer, and
- remains in OpenConfirmed state. - remains in OpenConfirmed state.
In the event of TCP connection valid indication [Event 14], or TCP In the event of TCP connection valid indication [Event 14], or TCP
connection succeeding [Event 16 or Event 17] while in OpenConfirm, connection succeeding [Event 16 or Event 17] while in OpenConfirm,
the local system needs to track the 2nd connection. the local system needs to track the 2nd connection.
If a TCP connection is attempted to an invalid port [Event If a TCP connection is attempted to an invalid port [Event
15], the local system will ignore the second connection 15], the local system will ignore the second connection
attempt. attempt.
If the local system receives a TCP connection fails event If the local system receives a TCP connection fails event
[Event 18] from the underlying TCP. or a NOTIFICATION [Event 18] from the underlying TCP, or a NOTIFICATION
message [Event 25] the local system: message [Event 25] the local system:
- resets the connect retry timer (sets the timer to - sets the Connect Retry timer to zero,
zero),
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) - increments the ConnectRetryCnt (connect retry count)
by 1, by 1,
- optionally performs peer oscillation damping, - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
If the local system receives a NOTIFICATION message [Event 24] with If the local system receives a NOTIFICATION message [Event 24]
a version error, the local system: with a version error, the local system:
- resets the connect retry timer (sets the timer to zero), - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection, and
- changes its state to Idle. [Verify this/or above] - changes its state to Idle.
If the OPEN message is valid [Event 19], the collision If the local system receives a valid OPEN message [Event 19], the
detect function is processed per Section 6.8. If this collision detect function is processed per Section 6.8. If this
connection is to be dropped due to connection collision, the connection is to be dropped due to connection collision, the
local system: local system:
- sends a NOTIFICATION with a Cease - sends a NOTIFICATION with a Cease
- resets the Connect timer (set to zero), - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection (send TCP FIN), - drops the TCP connection (send TCP FIN),
- increments the ConnectRetryCnt by 1 (connect retry count), and - increments the ConnectRetryCnt by 1 (connect retry count),
- optionally performs peer oscillation damping. - optionally performs peer oscillation damping, and
- changes its state to Idle.
If an OPEN message is received, all fields are check for If an OPEN message is received, all fields are check for
correctness. If the BGP message header checking [Event21] correctness. If the BGP message header checking [Event21]
or OPEN message check detects an error (see Section or OPEN message check detects an error (see Section
6.2)[Event22], the local system: 6.2)[Event22], the local system:
- sends a NOTIFICATION message with appropriate error - sends a NOTIFICATION message with appropriate error
code, code,
- resets the connect retry timer (sets the timer to - sets the Connect Retry timer to zero,
zero),
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, - increments the ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
If during the processing of another OPEN message, the BGP If during the processing of another OPEN message, the BGP
implementation determines my means outside the scope of implementation determines by means outside the scope of
this document that a connection collision has occurred and this document that a connection collision has occurred and
this connection is to be closed, the local system will this connection is to be closed, the local system will
issue a open collision dump [Event 23]. When the local issue a open collision dump [Event 23]. When the local
system receives a open collision dump event [Event 23], the system receives a open collision dump event [Event 23], the
local system: local system:
- send a NOTIFICATION with a Cease - sends a NOTIFICATION with a Cease
- resets the connect retry timer, - sets the Connect Retry timer to zero,
- releases all BGP resources - releases all BGP resources
- drops all TCP connection, - drops all TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1, - increments the ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
If the local system receives a KEEPALIVE message[Event 26], If the local system receives a KEEPALIVE message[Event 26],
- restarts the Hold timer, and - restarts the Hold timer, and
- changes its state to Established. - changes its state to Established.
In response to any other event [Events 9, 12-13, 27-28], In response to any other event [Events 9, 12-13, 20, 27-28],
the local system: the local system:
- sends a NOTIFICATION with a code of Finite State - sends a NOTIFICATION with a code of Finite State
Machine Error, Machine Error,
- resets the connect retry timer (sets to zero) - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retrycount) by 1, - increments the ConnectRetryCnt (connect retrycount) by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
Established State: Established State:
In the Established state BGP can exchange UPDATE, In the Established state BGP can exchange UPDATE,
NOTFICATION, and KEEPALIVE messages with its peer. NOTFICATION, and KEEPALIVE messages with its peer.
Any start event (Event 1, 3-7) is ignored in the Any start event (Event 1, 3-7) is ignored in the
Established state. Established state.
In response to a manual stop event (initiated by an In response to a manual stop event (initiated by an
operator)[Event2], the local sytem: operator)[Event2], the local sytem:
- sends the NOTIFICATION message with Cease, - sends the NOTIFICATION message with Cease,
- resets the connect retry timer to zero (0), - sets the Connect Retry timer to zero,
- delete all routes associated with this connection, - delete all routes associated with this connection,
- release BGP resources, - release BGP resources,
- drops TCP connection, - drops TCP connection,
- sets ConnectRetryCnt (connect retry count) - sets ConnectRetryCnt (connect retry count)
to zero (0), and to zero (0), and
- changes its state to Idle. - changes its state to Idle.
In response to an automatic stop event initiated by the In response to an automatic stop event initiated by the
system (automatic) [Event8], the local system: system (automatic) [Event8], the local system:
- sends a NOTIFICATION with Cease, - sends a NOTIFICATION with Cease,
- resets the connect retry timer (sets to zero) - sets the Connect Retry timer to zero
- deletes all routes associated with this connection, - deletes all routes associated with this connection,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) - increments the ConnectRetryCnt (connect retry count)
by 1, by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
An example automatic stop event is exceeding the number of An example automatic stop event is exceeding the number of
prefixes for a given peer and the local system prefixes for a given peer and the local system
automatically disconnecting the peer. automatically disconnecting the peer.
If the Hold timer expires [Event10], the local system: If the Hold timer expires [Event10], the local system:
- sends a NOTIFICATION message with Error Code Hold - sends a NOTIFICATION message with Error Code Hold
Timer Expired, Timer Expired,
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) - increments the ConnectRetryCnt (connect retry count)
by 1, by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
If the KeepAlive timer expires [Event11], the local system If the KeepAlive timer expires [Event11], the local system
sends a KEEPALIVE message, it restarts its KeepAlive timer, sends a KEEPALIVE message, it restarts its KeepAlive timer,
unless the negotiated Hold Time value is zero. unless the negotiated Hold Time value is zero.
Each time time the local system sends a KEEPALIVE or UPDATE Each time the local system sends a KEEPALIVE or UPDATE
message, it restarts its KeepAlive timer, unless the message, it restarts its KeepAlive timer, unless the
negotiated Hold Time value is zero. negotiated Hold Time value is zero.
A TCP connection indication [Event 14] received A TCP connection indication [Event 14] received
for a valid port will cause the 2nd connection to be for a valid port will cause the 2nd connection to be
tracked. tracked.
A TCP connection indications for invalid port [Event 15], A TCP connection indications for invalid port [Event 15],
will be ignored. will be ignored.
skipping to change at page 61, line 14 skipping to change at page 61, line 23
or Event 17], the 2nd connection SHALL be tracked until or Event 17], the 2nd connection SHALL be tracked until
it sends an OPEN message. it sends an OPEN message.
If a valid OPEN message [Event 19] is received, it will be If a valid OPEN message [Event 19] is received, it will be
checked to see if it collides (Section 6.8) with any other checked to see if it collides (Section 6.8) with any other
session. If the BGP implementation determines that this session. If the BGP implementation determines that this
connection needs to be terminated, it will process an open connection needs to be terminated, it will process an open
collision dump event[Event 23]. If this session needs to be collision dump event[Event 23]. If this session needs to be
terminated, the connection will be terminated by: terminated, the connection will be terminated by:
- send a NOTIFICATION with a Cease, - sends a NOTIFICATION with a Cease,
- resets the connect retry time (sets to zero), - sets the Connect Retry timer to zero,
- deletes all routes associated with this connection, - deletes all routes associated with this connection,
- release all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments ConnectRetryCnt (connect retry count) - increments ConnectRetryCnt (connect retry count)
by 1, by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
If the local system receives a NOTIFICATION message If the local system receives a NOTIFICATION message
[Event24 or Event 25] or a TCP connections fails [Event18] [Event24 or Event 25] or a TCP connections fails [Event18]
from the underlying TCP, it: from the underlying TCP, it:
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- delete all routes associated with this connection, - deletes all routes associated with this connection,
- releases all the BGP resources, - releases all the BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) - increments the ConnectRetryCnt (connect retry count)
by 1, and by 1, and
- changes its state to Idle. - changes its state to Idle.
If the local system receives a KEEPALIVE message If the local system receives a KEEPALIVE message
[Event 26], the local system will: [Event 26], the local system will:
- restarts its Hold Timer, if the negotiated Hold Time - restarts its Hold Timer, if the negotiated Hold Time
value is non-zero, and value is non-zero, and
skipping to change at page 62, line 9 skipping to change at page 62, line 16
the local system will: the local system will:
- process the update packet - process the update packet
- restarts its Hold timer, if the negotiated Hold Time - restarts its Hold timer, if the negotiated Hold Time
value is non-zero, and value is non-zero, and
- remain in the Established state. - remain in the Established state.
If the local system receives an UPDATE message, and the If the local system receives an UPDATE message, and the
UPDATE message error handling procedure (see Section 6.3) UPDATE message error handling procedure (see Section 6.3)
detects an error [Event28], the local system: detects an error [Event28], the local system:
- sends a NOTIFICATION message with Update error, - sends a NOTIFICATION message with Update error,
- resets the connect retry timer (sets to zero), - sets the Connect Retry timer to zero,
- delets all routes associated with this connection, - delets all routes associated with this connection,
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) - increments the ConnectRetryCnt (connect retry count)
by 1, by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
In response to any other event [Events 9, 12-13, 20-22] the In response to any other event [Events 9, 12-13, 20-22] the
local system: local system:
- sends a NOTIFICATION message with Error Code Finite - sends a NOTIFICATION message with Error Code Finite
State Machine Error, State Machine Error,
- deletes all routes associated with this connection, - deletes all routes associated with this connection,
- resets the connect retry timer (sets to zero) - sets the Connect Retry timer to zero
- releases all BGP resources, - releases all BGP resources,
- drops the TCP connection, - drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) - increments the ConnectRetryCnt (connect retry count)
by 1, by 1,
- optionally performs peer oscillation damping, and - optionally performs peer oscillation damping, and
- changes its state to Idle. - changes its state to Idle.
9. UPDATE Message Handling 9. UPDATE Message Handling
An UPDATE message may be received only in the Established state. An UPDATE message may be received only in the Established state.
skipping to change at page 72, line 13 skipping to change at page 72, line 22
When a BGP speaker receives an UPDATE message from an internal peer, When a BGP speaker receives an UPDATE message from an internal peer,
the receiving BGP speaker SHALL NOT re-distribute the routing infor- the receiving BGP speaker SHALL NOT re-distribute the routing infor-
mation contained in that UPDATE message to other internal peers, mation contained in that UPDATE message to other internal peers,
unless the speaker acts as a BGP Route Reflector [RFC2796]. unless the speaker acts as a BGP Route Reflector [RFC2796].
As part of Phase 3 of the route selection process, the BGP speaker As part of Phase 3 of the route selection process, the BGP speaker
has updated its Adj-RIBs-Out. All newly installed routes and all has updated its Adj-RIBs-Out. All newly installed routes and all
newly unfeasible routes for which there is no replacement route SHALL newly unfeasible routes for which there is no replacement route SHALL
be advertised to its peers by means of an UPDATE message. be advertised to its peers by means of an UPDATE message.
A BGP speaker SHOULT NOT advertise a given feasible BGP route from A BGP speaker SHOULD NOT advertise a given feasible BGP route from
its Adj-RIB-Out if it would produce an UPDATE message containing the its Adj-RIB-Out if it would produce an UPDATE message containing the
same BGP route as was previously advertised. same BGP route as was previously advertised.
Any routes in the Loc-RIB marked as unfeasible SHALL be removed. Any routes in the Loc-RIB marked as unfeasible SHALL be removed.
Changes to the reachable destinations within its own autonomous sys- Changes to the reachable destinations within its own autonomous sys-
tem SHALL also be advertised in an UPDATE message. tem SHALL also be advertised in an UPDATE message.
If due to the limits on the maximum size of an UPDATE message (see If due to the limits on the maximum size of an UPDATE message (see
Section 4) a single route doesn't fit into the message, the BGP Section 4) a single route doesn't fit into the message, the BGP
speaker MUST not advertise the route to its peers and MAY choose to speaker MUST not advertise the route to its peers and MAY choose to
skipping to change at page 72, line 45 skipping to change at page 73, line 12
The parameter MinRouteAdvertisementInterval determines the minimum The parameter MinRouteAdvertisementInterval determines the minimum
amount of time that must elapse between advertisement and/or with- amount of time that must elapse between advertisement and/or with-
drawal of routes to a particular destination by a BGP speaker to a drawal of routes to a particular destination by a BGP speaker to a
peer. This rate limiting procedure applies on a per-destination peer. This rate limiting procedure applies on a per-destination
basis, although the value of MinRouteAdvertisementInterval is set on basis, although the value of MinRouteAdvertisementInterval is set on
a per BGP peer basis. a per BGP peer basis.
Two UPDATE messages sent by a BGP speaker to a peer that advertise Two UPDATE messages sent by a BGP speaker to a peer that advertise
feasible routes and/or withdrawal of unfeasible routes to some common feasible routes and/or withdrawal of unfeasible routes to some common
set of destinations MUST be separated by at least set of destinations MUST be separated by at least MinRouteAdvertise-
MinRouteAdvertisementInterval. Clearly, this can only be achieved mentInterval. Clearly, this can only be achieved precisely by keeping
precisely by keeping a separate timer for each common set of destina- a separate timer for each common set of destinations. This would be
tions. This would be unwarranted overhead. Any technique which unwarranted overhead. Any technique which ensures that the interval
ensures that the interval between two UPDATE messages sent from a BGP between two UPDATE messages sent from a BGP speaker to a peer that
speaker to a peer that advertise feasible routes and/or withdrawal of advertise feasible routes and/or withdrawal of unfeasible routes to
unfeasible routes to some common set of destinations will be at least some common set of destinations will be at least MinRouteAdvertise-
MinRouteAdvertisementInterval, and will also ensure a constant upper mentInterval, and will also ensure a constant upper bound on the
bound on the interval is acceptable. interval is acceptable.
Since fast convergence is needed within an autonomous system, either Since fast convergence is needed within an autonomous system, either
(a) the MinRouteAdvertisementInterval used for internal peers SHOULD (a) the MinRouteAdvertisementInterval used for internal peers SHOULD
be shorter than the MinRouteAdvertisementInterval used for external be shorter than the MinRouteAdvertisementInterval used for external
peers, or (b) the procedure describe in this section SHOULD NOT apply peers, or (b) the procedure describe in this section SHOULD NOT apply
for routes sent to internal peers. for routes sent to internal peers.
This procedure does not limit the rate of route selection, but only This procedure does not limit the rate of route selection, but only
the rate of route advertisement. If new routes are selected multiple the rate of route advertisement. If new routes are selected multiple
times while awaiting the expiration of MinRouteAdvertisementInterval, times while awaiting the expiration of MinRouteAdvertisementInterval,
skipping to change at page 73, line 45 skipping to change at page 74, line 12
BGP speaker may avail itself of several methods to organize this BGP speaker may avail itself of several methods to organize this
information in an efficient manner. information in an efficient manner.
9.2.2.1 Information Reduction 9.2.2.1 Information Reduction
Information reduction may imply a reduction in granularity of policy Information reduction may imply a reduction in granularity of policy
control - after information is collapsed, the same policies will control - after information is collapsed, the same policies will
apply to all destinations and paths in the equivalence class. apply to all destinations and paths in the equivalence class.
The Decision Process may optionally reduce the amount of information The Decision Process may optionally reduce the amount of information
that it will place in the Adj-RIBs-Out by any of the following that it will place in the Adj-RIBs-Out by any of the following meth-
methods: ods:
a) Network Layer Reachability Information (NLRI): a) Network Layer Reachability Information (NLRI):
Destination IP addresses can be represented as IP address pre- Destination IP addresses can be represented as IP address pre-
fixes. In cases where there is a correspondence between the fixes. In cases where there is a correspondence between the
address structure and the systems under control of an autonomous address structure and the systems under control of an autonomous
system administrator, it will be possible to reduce the size of system administrator, it will be possible to reduce the size of
the NLRI carried in the UPDATE messages. the NLRI carried in the UPDATE messages.
b) AS_PATHs: b) AS_PATHs:
skipping to change at page 76, line 44 skipping to change at page 76, line 52
fies the conditions and allows for more complex policy configu- fies the conditions and allows for more complex policy configu-
rations. rations.
ATOMIC_AGGREGATE: ATOMIC_AGGREGATE:
If at least one of the routes to be aggregated has If at least one of the routes to be aggregated has
ATOMIC_AGGREGATE path attribute, then the aggregated route ATOMIC_AGGREGATE path attribute, then the aggregated route
SHALL have this attribute as well. SHALL have this attribute as well.
AGGREGATOR: AGGREGATOR:
Any AGGREGATOR attributes from the routes to be aggregated MUST Any AGGREGATOR attributes from the routes to be aggregated MUST
NOT be included in the aggregated route. The BGP speaker per- NOT be included in the aggregated route. The BGP speaker
forming the route aggregation MAY attach a new AGGREGATOR performing the route aggregation MAY attach a new AGGREGATOR
attribute (see Section 5.1.7). attribute (see Section 5.1.7).
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 sev-
several alternatives are outside the scope of this document. There eral alternatives are outside the scope of this document. There are
are two exceptions: 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 can not be viewed as better than considered, then that new route can not be viewed as better than
any other route (provided that the speaker is configured to accept any other route (provided that the speaker is configured to accept
such routes). If such a route were ever used, a routing loop could such routes). If such a route were ever used, a routing loop could
result. result.
- 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
SHOULD avoid using unstable routes, and it SHOULD NOT make rapid SHOULD avoid using unstable routes, and it SHOULD NOT make rapid
skipping to change at page 79, line 25 skipping to change at page 79, line 32
deprecated. deprecated.
UPDATE Message Error subcode 7 (AS Routing Loop) has been depre- UPDATE Message Error subcode 7 (AS Routing Loop) has been depre-
cated. cated.
OPEN Message Error subcode 5 (Authentication Failure) has been OPEN Message Error subcode 5 (Authentication Failure) has been
deprecated. deprecated.
Use of the Marker field for authentication has been deprecated. Use of the Marker field for authentication has been deprecated.
Use of TCP MD5 [RFC2385] for authentication is mandatory. Implementations MUST support TCP MD5 [RFC2385] for authentication.
Appendix B. Comparison with RFC1267 Appendix B. Comparison with RFC1267
All the changes listed in Appendix A, plus the following. All the changes listed in Appendix A, plus the following.
BGP-4 is capable of operating in an environment where a set of reach- BGP-4 is capable of operating in an environment where a set of reach-
able destinations may be expressed via a single IP prefix. The con- able destinations may be expressed via a single IP prefix. The con-
cept of network classes, or subnetting is foreign to BGP-4. To cept of network classes, or subnetting is foreign to BGP-4. To
accommodate these capabilities BGP-4 changes semantics and encoding accommodate these capabilities BGP-4 changes semantics and encoding
associated with the AS_PATH attribute. New text has been added to associated with the AS_PATH attribute. New text has been added to
skipping to change at page 84, line 21 skipping to change at page 84, line 28
more than once within the aggregated AS_PATH attribute, all, but more than once within the aggregated AS_PATH attribute, all, but
the last instance (rightmost occurrence) of that AS number SHOULD the last instance (rightmost occurrence) of that AS number SHOULD
be removed from the aggregated AS_PATH attribute. be removed from the aggregated AS_PATH attribute.
Security Considerations Security Considerations
The authentication mechanism that an implementation of BGP MUST sup- The authentication mechanism that an implementation of BGP MUST sup-
port is specified in [RFC2385]. The authentication provided by this port is specified in [RFC2385]. The authentication provided by this
mechanism could be done on a per peer basis. mechanism could be done on a per peer basis.
Security issues with BGP routing information dissemination are dis- BGP vulnerabilities analysis is discussed in [XXX].
cussed in [XXX].
IANA Considerations IANA Considerations
All extensions to this protocol, including new message types and Path All extensions to this protocol, including new message types and Path
Attributes MUST only be made using the Standards Action process Attributes MUST only be made using the Standards Action process
defined in [RFC2434]. defined in [RFC2434].
Normative References Normative References
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program Pro- [RFC791] Postel, J., "Internet Protocol - DARPA Internet Program Pro-
 End of changes. 

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