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

  <front>

<title abbrev="BFD Directed Return Reverse Path for MPLS LSPs">Bidirectional
Forwarding Detection (BFD) Directed Return Reverse 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 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 LSP ping extension, extension described in this document, document was developed and
      implemented resulting from the as a result of an operational experiment. The lessons
      learned from the operational experiment enabled the use of this
      extension between systems conforming to this specification.
      More implementations are  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>
  <!--
  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 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 the BFD
 Discriminator TLV. The BFD Reverse Path TLV <bcp14>MAY</bcp14> contain zero
 or more sub-TLVs.
      </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 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, 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

<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>
Reverse Path
  </dd>

  <dt>Reverse Path:</dt>
  <dd>This field contains none, one, 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 e.g., the Multicast P2MP LDP FEC
  Stack sub-TLV and mp2mp, the Multicast MP2MP LDP FEC Stack sub-TLV, are not
  permitted in the Reverse Path field.) If
  </dd>
</dl>

  <t>If the egress Label-Switching Router (LSR) LSR finds a multicast Target FEC Stack sub-TLV, it MUST
  <bcp14>MUST</bcp14> send an echo reply with the received BFD Reverse Path TLV,
  TLV and BFD Discriminator TLV and set the Return Code to "Inappropriate 192 ("Inappropriate
  Target FEC Stack sub-TLV present" (<xref 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 based on local policy, i.e., routing over an IP
  network, as described in Section 7 of <xref target="RFC5884" format="default"/>, i.e., routed over IP network.
        </t>
  format="default" sectionFormat="of" section="7"/>.</t>
  <t>
             If the egress peer LSR cannot find the path specified in the BFD
             Reverse Path TLV, it MUST <bcp14>MUST</bcp14> send Echo
             Reply an echo reply with
             the received BFD Discriminator TLV, TLV and 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>

	<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 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 ping with the BFD Reverse Path TLV does not
           support this specification, it will "result result in an echo response with
           the Return Code of set to 2 ("One or more of the TLVs was not
   understood") being sent
           understood"), as described in the echo response" (Section 3 of <xref target="RFC8029"/>). 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: 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, echo request, the egress BFD peer sends an Echo Reply 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
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 ping echo request with Return the Reply
         Path TLV <xref target="RFC7110"/> 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>

      <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
 foobar-1) <xref target="RFC7726" format="default"/>. 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.  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>
      <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 Reply 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 Reply Path TLV, as per <xref target="RFC7110" format="default"/>, with that sub-TLV.
  By using the LSP Ping ping with Return the Reply 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 ping with Return the Reply 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>

<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 ping
   with a new FEC in the BFD Reverse Path TLV. But in some scenarios, proactive measures cannot be taken.
    Because taken
    because the frequency of LSP Ping ping messages will be is 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>

      <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) in the "Sub-TLVs for TLV Types 1,
              16, and 21" registry 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
         and Carlos Pignataro. <contact fullname="Eric Gray"/> and <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>
  </back>
</rfc>