<?xml version="1.0"encoding="utf-8"?>encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" ipr="trust200902" docName="draft-ietf-mpls-bfd-directed-31" 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> <seriesInfoname="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> <dateyear="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 unidirectionalpathpath, 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 peertransmitstransmit 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 toproducingfalse positive defectnotifications, i.e.,notifications (i.e., falsealarms,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 itis tobe used to instruct the egress BFD system to use an explicit path for its BFD control packets associated with a particular BFD session.TheIANA has registered this TLVwill be allocated fromin theTLV and sub-TLV"TLVs" registry definedinby <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 abi-directionalbidirectional 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 arePerhaps: 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 tounderstandbetter understand the operational impact of the mechanism described in the document.</t> <section numbered="true" toc="default"> <name>ConventionsusedUsed inthisThis 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 ForwardingEquivalency Class</t> <t>LSP: LabelDetection</dd> <dt>FEC:</dt><dd>Forwarding Equivalence Class</dd> <dt>LSP:</dt><dd>Label SwitchedPath</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 inBCP 14BCP 14 <xreftarget="RFC2119" format="default"/>target="RFC2119"/> <xreftarget="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 unidirectionalpath, e.g.,path (e.g., MPLS-TELSP,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 theReverseBFD Reverse Path</name> <t> To bootstrap a BFD session over an MPLS LSP, LSPping, defined inping <xref target="RFC8029"format="default"/>, MUSTformat="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, thatMAY<bcp14>MAY</bcp14> containnone, onezero 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 TLVMUST<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 isincluded;included, then itMUST<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 TLVMUST<bcp14>MUST</bcp14> transmit BFD control packets. The format of the BFD Reverse Path TLV isaspresented 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 TLVType is two octets in length andType:</dt> <dd>This two-octet field has a value ofTBD1 (to be assigned by IANA as requested in16384 (see <xref target="iana-consider" format="default"/>).</t> <t> Length</dd> <dt>Length:</dt> <dd>This two-octet fieldis two octets long anddefines 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 (alreadydefined,defined or to be defined in the future) for TLV Types 1, 16, and 21of MPLS LSPin the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) PingParametersParameters" registry are permitted to be used in this field.Any other sub-TLV MUST NOTOther sub-TLVs <bcp14>MUST NOT</bcp14> be used. (This implies thatMulticastmulticast 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 includesnone, onezero or more sub-TLVs. However, the number of sub-TLVs in the Reverse Path fieldMUST<bcp14>MUST</bcp14> be limited. The default limit is 128 sub-TLV entries, but an implementationMAY<bcp14>MAY</bcp14> be able to control that limit. An empty BFD Reverse PathTLV, i.e.,TLV (i.e., a BFD Reverse Path TLV with nosub-TLVs present,sub-TLVs) is usedas withdrawal ofto 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 peerMUST<bcp14>MUST</bcp14> revert to using the local policy-based decision as described inSection 7 of<xref target="RFC5884"format="default"/>,format="default" sectionFormat="of" section="7"/>, i.e., routed over an IPnetwork. </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, itMUST<bcp14>MUST</bcp14> send an Echo Reply with the received BFD Discriminator TLV, BFD Reverse PathTLV,TLV and set the Return Code to"Failed193 ("Failed to establish the BFD session. The specified reverse path was notfound" (<xreffound.") (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, itMAY<bcp14>MAY</bcp14> establish the BFD session over an IP network, as defined in <xref target="RFC5884" format="default"/>. Note that thereturn codeReturn Code required by theMUST"<bcp14>MUST</bcp14>" clause in this paragraph does not preclude the session from being established over a different path as discussed in theMAY"<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 TLVMAY<bcp14>MAY</bcp14> be used in thebootstrappingprocess ofabootstrapping the BFD sessionprocessas described inSection 6 of<xreftarget="RFC5884"/>.target="RFC5884" section="6" sectionFormat="of" />. A system that supports this specificationMUST<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 sessionhas beenwas established according to the previously received BFD Reverse Path TLV, the egress BFD peerMUST<bcp14>MUST</bcp14> transition to transmitting periodic BFD Control messages asdefineddescribed inSection 7 of<xreftarget="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 thereturn codeReturn Code set to"Inappropriate192 ("Inappropriate Target FEC Stack sub-TLVpresent"present") to the ingress BFDpeerpeer, 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 notfound" (TBD4). Whenfound." (193):</dt> <dd>When a specified reverse path is unavailable, the egress BFD peer sends an Echo Reply with thereturn codeReturn Code set to"Failed193 ("Failed to establish the BFD session. The specified reverse path was notfound"found.") to the ingress BFDpeerpeer, 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, uponUpon detection of the network failure,MUSTthe 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 bythea change in the FEC used for the reverse direction of the BFD session, the ingress BFD peerMUST re-direct<bcp14>MUST</bcp14> redirect the reverse path of the BFD session using another FEC in the BFD Reverse PathTLV,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 totheegress 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,theingress 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 peerA,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 totheingress LSR peer A, e.g., the H-G-D-C-B-A tunnel, then by looking up the list of knownReverse Paths,reverse paths, itMAY<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 seteitheras either Static or RSVP-TE LSP, correspondingsub-TLVs, definedsub-TLVs (defined in <xref target="RFC7110"format="default"/>, MAYformat="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-TLVsare used in the BFD Reverse Path TLV, then the periodic verification of the control plane against the data plane, as recommended inSection 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 whetherat the egress BFD nodethe reverse LSP is mapped to the same FEC as the BFDsession.session at the egress BFD node. Selection and control of the rate of the LSP Ping with the Return Path TLV follows the recommendationofin <xref target="RFC5884"format="default"/>: "Theformat="default"/>:</t> <blockquote> The rate of generation of these LSP Ping Echo request messagesSHOULD<bcp14>SHOULD</bcp14> be significantly less than the rate of generation of the BFD Control packets. An implementationMAY<bcp14>MAY</bcp14> provide configuration options to control the rate of generation of the periodic LSP Ping Echo requestmessages." </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 avoidtheunnecessary 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>TheIANAis requested to assign a newhas assigned the following value for the BFD Reverse Path TLV from the 16384-31739 range in the "TLVs"registry ofsubregistry within the "Multiprotocol Label SwitchingArchitecture(MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. </t> <table anchor="bfdtlv-table" align="center"> <name>New BFD ReverseTypePath 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> <tdalign="left"> (TBD1)</td>align="left">16384</td> <td align="left">BFD ReversePath TLV</td>Path</td> <tdalign="left">This document</td>align="left">RFC 9612</td> <td align="left">Only non-multicastsub-TLVsub-TLVs (already defined or to be defined in the future) at <ereftarget="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 NOTOther sub-TLVs <bcp14>MUST NOT</bcp14> be used. </td> </tr> </tbody> </table><t/></section> <section anchor="iana-return-code" numbered="true" toc="default"> <name>ReturnCode</name>Codes</name> <t>TheIANAis requested to assign newhas assigned the following Return Code values from therange192-247ofrange in the "Return Codes"registry ofsubregistry within the"Multi-Protocol"Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) PingParameters", as in <xref target="return-code"/>.Parameters" registry. </t> <table anchor="return-code" align="center"> <name>New ReturnCode</name>Codes</name> <thead> <tr> <th align="left">Value</th> <thalign="left">Description</th>align="left">Meaning</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <tdalign="left"> (TBD3)</td>align="left">192</td> <td align="left">Inappropriate Target FEC Stack sub-TLVpresent.</td>present</td> <tdalign="left">This document</td>align="left">RFC 9612</td> </tr> <tr> <tdalign="left"> (TBD4)</td>align="left">193</td> <td align="left">Failed to establish the BFD session. The specified reverse path was not found.</td> <tdalign="left">This document</td>align="left">RFC 9612</td> </tr> </tbody> </table> </section> </section> <sectionnumbered="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> <sectionanchor="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-TLVsMUST<bcp14>MUST</bcp14> be limited to mitigate that threat. The default limit for the number of sub-TLVs is setin <xref target="bfd-reverse-path-tlv"/>to128.128 (see <xref target="bfd-reverse-path-tlv"/>). An implementationMAY<bcp14>MAY</bcp14> use a mechanism to control that limit. </t> </section> </middle> <back> <references> <name>Normative References</name> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5884.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5884.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/> <xi:includehref="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:includehref="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> <sectionnumbered="true"numbered="false" toc="default"> <name>Acknowledgments</name><t> The<t>The authors greatly appreciateathe thoroughreviewreviews andthe mosthelpful comments fromEric Gray<contact fullname="Eric Gray"/> andCarlos Pignataro.<contact fullname="Carlos Pignataro"/>. The authors much appreciate the help ofQian 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>