< draft-mirsky-bfd-mpls-demand-09.txt		draft-mirsky-bfd-mpls-demand-10.txt >
	BFD Working Group G. Mirsky		BFD Working Group G. Mirsky
	Internet-Draft ZTE Corp.		Internet-Draft Ericsson
	Intended status: Standards Track 30 March 2021		Intended status: Standards Track 1 October 2021
	Expires: 1 October 2021		Expires: 4 April 2022
	BFD in Demand Mode over Point-to-Point MPLS LSP		BFD in Demand Mode over Point-to-Point MPLS LSP
	draft-mirsky-bfd-mpls-demand-09		draft-mirsky-bfd-mpls-demand-10
	Abstract		Abstract
	This document describes procedures for using Bidirectional Forwarding		This document describes procedures for using Bidirectional Forwarding
	Detection (BFD) in Demand mode to detect data plane failures in		Detection (BFD) in Demand mode to detect data plane failures in
	Multiprotocol Label Switching (MPLS) point-to-point Label Switched		Multiprotocol Label Switching (MPLS) point-to-point Label Switched
	Paths.		Paths.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 1 October 2021.		This Internet-Draft will expire on 4 April 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as 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
	2. Conventions used in this document . . . . . . . . . . . . . . 2		2. Conventions used in this document . . . . . . . . . . . . . . 2
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
	2.2. Requirements Language . . . . . . . . . . . . . . . . . . 2		2.2. Requirements Language . . . . . . . . . . . . . . . . . . 2
	3. Use of the BFD Demand Mode . . . . . . . . . . . . . . . . . 3		3. Use of the BFD Demand Mode . . . . . . . . . . . . . . . . . 3
			3.1. The Applicability of BFD for Multipoint Networks . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	6. Normative References . . . . . . . . . . . . . . . . . . . . 4		6. Normative References . . . . . . . . . . . . . . . . . . . . 5
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5		7. Informative References . . . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	[RFC5884] defined use of the Asynchronous method of Bidirectional		[RFC5884] defined use of the Asynchronous method of Bidirectional
	Detection (BFD) [RFC5880] to monitor and detect failures in the data		Detection (BFD) [RFC5880] to monitor and detect failures in the data
	path of a Multiprotocol Label Switching (MPLS) Label Switched Path		path of a Multiprotocol Label Switching (MPLS) Label Switched Path
	(LSP). Use of the Demand mode, also specified in [RFC5880], has not		(LSP). Use of the Demand mode, also specified in [RFC5880], has not
	been defined so far. This document describes procedures for using		been defined so far. This document describes procedures for using
	the Demand mode of BFD protocol to detect data plane failures in MPLS		the Demand mode of BFD protocol to detect data plane failures in MPLS
	point-to-point (p2p) LSPs.		point-to-point (p2p) LSPs.
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 23 ¶
	* Final (F) flag in BFD control packet MUST be set;		* Final (F) flag in BFD control packet MUST be set;
	* Demand (D) flag in BFD control packet MUST be cleared.		* Demand (D) flag in BFD control packet MUST be cleared.
	The ingress LER changes the state of the BFD session to Down and		The ingress LER changes the state of the BFD session to Down and
	changes rate of BFD Control packets transmission to one packet per		changes rate of BFD Control packets transmission to one packet per
	second. The ingress LER in Down mode changes to Asynchronous mode		second. The ingress LER in Down mode changes to Asynchronous mode
	until the BFD session comes to Up state once again. Then the ingress		until the BFD session comes to Up state once again. Then the ingress
	LER switches to the Demand mode.		LER switches to the Demand mode.
			3.1. The Applicability of BFD for Multipoint Networks
			[RFC8562] defines the use of BFD in multipoint networks. This
			specification analyzes the case of p2p LSP. In that scenario, the
			ingress of the LSP acts as the MultipointHead, and the egress - as
			MultipointTail. The BFD state machines for MultipointHead,
			MultipointClient, and MultipointTail don't use the three-way
			handshakes for session establishment and teardown. As a result, the
			Init state is absent, and the session transitions to the Up state
			once the BFD session is administratively enabled. Hence, a BFD
			session over a p2p LSP, using principles of [RFC8562] or [RFC8563],
			can be established faster if the MultipointTail has been provisioned
			with the value of My Discriminator used by the MultipointHead for
			that BFD session. That value can be provided to the MultipointTail
			using different mechanisms, e.g., an extension to IGP. Description
			of mechanism to provide the value of My Discriminator used by the
			MultipointHead for the particular BFD session is outside the scope of
			this specification.
			Unsolicited notification of the detected failure by the
			MultipointTail to the MultipointClient performs as described above
			for the case when the ingress BFD system switches the remote peer
			into the Demand mode.
	4. IANA Considerations		4. IANA Considerations
	TBD		TBD
	5. Security Considerations		5. Security Considerations
	This document does not introduce new security aspects but inherits		This document does not introduce new security aspects but inherits
	all security considerations from [RFC5880], [RFC5884], [RFC7726],		all security considerations from [RFC5880], [RFC5884], [RFC7726],
	[RFC8029], and [RFC6425].		[RFC8029], and [RFC6425].
	skipping to change at page 5, line 27 ¶		skipping to change at page 6, line 5 ¶
	[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,		[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
	Aldrin, S., and M. Chen, "Detecting Multiprotocol Label		Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
	Switched (MPLS) Data-Plane Failures", RFC 8029,		Switched (MPLS) Data-Plane Failures", RFC 8029,
	DOI 10.17487/RFC8029, March 2017,		DOI 10.17487/RFC8029, March 2017,
	<https://www.rfc-editor.org/info/rfc8029>.		<https://www.rfc-editor.org/info/rfc8029>.
	[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>.
			[RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
			Ed., "Bidirectional Forwarding Detection (BFD) for
			Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562,
			April 2019, <https://www.rfc-editor.org/info/rfc8562>.
			7. Informative References
			[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
			Ed., "Bidirectional Forwarding Detection (BFD) Multipoint
			Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
			<https://www.rfc-editor.org/info/rfc8563>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	TBD		TBD
	Author's Address		Author's Address
	Greg Mirsky		Greg Mirsky
	ZTE Corp.		Ericsson
	Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com		Email: gregimirsky@gmail.com
End of changes. 9 change blocks.
	10 lines changed or deleted		48 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/