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 "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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" 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"
<title abbrev="BFD Directed Return Path for MPLS LSPs">Bidirectional Forward docName="draft-ietf-mpls-bfd-directed-31" number="9612" consensus="true" obsole
ing Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs)</t tes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth
itle> ="3" symRefs="true" sortRefs="true" version="3">
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-bfd-directed-31"/>
<front>
<title abbrev="BFD Directed Reverse Path for MPLS LSPs">Bidirectional
Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths
(LSPs)</title>
<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 39
</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 <t>The LSP ping extension described in this document was developed and
and implemented resulting from the operational experiment. The lessons lea implemented as a result of an operational experiment. The lessons
rned from learned from the operational experiment enabled the use of this
the operational experiment enabled the use between systems conforming to t extension between systems conforming to this specification. Further
his specification. implementation is encouraged to better understand the operational impact
More implementations are encouraged to understand better the operational i
mpact
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&nbsp;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>
<!-- When BFD is used to monitor an explicitly routed unidirectional path
BFD is best suited to monitor bi-directional co-routed paths. (e.g., MPLS-TE LSP), BFD control packets in the forward direction would
In most cases, given stable environments, the forward and reverse directions b
etween two nodes are
likely to be co-routed.
-->
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= To bootstrap a BFD session over an MPLS LSP, LSP ping <xref target="RFC8029"
"RFC8029" format="default"/>, MUST be used with format="default"/> <bcp14>MUST</bcp14> be used with the BFD Discriminator TLV
BFD Discriminator TLV <xref target="RFC5884" format="default"/>. <xref target="RFC5884" format="default"/>. This document defines a new TLV,
This document defines a new TLV, BFD Reverse Path TLV, that MAY contain none, o the BFD Reverse Path TLV, that can be used to carry information about the
ne or more sub-TLVs reverse path for the BFD session that is specified by the value in the BFD
that can be used to carry information about the reverse path for Discriminator TLV. The BFD Reverse Path TLV <bcp14>MAY</bcp14> contain zero
the BFD session that is specified by the value in BFD Discriminator TLV. or more sub-TLVs.
</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 <dl newline="true" spacing="normal">
TBD1 (to be assigned by IANA <dt>BFD Reverse Path TLV Type:</dt>
as requested in <xref target="iana-consider" format="default"/>). <dd>This two-octet field has a value of 16384 (see <xref
</t> target="iana-consider" format="default"/>).
<t> </dd>
Length field is two octets long and defines the length in octets of
the Reverse Path field. <dt>Length:</dt>
</t> <dd>This two-octet field defines the length in octets of the
<t> Reverse Path field.
Reverse Path field contains none, one, or more sub-TLVs. Only non-multicast Targ </dd>
et FEC Stack sub-TLVs (already defined, or to be
defined in the future) for TLV Types 1, 16, and 21 of MPLS LSP Ping <dt>Reverse Path:</dt>
Parameters registry are permitted to be used in this field. Any other <dd>This field contains zero or more sub-TLVs. Only non-multicast Target FEC
sub-TLV MUST NOT be used. (This implies that Multicast Target FEC Stack sub-T Stack sub-TLVs (already defined or to be defined in the future) for TLV
LVs, i.e., p2mp Types 1, 16, and 21 in the "Multiprotocol Label Switching (MPLS) Label
and mp2mp, are not permitted in the Reverse Path field.) If the egress Label- Switched Paths (LSPs) Ping Parameters" registry are permitted to be used in
Switching Router (LSR) finds multicast this field. Other sub-TLVs <bcp14>MUST NOT</bcp14> be used. (This implies
Target Stack sub-TLV, it MUST send echo reply with the received Reve that multicast Target FEC Stack sub-TLVs, e.g., the Multicast P2MP LDP FEC
rse Path TLV, Stack sub-TLV and the Multicast MP2MP LDP FEC Stack sub-TLV, are not
BFD Discriminator TLV and set the Return Code to "Inappropriate Targ permitted in the Reverse Path field.)
et FEC Stack </dd>
sub-TLV present" (<xref target="return-codes" format="default"/>). </dl>
The BFD Reverse Path TLV includes none, one or more sub-TLVs.
However, the number of sub-TLVs in the Reverse Path field MUST be lim <t>If the egress LSR finds a multicast Target FEC Stack sub-TLV, it
ited. <bcp14>MUST</bcp14> send an echo reply with the received BFD Reverse Path
The default limit is 128 sub-TLV entries, but an implementation MAY b TLV and BFD Discriminator TLV and set the Return Code to 192 ("Inappropriate
e able to control that limit. Target FEC Stack sub-TLV present") (see <xref target="return-codes"
An empty BFD Reverse Path TLV, i.e., no sub-TLVs present, is used format="default"/>). The BFD Reverse Path TLV includes zero or more
as withdrawal of any previously set reverse path for the BFD session sub-TLVs. However, the number of sub-TLVs in the Reverse Path field
identified in the BFD Discriminator TLV. <bcp14>MUST</bcp14> be limited. The default limit is 128 sub-TLV entries,
If no sub-TLVs are found in the BFD Reverse Path TLV, the egress BFD but an implementation <bcp14>MAY</bcp14> be able to control that limit. An
peer MUST revert to empty BFD Reverse Path TLV (i.e., a BFD Reverse Path TLV with no sub-TLVs)
using the local policy-based decision as described in Section 7 of <x is used to withdraw any previously set reverse path for the BFD session
ref target="RFC5884" format="default"/>, i.e., routed over IP network. identified in the BFD Discriminator TLV. If no sub-TLVs are found in the
</t> BFD Reverse Path TLV, the egress BFD peer <bcp14>MUST</bcp14> revert to
<t> using the decision based on local policy, i.e., routing over an IP
If the egress peer LSR cannot find the path specified in the Revers network, as described in <xref target="RFC5884"
e Path TLV, it MUST send Echo format="default" sectionFormat="of" section="7"/>.</t>
Reply with the received BFD Discriminator TLV, Reverse Path TLV, <t>
and set the Return Code to "Failed to establish the If the egress peer LSR cannot find the path specified in the BFD
BFD session. The specified reverse path was not found" (<xref targe Reverse Path TLV, it <bcp14>MUST</bcp14> send an echo reply with
t="return-codes" format="default"/>). the received BFD Discriminator TLV and BFD Reverse Path TLV and set
If an implementation provides additional configuration options, the the Return Code to 193 ("Failed to establish the BFD session. The
se can control actions at the egress BFD peer, including specified reverse path was not found.") (see <xref
when the path specified in the Reverse Path TLV cannot be found. target="return-codes" format="default"/>). If an implementation
For example, optionally, if the egress peer LSR cannot find the path specified provides additional configuration options, these can control
in the Reverse Path actions at the egress BFD peer, including when the path specified
TLV, it MAY establish the BFD session over an IP network, as defined in <xref in the BFD Reverse Path TLV cannot be found. For example,
target="RFC5884" format="default"/>. if the egress peer LSR cannot find the path specified
Note that the return code required by the MUST clause does not preclude the se in the BFD Reverse Path TLV, it <bcp14>MAY</bcp14> establish the
ssion from being established over a different path as discussed in the MAY claus BFD session over an IP network, as defined in <xref
e. 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 <t>
session process described in Section 6 of <xref target="RFC5884"/>. A system The BFD Reverse Path TLV <bcp14>MAY</bcp14> be used in the process
that of bootstrapping the BFD session as described in <xref
supports this specification MUST support using the BFD Reverse Path target="RFC5884" section="6" sectionFormat="of" />. A system that
TLV after the BFD session has been established. If a system that supports this specification <bcp14>MUST</bcp14> support using the
supports this specification receives an LSP Ping with the BFD BFD Reverse Path TLV after the BFD session has been established. If
Discriminator TLV and no BFD Reverse Path TLV even though the reverse a system that supports this specification receives an LSP ping with
path for the specified BFD session has been established according to the BFD Discriminator TLV and no BFD Reverse Path TLV even though
the previously received BFD Reverse Path TLV, the egress BFD peer MUST the reverse path for the specified BFD session was established
transition to transmitting periodic BFD Control messages as defined according to the previously received BFD Reverse Path TLV, the
in Section 7 of <xref target="RFC5884"/>. If a BFD system that received an LS egress BFD peer <bcp14>MUST</bcp14> transition to transmitting
P Ping with periodic BFD Control messages as described in <xref
the BFD Reverse Path TLV does not support this specification, it will "result target="RFC5884" section="7" sectionFormat="of" />. If a BFD system
in the Return Code of 2 ("One or more of the TLVs was not that received an LSP ping with the BFD Reverse Path TLV does not
understood") being sent in the echo response" (Section 3 of <xref target="RFC support this specification, it will result in an echo response with
8029"/>). the Return Code set to 2 ("One or more of the TLVs was not
understood"), as described in <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
could be due to a change in the FEC used in the BFD Reverse Path TLV. TLV could be due to a change in the FEC used in the BFD Reverse Path
The ingress BFD peer, upon detection of the network failure, MUST trans TLV. Upon detection of the network failure, the ingress BFD peer
mit the LSP Ping Echo request with Return Path TLV <bcp14>MUST</bcp14> transmit the LSP ping echo request with the Reply
to verify whether the FEC is still valid. If the failure was caused by the c Path TLV <xref target="RFC7110"/> to verify whether the FEC is still
hange in the FEC used for the valid. If the failure was caused by a change 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
e reverse path of the BFD session <bcp14>MUST</bcp14> 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>
<t> <t>
In the network presented in <xref target="use-case-fig" format="default"/>, ing In the network presented in <xref target="use-case-fig" format="default"/>,
ress LSR peer A monitors two ingress LSR peer A monitors two tunnels to egress LSR peer H: A-B-C-D-G-H and
tunnels to the egress LSR peer H: A-B-C-D-G-H and A-B-E-F-G-H. A-B-E-F-G-H. To bootstrap a BFD session to monitor the first tunnel, ingress
To bootstrap a BFD session to monitor the first tunnel, the ingress LSR peer A LSR peer A includes a BFD Discriminator TLV with a Discriminator value (e.g.,
includes foobar-1) <xref target="RFC7726" format="default"/>. Ingress LSR peer A include
a BFD Discriminator TLV with Discriminator value (e.g., foobar-1). Peer A inclu s a BFD
des Reverse Path TLV referencing the H-G-D-C-B-A tunnel to control the path from
a BFD Reverse Path TLV referencing the H-G-D-C-B-A tunnel to control the path f the egress LSR. To bootstrap a BFD session to monitor the second tunnel,
rom the egress LSR. ingress LSR peer A includes a BFD Discriminator TLV with a different
To bootstrap a BFD session to monitor the second tunnel, ingress LSR peer A, in Discriminator value (e.g., foobar-2) and a BFD Reverse Path TLV that
cludes references the H-G-F-E-B-A tunnel.
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.
</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>
<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 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"/> of sub-TLVs composes the Reply 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 the Reply Path TLV, as per <xref target="RFC7110" format="default"/>, with tha
at sub-TLV. t sub-TLV.
By using the LSP Ping with Return Path TLV, an operator monitors whether By using the LSP ping with 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 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 Reply 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 <t>
with a new FEC in the BFD Reverse Path TLV. But in some scenarios, proactive Suppose an operator planned a network maintenance activity that
measures cannot be taken. possibly affects the FEC used in the BFD Reverse Path TLV. In that case,
Because the frequency of LSP Ping messages will be lower than the defect det the operator can avoid unnecessary disruption by using the LSP ping
ection time provided by the BFD session. 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 is lower than the defect detectio
n 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>
<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">&nbsp;(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&nbsp;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) in the "Sub-TLVs for TLV Types 1,
at <eref target="https://www.iana.org/assignments/mpls-lsp-ping-pa 16, and 21" registry at <eref brackets="angle"
rameters/mpls-lsp-ping-parameters.xml#sub-tlv-1-16-21"> target="https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-
[https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-ls parameters.xml#sub-tlv-1-16-21"/>
p-ping-parameters.xml#sub-tlv-1-16-21]</eref> are permitted to be used in this field. Other sub-TLVs
are permitted to be used in this field. Any other sub-TLV MUST NO <bcp14>MUST NOT</bcp14> be used.
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">&nbsp;(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&nbsp;document</td> <td align="left">RFC 9612</td>
</tr> </tr>
<tr> <tr>
<td align="left">&nbsp;(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&nbsp;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>
</back> </back>
</rfc> </rfc>
 End of changes. 53 change blocks. 
353 lines changed or deleted 288 lines changed or added

This html diff was produced by rfcdiff 1.48.