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

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>
<?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" number="9612" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>

<!-- xml2rfc v2v3 conversion 3.6.0 [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)
-->
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<front>

    <title abbrev="BFD Directed Return Path for MPLS LSPs">Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-bfd-directed-31"/> name="RFC" value="9612"/>
    <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Tantsura" fullname="Jeff  Tantsura">
      <organization>NVIDIA</organization>
      <address>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="I." surname="Varlashkin" fullname="Ilya Varlashkin">
      <organization>Google</organization>
      <address>
        <email>imv@google.com</email>
      </address>
    </author>
    <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>mach.chen@huawei.com</email>
      </address>
    </author>

    <date year="2024"/>

    <area>Routing</area>
    <workgroup>MPLS Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2024" month="July"/>

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

    <keyword>LSP Ping</keyword>
    <keyword>BFD </keyword>
    <keyword>BFD</keyword>

    <abstract>
      <t>
Bidirectional Forwarding Detection (BFD) is expected to be able to
monitor a wide variety of encapsulations of paths between systems.
When a BFD session monitors an explicitly routed unidirectional path 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.
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 transmit BFD control packets
over the specified LSP.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
 <xref target="RFC5880"/>, <xref target="RFC5881"/>, and <xref target="RFC5883"/>
 established the Bidirectional Forwarding Detection (BFD)
 protocol for IP networks. <xref target="RFC5884" format="default"/> and <xref target="RFC7726" format="default"/>
 set rules for using BFD Asynchronous mode over MPLS Label Switched Paths (LSPs),
 while not defining means to control the path that an egress BFD system uses to send BFD
 control packets towards the ingress BFD system.
      </t>
      <t>
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
toward the ingress may be disjoint from the monitored LSP in the forward direction.
The fact that BFD control packets are not
   guaranteed to follow the same links and nodes in both forward and
   reverse directions may be one of the factors contributing to producing false positive defect
   notifications, i.e.,
   notifications (i.e., false alarms, alarms) at the ingress BFD peer.  Ensuring that both directions
   of the BFD session use co-routed paths may, in some environments, improve the
   determinism of the failure detection and localization.

      </t>
      <t>
 This document defines the BFD Reverse Path TLV as an extension to LSP Ping
 <xref target="RFC8029" format="default"/> and proposes that it is to be used to
 instruct the egress BFD system to use an explicit path for its BFD control
 packets associated with a particular BFD session.
 The  IANA has registered this
 TLV will be allocated from in the
 TLV and sub-TLV "TLVs" registry defined in by <xref target="RFC8029" format="default"/>.
 format="default"/> (see <xref target="iana-TLV" format="default"/>).  As a special case, forward and reverse directions of the
 BFD session can form a bi-directional bidirectional co-routed associated channel.
      </t>
      <t>The
