draft-ietf-bfd-unaffiliated-echo-01.txt		draft-ietf-bfd-unaffiliated-echo-jhaas.txt
	BFD Working Group W. Cheng		BFD Working Group W. Cheng
	Internet-Draft R. Wang		Internet-Draft R. Wang
	Updates: 5880 (if approved) China Mobile		Updates: 5880 (if approved) China Mobile
	Intended status: Standards Track X. Min		Intended status: Standards Track X. Min
	Expires: May 6, 2021 ZTE Corp.		Expires: October 7, 2021 ZTE Corp.
	R. Rahman		R. Rahman
	Cisco Systems		Cisco Systems
	R. Boddireddy		R. Boddireddy
	Juniper Networks		Juniper Networks
	November 2, 2020		April 5, 2021
	Unaffiliated BFD Echo Function		Unaffiliated BFD Echo Function
	draft-ietf-bfd-unaffiliated-echo-01		draft-ietf-bfd-unaffiliated-echo-01
	Abstract		Abstract
	Bidirectional Forwarding Detection (BFD) is a fault detection		Bidirectional Forwarding Detection (BFD) is a fault detection
	protocol that can quickly determine a communication failure between		protocol that can quickly determine a communication failure between
	two forwarding engines. This document proposes a use of the BFD Echo		two forwarding engines. This document proposes a use of the BFD Echo
	function where the local system supports BFD but the neighboring		function where the local system supports BFD but the neighboring
	system does not support BFD.		system does not support BFD.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://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 May 6, 2021.		This Internet-Draft will expire on October 7, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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		(http://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. Updates to RFC 5880 . . . . . . . . . . . . . . . . . . . . . 3		2. Updates to RFC 5880 . . . . . . . . . . . . . . . . . . . . . 3
	3. Unaffiliated BFD Echo Procedures . . . . . . . . . . . . . . 6		3. Unaffiliated BFD Echo Procedures . . . . . . . . . . . . . . 6
	4. Unaffilicated BFD Echo Applicability . . . . . . . . . . . . 7		4. Unaffilicated BFD Echo Applicability . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	To minimize the impact of device/link faults on services and improve		To minimize the impact of device/link faults on services and improve
	network availability, a network device must be able to quickly detect		network availability, a network device must be able to quickly detect
	faults in communication with adjacent devices. Measures can then be		faults in communication with adjacent devices. Measures can then be
	taken to promptly rectify the faults to ensure service continuity.		taken to promptly rectify the faults to ensure service continuity.
	BFD [RFC5880] is a low-overhead, short-duration method to detect		BFD [RFC5880] is a low-overhead, short-duration method to detect
	faults on the communication path between adjacent forwarding engines.		faults on the communication path between adjacent forwarding engines.
	The faults can be on interface, data link, and even forwarding		The faults can be on interfaces, data link(s), and even the
	engine. It is a single, unified mechanism to monitor any media and		forwarding engines. It is a single, unified mechanism to monitor any
	protocol layers in real time.		media and protocol layers in real time.
	BFD defines Asynchronous mode to satisfy various deployment		BFD defines an Asynchronous mode to satisfy various deployment
	scenarios, and also supports Echo function to reduce the device		scenarios. It also supports an Echo function to reduce the device
	requirement for BFD. When the Echo function is activated, the local		requirement for BFD. When the Echo function is activated, the local
	system sends BFD Echo packets and the remote system loops back the		system sends BFD Echo packets and the remote system loops back the
	received Echo packets through the forwarding path. If several		received Echo packets through the forwarding path. If several
	consecutive BFD Echo packets are not received by the local system,		consecutive BFD Echo packets are not received by the local system,
	then the BFD session is declared to be Down.		then the BFD session is declared to be Down.
	When using BFD Echo function, there are two typical scenarios as		When using BFD Echo function, there are two typical scenarios as
	below:		below:
	o Full BFD protocol capability with affiliated Echo function: this		o Full BFD protocol capability with affiliated Echo function: This
	scenario requires both the local device and the neighboring device		scenario requires both the local device and the neighboring device
	to support full BFD protocol.		to support the full BFD protocol.
	o Only BFD Echo function without full BFD protocol capability:		o BFD Echo-Only function without full BFD protocol capability: This
	this scenario requires only the local device to support sending		scenario requires only the local device to support sending and
	and demultiplexing BFD Control packets.		demultiplexing BFD Control packets.
	The two typical scenarios are both reasonable and useful, and the		The latter scenario is referred to as Unaffiliated BFD Echo function
	latter is referred to as Unaffiliated BFD Echo function in this		in this document.
	document.
	Section 6.2.2 of [BBF-TR-146] describes one use case of the		Section 6.2.2 of [BBF-TR-146] describes one use case of the
	Unaffiliated BFD Echo function, and at least one more use case is		Unaffiliated BFD Echo function, and at least one more use case is
	known in the field BFD deployment.		known is known to be deployed.
	This document describes the use of the Unaffiliated BFD Echo function		This document describes the use of the Unaffiliated BFD Echo function
	over IPv4 and IPv6 for single IP hop.		over IPv4 and IPv6 for single IP hop.
	2. Updates to RFC 5880		2. Updates to RFC 5880
	The Unaffiliated BFD Echo function described in this document reuses		The Unaffiliated BFD Echo function described in this document reuses
	the BFD Echo function as described in [RFC5880] and [RFC5881], but		the BFD Echo function as described in [RFC5880] and [RFC5881], but
	does not require BFD asynchronous mode. When using the Unaffiliated		does not require BFD Asynchronous mode. When using the Unaffiliated
	BFD Echo function, only the local system has the BFD protocol		BFD Echo function, only the local system has the BFD protocol
	enabled, the remote system just loops back the received BFD Echo		enabled; the remote system just loops back the received BFD Echo
	packets as regular data packets.		packets as regular data packets.
	With that said, this document updates [RFC5880] with respect to its		This document updates [RFC5880] with respect to its descriptions on
	descriptions on the BFD Echo function as follows.		the BFD Echo function as follows.
	o [RFC5880] states in the 4th paragraph of Section 3.2:		o [RFC5880] states in the 4th paragraph of Section 3.2:
	An adjunct to both modes is the Echo function. When the Echo		An adjunct to both modes is the Echo function. When the Echo
	function is active, a stream of BFD Echo packets is transmitted in		function is active, a stream of BFD Echo packets is transmitted in
	such a way as to have the other system loop them back through its		such a way as to have the other system loop them back through its
	forwarding path. If a number of packets of the echoed data stream		forwarding path. If a number of packets of the echoed data stream
	are not received, the session is declared to be down. The Echo		are not received, the session is declared to be down. The Echo
	function may be used with either Asynchronous or Demand mode.		function may be used with either Asynchronous or Demand mode.
	Since the Echo function is handling the task of detection, the		Since the Echo function is handling the task of detection, the
	skipping to change at page 7, line 34		skipping to change at page 7, line 30
	+--------+ +---------+		+--------+ +---------+
	| A |---------------------------------| B |		| A |---------------------------------| B |
	| |Inf 1 Inf 1| |		| |Inf 1 Inf 1| |
	+--------+10.1.1.1/24 10.1.1.2/24+---------+		+--------+10.1.1.1/24 10.1.1.2/24+---------+
	BFD is supported. BFD is not supported.		BFD is supported. BFD is not supported.
	Figure 1: Unaffiliated BFD Echo deployment scenario		Figure 1: Unaffiliated BFD Echo deployment scenario
	4. Unaffilicated BFD Echo Applicability		4. Unaffilicated BFD Echo Applicability
	With the more and more application of BFD detection, there are some		Some devices that would benefit from the use of BFD may be unable to
	scenarios the BFD Echo function is deployed. And due to the		support the full BFD protocol. Examples of such devices include
	different capabilities of the devices deploying BFD Echo function,		servers running virtual machines, or Internet of Things (IoT)
	it's required to apply Unaffiliated BFD Echo to the devices that		devices. The Unaffiliated BFD Echo function can be used when two
	couldn't afford the overhead of the full BFD protocol capability,		devices are connected and only one of them supports the BFD protocol,
	such as the servers running virtual machines or some Internet of		and the other is capable of looping BFD Echo packets.
	Things (IoT) devices. Unaffiliated BFD Echo can be used when two
	devices are connected and only one of them supports BFD protocol
	capability.
	Unaffiliated BFD Echo function is reasonable and useful. Firstly,
	Unaffiliated BFD Echo can use BFD protocol capability at the local
	BFD-supported device, while using IP forwarding capability at the
	peer BFD-unsupported device, so Unaffiliated BFD Echo can support
	fast detecting and manage BFD sessions very effectively. Secondly,
	it is scalable when using Unaffiliated BFD Echo to adapt to different
	capabilities of devices.
	5. Security Considerations		5. Security Considerations
			All Security Considerations from [RFC5880] and [RFC5881] apply.
	Unicast Reverse Path Forwarding (uRPF), as specified in [RFC3704] and		Unicast Reverse Path Forwarding (uRPF), as specified in [RFC3704] and
	[RFC8704], is a security feature that prevents the IP address		[RFC8704], is a security feature that prevents the IP address
	spoofing attacks which is commonly used in DoS, DDoS. uRPF has two		spoofing attacks which is commonly used in DoS, DDoS. uRPF has two
	modes called strict mode and loose mode. uRPF strict mode means that		modes called strict mode and loose mode. uRPF strict mode means that
	the router will perform checks for all incoming packets on a certain		the router will perform checks for all incoming packets on a certain
	interface: whether the router has a matching entry for the source IP		interface: whether the router has a matching entry for the source IP
	in the routing table and whether the router uses the same interface		in the routing table and whether the router uses the same interface
	to reach this source IP as where the router received this packet on.		to reach this source IP as where the router received this packet on.
	Note that the use of BFD Echo function would prevent the use of uRPF		Note that the use of BFD Echo function would prevent the use of uRPF
	in strict mode.		in strict mode.
	6. IANA Considerations		6. IANA Considerations
	This document has no IANA action requested.		This document has no IANA action requested.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky		The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky
	skipping to change at page 9, line 6		skipping to change at page 8, line 41
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,		(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
	<https://www.rfc-editor.org/info/rfc5880>.		<https://www.rfc-editor.org/info/rfc5880>.
	[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,		(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI
	DOI 10.17487/RFC5881, June 2010,		10.17487/RFC5881, June 2010, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5881>.		editor.org/info/rfc5881>.
	9.2. Informative References		9.2. Informative References
	[BBF-TR-146]		[BBF-TR-146]
	Broadband Forum, "BBF Technical Report - Subscriber		Broadband Forum, "BBF Technical Report - Subscriber
	Sessions Issue 1", 2013, <https://www.broadband-		Sessions Issue 1", 2013, <https://www.broadband-
	forum.org/technical/download/TR-146.pdf>.		forum.org/technical/download/TR-146.pdf>.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March		Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
End of changes. 22 change blocks.
	46 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/