draft-ietf-idr-bgp4-25.txt		draft-ietf-idr-bgp4-26.txt
	Network Working Group Y. Rekhter		Network Working Group Y. Rekhter
	INTERNET DRAFT T.Li		INTERNET DRAFT T.Li
	Obsoletes: RFC1771 S. Hares		Obsoletes: RFC1771 S. Hares
	Editors		Editors
	A Border Gateway Protocol 4 (BGP-4)		A Border Gateway Protocol 4 (BGP-4)
	<draft-ietf-idr-bgp4-25.txt>		<draft-ietf-idr-bgp4-26.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 3, line 40		skipping to change at page 3, line 40
	6.2 OPEN message error handling . . . . . . . . . . . . . . . . . 32		6.2 OPEN message error handling . . . . . . . . . . . . . . . . . 32
	6.3 UPDATE message error handling . . . . . . . . . . . . . . . . 33		6.3 UPDATE message error handling . . . . . . . . . . . . . . . . 33
	6.4 NOTIFICATION message error handling . . . . . . . . . . . . . 35		6.4 NOTIFICATION message error handling . . . . . . . . . . . . . 35
	6.5 Hold Timer Expired error handling . . . . . . . . . . . . . . 35		6.5 Hold Timer Expired error handling . . . . . . . . . . . . . . 35
	6.6 Finite State Machine error handling . . . . . . . . . . . . . 35		6.6 Finite State Machine error handling . . . . . . . . . . . . . 35
	6.7 Cease . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35		6.7 Cease . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	6.8 BGP connection collision detection . . . . . . . . . . . . . 36		6.8 BGP connection collision detection . . . . . . . . . . . . . 36
	7. BGP Version Negotiation . . . . . . . . . . . . . . . . . . . 37		7. BGP Version Negotiation . . . . . . . . . . . . . . . . . . . 37
	8. BGP Finite State machine . . . . . . . . . . . . . . . . . . . 38		8. BGP Finite State machine . . . . . . . . . . . . . . . . . . . 38
	8.1 Events for the BGP FSM . . . . . . . . . . . . . . . . . . . 39		8.1 Events for the BGP FSM . . . . . . . . . . . . . . . . . . . 39
	8.1.1 Optional Events linked to Optional Session attributes . . . 39		8.1.1 Optional Events linked to Optional Session attributes
			. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	8.1.2 Administrative Events . . . . . . . . . . . . . . . . . . 44		8.1.2 Administrative Events . . . . . . . . . . . . . . . . . . 44
	8.1.3 Timer Events . . . . . . . . . . . . . . . . . . . . . . . 47		8.1.3 Timer Events . . . . . . . . . . . . . . . . . . . . . . . 47
	8.1.4 TCP connection based Events . . . . . . . . . . . . . . . . 49		8.1.4 TCP connection based Events . . . . . . . . . . . . . . . . 49
	8.1.5 BGP Messages based Events . . . . . . . . . . . . . . . . . 51		8.1.5 BGP Messages based Events . . . . . . . . . . . . . . . . . 51
	8.2 Description of FSM . . . . . . . . . . . . . . . . . . . . . 53		8.2 Description of FSM . . . . . . . . . . . . . . . . . . . . . 53
	8.2.1 FSM Definition . . . . . . . . . . . . . . . . . . . . . . 53		8.2.1 FSM Definition . . . . . . . . . . . . . . . . . . . . . . 53
	8.2.1.1 Terms "active" and "passive" . . . . . . . . . . . . . . 54		8.2.1.1 Terms "active" and "passive" . . . . . . . . . . . . . . 54
	8.2.1.2 FSM and collision detection . . . . . . . . . . . . . . . 54		8.2.1.2 FSM and collision detection . . . . . . . . . . . . . . . 54
	8.2.1.3 FSM and Optional Attributes . . . . . . . . . . . . . . 55		8.2.1.3 FSM and Optional Attributes . . . . . . . . . . . . . . 55
	8.2.1.4 FSM Event numbers . . . . . . . . . . . . . . . . . . . . 55		8.2.1.4 FSM Event numbers . . . . . . . . . . . . . . . . . . . . 55
	skipping to change at page 5, line 30		skipping to change at page 5, line 30
	support for advertising a set of destinations as an IP prefix and		support for advertising a set of destinations as an IP prefix and
	eliminating the concept of network "class" within BGP. BGP-4 also		eliminating the concept of network "class" within BGP. BGP-4 also
	introduces mechanisms which allow aggregation of routes, including		introduces mechanisms which allow aggregation of routes, including
	aggregation of AS paths.		aggregation of AS paths.
	Routing information exchanged via BGP supports only the destination-		Routing information exchanged via BGP supports only the destination-
	based forwarding paradigm, which assumes that a router forwards a		based forwarding paradigm, which assumes that a router forwards a
	packet based solely on the destination address carried in the IP		packet based solely on the destination address carried in the IP
	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 par-
	paradigm.		adigm.
	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		Adj-RIB-In
	The Adj-RIBs-In contain unprocessed routing information that has		The Adj-RIBs-In contain unprocessed routing information that has
	been advertised to the local BGP speaker by its peers.		been advertised to the local BGP speaker by its peers.
	skipping to change at page 17, line 25		skipping to change at page 17, line 25
	of trailing bits is irrelevant.		of trailing bits is irrelevant.
	Total Path Attribute Length:		Total Path Attribute Length:
	This 2-octet unsigned integer indicates the total length of the		This 2-octet unsigned integer indicates the total length of the
	Path Attributes field in octets. Its value allows the length of		Path Attributes field in octets. Its value allows the length of
	the Network Layer Reachability field to be determined as speci-		the Network Layer Reachability field to be determined as speci-
	fied below.		fied below.
	A value of 0 indicates that neither the Network Layer Reacha-		A value of 0 indicates that neither the Network Layer Reacha-
	bility Information field, nor the Path Attribute field is pre-		bility Information field, nor the Path Attribute field is
	sent in this UPDATE message.		present in this UPDATE message.
	Path Attributes:		Path Attributes:
	A variable length sequence of path attributes is present in		A variable length sequence of path attributes is present in
	every UPDATE message, except for an UPDATE message that carries		every UPDATE message, except for an UPDATE message that carries
	only the withdrawn routes. Each path attribute is a triple		only the withdrawn routes. Each path attribute is a triple
	<attribute type, attribute length, attribute value> of variable		<attribute type, attribute length, attribute value> of variable
	length.		length.
	Attribute Type is a two-octet field that consists of the		Attribute Type is a two-octet field that consists of the
	skipping to change at page 73, line 9		skipping to change at page 73, line 9
	wise, if the Adj-RIB-In has no route with NLRI identical to the new		wise, if the Adj-RIB-In has no route with NLRI identical to the new
	route, the new route SHALL be placed in the Adj-RIB-In.		route, the new route SHALL be placed in the Adj-RIB-In.
	Once the BGP speaker updates the Adj-RIB-In, the speaker SHALL run		Once the BGP speaker updates the Adj-RIB-In, the speaker SHALL run
	its Decision Process.		its Decision Process.
	9.1 Decision Process		9.1 Decision Process
	The Decision Process selects routes for subsequent advertisement by		The Decision Process selects routes for subsequent advertisement by
	applying the policies in the local Policy Information Base (PIB) to		applying the policies in the local Policy Information Base (PIB) to
	the routes stored in its Adj-RIBs-In. The output of the Decision Pro-		the routes stored in its Adj-RIBs-In. The output of the Decision
	cess is the set of routes that will be advertised to peers; the		Process is the set of routes that will be advertised to peers; the
	selected routes will be stored in the local speaker's Adj-RIBs-Out		selected routes will be stored in the local speaker's Adj-RIBs-Out
	according to policy.		according to policy.
	The BGP Decision Process described here is conceptual, and does not		The BGP Decision Process described here is conceptual, and does not
	have to be implemented precisely as described here, as long as the		have to be implemented precisely as described here, as long as the
	implementations support the described functionality and their exter-		implementations support the described functionality and their exter-
	nally visible behavior is the same.		nally visible behavior is the same.
	The selection process is formalized by defining a function that takes		The selection process is formalized by defining a function that takes
	the attribute of a given route as an argument and returns either (a)		the attribute of a given route as an argument and returns either (a)
	skipping to change at page 77, line 12		skipping to change at page 77, line 12
	ing the BGP route's NEXT_HOP. Mutually recursive routes (routes		ing the BGP route's NEXT_HOP. Mutually recursive routes (routes
	resolving each other or themselves), also fail the resolvability		resolving each other or themselves), also fail the resolvability
	check.		check.
	It is also important that implementations do not consider feasible		It is also important that implementations do not consider feasible
	routes that would become unresolvable if they were installed in the		routes that would become unresolvable if they were installed in the
	Routing Table even if their NEXT_HOPs are resolvable using the cur-		Routing Table even if their NEXT_HOPs are resolvable using the cur-
	rent contents of the Routing Table (an example of such routes would		rent contents of the Routing Table (an example of such routes would
	be mutually recursive routes). This check ensures that a BGP speaker		be mutually recursive routes). This check ensures that a BGP speaker
	does not install in the Routing Table routes that will be removed and		does not install in the Routing Table routes that will be removed and
	not used by the speaker. Therefore, in addition to local Routing		not used by the speaker. Therefore, in addition to local Routing Ta-
	Table stability, this check also improves behavior of the protocol in		ble stability, this check also improves behavior of the protocol in
	the network.		the network.
	Whenever a BGP speaker identifies a route that fails the resolvabil-		Whenever a BGP speaker identifies a route that fails the resolvabil-
	ity check because of mutual recursion, an error message SHOULD be		ity check because of mutual recursion, an error message SHOULD be
	logged.		logged.
	9.1.2.2 Breaking Ties (Phase 2)		9.1.2.2 Breaking Ties (Phase 2)
	In its Adj-RIBs-In a BGP speaker may have several routes to the same		In its Adj-RIBs-In a BGP speaker may have several routes to the same
	destination that have the same degree of preference. The local		destination that have the same degree of preference. The local
	skipping to change at page 78, line 49		skipping to change at page 78, line 49
	MULTI_EXIT_DISC attribute MAY still be performed. If an implemen-		MULTI_EXIT_DISC attribute MAY still be performed. If an implemen-
	tation chooses to remove MULTI_EXIT_DISC, then the optional com-		tation chooses to remove MULTI_EXIT_DISC, then the optional com-
	parison on MULTI_EXIT_DISC if performed at all MUST be performed		parison on MULTI_EXIT_DISC if performed at all MUST be performed
	only among EBGP learned routes. The best EBGP learned route may		only among EBGP learned routes. The best EBGP learned route may
	then be compared with IBGP learned routes after the removal of the		then be compared with IBGP learned routes after the removal of the
	MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a		MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a
	subset of EBGP learned routes and the selected "best" EBGP learned		subset of EBGP learned routes and the selected "best" EBGP learned
	route will not have MULTI_EXIT_DISC removed, then the		route will not have MULTI_EXIT_DISC removed, then the
	MULTI_EXIT_DISC must be used in the comparison with IBGP learned		MULTI_EXIT_DISC must be used in the comparison with IBGP learned
	routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used		routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used
	in route comparisons which reach this step in the Decision Pro-		in route comparisons which reach this step in the Decision
	cess. Including the MULTI_EXIT_DISC of an EBGP learned route in		Process. Including the MULTI_EXIT_DISC of an EBGP learned route
	the comparison with an IBGP learned route, then removing the		in the comparison with an IBGP learned route, then removing the
	MULTI_EXIT_DISC attribute and advertising the route has been		MULTI_EXIT_DISC attribute and advertising the route has been
	proven to cause route loops.		proven to cause route loops.
	d) If at least one of the candidate routes was received via EBGP,		d) If at least one of the candidate routes was received via EBGP,
	remove from consideration all routes which were received via IBGP.		remove from consideration all routes which were received via IBGP.
	e) Remove from consideration any routes with less-preferred inte-		e) Remove from consideration any routes with less-preferred inte-
	rior cost. The interior cost of a route is determined by calcu-		rior cost. The interior cost of a route is determined by calcu-
	lating the metric to the NEXT_HOP for the route using the Routing		lating the metric to the NEXT_HOP for the route using the Routing
	Table. If the NEXT_HOP hop for a route is reachable, but no cost		Table. If the NEXT_HOP hop for a route is reachable, but no cost
	skipping to change at page 96, line 4		skipping to change at page 96, line 4
	All the BGP messages contain an 8-bit message type, for which IANA is		All the BGP messages contain an 8-bit message type, for which IANA is
	to create and maintain a registry entitled "BGP Message Types". This		to create and maintain a registry entitled "BGP Message Types". This
	document defines the following message types:		document defines the following message types:
	Name Value Definition		Name Value Definition
	---- ----- ----------		---- ----- ----------
	OPEN 1 See Section 4.2		OPEN 1 See Section 4.2
	UPDATE 2 See Section 4.3		UPDATE 2 See Section 4.3
	KEEPALIVE 3 See Section 4.4		KEEPALIVE 3 See Section 4.4
	NOTIFICATION 4 See Section 4.5		NOTIFICATION 4 See Section 4.5
	Future assignment are to be made using the Standards Action process		Future assignment are to be made using either the Standards Action
	defined in [RFC2434]. Assignments consist of a name and the value.		process defined in [RFC2434], or the Early IANA Allocation process
			defined in [kompella-zinin]. Assignments consist of a name and the
			value.
	The BGP UPDATE messages may carry one or more Path Attributes, where		The BGP UPDATE messages may carry one or more Path Attributes, where
	each Attribute contains an 8-bit Attribute Type Code. IANA is already		each Attribute contains an 8-bit Attribute Type Code. IANA is already
	maintaining such a registry, entitled "BGP Path Attributes". [note to		maintaining such a registry, entitled "BGP Path Attributes". [note to
	IANA, the registry already exists at http://www.iana.org/assign-		IANA, the registry already exists at http://www.iana.org/assign-
	ments/bgp-parameters, but should be renamed per this document. XXX to		ments/bgp-parameters, but should be renamed per this document. XXX to
	be removed upon RFC publication.] This document defines the following		be removed upon RFC publication.] This document defines the following
	Path Attributes Type Codes:		Path Attributes Type Codes:
	Name Value Definition		Name Value Definition
	---- ----- ----------		---- ----- ----------
	ORIGIN 1 See Section 5.1.1		ORIGIN 1 See Section 5.1.1
	AS_PATH 2 See Section 5.1.2		AS_PATH 2 See Section 5.1.2
	NEXT_HOP 3 See Section 5.1.3		NEXT_HOP 3 See Section 5.1.3
	MULTI_EXIT_DISC 4 See Section 5.1.4		MULTI_EXIT_DISC 4 See Section 5.1.4
	LOCAL_PREF 5 See Section 5.1.5		LOCAL_PREF 5 See Section 5.1.5
	ATOMIC_AGGREGATE 6 See Section 5.1.6		ATOMIC_AGGREGATE 6 See Section 5.1.6
	AGGREGATOR 7 See Section 5.1.7		AGGREGATOR 7 See Section 5.1.7
	Future assignment are to be made using the Standards Action process		Future assignment are to be made using either the Standards Action
	defined in [RFC2434]. Assignments consist of a name and the value.		process defined in [RFC2434], or the Early IANA Allocation process
			defined in [kompella-zinin]. Assignments consist of a name and the
			value.
	The BGP NOTIFICATION message carries an 8-bit Error Code, for which		The BGP NOTIFICATION message carries an 8-bit Error Code, for which
	IANA is to create and maintain a registry entitled "BGP Error Codes".		IANA is to create and maintain a registry entitled "BGP Error Codes".
	This document defines the following Error Codes:		This document defines the following Error Codes:
	Name Value Definition		Name Value Definition
	------------ ----- ----------		------------ ----- ----------
	Message Header Error 1 Section 6.1		Message Header Error 1 Section 6.1
	OPEN Message Error 2 Section 6.2		OPEN Message Error 2 Section 6.2
	UPDATE Message Error 3 Section 6.3		UPDATE Message Error 3 Section 6.3
	Hold Timer Expired 4 Section 6.5		Hold Timer Expired 4 Section 6.5
	Finite State Machine Error 5 Section 6.6		Finite State Machine Error 5 Section 6.6
	Cease 6 Section 6.7		Cease 6 Section 6.7
	Future assignment are to be made using the Standards Action process		Future assignment are to be made using either the Standards Action process
	defined in [RFC2434]. Assignments consist of a name and the value.		defined in [RFC2434], or the Early IANA Allocation process defined
			in [kompella-zinin]. Assignments consist of a name and the value.
	The BGP NOTIFICATION message carries an 8-bit Error Subcode, where		The BGP NOTIFICATION message carries an 8-bit Error Subcode, where
	each Subcode has to be defined within the context of a particular		each Subcode has to be defined within the context of a particular
	Error Code, and thus has to be unique only within that context.		Error Code, and thus has to be unique only within that context.
	IANA is to create and maintain a set of registries, "Error Subcodes",		IANA is to create and maintain a set of registries, "Error Subcodes",
	with a separate registry for each BGP Error Code. Future assignments		with a separate registry for each BGP Error Code. Future assignment are
	are to be made using the Standards Action process defined in		to be made using either the Standards Action process defined in [RFC2434],
	[RFC2434]. Assignments consist of a name and the value.		or the Early IANA Allocation process defined in [kompella-zinin].
			Assignments consist of a name and the value.
	This document defines the following Message Header Error subcodes:		This document defines the following Message Header Error subcodes:
	Name Value Definition		Name Value Definition
	-------------------- ----- ----------		-------------------- ----- ----------
	Connection Not Synchronized 1 See Section 6.1		Connection Not Synchronized 1 See Section 6.1
	Bad Message Length 2 See Section 6.1		Bad Message Length 2 See Section 6.1
	Bad Message Type 3 See Section 6.1		Bad Message Type 3 See Section 6.1
	This document defines the following OPEN Message Error subcodes:		This document defines the following OPEN Message Error subcodes:
	skipping to change at page 98, line 45		skipping to change at page 98, line 46
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5		[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Signature Option", RFC2385, August 1998.		Signature Option", RFC2385, August 1998.
	[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA		[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
	Considerations Section in RFCs", RFC2434, October 1998		Considerations Section in RFCs", RFC2434, October 1998
	[RFC2474] Nichols, K., et al.,"Definition of the Differentiated Ser-		[RFC2474] Nichols, K., et al.,"Definition of the Differentiated
	vices Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474, Decem-		Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474,
	ber 1998		December 1998
	Non-normative References		Non-normative References
	[RFC904] Mills, D., "Exterior Gateway Protocol Formal Specification",		[RFC904] Mills, D., "Exterior Gateway Protocol Formal Specification",
	RFC904, April 1984.		RFC904, April 1984.
	[RFC1092] Rekhter, Y., "EGP and Policy Based Routing in the New		[RFC1092] Rekhter, Y., "EGP and Policy Based Routing in the New
	NSFNET Backbone", RFC1092, February 1989.		NSFNET Backbone", RFC1092, February 1989.
	[RFC1093] Braun, H-W., "The NSFNET Routing Architecture", RFC1093,		[RFC1093] Braun, H-W., "The NSFNET Routing Architecture", RFC1093,
	skipping to change at page 100, line 14		skipping to change at page 100, line 20
	3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint		3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint
	[IS10747] "Information Processing Systems - Telecommunications and		[IS10747] "Information Processing Systems - Telecommunications and
	Information Exchange between Systems - Protocol for Exchange of		Information Exchange between Systems - Protocol for Exchange of
	Inter-domain Routeing Information among Intermediate Systems to Sup-		Inter-domain Routeing Information among Intermediate Systems to Sup-
	port Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993		port Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993
	[BGP_VULN] Murphy, S., "BGP Security Vulnerabilities Analysis",		[BGP_VULN] Murphy, S., "BGP Security Vulnerabilities Analysis",
	draft-ietf-idr-bgp-vuln-00.txt, work in progress		draft-ietf-idr-bgp-vuln-00.txt, work in progress
			[kompella-zinin] Kompella, K., Zinin, A., "Early IANA Allocation of
			Standards Track Codepoints", Work in progress
	Editors' Addresses		Editors' Addresses
	Yakov Rekhter		Yakov Rekhter
	Juniper Networks		Juniper Networks
	email: yakov@juniper.net		email: yakov@juniper.net
	Tony Li		Tony Li
	email: tony.li@tony.li		email: tony.li@tony.li
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/