< draft-ietf-idr-bgp-bfd-strict-mode-00.txt		draft-ietf-idr-bgp-bfd-strict-mode-01.txt >
	IDR WorkGroup M. Zheng		IDR Workgroup M. Zheng
	Internet-Draft Indivdual Contributor		Internet-Draft Individual Contributor
	Intended status: Standards Track A. Lindem		Intended status: Standards Track A. Lindem
	Expires: March 24, 2020 Cisco Systems		Expires: May 5, 2020 Cisco Systems
	J. Haas		J. Haas
	Juniper Networks, Inc.		Juniper Networks, Inc.
	September 21, 2019		A. Fu
			Bloomberg L.P.
			November 2, 2019
	BGP BFD Strict-Mode		BGP BFD Strict-Mode
	draft-ietf-idr-bgp-bfd-strict-mode-00		draft-ietf-idr-bgp-bfd-strict-mode-01
	Abstract		Abstract
	This document specifies extensions to RFC4271 BGP-4 that enable a BGP		This document specifies extensions to RFC4271 BGP-4 that enable a BGP
	speaker to negotiate additional Bidirectional Forwarding Detection		speaker to negotiate additional Bidirectional Forwarding Detection
	(BFD) extensions using a BGP capability. This BFD capability enables		(BFD) extensions using a BGP capability. This BFD capability enables
	a BGP speaker to prevent a BGP session from being established until a		a BGP speaker to prevent a BGP session from being established until a
	BFD session is established. It is referred to as BGP BFD "strict-		BFD session is established. It is referred to as BGP BFD "strict-
	mode". BGP BFD strict-mode will be supported when both the local		mode". BGP BFD strict-mode will be supported when both the local
	speaker and its remote peer are BFD strict-mode capable.		speaker and its remote peer are BFD strict-mode capable.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 24, 2020.		This Internet-Draft will expire on May 5, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. BFD Capability . . . . . . . . . . . . . . . . . . . . . . . 3		3. BFD Strict-Mode Capability . . . . . . . . . . . . . . . . . 3
	4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Manageability Considerations . . . . . . . . . . . . . . . . 5		5. Manageability Considerations . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4
	9. Normative References . . . . . . . . . . . . . . . . . . . . 6		9. Normative References . . . . . . . . . . . . . . . . . . . . 4
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	Bidirectional Forwarding Detection BFD [RFC5882] enables routers to		Bidirectional Forwarding Detection BFD [RFC5882] enables routers to
	monitor data plane connectivity and to detect faults in the		monitor data plane connectivity and to detect faults in the
	bidirectional forwarding path between them. This capability is		bidirectional forwarding path between them. This capability is
	leveraged by routing protocols such as BGP [RFC4271] to rapidly react		leveraged by routing protocols such as BGP [RFC4271] to rapidly react
	to topology changes in the face of path failures.		to topology changes in the face of path failures.
	The BFD interaction with BGP is specified in Section 10.2 of		The BFD interaction with BGP is specified in Section 10.2 of
	skipping to change at page 2, line 50 ¶		skipping to change at page 3, line 4 ¶
	To avoid situations which result in routing churn and to minimize the		To avoid situations which result in routing churn and to minimize the
	impact of network interruptions, it will be beneficial to disallow		impact of network interruptions, it will be beneficial to disallow
	BGP to establish a session until BFD session is successfully		BGP to establish a session until BFD session is successfully
	established and has stabilized. We refer to this mode of operation		established and has stabilized. We refer to this mode of operation
	as BGP BFD "strict-mode". However, always using "strict-mode" would		as BGP BFD "strict-mode". However, always using "strict-mode" would
	preclude BGP operation in an environment where not all routers		preclude BGP operation in an environment where not all routers
	support BFD strict-mode or have BFD enabled. This document defines		support BFD strict-mode or have BFD enabled. This document defines
	BGP "strict-mode" operation as preventing BGP session establishment		BGP "strict-mode" operation as preventing BGP session establishment
	until both the local and remove speakers have a stable BFD session.		until both the local and remove speakers have a stable BFD session.
	The document also specifies the BGP protocol extensions for BGP		The document also specifies the BGP protocol extensions for BGP
	capability [RFC5492] for announcing BFD parameters including a BGP		capability [RFC5492] for announcing BFD parameters including a BGP
	speaker's support for "strict-mode", i.e., requiring a BFD session		speaker's support for "strict-mode", i.e., requiring a BFD session
	for BGP session establishment.		for BGP session establishment.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. BFD Capability		3. BFD Strict-Mode Capability
	The BGP Capability [RFC5492] for BFD parameters will allow a BGP		The BGP Strict-Mode Capability [RFC5492] will allow a BGP speaker's
	speaker's BFD capabilities including its support for BFD strict-mode.		to advertise this capability. The capability is defined as follows:
	This capability is defined as follows:
	Capability code: TBD		Capability code: TBD
	Capability length: 1 octet		Capability length: 0 octets
	Capability value: Consists of 1 octet BFD flags as follows:
	+--------------------------------------------------+
	| BFD Flags (8 bits) |
	+--------------------------------------------------+
	The use and meaning of the fields are as follows:
	BFD Flags: This field contains bit flags relating to BFD.
	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+
	|S| Reserved |
	+-+-+-+-+-+-+-+-+
	The most significant bit is defined as state of Strict-Mode ("Strict-
	Mode", or "S") bit, which can be used by a BGP speaker to signal its
	support for BFD Strict-mode. When set (value 1), this bit indicates
	that the BGP speaker has the BFD "Strict-mode" enabled. If both
	local BGP speaker and its peer have BFD strict-mode enabled, then BGP
	session establishment will be prevented until a BFD session is
	established between the peering addresses. A BGP speaker with BFD
	strict-mode enabled MUST advertise the BFD capability with "S" bit
	set.
	The remaining bits are reserved and SHOULD be set to zero by the
	sender and MUST be ignored by the receiver.
	4. Operation		4. Operation
	A BGP speaker which supports capabilities advertisement and has BFD		A BGP speaker which supports capabilities advertisement MUST include
	strict-mode enabled MUST include the BGP BFD capability with the "S"		the BFD strict-mode capability.
	Bit set in the BGP capabilities it advertises.
	A BGP speaker which supports BFD capability, examines the list of		A BGP speaker which supports the BFD Strict-Mode capability, examines
	capabilities present in the Capabilities BFD Parameter that the		the list of capabilities present in the capabilities that the speaker
	speaker receives from its peer. If both the local and remote BGP		receives from its peer. If both the local and remote BGP speakers
	speakers have BFD strict-mode enabled, the BGP finite state machine		include the BFD strict-mode capability, the BGP finite state machine
	does not transition to the Established state from OpenSent or		does not transition to the Established state from OpenSent or
	OpenConfirm state [RFC4271] until the BFD session is in the Up state		OpenConfirm state [RFC4271] until the BFD session is in the Up state
	(see below for AdminDown state). This means that a KEEPALIVE message		(see below for AdminDown state). This means that a KEEPALIVE message
	is not sent nor is the KeepaliveTimer set.		is not sent nor is the KeepaliveTimer set.
	If the BFD session does not transition to the Up state, and the		If the BFD session does not transition to the Up state, and the
	HoldTimer has been negotiated to a non-zero value, the BGP FSM will		HoldTimer has been negotiated to a non-zero value, the BGP FSM will
	close the session appropriately. If the HoldTimer has been		close the session appropriately. If the HoldTimer has been
	negotiated to a zero value, the session should be closed after a time		negotiated to a zero value, the session should be closed after a time
	of X. This time X is referred as "BGP BFD Hold time". The proposed		of X. This time X is referred as "BGP BFD Hold time". The proposed
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 10 ¶
	If BFD session is in the AdminDown state, then the BGP finite state		If BFD session is in the AdminDown state, then the BGP finite state
	machine will proceed normally without input from BFD. This means		machine will proceed normally without input from BFD. This means
	that BFD session "AdminDown" state WILL NOT prevent the BGP state		that BFD session "AdminDown" state WILL NOT prevent the BGP state
	transition to Established state from OpenConfirm.		transition to Established state from OpenConfirm.
	Once the BFD session has transitioned to the Up state, the BGP FSM		Once the BFD session has transitioned to the Up state, the BGP FSM
	may proceed to transition to the Established state from the OpenSent		may proceed to transition to the Established state from the OpenSent
	or OpenConfirm state appropriately. I.e. a KEEPALIVE message is		or OpenConfirm state appropriately. I.e. a KEEPALIVE message is
	sent, and the KeepaliveTimer is started.		sent, and the KeepaliveTimer is started.
	If either BGP peer has not advertised the BFD Capability with strict-		If either BGP peer has not advertised the BFD Strict-Mode Capability,
	mode enabled, then a BFD session WILL NOT be required for the BGP		then a BFD session WILL NOT be required for the BGP session to reach
	session to reach Established state. This does not preclude usage of		Established state. This does not preclude usage of BFD after BGP
	BFD after BGP session establishment [RFC5882].		session establishment [RFC5882].
	5. Manageability Considerations		5. Manageability Considerations
	Auto-configuration is possible for the enabling BGP BFD restrict-		Auto-configuration is possible for the enabling BGP BFD Strict-Mode.
	mode. However, the configuration automation is out of the scope of		However, the configuration automation is out of the scope of this
	this document.		document.
	A BGP NOTIFICATION message subcode indicating BFD Hold timer		A BGP NOTIFICATION message Subcode indicating BFD Hold timer
	expiration may be required for network management. (To be discussed		expiration may be required for network management. (To be discussed
	in the next revision of this document.)		in the next revision of this document.)
	6. Security Considerations		6. Security Considerations
	The mechanism defined in this document interacts with the BGP finite		The mechanism defined in this document interacts with the BGP finite
	state machine when so configured. The security considerations of BFD		state machine when so configured. The security considerations of BFD
	thus become considerations for BGP-4 [RFC4271] so used. The use of		thus, become considerations for BGP-4 [RFC4271] so used. Given that
	the BFD Authentication mechanism defined in [RFC5880] is thus		a BFD session is required for a BGP session, a Denial-of-Service
	RECOMMENDED when used to protect BGP-4 [RFC4271].		(DoS) attack on BGP can now be mounted by preventing a BFD session
			between the BGP peers from being established or interrupting an
			existing BFD session. The use of the BFD Authentication mechanism
			defined in [RFC5880] is thus RECOMMENDED when used to protect BGP-4
			[RFC4271].
	7. IANA Considerations		7. IANA Considerations
	This document defines a new BGP capability - BFD Capability. The		This document defines a new BGP capability - BFD Capability. The
	Capability Code for BFD Capability is TBD.		Capability Code for BFD Capability is TBD.
	IANA is requested to establish a "BGP BFD Capability Flags" registry
	within the "Border Gateway Protocol (BGP) Parameters" grouping. The
	Registration Procedure should be Standards Action, the initial values
	as follows:
	+--------------+---------------+------------+---------------+
	| Bit Position | Name | Short Name | Reference |
	+--------------+---------------+------------+---------------+
	| 0 | Strict-Mode | S | this document |
	| 1-7 | Unassigned | | this document |
	+--------------+---------------+------------+---------------+
	8. Acknowledgement		8. Acknowledgement
	The authors would like to acknowledge the review and inputs from		The authors would like to acknowledge the review and inputs from
	Shyam Sethuram, Mohammed Mirza, Bruno Decraene, and Carlos Pignataro.		Shyam Sethuram, Mohammed Mirza, Bruno Decraene, Carlos Pignataro, and
			Enke Chen.
	9. Normative References		9. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	skipping to change at page 6, line 37 ¶		skipping to change at page 5, line 35 ¶
	DOI 10.17487/RFC5882, June 2010,		DOI 10.17487/RFC5882, June 2010,
	<https://www.rfc-editor.org/info/rfc5882>.		<https://www.rfc-editor.org/info/rfc5882>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	Authors' Addresses		Authors' Addresses
	Mercia Zheng		Mercia Zheng
	Indivdual Contributor		Individual Contributor
	Email: merciaz.ietf@gmail.com		Email: merciaz.ietf@gmail.com
	Acee Lindem		Acee Lindem
	Cisco Systems		Cisco Systems
	301 Midenhall Way		301 Midenhall Way
	GARY, NC 27513		GARY, NC 27513
	UNITED STATES		UNITED STATES
	Email: acee@cisco.com		Email: acee@cisco.com
	Jeffrey Haas		Jeffrey Haas
	Juniper Networks, Inc.		Juniper Networks, Inc.
	1133 Innovation Way		1133 Innovation Way
	SUNNYVALE, CALIFORNIA 94089		SUNNYVALE, CALIFORNIA 94089
	UNITED STATES		UNITED STATES
	Email: jhaas@juniper.net		Email: jhaas@juniper.net
			Albert Fu
			Bloomberg L.P.
			Email: afu14@bloomberg.net
End of changes. 20 change blocks.
	79 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/