<!-- [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.
      More implementations are

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 learned from
      the operational experiment enabled the use between systems conforming to this specification.
      Further implementation is encouraged to understand better understand the operational impact
      of the mechanism described in the document.</t>
      <section numbered="true" toc="default">
        <name>Conventions used Used in this This document</name>

         <section title="Terminology">

            <t>BFD:          Bidirectional Forwarding Detection</t>
            <t>FEC:

        <section>
	  <name>Terminology</name>

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

        <section numbered="true" toc="default">
          <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/>
    <xref target="RFC8174" format="default"/> target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
        </t>

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

<!-- [rfced] FYI - The following comment was left in the xml file. We removed
it.

  BFD is best suited to monitor bi-directional co-routed paths.  In
  most cases, given stable environments, the forward and reverse directions
  between two nodes are likely to be co-routed.
-->
   When BFD is used to monitor an explicitly routed unidirectional path,
   e.g., path
   (e.g., MPLS-TE LSP, LSP), BFD control packets in the forward direction would
   be in-band using the mechanism defined in <xref target="RFC5884"/>. However, the
   reverse direction of the BFD session would follow the shortest path
   route, which could be completely or partially disjoint from the
   forward path. This creates the potential for the failure of a
   disjoint resource on the reverse path to trigger a BFD failure
   detection, even though the forward path is unaffected.
</t>
      <t>
   If the reverse path is congruent with the forward path, the potential
   for such false positives is greatly reduced. For this purpose, this
   specification provides a means for the egress BFD peer to be
   instructed to use a specific path for BFD control packets.
</t>
    </section>
    <section anchor="direct-reverse-bfd" numbered="true" toc="default">
      <name>Control of the Reverse BFD Reverse Path</name>
      <t>
 To bootstrap a BFD session over an MPLS LSP, LSP ping, defined in ping <xref target="RFC8029" format="default"/>, MUST format="default"/> <bcp14>MUST</bcp14> be used with the
 BFD Discriminator TLV <xref target="RFC5884" format="default"/>.
 This document defines a new TLV, the BFD Reverse Path TLV, that MAY <bcp14>MAY</bcp14> contain none, one zero or more sub-TLVs
 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.
      </t>
      <section anchor="bfd-reverse-path-tlv" numbered="true" toc="default">
        <name>BFD Reverse Path TLV</name>

        <t>
The BFD Reverse Path TLV is an optional TLV within the LSP ping <xref target="RFC8029" format="default"/>.
However, if used, the BFD Discriminator TLV MUST <bcp14>MUST</bcp14> be included in an Echo Request message
as well. If the BFD Discriminator TLV is not present when the BFD Reverse
Path TLV is included; included, then it MUST <bcp14>MUST</bcp14> be treated as a malformed Echo Request, as described in <xref target="RFC8029" format="default"/>.
</t>
        <t>
The BFD Reverse Path TLV carries information about the path onto which the egress BFD peer of the BFD session referenced by the BFD
Discriminator TLV MUST <bcp14>MUST</bcp14> transmit BFD control packets. The format of the BFD Reverse Path TLV is as presented in <xref target="mpls-bfd-tlv" format="default"/>.
</t>
        <figure anchor="mpls-bfd-tlv">
          <name>BFD Reverse Path TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   BFD Reverse Path TLV Type   |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Reverse Path                         |
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
            BFD

<!-- [rfced] We updated the text after Figure 1 to be a definition list. Note
that we split the paragraph under "Reverse Path" - we included the first
four sentences as the definition and put the remaining sentences in a new
paragraph outside of the definition list. Please let us know if this is
incorrect.
-->

<dl newline="true" spacing="normal">
  <dt>BFD Reverse Path TLV Type is two octets in length and Type:</dt>
  <dd>This two-octet field has a value of TBD1 (to be assigned by IANA
            as requested in 16384 (see <xref
  target="iana-consider" format="default"/>).
        </t>
        <t>
            Length
  </dd>

  <dt>Length:</dt>
  <dd>This two-octet field is two octets long and defines the length in octets of the
  Reverse Path field.
        </t>
        <t>
  </dd>

<!-- [rfced] FYI - We updated "none, one or more sub-TLVs" to "zero or more
sub-TLVs". Let us know any concerns.

Original:
   This document defines a new TLV, BFD Reverse Path TLV, that MAY contain
   none, one or more sub-TLVs 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.
   ...
   Reverse Path field contains none, one, or more sub-TLVs.
   ...
   The BFD Reverse Path TLV includes none, one or more sub-TLVs.

Updated:
   This document defines a new TLV, the BFD Reverse Path TLV, that MAY contain
   zero or more sub-TLVs that can be used to carry information
   about the the reverse path for the BFD session that is specified by the
   value in the BFD Discriminator TLV.
   ...
   This field contains zero or more sub-TLVs.
   ...
   The BFD Reverse Path TLV includes zero or more sub-TLVs.
-->

<!-- [rfced] Does the phrase "that can be used to carry information..." modify
"new TLV" or "none, one or more sub-TLVs"? If it modifies "new TLV", may
we update as follows for clarity?

Original:
   This document defines a new TLV, BFD Reverse Path TLV, that MAY contain
   none, one or more sub-TLVs 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.

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, defined or to be defined in the future)
  for TLV Types 1, 16, and 21 of MPLS LSP in the "Multiprotocol Label Switching (MPLS)
  Label Switched Paths (LSPs) Ping
   Parameters Parameters" registry are permitted to be
  used in this field. Any other
   sub-TLV MUST NOT Other sub-TLVs <bcp14>MUST NOT</bcp14> be used. (This
  implies that Multicast 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" (<xref (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 none, one zero or more
  sub-TLVs.  However, the number of sub-TLVs in the Reverse Path field MUST
  <bcp14>MUST</bcp14> be limited.  The default limit is 128 sub-TLV entries,
  but an implementation MAY <bcp14>MAY</bcp14> be able to control that limit.  An
  empty BFD Reverse Path TLV, i.e., TLV (i.e., a BFD Reverse Path TLV with no sub-TLVs present, sub-TLVs)
  is used
           as withdrawal of 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 MUST <bcp14>MUST</bcp14> revert to
  using the local policy-based decision as described in Section 7 of <xref target="RFC5884" format="default"/>,
  format="default" sectionFormat="of" section="7"/>, i.e., routed over an IP network.
        </t>
  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 MUST <bcp14>MUST</bcp14> send an Echo Reply with
             the received BFD Discriminator TLV, BFD Reverse Path TLV, TLV and set
             the Return Code to "Failed 193 ("Failed to establish the BFD session. The
             specified reverse path was not found" (<xref 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 MAY <bcp14>MAY</bcp14> establish the
             BFD session over an IP network, as defined in <xref
             target="RFC5884" format="default"/>.  Note that the return code Return Code
             required by the MUST "<bcp14>MUST</bcp14>" clause in this paragraph does not preclude
             the session from being established over a different path as
             discussed in the MAY "<bcp14>MAY</bcp14>" clause.
        </t>

<!-- [rfced] This sentence may be difficult for readers to follow because of
the nested quotation marks. May we rephrase as follows to avoid a direct
quote and the nested quotation marks?

Original:
   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"
   (Section 3 of [RFC8029]).

Perhaps:
   If a BFD system that received an
   LSP Ping with the BFD Reverse Path TLV does not support this
   specification, it will result in an echo response with the Return Code
   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 MAY <bcp14>MAY</bcp14> be used in the bootstrapping process
           of a bootstrapping the BFD session process as described in Section 6 of <xref target="RFC5884"/>.
           target="RFC5884" section="6" sectionFormat="of" />.  A system that
           supports this specification MUST <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 has been was established
           according to the previously received BFD Reverse Path TLV, the
           egress BFD peer MUST <bcp14>MUST</bcp14> transition to transmitting
           periodic BFD Control messages as defined described in Section 7 of <xref target="RFC5884"/>. 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" (Section 3 of <xref target="RFC8029"/>). (<xref target="RFC8029" section="3" sectionFormat="of"
           />).
   </t>
      </section>
      <section anchor="return-codes" numbered="true" toc="default">
        <name>Return Codes</name>
        <t>
This document defines the following Return Codes for the MPLS LSP Echo Reply:
</t>
        <ul spacing="normal">
          <li>
"Inappropriate
        <dl spacing="normal" newline="true">
          <dt>"Inappropriate Target FEC Stack sub-TLV present" (TBD3). When (192):</dt>
	  <dd>When a multicast Target FEC Stack sub-TLV is found in
the received Echo Request, the egress BFD peer sends an Echo Reply with the return code Return Code set to
"Inappropriate 192
("Inappropriate Target FEC Stack sub-TLV present" present") to the ingress BFD peer peer, as described in <xref target="bfd-reverse-path-tlv" format="default"/>.
</li>
          <li>
"Failed
</dd>
          <dt>"Failed to establish the BFD session. The specified reverse path was not found" (TBD4).
When found." (193):</dt>
<dd>When a specified reverse path is unavailable, the egress BFD peer sends an
Echo Reply with the return
code Return Code set to "Failed 193 ("Failed to establish the BFD
session. The specified reverse path was not found" found.") to the ingress BFD peer peer, as
described in <xref target="bfd-reverse-path-tlv" format="default"/>.
</li>
        </ul>
</dd>
        </dl>
      </section>
      <section anchor="failure-character-sec" numbered="true" toc="default">
        <name>Failure Characterization</name>
        <t>

         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.
         The ingress BFD peer, upon
         Upon detection of the network failure, MUST the ingress BFD peer <bcp14>MUST</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 a change in the FEC used for the
    reverse direction of the BFD session, the ingress BFD peer MUST re-direct <bcp14>MUST</bcp14> redirect the reverse path of the BFD session
 using another FEC in the BFD Reverse Path TLV, TLV and notify an operator.
        </t>
        </section>
    </section>
    <section anchor="use-case" numbered="true" toc="default">
      <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>
 In the network presented in <xref target="use-case-fig" format="default"/>, ingress 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.
 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). 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.
 To bootstrap a BFD session to monitor the second tunnel, ingress LSR peer A, A includes
 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 references the H-G-F-E-B-A tunnel.
      </t>
      <figure anchor="use-case-fig">
        <name>Use Case for BFD Reverse Path TLV</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        C---------D
        |         |
