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/