< draft-ietf-mpls-bfd-directed-17.txt		draft-ietf-mpls-bfd-directed-18.txt >
	MPLS Working Group G. Mirsky		MPLS Working Group G. Mirsky
	Internet-Draft ZTE		Internet-Draft ZTE
	Intended status: Standards Track J. Tantsura		Intended status: Standards Track J. Tantsura
	Expires: August 20, 2021 Juniper Networks		Expires: 21 February 2022 Juniper Networks
	I. Varlashkin		I. Varlashkin
	Google		Google
	M. Chen		M. Chen
	Huawei		Huawei
	February 16, 2021		20 August 2021
	Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS		Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS
	Label Switched Paths (LSPs)		Label Switched Paths (LSPs)
	draft-ietf-mpls-bfd-directed-17		draft-ietf-mpls-bfd-directed-18
	Abstract		Abstract
	Bidirectional Forwarding Detection (BFD) is expected to be able to		Bidirectional Forwarding Detection (BFD) is expected to be able to
	monitor a wide variety of encapsulations of paths between systems.		monitor a wide variety of encapsulations of paths between systems.
	When a BFD session monitors an explicitly routed unidirectional path		When a BFD session monitors an explicitly routed unidirectional path
	there may be a need to direct egress BFD peer to use a specific path		there may be a need to direct egress BFD peer to use a specific path
	for the reverse direction of the BFD session.		for the reverse direction of the BFD session.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 August 20, 2021.		This Internet-Draft will expire on 21 February 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		Please review these documents carefully, as they describe your rights
	to this document. Code Components extracted from this document must		and restrictions with respect to this document. Code Components
	include Simplified BSD License text as described in Section 4.e of		extracted from this document must include Simplified BSD License text
	the Trust Legal Provisions and are provided without warranty as		as described in Section 4.e of the Trust Legal Provisions and are
	described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions used in this document . . . . . . . . . . . . 3		1.1. Conventions used in this document . . . . . . . . . . . . 3
	1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3		1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	3. Control of the Reverse BFD Path . . . . . . . . . . . . . . . 3		3. Control of the Reverse BFD Path . . . . . . . . . . . . . . . 3
	3.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . . . 3		3.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . . . 3
	3.2. Return Codes . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Return Codes . . . . . . . . . . . . . . . . . . . . . . 5
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 28 ¶
	2. Problem Statement		2. Problem Statement
	When BFD is used to monitor explicitly routed unidirectional path,		When BFD is used to monitor explicitly routed unidirectional path,
	e.g., MPLS-TE LSP, BFD control packets in forward direction would be		e.g., MPLS-TE LSP, BFD control packets in forward direction would be
	in-band using the mechanism defined in [RFC5884]. But the reverse		in-band using the mechanism defined in [RFC5884]. But the reverse
	direction of the BFD session would follow the shortest path route and		direction of the BFD session would follow the shortest path route and
	that might lead to the problem in detecting failures on an explicit		that might lead to the problem in detecting failures on an explicit
	unidirectional path, as described below:		unidirectional path, as described below:
	o detection by an ingress node of a failure on the reverse path may		* detection by an ingress node of a failure on the reverse path may
	not be unambiguously interpreted as the failure of the path in the		not be unambiguously interpreted as the failure of the path in the
	forward direction.		forward direction.
	To address this scenario, the egress BFD peer would be instructed to		To address this scenario, the egress BFD peer would be instructed to
	use a specific path for BFD control packets.		use a specific path for BFD control packets.
	3. Control of the Reverse BFD Path		3. Control of the Reverse BFD Path
	To bootstrap a BFD session over an MPLS LSP, LSP ping, defined in		To bootstrap a BFD session over an MPLS LSP, LSP ping, defined in
	[RFC8029], MUST be used with BFD Discriminator TLV [RFC5884]. This		[RFC8029], MUST be used with BFD Discriminator TLV [RFC5884]. This
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 20 ¶
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BFD Reverse Path TLV Type | Length |		| BFD Reverse Path TLV Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reverse Path |		| Reverse Path |
	~ ~		~ ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: BFD Reverse Path TLV		Figure 1: BFD Reverse Path TLV
	BFD Reverse Path TLV Type is two octets in length and has a value of		BFD Reverse Path TLV Type is two octets in length and has a value of
	TBD1 (to be assigned by IANA as requested in Section 6).		TBD1 (to be assigned by IANA as requested in Section 6).
	Length field is two octets long and defines the length in octets of		Length field is two octets long and defines the length in octets of
	the Reverse Path field.		the Reverse Path field.
	Reverse Path field contains none, one or more sub-TLVs. Any non-		Reverse Path field contains none, one or more sub-TLVs. Any non-
	multicast Target FEC Stack sub-TLV (already defined, or to be defined		multicast Target FEC Stack sub-TLV (already defined, or to be defined
	in the future) for TLV Types 1, 16, and 21 of MPLS LSP Ping		in the future) for TLV Types 1, 16, and 21 of MPLS LSP Ping
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	If the egress LSR cannot find the path specified in the Reverse Path		If the egress LSR cannot find the path specified in the Reverse Path
	TLV it MUST send Echo Reply with the received BFD Discriminator TLV,		TLV it MUST send Echo Reply with the received BFD Discriminator TLV,
	Reverse Path TLV and set the Return Code to "Failed to establish the		Reverse Path TLV and set the Return Code to "Failed to establish the
	BFD session. The specified reverse path was not found" Section 3.2.		BFD session. The specified reverse path was not found" Section 3.2.
	An implementation MAY provide configuration options to define action		An implementation MAY provide configuration options to define action
	at the egress BFD peer. For example, if the egress LSR cannot find		at the egress BFD peer. For example, if the egress LSR cannot find
	the path specified in the Reverse Path TLV, it MAY establish the BFD		the path specified in the Reverse Path TLV, it MAY establish the BFD
	session over an IP network, as defined in [RFC5884].		session over an IP network, as defined in [RFC5884].
	The BFD Reverse Path TLV MAY be used in the bootstrapping of a BFD
	session process described in Section 6 [RFC5884]. A system that
	supports this specification MUST support using the BFD Reverse Path
	TLV after the BFD session has been established. If a system that
	supports this specification receives an LSP Ping with the BFD
	Discriminator TLV and no BFD Reverse Path TLV even though the reverse
	path for the specified BFD session has been established according to
	the previously received BFD Reverse Path TLV, the egress LSR MUST
	transition to transmitting periodic BFD Control messages as defined
	in Section 7 [RFC5884].
	3.2. Return Codes		3.2. Return Codes
	This document defines the following Return Codes for MPLS LSP Echo		This document defines the following Return Codes for MPLS LSP Echo
	Reply:		Reply:
	o "Inappropriate Target FEC Stack sub-TLV present", (TBD3). When		* "Inappropriate Target FEC Stack sub-TLV present", (TBD3). When
	multicast Target FEC Stack sub-TLV found in the received Echo		multicast Target FEC Stack sub-TLV found in the received Echo
	Request by the egress BFD peer, an Echo Reply with the return code		Request by the egress BFD peer, an Echo Reply with the return code
	set to "Inappropriate Target FEC Stack sub-TLV present" MUST be		set to "Inappropriate Target FEC Stack sub-TLV present" MUST be
	sent to the ingress BFD peer Section 3.1.		sent to the ingress BFD peer Section 3.1.
	o "Failed to establish the BFD session. The specified reverse path		* "Failed to establish the BFD session. The specified reverse path
	was not found", (TBD4). When a specified reverse path is not		was not found", (TBD4). When a specified reverse path is not
	available at the egress BFD peer, an Echo Reply with the return		available at the egress BFD peer, an Echo Reply with the return
	code set to "Failed to establish the BFD session. The specified		code set to "Failed to establish the BFD session. The specified
	reverse path was not found" MUST be sent back to the ingress BFD		reverse path was not found" MUST be sent back to the ingress BFD
	peer Section 3.1.		peer Section 3.1.
	4. Use Case Scenario		4. Use Case Scenario
	In the network presented in Figure 2 node A monitors two tunnels to		In the network presented in Figure 2 node A monitors two tunnels to
	node H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap a BFD session to		node H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap a BFD session to
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	6. IANA Considerations		6. IANA Considerations
	6.1. BFD Reverse Path TLV		6.1. BFD Reverse Path TLV
	The IANA is requested to assign a new value for BFD Reverse Path TLV		The IANA is requested to assign a new value for BFD Reverse Path TLV
	from the "Multiprotocol Label Switching Architecture (MPLS) Label		from the "Multiprotocol Label Switching Architecture (MPLS) Label
	Switched Paths (LSPs) Ping Parameters - TLVs" registry, "TLVs and		Switched Paths (LSPs) Ping Parameters - TLVs" registry, "TLVs and
	sub-TLVs" sub-registry.		sub-TLVs" sub-registry.
	+--------+----------------------+---------------+		+=========+======================+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+--------+----------------------+---------------+		+=========+======================+===============+
	| (TBD1) | BFD Reverse Path TLV | This document |		| (TBD1) | BFD Reverse Path TLV | This document |
	+--------+----------------------+---------------+		+---------+----------------------+---------------+
	Table 1: New BFD Reverse Type TLV		Table 1: New BFD Reverse Type TLV
	6.2. Return Code		6.2. Return Code
	The IANA is requested to assign a new Return Code value from the		The IANA is requested to assign a new Return Code value from the
	"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)		"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
	Ping Parameters" registry, "Return Codes" sub-registry, as follows		Ping Parameters" registry, "Return Codes" sub-registry, as follows
	using a Standards Action value.		using a Standards Action value.
	+--------+----------------------------------------------+-----------+		+=========+=============================+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+--------+----------------------------------------------+-----------+		+=========+=============================+===============+
	| (TBD3) | Inappropriate Target FEC Stack sub-TLV | This docu |		| (TBD3) | Inappropriate Target FEC | This document |
	| | present. | ment |		| | Stack sub-TLV present. | |
	| (TBD4) | Failed to establish the BFD session. The | This docu |		+---------+-----------------------------+---------------+
	| | specified reverse path was not found. | ment |		| (TBD4) | Failed to establish the BFD | This document |
	+--------+----------------------------------------------+-----------+		| | session. The specified | |
			| | reverse path was not found. | |
			+---------+-----------------------------+---------------+
	Table 2: New Return Code		Table 2: New Return Code
	7. Implementation Status		7. Implementation Status
	- The organization responsible for the implementation: ZTE		- The organization responsible for the implementation: ZTE
	Corporation.		Corporation.
	- The implementation's name ROSng empowers traditional routers, e.g.,		- The implementation's name ROSng empowers traditional routers, e.g.,
	ZXCTN 6000.		ZXCTN 6000.
	- A brief general description: A Return Path can be specified for a		- A brief general description: A Return Path can be specified for a
	skipping to change at page 9, line 27 ¶		skipping to change at page 9, line 33 ¶
	The authors greatly appreciate a thorough review and the most helpful		The authors greatly appreciate a thorough review and the most helpful
	comments from Eric Gray and Carlos Pignataro. The authors much		comments from Eric Gray and Carlos Pignataro. The authors much
	appreciate the help of Qian Xin, who provided information about the		appreciate the help of Qian Xin, who provided information about the
	implementation of this specification.		implementation of this specification.
	Authors' Addresses		Authors' Addresses
	Greg Mirsky		Greg Mirsky
	ZTE		ZTE
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com
	Jeff Tantsura		Jeff Tantsura
	Juniper Networks		Juniper Networks
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Ilya Varlashkin		Ilya Varlashkin
	Google		Google
	Email: Ilya@nobulus.com		Email: Ilya@nobulus.com
End of changes. 15 change blocks.
	43 lines changed or deleted		34 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/