A-------B         G-----H
        |         |
        E---------F
]]></artwork>
      </figure>
      <t>
If an operator needs egress LSR peer H to monitor a path to the ingress LSR peer A, e.g.,
the H-G-D-C-B-A tunnel, then by looking up the list of known Reverse Paths, reverse paths,
it MAY <bcp14>MAY</bcp14> find and use the existing BFD session.
</t>
    </section>
    <section anchor="operational-sec" numbered="true" toc="default">
      <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>
  When an explicit path is set either as either Static or RSVP-TE LSP,
  corresponding sub-TLVs, defined sub-TLVs (defined in <xref target="RFC7110" format="default"/>, MAY format="default"/>) <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"/>
  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.
  If any of the sub-TLVs defined in <xref target="RFC7110" format="default"/>
  sub-TLVs
   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 <xref target="RFC5884" section="4" sectionFormat="of" format="default"/>, MUST <bcp14>MUST</bcp14> use
  the Return Path TLV, as per <xref target="RFC7110" format="default"/>, with that sub-TLV.
  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 session. session at the egress BFD node.
  Selection and control of the rate of the LSP Ping with the Return Path TLV
      follows the recommendation of in <xref target="RFC5884" format="default"/>:
"The format="default"/>:</t>
<blockquote>
The rate of generation of these LSP Ping Echo request messages SHOULD
<bcp14>SHOULD</bcp14> be significantly less than the rate of generation of the
BFD Control packets.  An implementation MAY <bcp14>MAY</bcp14> provide
configuration options to control the rate of generation of the periodic LSP
Ping Echo request messages."
      </t> messages.
