Diff: rfc9612.original.xml

	rfc9612.original.xml	rfc9612.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>

	<!DOCTYPE rfc [	<!DOCTYPE rfc [

	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>
	<?rfc tocdepth="3"?>
	<?rfc tocindent="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" ipr="trust200902"
	docName="draft-ietf-mpls-bfd-directed-31" obsoletes="" updates="" submissionTyp
	e="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="t
	rue" version="3">
	<!-- xml2rfc v2v3 conversion 3.6.0 -->
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>


	<front>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" ipr="trust200902"
		docName="draft-ietf-mpls-bfd-directed-31" number="9612" consensus="true" obsole
		tes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth
		="3" symRefs="true" sortRefs="true" version="3">

		<front>

		<!-- [rfced] The document title includes "Directed Return Path". Is this
		correct, or should it be updated to "Reverse Path"? We ask because 1)
		"Directed" does not appear elsewhere in the document, and 2) the document
		defines the "BFD Reverse Path TLV" (although "Return Path TLV" is
		mentioned multiple times in the document).

		Please review and let us know if any updates to the document title are needed.

		Original:
		Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS
		Label Switched Paths (LSPs)

		Perhaps:
		Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched
		Paths (LSPs)
		-->

	<title abbrev="BFD Directed Return Path for MPLS LSPs">Bidirectional Forward ing Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs)</t itle>	<title abbrev="BFD Directed Return Path for MPLS LSPs">Bidirectional Forward ing Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs)</t itle>

	<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-bfd-directed-31"/>	<seriesInfo name="RFC" value="9612"/>
	<author initials="G." surname="Mirsky" fullname="Greg Mirsky">	<author initials="G." surname="Mirsky" fullname="Greg Mirsky">
	<organization>Ericsson</organization>	<organization>Ericsson</organization>
	<address>	<address>
	<email>gregimirsky@gmail.com</email>	<email>gregimirsky@gmail.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">	<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
	<organization>NVIDIA</organization>	<organization>NVIDIA</organization>
	<address>	<address>
	<email>jefftant.ietf@gmail.com</email>	<email>jefftant.ietf@gmail.com</email>

	skipping to change at line 46 ¶	skipping to change at line 54 ¶
	</author>	</author>
	<author initials="I." surname="Varlashkin" fullname="Ilya Varlashkin">	<author initials="I." surname="Varlashkin" fullname="Ilya Varlashkin">
	<organization>Google</organization>	<organization>Google</organization>
	<address>	<address>
	<email>imv@google.com</email>	<email>imv@google.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">	<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
	<organization>Huawei</organization>	<organization>Huawei</organization>
	<address>	<address>

	<postal>
	<street/>
	<city/>
	<code/>
	<country/>
	</postal>
	<email>mach.chen@huawei.com</email>	<email>mach.chen@huawei.com</email>
	</address>	</address>
	</author>	</author>


	<date year="2024"/>	<date year="2024" month="July"/>

		<area>RTG</area>
		<workgroup>mpls</workgroup>


	<area>Routing</area>
	<workgroup>MPLS Working Group</workgroup>
	<keyword>Internet-Draft</keyword>
	<keyword>LSP Ping</keyword>	<keyword>LSP Ping</keyword>

	<keyword>BFD </keyword>	<keyword>BFD</keyword>

	<abstract>	<abstract>
	<t>	<t>
	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 there may b e a need to direct	When a BFD session monitors an explicitly routed unidirectional path, there may be a need to direct
	the egress BFD peer to use a specific path for the reverse direction of the BFD session.	the egress BFD peer to use a specific path for the reverse direction of the BFD session.
	This document describes an extension to the MPLS Label Switched Path (LSP) echo request that	This document describes an extension to the MPLS Label Switched Path (LSP) echo request that

	allows a BFD system to request that the remote BFD peer transmits BFD control pa ckets	allows a BFD system to request that the remote BFD peer transmit BFD control pac kets
	over the specified LSP.	over the specified LSP.
	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>
	<section anchor="intro" numbered="true" toc="default">	<section anchor="intro" numbered="true" toc="default">
	<name>Introduction</name>	<name>Introduction</name>
	<t>	<t>
	<xref target="RFC5880"/>, <xref target="RFC5881"/>, and <xref target="RFC5883"/ >	<xref target="RFC5880"/>, <xref target="RFC5881"/>, and <xref target="RFC5883"/ >
	established the Bidirectional Forwarding Detection (BFD)	established the Bidirectional Forwarding Detection (BFD)
	protocol for IP networks. <xref target="RFC5884" format="default"/> and <xref t arget="RFC7726" format="default"/>	protocol for IP networks. <xref target="RFC5884" format="default"/> and <xref t arget="RFC7726" format="default"/>
	set rules for using BFD Asynchronous mode over MPLS Label Switched Paths (LSPs) ,	set rules for using BFD Asynchronous mode over MPLS Label Switched Paths (LSPs) ,

	while not defining means to control the path an egress BFD system uses to send BFD	while not defining means to control the path that an egress BFD system uses to send BFD
	control packets towards the ingress BFD system.	control packets towards the ingress BFD system.
	</t>	</t>
	<t>	<t>
	When BFD is used to detect defects of the traffic-engineered LSP,	When BFD is used to detect defects of the traffic-engineered LSP,
	the path of the BFD control packets transmitted by the egress BFD system	the path of the BFD control packets transmitted by the egress BFD system
	toward the ingress may be disjoint from the monitored LSP in the forward directi on.	toward the ingress may be disjoint from the monitored LSP in the forward directi on.
	The fact that BFD control packets are not	The fact that BFD control packets are not
	guaranteed to follow the same links and nodes in both forward and	guaranteed to follow the same links and nodes in both forward and

	reverse directions may be one of the factors contributing to producing false	reverse directions may be one of the factors contributing to false positive d
	positive defect	efect
	notifications, i.e., false alarms, at the ingress BFD peer. Ensuring that bo	notifications (i.e., false alarms) at the ingress BFD peer. Ensuring that bo
	th directions	th directions
	of the BFD session use co-routed paths may, in some environments, improve the	of the BFD session use co-routed paths may, in some environments, improve the
	determinism of the failure detection and localization.	determinism of the failure detection and localization.

	</t>	</t>
	<t>	<t>
	This document defines the BFD Reverse Path TLV as an extension to LSP Ping	This document defines the BFD Reverse Path TLV as an extension to LSP Ping

	<xref target="RFC8029" format="default"/> and proposes	<xref target="RFC8029" format="default"/> and proposes that it be used to
	that it is to be used to instruct the egress BFD system to use an explicit	instruct the egress BFD system to use an explicit path for its BFD control
	path for its BFD control packets associated with a particular BFD session.	packets associated with a particular BFD session. IANA has registered this
	The TLV will be allocated from the	TLV in the "TLVs" registry defined by <xref target="RFC8029"
	TLV and sub-TLV registry defined in <xref target="RFC8029" format="default"/>.	format="default"/> (see <xref target="iana-TLV" format="default"/>). As a spec
	As a special case, forward and reverse	ial case, forward and reverse directions of the
	directions of the BFD session can form a bi-directional co-routed associated ch	BFD session can form a bidirectional co-routed associated channel.
	annel.
	</t>	</t>

	<t>The LSP ping extension, described in this document, was developed	<!-- [rfced] Please clarify "resulting from the operational experiment".

		Original:
		The LSP ping extension, described in this document, was developed and
		implemented resulting from the operational experiment.

		Perhaps:
		The LSP ping extension described in this document was developed and
		implemented as a result of an operational experiment.
		-->

		<!-- [rfced] May we clarify "the use between systems" as follows?

		Original:
		The lessons
		learned from the operational experiment enabled the use between
		systems conforming to this specification.

		Perhaps:
		The lessons
		learned from the operational experiment enabled the use of this
		extension between
		systems conforming to this specification.
		-->

		<t>The LSP ping extension described in this document was developed
	and implemented resulting from the operational experiment. The lessons lea rned from	and implemented resulting from the operational experiment. The lessons lea rned from
	the operational experiment enabled the use between systems conforming to t his specification.	the operational experiment enabled the use between systems conforming to t his specification.

	More implementations are encouraged to understand better the operational i mpact	Further implementation is encouraged to better understand the operational impact
	of the mechanism described in the document.</t>	of the mechanism described in the document.</t>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">

	<name>Conventions used in this document</name>	<name>Conventions Used in This document</name>

	<section title="Terminology">


	<t>BFD: Bidirectional Forwarding Detection</t>	<section>
	<t>FEC: Forwarding Equivalency Class</t>	<name>Terminology</name>
	<t>LSP: Label Switched Path</t>
	<t>LSR: Label-Switching router</t>


		<dl newline="false" spacing="normal" indent="7">
		<dt>BFD:</dt><dd>Bidirectional Forwarding Detection</dd>
		<dt>FEC:</dt><dd>Forwarding Equivalence Class</dd>
		<dt>LSP:</dt><dd>Label Switched Path</dd>
		<dt>LSR:</dt><dd>Label Switching Router</dd>
		</dl>
	</section>	</section>

	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Requirements Language</name>	<name>Requirements Language</name>

	<t>	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"MAY", and "OPTIONAL" in this document are to be interpreted as	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="R	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	FC8174" format="default"/>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
	when, and only when, they appear in all capitals, as shown here.	to be interpreted as described in BCP 14 <xref target="RFC2119"/>
	</t>	<xref target="RFC8174"/> when, and only when, they appear in all capitals,
		as shown here.
		</t>

	</section>	</section>
	</section>	</section>
	</section>	</section>
	<section anchor="problem-statement" numbered="true" toc="default">	<section anchor="problem-statement" numbered="true" toc="default">
	<name>Problem Statement</name>	<name>Problem Statement</name>
	<t>	<t>

	<!--
	BFD is best suited to monitor bi-directional co-routed paths.	<!-- [rfced] FYI - The following comment was left in the xml file. We removed
	In most cases, given stable environments, the forward and reverse directions b	it.
	etween two nodes are
	likely to be co-routed.	BFD is best suited to monitor bi-directional co-routed paths. In
	-->	most cases, given stable environments, the forward and reverse directions
	When BFD is used to monitor an explicitly routed unidirectional path,	between two nodes are likely to be co-routed.
	e.g., MPLS-TE LSP, BFD control packets in the forward direction would	-->
		When BFD is used to monitor an explicitly routed unidirectional path
		(e.g., MPLS-TE LSP), BFD control packets in the forward direction would
	be in-band using the mechanism defined in <xref target="RFC5884"/>. However, the	be in-band using the mechanism defined in <xref target="RFC5884"/>. However, the
	reverse direction of the BFD session would follow the shortest path	reverse direction of the BFD session would follow the shortest path
	route, which could be completely or partially disjoint from the	route, which could be completely or partially disjoint from the
	forward path. This creates the potential for the failure of a	forward path. This creates the potential for the failure of a
	disjoint resource on the reverse path to trigger a BFD failure	disjoint resource on the reverse path to trigger a BFD failure
	detection, even though the forward path is unaffected.	detection, even though the forward path is unaffected.
	</t>	</t>
	<t>	<t>
	If the reverse path is congruent with the forward path, the potential	If the reverse path is congruent with the forward path, the potential
	for such false positives is greatly reduced. For this purpose, this	for such false positives is greatly reduced. For this purpose, this
	specification provides a means for the egress BFD peer to be	specification provides a means for the egress BFD peer to be
	instructed to use a specific path for BFD control packets.	instructed to use a specific path for BFD control packets.
	</t>	</t>
	</section>	</section>
	<section anchor="direct-reverse-bfd" numbered="true" toc="default">	<section anchor="direct-reverse-bfd" numbered="true" toc="default">

	<name>Control of the Reverse BFD Path</name>	<name>Control of the BFD Reverse Path</name>
	<t>	<t>

	To bootstrap a BFD session over an MPLS LSP, LSP ping, defined in <xref target= "RFC8029" format="default"/>, MUST be used with	To bootstrap a BFD session over an MPLS LSP, LSP ping <xref target="RFC8029" fo rmat="default"/> <bcp14>MUST</bcp14> be used with the
	BFD Discriminator TLV <xref target="RFC5884" format="default"/>.	BFD Discriminator TLV <xref target="RFC5884" format="default"/>.

	This document defines a new TLV, BFD Reverse Path TLV, that MAY contain none, o ne or more sub-TLVs	This document defines a new TLV, the BFD Reverse Path TLV, that <bcp14>MAY</bcp 14> contain zero or more sub-TLVs
	that can be used to carry information about the reverse path for	that can be used to carry information about the reverse path for

	the BFD session that is specified by the value in BFD Discriminator TLV.	the BFD session that is specified by the value in the BFD Discriminator TLV.
	</t>	</t>
	<section anchor="bfd-reverse-path-tlv" numbered="true" toc="default">	<section anchor="bfd-reverse-path-tlv" numbered="true" toc="default">
	<name>BFD Reverse Path TLV</name>	<name>BFD Reverse Path TLV</name>


	<t>	<t>
	The BFD Reverse Path TLV is an optional TLV within the LSP ping <xref target="RF C8029" format="default"/>.	The BFD Reverse Path TLV is an optional TLV within the LSP ping <xref target="RF C8029" format="default"/>.

	However, if used, the BFD Discriminator TLV MUST be included in an Echo Request message	However, if used, the BFD Discriminator TLV <bcp14>MUST</bcp14> be included in a n Echo Request message
	as well. If the BFD Discriminator TLV is not present when the BFD Reverse	as well. If the BFD Discriminator TLV is not present when the BFD Reverse

	Path TLV is included; then it MUST be treated as malformed Echo Request, as desc ribed in <xref target="RFC8029" format="default"/>.	Path TLV is included, then it <bcp14>MUST</bcp14> be treated as a malformed Echo Request, as described in <xref target="RFC8029" format="default"/>.
	</t>	</t>
	<t>	<t>
	The BFD Reverse Path TLV carries information about the path onto which the egres s BFD peer of the BFD session referenced by the BFD	The BFD Reverse Path TLV carries information about the path onto which the egres s BFD peer of the BFD session referenced by the BFD

	Discriminator TLV MUST transmit BFD control packets. The format of the BFD Rever se Path TLV is as presented in <xref target="mpls-bfd-tlv" format="default"/>.	Discriminator TLV <bcp14>MUST</bcp14> transmit BFD control packets. The format o f the BFD Reverse Path TLV is presented in <xref target="mpls-bfd-tlv" format="d efault"/>.
	</t>	</t>
	<figure anchor="mpls-bfd-tlv">	<figure anchor="mpls-bfd-tlv">
	<name>BFD Reverse Path TLV</name>	<name>BFD Reverse Path TLV</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	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 \|
	~ ~	~ ~
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>
	BFD Reverse Path TLV Type is two octets in length and has a value of	<!-- [rfced] We updated the text after Figure 1 to be a definition list. Note
	TBD1 (to be assigned by IANA	that we split the paragraph under "Reverse Path" - we included the first
	as requested in <xref target="iana-consider" format="default"/>).	four sentences as the definition and put the remaining sentences in a new
	</t>	paragraph outside of the definition list. Please let us know if this is
	<t>	incorrect.
	Length field is two octets long and defines the length in octets of	-->
	the Reverse Path field.
	</t>	<dl newline="true" spacing="normal">
	<t>	<dt>BFD Reverse Path TLV Type:</dt>
	Reverse Path field contains none, one, or more sub-TLVs. Only non-multicast Targ	<dd>This two-octet field has a value of 16384 (see <xref
	et FEC Stack sub-TLVs (already defined, or to be	target="iana-consider" format="default"/>).
	defined in the future) for TLV Types 1, 16, and 21 of MPLS LSP Ping	</dd>
	Parameters registry are permitted to be used in this field. Any other
	sub-TLV MUST NOT be used. (This implies that Multicast Target FEC Stack sub-T	<dt>Length:</dt>
	LVs, i.e., p2mp	<dd>This two-octet field defines the length in octets of the
	and mp2mp, are not permitted in the Reverse Path field.) If the egress Label-	Reverse Path field.
	Switching Router (LSR) finds multicast	</dd>
	Target Stack sub-TLV, it MUST send echo reply with the received Reve
	rse Path TLV,	<!-- [rfced] FYI - We updated "none, one or more sub-TLVs" to "zero or more
	BFD Discriminator TLV and set the Return Code to "Inappropriate Targ	sub-TLVs". Let us know any concerns.
	et FEC Stack
	sub-TLV present" (<xref target="return-codes" format="default"/>).	Original:
	The BFD Reverse Path TLV includes none, one or more sub-TLVs.	This document defines a new TLV, BFD Reverse Path TLV, that MAY contain
	However, the number of sub-TLVs in the Reverse Path field MUST be lim	none, one or more sub-TLVs that can be used to carry information
	ited.	about the reverse path for the BFD session that is specified by the
	The default limit is 128 sub-TLV entries, but an implementation MAY b	value in BFD Discriminator TLV.
	e able to control that limit.	...
	An empty BFD Reverse Path TLV, i.e., no sub-TLVs present, is used	Reverse Path field contains none, one, or more sub-TLVs.
	as withdrawal of any previously set reverse path for the BFD session	...
	identified in the BFD Discriminator TLV.	The BFD Reverse Path TLV includes none, one or more sub-TLVs.
	If no sub-TLVs are found in the BFD Reverse Path TLV, the egress BFD
	peer MUST revert to	Updated:
	using the local policy-based decision as described in Section 7 of <x	This document defines a new TLV, the BFD Reverse Path TLV, that MAY contain
	ref target="RFC5884" format="default"/>, i.e., routed over IP network.	zero or more sub-TLVs that can be used to carry information
	</t>	about the the reverse path for the BFD session that is specified by the
	<t>	value in the BFD Discriminator TLV.
	If the egress peer LSR cannot find the path specified in the Revers	...
	e Path TLV, it MUST send Echo	This field contains zero or more sub-TLVs.
	Reply with the received BFD Discriminator TLV, Reverse Path TLV,	...
	and set the Return Code to "Failed to establish the	The BFD Reverse Path TLV includes zero or more sub-TLVs.
	BFD session. The specified reverse path was not found" (<xref targe	-->
	t="return-codes" format="default"/>).
	If an implementation provides additional configuration options, the	<!-- [rfced] Does the phrase "that can be used to carry information..." modify
	se can control actions at the egress BFD peer, including	"new TLV" or "none, one or more sub-TLVs"? If it modifies "new TLV", may
	when the path specified in the Reverse Path TLV cannot be found.	we update as follows for clarity?
	For example, optionally, if the egress peer LSR cannot find the path specified
	in the Reverse Path	Original:
	TLV, it MAY establish the BFD session over an IP network, as defined in <xref	This document defines a new TLV, BFD Reverse Path TLV, that MAY contain
	target="RFC5884" format="default"/>.	none, one or more sub-TLVs that can be used to carry information
	Note that the return code required by the MUST clause does not preclude the se	about the reverse path for the BFD session that is specified by the
	ssion from being established over a different path as discussed in the MAY claus	value in BFD Discriminator TLV.
	e.
		Perhaps (modifies "new TLV"):
		This document defines a new TLV, the BFD Reverse Path TLV,
		that can be used to carry information
		about the reverse path for the BFD session that is specified by the
		value in the BFD Discriminator TLV. The BFD Reverse Path TLV MAY contain
		zero or more sub-TLVs.
		-->

		<dt>Reverse Path:</dt>
		<dd>This field contains zero or more sub-TLVs. Only non-multicast
		Target FEC Stack sub-TLVs (already defined or to be defined in the future)
		for TLV Types 1, 16, and 21 in the "Multiprotocol Label Switching (MPLS)
		Label Switched Paths (LSPs) Ping Parameters" registry are permitted to be
		used in this field. Other sub-TLVs <bcp14>MUST NOT</bcp14> be used. (This
		implies that multicast Target FEC Stack sub-TLVs, i.e., p2mp and mp2mp, are
		not permitted in the Reverse Path field.)
		</dd>
		</dl>

		<!-- [rfced] Please clarify the following phrases in the sentences below:

		"received Reverse Path TLV, BFD Discriminator TLV"
		"received BFD Discriminator TLV, BFD Reverse Path TLV"

		Original:
		If the egress Label-Switching Router
		(LSR) finds multicast Target Stack sub-TLV, it MUST send echo
		reply with the received Reverse Path TLV, BFD Discriminator TLV
		and set the Return Code to "Inappropriate Target FEC Stack sub-TLV
		present" (Section 3.2).
		...
		If the egress peer LSR cannot find the path specified in the Reverse
		Path 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 BFD session. The specified reverse path was not found"
		(Section 3.2).

		Perhaps:
		If the egress LSR finds a multicast Target FEC Stack sub-TLV, it MUST
		send an echo reply with the received BFD Reverse Path TLV and BFD
		Discriminator TLV and set the Return Code to 192 ("Inappropriate
		Target FEC Stack sub-TLV present") (see Section 3.2).
		...
		If the egress peer LSR cannot find the path specified in the BFD
		Reverse Path TLV, it MUST send an Echo Reply with the received BFD
		Discriminator TLV and BFD Reverse Path TLV and set the Return Code to
		193 ("Failed to establish the BFD session. The specified reverse
		path was not found") (see Section 3.2).
		-->

		<!-- [rfced] Please confirm that "Section 7 of [RFC5884]" is correct here. We
		do not see "policy" or "decision" in RFC 5884 and only see "local" used
		once in Section 7. Perhaps "as described in Section 7 of [RFC5884]"
		should appear after the phrase "i.e., routed over IP network"? Section 7
		of RFC 5884 says, "The BFD Control packet sent by the egress LSR to the
		ingress LSR MAY be routed based on the destination IP address".

		Let us know if any updates would be helpful.

		Original:
		If no sub-TLVs are found in the BFD Reverse
		Path TLV, the egress BFD peer MUST revert to using the local policy-
		based decision as described in Section 7 of [RFC5884], i.e., routed
		over IP network.

		Perhaps:
		If no sub-TLVs are found in the BFD Reverse
		Path TLV, the egress BFD peer MUST revert to using the decision
		based on local policy, i.e., routing
		over an IP network, as described in Section 7 of [RFC5884].
		-->

		<t>If the egress LSR finds a multicast Target FEC Stack sub-TLV, it
		<bcp14>MUST</bcp14> send an echo reply with the received BFD Reverse Path
		TLV, BFD Discriminator TLV and set the Return Code to 192 ("Inappropriate
		Target FEC Stack sub-TLV present") (see <xref target="return-codes"
		format="default"/>). The BFD Reverse Path TLV includes zero or more
		sub-TLVs. However, the number of sub-TLVs in the Reverse Path field
		<bcp14>MUST</bcp14> be limited. The default limit is 128 sub-TLV entries,
		but an implementation <bcp14>MAY</bcp14> be able to control that limit. An
		empty BFD Reverse Path TLV (i.e., a BFD Reverse Path TLV with no sub-TLVs)
		is used to withdraw any previously set reverse path for the BFD session
		identified in the BFD Discriminator TLV. If no sub-TLVs are found in the
		BFD Reverse Path TLV, the egress BFD peer <bcp14>MUST</bcp14> revert to
		using the local policy-based decision as described in <xref target="RFC5884"
		format="default" sectionFormat="of" section="7"/>, i.e., routed over an IP
		network.</t>
		<!-- [rfced] Is "optionally" needed in this sentence?

		Original:
		For example, optionally, if the egress peer LSR
		cannot find the path specified in the Reverse Path TLV, it MAY
		establish the BFD session over an IP network, as defined in
		[RFC5884].

		Perhaps:
		For example, if the egress peer LSR
		cannot find the path specified in the Reverse Path TLV, it MAY
		establish the BFD session over an IP network, as defined in
		[RFC5884].
		-->

		<t>
		If the egress peer LSR cannot find the path specified in the BFD
		Reverse Path TLV, it <bcp14>MUST</bcp14> send an Echo Reply with
		the received BFD Discriminator TLV, BFD Reverse Path TLV and set
		the Return Code to 193 ("Failed to establish the BFD session. The
		specified reverse path was not found.") (see <xref
		target="return-codes" format="default"/>). If an implementation
		provides additional configuration options, these can control
		actions at the egress BFD peer, including when the path specified
		in the BFD Reverse Path TLV cannot be found. For example,
		optionally, if the egress peer LSR cannot find the path specified
		in the BFD Reverse Path TLV, it <bcp14>MAY</bcp14> establish the
		BFD session over an IP network, as defined in <xref
		target="RFC5884" format="default"/>. Note that the Return Code
		required by the "<bcp14>MUST</bcp14>" clause in this paragraph does
		not preclude
		the session from being established over a different path as
		discussed in the "<bcp14>MAY</bcp14>" clause.
	</t>	</t>

	<t>
	The BFD Reverse Path TLV MAY be used in the bootstrapping of a BFD	<!-- [rfced] This sentence may be difficult for readers to follow because of
	session process described in Section 6 of <xref target="RFC5884"/>. A system	the nested quotation marks. May we rephrase as follows to avoid a direct
	that	quote and the nested quotation marks?
	supports this specification MUST support using the BFD Reverse Path
	TLV after the BFD session has been established. If a system that	Original:
	supports this specification receives an LSP Ping with the BFD	If a BFD system that received an
	Discriminator TLV and no BFD Reverse Path TLV even though the reverse	LSP Ping with the BFD Reverse Path TLV does not support this
	path for the specified BFD session has been established according to	specification, it will "result in the Return Code of 2 ("One or more
	the previously received BFD Reverse Path TLV, the egress BFD peer MUST	of the TLVs was not understood") being sent in the echo response"
	transition to transmitting periodic BFD Control messages as defined	(Section 3 of [RFC8029]).
	in Section 7 of <xref target="RFC5884"/>. If a BFD system that received an LS
	P Ping with	Perhaps:
	the BFD Reverse Path TLV does not support this specification, it will "result	If a BFD system that received an
	in the Return Code of 2 ("One or more of the TLVs was not	LSP Ping with the BFD Reverse Path TLV does not support this
	understood") being sent in the echo response" (Section 3 of <xref target="RFC	specification, it will result in an echo response with the Return Code
	8029"/>).	set to 2 ("One or more of the TLVs was not understood"), as described in
		Section 3 of [RFC8029].
		-->

		<t>
		The BFD Reverse Path TLV <bcp14>MAY</bcp14> be used in the process
		of bootstrapping the BFD session as described in <xref
		target="RFC5884" section="6" sectionFormat="of" />. A system that
		supports this specification <bcp14>MUST</bcp14> 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 was established
		according to the previously received BFD Reverse Path TLV, the
		egress BFD peer <bcp14>MUST</bcp14> transition to transmitting
		periodic BFD Control messages as described in <xref target="RFC5884"
		section="7" sectionFormat="of" />. If a BFD system that received an
		LSP Ping with the BFD Reverse Path TLV does not support this
		specification, it will "result in the Return Code of 2 ("One or
		more of the TLVs was not understood") being sent in the echo
		response" (<xref target="RFC8029" section="3" sectionFormat="of"
		/>).
	</t>	</t>
	</section>	</section>
	<section anchor="return-codes" numbered="true" toc="default">	<section anchor="return-codes" numbered="true" toc="default">
	<name>Return Codes</name>	<name>Return Codes</name>
	<t>	<t>

	This document defines the following Return Codes for MPLS LSP Echo Reply:	This document defines the following Return Codes for the MPLS LSP Echo Reply:
	</t>	</t>

	<ul spacing="normal">	<dl spacing="normal" newline="true">
	<li>	<dt>"Inappropriate Target FEC Stack sub-TLV present" (192):</dt>
	"Inappropriate Target FEC Stack sub-TLV present" (TBD3). When multicast Target F	<dd>When a multicast Target FEC Stack sub-TLV is found in
	EC Stack sub-TLV found in	the received Echo Request, the egress BFD peer sends an Echo Reply with the Retu
	the received Echo Request, the egress BFD peer sends an Echo Reply with the retu	rn Code set to 192
	rn code set to	("Inappropriate Target FEC Stack sub-TLV present") to the ingress BFD peer, as d
	"Inappropriate Target FEC Stack sub-TLV present" to the ingress BFD peer <xref t	escribed in <xref target="bfd-reverse-path-tlv" format="default"/>.
	arget="bfd-reverse-path-tlv" format="default"/>.	</dd>
	</li>	<dt>"Failed to establish the BFD session. The specified reverse path w
	<li>	as not found." (193):</dt>
	"Failed to establish the BFD session. The specified reverse path was not found"	<dd>When a specified reverse path is unavailable, the egress BFD peer sends an
	(TBD4).	Echo Reply with the Return Code set to 193 ("Failed to establish the BFD
	When a specified reverse path is unavailable, the egress BFD peer sends an Echo	session. The specified reverse path was not found.") to the ingress BFD peer, as
	Reply with the return	described in <xref target="bfd-reverse-path-tlv" format="default"/>.
	code set to "Failed to establish the BFD session. The specified reverse path was	</dd>
	not found"	</dl>
	to the ingress BFD peer <xref target="bfd-reverse-path-tlv" format="default"/>.
	</li>
	</ul>
	</section>	</section>
	<section anchor="failure-character-sec" numbered="true" toc="default">	<section anchor="failure-character-sec" numbered="true" toc="default">
	<name>Failure Characterization</name>	<name>Failure Characterization</name>
	<t>	<t>

	A failure detected by a BFD session that uses the BFD Reverse Path TLV	A failure detected by a BFD session that uses the BFD Reverse Path TLV
	could be due to a change in the FEC used in the BFD Reverse Path TLV.	could be due to a change in the FEC used in the BFD Reverse Path TLV.

	The ingress BFD peer, upon detection of the network failure, MUST trans	Upon detection of the network failure, the ingress BFD peer <bcp14>MUST
	mit the LSP Ping Echo request with Return Path TLV	</bcp14> transmit the LSP Ping Echo request with the Return Path TLV
	to verify whether the FEC is still valid. If the failure was caused by the c	to verify whether the FEC is still valid. If the failure was caused by a cha
	hange in the FEC used for the	nge in the FEC used for the
	reverse direction of the BFD session, the ingress BFD peer MUST re-direct th	reverse direction of the BFD session, the ingress BFD peer <bcp14>MUST</bcp1
	e reverse path of the BFD session	4> redirect the reverse path of the BFD session
	using another FEC in BFD Reverse Path TLV, and notify an operator.	using another FEC in the BFD Reverse Path TLV and notify an operator.
	</t>	</t>
	</section>	</section>
	</section>	</section>
	<section anchor="use-case" numbered="true" toc="default">	<section anchor="use-case" numbered="true" toc="default">
	<name>Use Case Scenario</name>	<name>Use Case Scenario</name>


		<!-- [rfced] The second sentence below includes the citation [RFC7726], but
		the first sentence (which appears earlier in the same paragraph) does
		not. Perhaps the citation should appear in the first sentence instead of
		the second, or perhaps it should appear in both? Please review.

		Original:
		To bootstrap a BFD session to monitor the first tunnel, the ingress LSR
		peer A includes a BFD Discriminator TLV with Discriminator value
		(e.g., foobar-1).
		...
		To bootstrap a BFD session to monitor the second tunnel, ingress LSR
		peer A, includes a BFD Discriminator TLV with a different
		Discriminator value (e.g., foobar-2) [RFC7726] and a BFD Reverse Path
		TLV that references the H-G-F-E-B-A tunnel.

		Perhaps:
		To bootstrap a BFD session to monitor the first tunnel, the ingress LSR
		peer A includes a BFD Discriminator TLV with a Discriminator value
		(e.g., foobar-1) [RFC7726].
		...
		To bootstrap a BFD session to monitor the second tunnel, the ingress LSR
		peer A includes a BFD Discriminator TLV with a different
		Discriminator value (e.g., foobar-2) and a BFD Reverse Path
		TLV that references the H-G-F-E-B-A tunnel.
		-->

		<!-- [rfced] Would you like to update "Peer A" to "Ingress LSR peer A"? The
		other sentences in the same paragraph use "ingress LSR peer A".

		Original:
		Peer A includes a BFD Reverse Path TLV referencing
		the H-G-D-C-B-A tunnel to control the path from the egress LSR.

		Perhaps:
		Ingress LSR peer A includes a BFD Reverse Path TLV referencing
		the H-G-D-C-B-A tunnel to control the path from the egress LSR.
		-->

	<t>	<t>
	In the network presented in <xref target="use-case-fig" format="default"/>, ing ress LSR peer A monitors two	In the network presented in <xref target="use-case-fig" format="default"/>, ing ress LSR peer A monitors two

	tunnels to the egress LSR peer H: A-B-C-D-G-H and A-B-E-F-G-H.	tunnels to egress LSR peer H: A-B-C-D-G-H and A-B-E-F-G-H.
	To bootstrap a BFD session to monitor the first tunnel, the ingress LSR peer A	To bootstrap a BFD session to monitor the first tunnel, ingress LSR peer A incl
	includes	udes
	a BFD Discriminator TLV with Discriminator value (e.g., foobar-1). Peer A inclu	a BFD Discriminator TLV with a Discriminator value (e.g., foobar-1). Peer A inc
	des	ludes
	a BFD Reverse Path TLV referencing the H-G-D-C-B-A tunnel to control the path f rom the egress LSR.	a BFD Reverse Path TLV referencing the H-G-D-C-B-A tunnel to control the path f rom the egress LSR.

	To bootstrap a BFD session to monitor the second tunnel, ingress LSR peer A, in cludes	To bootstrap a BFD session to monitor the second tunnel, ingress LSR peer A inc ludes
	a BFD Discriminator TLV with a different Discriminator value (e.g., foobar-2)	a BFD Discriminator TLV with a different Discriminator value (e.g., foobar-2)
	<xref target="RFC7726" format="default"/> and a BFD Reverse Path TLV that refe rences the H-G-F-E-B-A tunnel.	<xref target="RFC7726" format="default"/> and a BFD Reverse Path TLV that refe rences the H-G-F-E-B-A tunnel.
	</t>	</t>
	<figure anchor="use-case-fig">	<figure anchor="use-case-fig">
	<name>Use Case for BFD Reverse Path TLV</name>	<name>Use Case for BFD Reverse Path TLV</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	C---------D	C---------D
	\| \|	\| \|
	A-------B G-----H	A-------B G-----H
	\| \|	\| \|
	E---------F	E---------F
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	<t>	<t>

	If an operator needs egress LSR peer H to monitor a path to the ingress LSR peer	If an operator needs egress LSR peer H to monitor a path to ingress LSR peer A,
	A, e.g.,	e.g.,
	H-G-D-C-B-A tunnel, then by looking up the list of known Reverse Paths,	the H-G-D-C-B-A tunnel, then by looking up the list of known reverse paths,
	it MAY find and use the existing BFD session.	it <bcp14>MAY</bcp14> find and use the existing BFD session.
	</t>	</t>
	</section>	</section>
	<section anchor="operational-sec" numbered="true" toc="default">	<section anchor="operational-sec" numbered="true" toc="default">
	<name>Operational Considerations</name>	<name>Operational Considerations</name>


		<!-- [rfced] Please confirm that "[RFC7110]" is correct in these sentences. We
		ask because "Return Path TLV" appears just once in RFC 7110, though
		"return path" appears many times. RFC 7110 defines the "Reply Path TLV".

		Original:
		If a particular set
		of sub-TLVs composes the Return Path TLV [RFC7110] and does not
		increase the length of the Maximum Transmission Unit for the given
		LSP, that set can be safely used in the BFD Reverse Path TLV.
		...
		...then the periodic verification of the control plane against the data
		plane, as recommended in Section 4 of [RFC5884], MUST use the Return
		Path TLV, as per [RFC7110], with that sub-TLV.
		-->

		<!-- [rfced] We have updated the "If" clause at the beginning of this sentence
		as shown below. Please let us know any concerns.

		Original:
		If any of defined in [RFC7110] sub-TLVs used in BFD Reverse Path TLV,
		then the periodic verification of the control plane against the data
		plane, as recommended in Section 4 of [RFC5884], MUST use the Return
		Path TLV, as per [RFC7110], with that sub-TLV.

		Current:
		If any of the sub-TLVs defined in [RFC7110] are used in the BFD Reverse Path
		TLV,
		then the periodic verification of the control plane against the data
		plane, as recommended in Section 4 of [RFC5884], MUST use the Return
		Path TLV, as per [RFC7110], with that sub-TLV.
		-->

	<t>	<t>

	When an explicit path is set either as Static or RSVP-TE LSP,	When an explicit path is set as either Static or RSVP-TE LSP,
	corresponding sub-TLVs, defined in <xref target="RFC7110" format="default"/>,	corresponding sub-TLVs (defined in <xref target="RFC7110" format="default"/>)
	MAY be used	<bcp14>MAY</bcp14> be used
	to identify the explicit reverse path for the BFD session. If a particular set of sub-TLVs composes the Return Path TLV <xref target="RFC7110"/>	to identify the explicit reverse path for the BFD session. If a particular set of sub-TLVs composes the Return Path TLV <xref target="RFC7110"/>
	and does not increase the length of the Maximum Transmission Unit for the giv en LSP, that set can be safely used in the BFD Reverse Path TLV.	and does not increase the length of the Maximum Transmission Unit for the giv en LSP, that set can be safely used in the BFD Reverse Path TLV.

	If any of defined in <xref target="RFC7110" format="default"/>	If any of the sub-TLVs defined in <xref target="RFC7110" format="default"/>
	sub-TLVs used in BFD Reverse Path TLV, then the periodic verification of the c	are used in the BFD Reverse Path TLV, then the periodic verification of the c
	ontrol plane	ontrol plane
	against the data plane, as recommended in Section 4 of <xref target="RFC5884"	against the data plane, as recommended in <xref target="RFC5884" section="4" s
	format="default"/>, MUST use	ectionFormat="of" format="default"/>, <bcp14>MUST</bcp14> use
	the Return Path TLV, as per <xref target="RFC7110" format="default"/>, with th at sub-TLV.	the Return Path TLV, as per <xref target="RFC7110" format="default"/>, with th at sub-TLV.

	By using the LSP Ping with Return Path TLV, an operator monitors whether	By using the LSP Ping with the Return Path TLV, an operator monitors whether
	at the egress BFD node the reverse LSP is mapped to the same FEC as the BFD se	the reverse LSP is mapped to the same FEC as the BFD session at the egress BF
	ssion.	D node.
	Selection and control of the rate of LSP Ping with Return Path TLV	Selection and control of the rate of the LSP Ping with the Return Path TLV
	follows the recommendation of <xref target="RFC5884" format="default"/>:	follows the recommendation in <xref target="RFC5884" format="default"/>:</
	"The rate of generation of these LSP Ping Echo request	t>
	messages SHOULD be significantly less than the rate of generation of	<blockquote>
	the BFD Control packets. An implementation MAY provide configuration	The rate of generation of these LSP Ping Echo request messages
	options to control the rate of generation of the periodic LSP Ping	<bcp14>SHOULD</bcp14> be significantly less than the rate of generation of the
	Echo request messages."	BFD Control packets. An implementation <bcp14>MAY</bcp14> provide
	</t>	configuration options to control the rate of generation of the periodic LSP
	<t>	Ping Echo request messages.
	Suppose an operator planned network maintenance activity that	</blockquote>
	possibly affects FEC used in the BFD Reverse Path TLV. In that case,
	the operator can avoid the unnecessary disruption by using the LSP Ping	<!-- [rfced] The text starting with "Because the frequency" is a sentence
		fragment (i.e., incomplete sentence). How may we update to create a
		complete sentence? Also, should "will be" be updated to "is"? The
		preceding sentence is included for context below.

		Original:
		But in some
		scenarios, proactive measures cannot be taken. Because the frequency
		of LSP Ping messages will be lower than the defect detection time
		provided by the BFD session.

		Perhaps:
		But in some
		scenarios, proactive measures cannot be taken because the frequency
		of LSP Ping messages is lower than the defect detection time
		provided by the BFD session.
		-->

		<t>
		Suppose an operator planned a network maintenance activity that
		possibly affects the FEC used in the BFD Reverse Path TLV. In that case,
		the operator can avoid unnecessary disruption by using the LSP Ping
	with a new FEC in the BFD Reverse Path TLV. But in some scenarios, proactive measures cannot be taken.	with a new FEC in the BFD Reverse Path TLV. But in some scenarios, proactive measures cannot be taken.
	Because the frequency of LSP Ping messages will be lower than the defect det ection time provided by the BFD session.	Because the frequency of LSP Ping messages will be lower than the defect det ection time provided by the BFD session.
	As a result, a change in the reverse-path FEC will first be detected as the BFD session's failure.	As a result, a change in the reverse-path FEC will first be detected as the BFD session's failure.
	An operator will be notified as described in <xref target="failure-character- sec"/>.	An operator will be notified as described in <xref target="failure-character- sec"/>.
	</t>	</t>
	</section>	</section>
	<section anchor="iana-consider" numbered="true" toc="default">	<section anchor="iana-consider" numbered="true" toc="default">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>


		<!-- [rfced] IANA Considerations

		a) FYI - In Table 1, we made the following updates. If no objections, we will
		ask IANA to update the registry accordingly prior to publication.

		- removed "TLV" from the "TLV Name" column. This aligns with the majority of the
		names listed in the "TLVs" registry.

		- edited the text in the "Sub-TLV Registry" column:

		Link to "TLVs" registry: https://www.iana.org/assignments/mpls-lsp-ping-paramete
		rs/mpls-lsp-ping-parameters.xhtml#tlvs

		b) In Table 1, may we further update the "Sub-TLV Registry" column to include
		the registry name?

		Current:
		Only non-multicast sub-TLVs (already defined or to be defined in the
		future) at <https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp
		-ping-parameters.xml#sub-tlv-1-16-21>
		are permitted to be used in this field. Other sub-TLVs MUST NOT be used.

		Perhaps:
		Only non-multicast sub-TLVs (already defined or to be defined in the future) i
		n
		the "Sub-TLVs for TLV Types 1, 16, and 21" registry at
		<https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-param
		eters.xml#sub-tlv-1-16-21>
		are permitted to be used in this field. Other sub-TLVs MUST NOT be used.

		c) We removed the period from the description of the first error
		code below (phrase) and retained periods for the second (complete
		sentences). This aligns with the pattern we see in the "Return Codes"
		registry. If no objections, we will ask IANA to update the registry
		accordingly.

		Link to "Return Codes" registry: https://www.iana.org/assignments/mpls-lsp-ping-
		parameters/mpls-lsp-ping-parameters.xhtml#return-codes

		Original:
		(TBD3) Inappropriate Target FEC Stack sub-TLV present.
		...
		(TBD4) Failed to establish the BFD session. The specified reverse path was no
		t found.

		Current:
		192 Inappropriate Target FEC Stack sub-TLV present
		...
		193 Failed to establish the BFD session. The specified reverse path was not f
		ound.
		-->

	<section anchor="iana-TLV" numbered="true" toc="default">	<section anchor="iana-TLV" numbered="true" toc="default">
	<name>BFD Reverse Path TLV</name>	<name>BFD Reverse Path TLV</name>
	<t>	<t>

	The IANA is requested to assign a new value for BFD Reverse Path TLV from t	IANA has assigned the following value for the BFD Reverse Path TLV from the
	he 16384-31739 range in the "TLVs" registry of "Multiprotocol Label	16384-31739 range in the "TLVs" subregistry within the "Multiprotocol Label Swi
	Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters"	tching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry.
	registry.
	</t>	</t>
	<table anchor="bfdtlv-table" align="center">	<table anchor="bfdtlv-table" align="center">

	<name>New BFD Reverse Type TLV</name>	<name>New BFD Reverse Path TLV</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Type</th>	<th align="left">Type</th>
	<th align="left">TLV Name</th>	<th align="left">TLV Name</th>
	<th align="left">Reference</th>	<th align="left">Reference</th>
	<th align="left">Sub-TLV Registry</th>	<th align="left">Sub-TLV Registry</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>

	<td align="left"> (TBD1)</td>	<td align="left">16384</td>
	<td align="left">BFD Reverse Path TLV</td>	<td align="left">BFD Reverse Path</td>
	<td align="left">This document</td>	<td align="left">RFC 9612</td>
	<td align="left">Only non-multicast sub-TLV (already defined or to	<td align="left">Only non-multicast sub-TLVs (already defined or
	be defined in the future)	to be defined in the future) at <eref brackets="angle"
	at <eref target="https://www.iana.org/assignments/mpls-lsp-ping-pa	target="https://www.iana.org/assignments/mpls-lsp-ping-parameters/
	rameters/mpls-lsp-ping-parameters.xml#sub-tlv-1-16-21">	mpls-lsp-ping-parameters.xml#sub-tlv-1-16-21"/>
	[https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-ls	are permitted to be used in this field. Other sub-TLVs <bcp14>MUS
	p-ping-parameters.xml#sub-tlv-1-16-21]</eref>	T NOT</bcp14> be used.
	are permitted to be used in this field. Any other sub-TLV MUST NO
	T be used.
	</td>	</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	<t/>
	</section>	</section>
	<section anchor="iana-return-code" numbered="true" toc="default">	<section anchor="iana-return-code" numbered="true" toc="default">

	<name>Return Code</name>	<name>Return Codes</name>
	<t>	<t>

	The IANA is requested to assign new Return Code values from the range 192-247 of	IANA has assigned the following Return Code values from the 192-247 range in the
	the "Return Codes" registry	"Return Codes" subregistry
	of the "Multi-Protocol Label Switching (MPLS)	within the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Pin
	Label Switched Paths (LSPs) Ping Parameters", as in <xref target="return-code"/>	g Parameters" registry.
	.
	</t>	</t>
	<table anchor="return-code" align="center">	<table anchor="return-code" align="center">

	<name>New Return Code</name>	<name>New Return Codes</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Value</th>	<th align="left">Value</th>

	<th align="left">Description</th>	<th align="left">Meaning</th>
	<th align="left">Reference</th>	<th align="left">Reference</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>

	<td align="left"> (TBD3)</td>	<td align="left">192</td>
	<td align="left">Inappropriate Target FEC Stack sub-TLV present.</	<td align="left">Inappropriate Target FEC Stack sub-TLV present</t
	td>	d>
	<td align="left">This document</td>	<td align="left">RFC 9612</td>
	</tr>	</tr>
	<tr>	<tr>

	<td align="left"> (TBD4)</td>	<td align="left">193</td>
	<td align="left">Failed to establish the BFD session. The specifie d reverse path was not found.</td>	<td align="left">Failed to establish the BFD session. The specifie d reverse path was not found.</td>

	<td align="left">This document</td>	<td align="left">RFC 9612</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	</section>	</section>

	<section numbered="true" toc="default">
	<name>Implementation Status</name>
	<t>Note to RFC Editor: This section MUST be removed before publication of
	the document.</t>
	<t>
	This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of
	this Internet-Draft, and is based on a proposal described in
	<xref target="RFC7942"/>. The description of implementations in this secti
	on is
	intended to assist the IETF in its decision processes in
	progressing drafts to RFCs. Please note that the listing of any
	individual implementation here does not imply endorsement by the
	IETF. Furthermore, no effort has been spent to verify the
	information presented here that was supplied by IETF contributors.
	This is not intended as, and must not be construed to be, a
	catalog of available implementations or their features. Readers
	are advised to note that other implementations may exist.
	</t>
	<t>
	According to <xref target="RFC7942"/>, "this will allow reviewers and work
	ing
	groups to assign due consideration to documents that have the
	benefit of running code, which may serve as evidence of valuable
	experimentation and feedback that have made the implemented
	protocols more mature. It is up to the individual working groups
	to use this information as they see fit".
	</t>
	<t>- The organization responsible for the implementation: ZTE Corporation
	.</t>
	<t>- The implementation's name ROSng empowers commonly used routers, e.g.
	, ZXCTN 6000.</t>
	<t>- A brief general description: A Return Path can be specified for a BF
	D session over RSVP tunnel or LSP.
	The same can be specified for a backup RSVP tunnel/LSP.</t>
	<t> The implementation's level of maturity: production.</t>
	<t>- Coverage: RSVP LSP (no support for Static LSP)</t>
	<t> - Version compatibility: draft-ietf-mpls-bfd-directed-10.</t>
	<t>- Licensing: proprietary.</t>
	<t>- Implementation experience: simple once you support RFC 7110.</t>
	<t>- Contact information: Qian Xin qian.xin2@zte.com.cn</t>
	<t>- The date when information about this particular implementation was l
	ast updated: 12/16/2019</t>


	</section>
	<section anchor="security" numbered="true" toc="default">	<section anchor="security" numbered="true" toc="default">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>	<t>
	Security considerations discussed in <xref target="RFC5880" format="default"/>, <xref target="RFC5884" format="default"/>, <xref target="RFC7726" format="defau lt"/>,	Security considerations discussed in <xref target="RFC5880" format="default"/>, <xref target="RFC5884" format="default"/>, <xref target="RFC7726" format="defau lt"/>,
	<xref target="RFC8029" format="default"/>, and <xref target="RFC7110" format="d efault"/> apply to this document.	<xref target="RFC8029" format="default"/>, and <xref target="RFC7110" format="d efault"/> apply to this document.
	</t>	</t>
	<t>	<t>

	BFD Reverse Path TLV may be exploited as an attack vector by inflating the	The BFD Reverse Path TLV may be exploited as an attack vector by inflating
	number of included sub-TLVs.	the number of included sub-TLVs.
	The number of sub-TLVs MUST be limited to mitigate that threat. The defaul	The number of sub-TLVs <bcp14>MUST</bcp14> be limited to mitigate that thr
	t limit for the number of sub-TLVs is	eat. The default limit for the number of sub-TLVs is
	set in <xref target="bfd-reverse-path-tlv"/> to 128. An implementation MAY	set to 128 (see <xref target="bfd-reverse-path-tlv"/>). An implementation
	use a mechanism to control that limit.	<bcp14>MAY</bcp14> use a mechanism to control that limit.
	</t>	</t>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
	.2119.xml"/>	9.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
	.8174.xml"/>	4.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.588
	.5880.xml"/>	0.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.588
	.5881.xml"/>	1.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.588
	.5883.xml"/>	3.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.588
	.5884.xml"/>	4.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.802
	.8029.xml"/>	9.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.711
	.7110.xml"/>	0.xml"/>
	<!-- <?rfc include="reference.RFC.5586"?> -->	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.772
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.772	6.xml"/>
	6.xml"/>
	</references>	</references>

	<references title="Informative References">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<section numbered="false" toc="default">
	.7942.xml"/>
	</references>
	<section numbered="true" toc="default">
	<name>Acknowledgments</name>	<name>Acknowledgments</name>

	<t>	<t>The authors greatly appreciate the thorough reviews and helpful
	The authors greatly appreciate a thorough review and the most helpful c	comments from <contact fullname="Eric Gray"/> and <contact
	omments from Eric Gray	fullname="Carlos Pignataro"/>. The authors much appreciate the help of
	and Carlos Pignataro.	<contact fullname="Qian Xin"/>, who provided information about the
	The authors much appreciate the help of Qian Xin, who provided informat	implementation of this specification.
	ion about the implementation of this specification.
	</t>	</t>
	</section>	</section>


		<!-- [rfced] Abbreviations

		a) FYI - We updated the expansion of FEC as follows because "Equivalence"
		rather than "Equivalency" in this expansion is much more common in past RFCs
		and is used in the normative references for this document (e.g., RFCs 5884,
		7110, 7726, and 8029). Let us know any concerns.

		Original:
		FEC: Forwarding Equivalency Class

		Perhaps:
		FEC: Forwarding Equivalence Class

		b) Please clarify "p2mp and mp2mp" here. Also, is "i.e." correct, or should
		"e.g." be used here?

		Original:
		(This implies that Multicast
		Target FEC Stack sub-TLVs, i.e., p2mp and mp2mp, are not permitted
		in the Reverse Path field.)

		Perhaps:
		(This implies that multicast
		Target FEC Stack sub-TLVs, e.g., the Multicast P2MP LDP FEC Stack
		sub-TLV and the Multicast MP2MP LDP FEC Stack sub-TLV, are not permitted
		in the Reverse Path field.)
		-->

		<!-- [rfced] Terminology

		a) We note inconsistencies in the terms listed below. We chose the form on the
		right. Please let us know any objections.

		Reverse Path TLV vs. BFD Reverse Type TLV vs. BFD Reverse Path TLV

		return code vs. Return Code

		Target Stack sub-TLV vs. Target FEC Stack sub-TLV

		b) We also note inconsistencies with the following terms. Which form is
		preferred?

		LSP Ping vs. LSP ping
		Note: RFC 8029 uses "LSP ping" (lowercase), but RFC 5884 uses "LSP Ping"
		(capitalized).

		Echo request vs. echo request vs. Echo Request
		Note: Usage is mixed in published RFCs. For example, RFC 7110 uses "echo
		request", RFC 5884 uses "Echo request", and RFC 8029 uses "echo request"
		(all of these RFCs are normative references for this document)

		echo reply vs. Echo Reply
		Note: Same pattern as above.
		-->
		<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed.

		Note that our script did not flag any words in particular, but this should
		still be reviewed as a best practice.
		-->

	</back>	</back>
	</rfc>	</rfc>

End of changes. 61 change blocks.
	322 lines changed or deleted	650 lines changed or added
This html diff was produced by rfcdiff 1.48.