</blockquote>

<!-- [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 the 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.
    Because the frequency of LSP Ping messages will be lower than the defect detection 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.
   An operator will be notified as described in <xref target="failure-character-sec"/>.
      </t>
    </section>
    <section anchor="iana-consider" numbered="true" toc="default">
      <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-parameters/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) in
  the "Sub-TLVs for TLV Types 1, 16, and 21" registry 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.

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 not found.

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

      <section anchor="iana-TLV" numbered="true" toc="default">
        <name>BFD Reverse Path TLV</name>
        <t>
     The
     IANA is requested to assign a new has assigned the following value for the BFD Reverse Path TLV from the 16384-31739 range in the "TLVs" registry of subregistry within the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry.
        </t>
        <table anchor="bfdtlv-table" align="center">
          <name>New BFD Reverse Type Path TLV</name>
          <thead>
            <tr>
              <th align="left">Type</th>
              <th align="left">TLV Name</th>
              <th align="left">Reference</th>
              <th align="left">Sub-TLV Registry</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">&nbsp;(TBD1)</td> align="left">16384</td>
              <td align="left">BFD Reverse Path TLV</td> Path</td>
              <td align="left">This&nbsp;document</td> align="left">RFC 9612</td>
              <td align="left">Only non-multicast sub-TLV sub-TLVs (already defined or
              to be defined in the future) at <eref target="https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-1-16-21">
              [https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-1-16-21]</eref> brackets="angle"
              target="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. Any other sub-TLV MUST NOT Other sub-TLVs <bcp14>MUST NOT</bcp14> be used.
               </td>
            </tr>
          </tbody>
        </table>
        <t/>
      </section>
      <section anchor="iana-return-code" numbered="true" toc="default">
        <name>Return Code</name> Codes</name>
        <t>
The
IANA is requested to assign new has assigned the following Return Code values from the range 192-247 of range in the "Return Codes" registry
of subregistry
within the "Multi-Protocol "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", as in <xref target="return-code"/>. Parameters" registry.
</t>
        <table anchor="return-code" align="center">
          <name>New Return Code</name> Codes</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th> align="left">Meaning</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">&nbsp;(TBD3)</td> align="left">192</td>
              <td align="left">Inappropriate Target FEC Stack sub-TLV present.</td> present</td>
              <td align="left">This&nbsp;document</td> align="left">RFC 9612</td>
            </tr>
            <tr>
              <td align="left">&nbsp;(TBD4)</td> align="left">193</td>
              <td align="left">Failed to establish the BFD session. The specified reverse path was not found.</td>
              <td align="left">This&nbsp;document</td> align="left">RFC 9612</td>
            </tr>
          </tbody>
        </table>
      </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 section 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 working
     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 BFD 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 last updated: 12/16/2019</t>

    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
 Security considerations discussed in <xref target="RFC5880" format="default"/>, <xref target="RFC5884" format="default"/>, <xref target="RFC7726" format="default"/>,
 <xref target="RFC8029" format="default"/>, and <xref target="RFC7110" format="default"/> apply to this document.
      </t>
      <t>
      The BFD Reverse Path TLV may be exploited as an attack vector by inflating the number of included sub-TLVs.
      The number of sub-TLVs MUST <bcp14>MUST</bcp14> be limited to mitigate that threat. The default limit for the number of sub-TLVs is
      set in <xref target="bfd-reverse-path-tlv"/> to 128. 128 (see <xref target="bfd-reverse-path-tlv"/>). An implementation MAY <bcp14>MAY</bcp14> use a mechanism to control that limit.
      </t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5884.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5884.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7110.xml"/>
      <!-- <?rfc include="reference.RFC.5586"?> --> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7110.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7726.xml"/>
    </references>
      <references title="Informative References">
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7726.xml"/>
    </references>

    <section numbered="true" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
         The
      <t>The authors greatly appreciate a the thorough review reviews and the most helpful
      comments from Eric Gray <contact fullname="Eric Gray"/> and Carlos Pignataro. <contact
      fullname="Carlos Pignataro"/>.  The authors much appreciate the help of Qian Xin,
      <contact fullname="Qian Xin"/>, who provided information about the
      implementation of this specification.
      </t>
    </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>
</rfc>