rfc9747xml2.original.xml   rfc9747.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-bfd-unaffiliated-echo- <!DOCTYPE rfc [
14" updates="5880" consensus="true" submissionType="IETF"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
<title abbrev="Unaffiliated BFD Echo"> Unaffiliated Bidirectional Forwarding docName="draft-ietf-bfd-unaffiliated-echo-14" number="9747" obsoletes="" update
Detection (BFD) Echo </title> s="5880" consensus="true" submissionType="IETF" tocInclude="true" symRefs="true"
sortRefs="true" version="3" xml:lang="en">
<front>
<title abbrev="Unaffiliated BFD Echo"> Unaffiliated Bidirectional Forwarding
Detection (BFD) Echo </title>
<seriesInfo name="RFC" value="9747"/>
<author fullname="Weiqiang Cheng" initials="W" surname="Cheng"> <author fullname="Weiqiang Cheng" initials="W" surname="Cheng">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Beijing</city>
<!-- Reorder these if your country does things differently --> <country>China</country>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal> </postal>
<phone></phone>
<email>chengweiqiang@chinamobile.com</email> <email>chengweiqiang@chinamobile.com</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<author fullname="Ruixue Wang" initials="R" surname="Wang"> <author fullname="Ruixue Wang" initials="R" surname="Wang">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Beijing</city>
<!-- Reorder these if your country does things differently --> <country>China</country>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal> </postal>
<phone></phone>
<email>wangruixue@chinamobile.com</email> <email>wangruixue@chinamobile.com</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<author fullname="Xiao Min" initials="X" surname="Min" role="editor"> <author fullname="Xiao Min" initials="X" surname="Min" role="editor">
<organization>ZTE Corp.</organization> <organization>ZTE Corp.</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Nanjing</city>
<!-- Reorder these if your country does things differently --> <country>China</country>
<city>Nanjing</city>
<region></region>
<code></code>
<country>China</country>
</postal> </postal>
<phone></phone>
<email>xiao.min2@zte.com.cn</email> <email>xiao.min2@zte.com.cn</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<author fullname="Reshad Rahman" initials="R" surname="Rahman"> <author fullname="Reshad Rahman" initials="R" surname="Rahman">
<organization>Equinix</organization> <organization>Equinix</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Ottawa</city>
<!-- Reorder these if your country does things differently --> <country>Canada</country>
<city>Ottawa</city>
<region></region>
<code></code>
<country>Canada</country>
</postal> </postal>
<phone></phone>
<email>reshad@yahoo.com</email> <email>reshad@yahoo.com</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<author fullname="Raj Chetan Boddireddy" initials="R" surname="Boddireddy"> <author fullname="Raj Chetan Boddireddy" initials="R" surname="Boddireddy">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>rchetan@juniper.net</email> <email>rchetan@juniper.net</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<date year="2025" month="March"/>
<area>RTG</area>
<workgroup>bfd</workgroup>
<date year="2024"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<area>Routing</area> <keyword>example</keyword>
<workgroup>BFD Working Group</workgroup>
<keyword>Request for Comments</keyword> <!-- [rfced] Because this document updates RFC 5880, please
<keyword>RFC</keyword> review the errata reported for RFC 5880
<keyword>Internet Draft</keyword> (https://www.rfc-editor.org/errata/rfc5880).
<keyword>I-D</keyword> Please let us know if you agree that none of them are
relevant to the content of this document.
-->
<abstract> <abstract>
<t>
<t>
This document specifies an extension to the Bidirectional Forwarding Dete ction (BFD) This document specifies an extension to the Bidirectional Forwarding Dete ction (BFD)
protocol that enables the use of the BFD Echo function without the need f or an associated protocol that enables the use of the BFD Echo function without the need f or an associated
BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of
forwarding path failures in networks where establishing BFD control sessi ons is impractical forwarding path failures in networks where establishing BFD control sessi ons is impractical
or undesirable. By decoupling the Echo function from the control plane, n etwork devices can or undesirable. By decoupling the Echo function from the control plane, n etwork devices can
utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network
resiliency and operational efficiency. resiliency and operational efficiency.
</t> </t>
<t> <t>
This document updates RFC 5880 by defining a new Unaffiliated BFD Echo me chanism. This document updates RFC 5880 by defining a new Unaffiliated BFD Echo me chanism.
</t> </t>
</abstract> </abstract>
</front>
</front> <middle>
<section>
<middle> <name>Introduction</name>
<t>
<section title="Introduction">
<t>
To minimize the impact of device and link faults on services and to impro ve network availability To minimize the impact of device and link faults on services and to impro ve network availability
in single-hop scenarios, a network device needs the capability to quickly detect communication in single-hop scenarios, a network device needs the capability to quickly detect communication
faults with adjacent devices. Prompt detection allows for timely remedial actions to ensure faults with adjacent devices. Prompt detection allows for timely remedial actions to ensure
service continuity. service continuity.
</t> </t>
<t>
<t>
BFD <xref target="RFC5880"/> provides a low-overhead, short-interval meth od for detecting faults BFD <xref target="RFC5880"/> provides a low-overhead, short-interval meth od for detecting faults
on the communication path between adjacent forwarding engines, which may include interfaces, data on the communication path between adjacent forwarding engines, which may include interfaces, data
links, and the forwarding engines themselves. BFD offers a unified mechan ism to monitor any media links, and the forwarding engines themselves. BFD offers a unified mechan ism to monitor any media
and protocol layers in real time. and protocol layers in real time.
</t> </t>
<t>
<t> BFD defines two primary modes -- Asynchronous mode and Demand mode -- to
BFD defines two primary modes-Asynchronous mode and Demand mode-to accomm accommodate various deployment
odate various deployment
scenarios. Additionally, it supports an Echo function that reduces the le vel of BFD support required scenarios. Additionally, it supports an Echo function that reduces the le vel of BFD support required
in device implementations, as described in Section 3.2 of <xref target="R FC5880"/>. When the Echo in device implementations, as described in <xref section="3.2" sectionFor mat="of" target="RFC5880"/>. When the Echo
function is activated, the local system sends BFD Echo packets, and the r emote system loops back the function is activated, the local system sends BFD Echo packets, and the r emote system loops back the
received Echo packets through the forwarding path, as described in Sectio received Echo packets through the forwarding path, as described in <xref
n 5 of <xref target="RFC5880"/> section="5" sectionFormat="of" target="RFC5880"/>
and Section 4 of <xref target="RFC5881"/>. If several consecutive BFD Ech and <xref section="4" sectionFormat="of" target="RFC5881"/>. If several c
o packets are not received onsecutive BFD Echo packets are not received
by the local system, the BFD session is declared Down. by the local system, the BFD session is declared Down.
</t> </t>
<t>
<t>
There are two typical scenarios when using the BFD Echo function: There are two typical scenarios when using the BFD Echo function:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
Full BFD protocol capability with adjunct Echo function (Affiliated BFD E cho): This scenario requires Full BFD protocol capability with adjunct Echo function (Affiliated BFD E cho): This scenario requires
both the local device and the adjacent device to support the full BFD pro tocol. This operation remains both the local device and the adjacent device to support the full BFD pro tocol. This operation remains
unchanged from <xref target="RFC5880"/>. unchanged from <xref target="RFC5880"/>.
</t> </t>
<t> </li>
<li>
<t>
BFD Echo-Only method without full BFD protocol capability (Unaffiliated B FD Echo): This scenario requires BFD Echo-Only method without full BFD protocol capability (Unaffiliated B FD Echo): This scenario requires
only the local device to support sending and demultiplexing BFD Control p ackets. In this case, BFD only the local device to support sending and demultiplexing BFD Control p ackets. In this case, BFD
Control packets are sent over the BFD Echo port, and the processing proce dures for Asynchronous mode Control packets are sent over the BFD Echo port, and the processing proce dures for Asynchronous mode
are used with the modifications specified in this document. Note that thi s method requires the local device are used with the modifications specified in this document. Note that thi s method requires the local device
to send packets with one of its own IP addresses as the destination addre ss, upon receipt of which the adjacent to send packets with one of its own IP addresses as the destination addre ss, upon receipt of which the adjacent
device loops them back to the local device. Also note that this method mo nitors the connectivity to a device device loops them back to the local device. Also note that this method mo nitors the connectivity to a device
over a specific interface and does not verify the availability of a speci fic IP address at that device. over a specific interface and does not verify the availability of a speci fic IP address at that device.
</t> </t>
</list> </li>
</ul>
<t>
This document specifies the Unaffiliated BFD Echo scenario. This document specifies the Unaffiliated BFD Echo scenario.
</t> </t>
<t>
<t> <xref section="5" sectionFormat="of" target="RFC5880"/> indicates that th
Section 5 of <xref target="RFC5880"/> indicates that the payload of an Af e payload of an Affiliated BFD Echo packet is a local
filiated BFD Echo packet is a local matter; therefore, its contents are outside the scope of that specificati
matter and, therefore, its contents are outside the scope of that specifi on. This document, however,
cation. This document, however,
specifies the contents of the Unaffiliated BFD Echo packet and the proced ures for handling them. While this specifies the contents of the Unaffiliated BFD Echo packet and the proced ures for handling them. While this
may appear to contravene Section 5 of <xref target="RFC5880"/>, the core behavior in that RFC states that the may appear to contravene <xref section="5" sectionFormat="of" target="RFC 5880"/>, the core behavior in that RFC states that the
contents of BFD Echo packets are a local matter; this document is definin g that "local matter". Regarding the contents of BFD Echo packets are a local matter; this document is definin g that "local matter". Regarding the
selection of IP addresses, the rules stated in Section 4 of <xref target= "RFC5881"/> are applicable to the selection of IP addresses, the rules stated in <xref section="4" sectionF ormat="of" target="RFC5881"/> are applicable to the
encapsulation of an Unaffiliated BFD Echo packet. encapsulation of an Unaffiliated BFD Echo packet.
</t> </t>
<t>
<t>
Section 6.2.2 of <xref target="BBF-TR-146"/> describes a use case for the Unaffiliated BFD Echo. Section 6.2.2 of <xref target="BBF-TR-146"/> describes a use case for the Unaffiliated BFD Echo.
</t> </t>
<t>
<t>
This document updates <xref target="RFC5880"/> by defining a new method o f BFD Echo-only operation which only This document updates <xref target="RFC5880"/> by defining a new method o f BFD Echo-only operation which only
impacts the BFD Echo packets sender without requiring an implementation t impacts the sender of BFD Echo packets without requiring an implementatio
o support the BFD protocol at the n to support the BFD protocol at the
loop-back device, such that any IP forwarder can loop-back the BFD Echo p loopback device, such that any IP forwarder can loop back the BFD Echo pa
ackets. It specifies the use of the ckets. It specifies the use of the
Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. The reason why it cannot be used for multihop Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. The reason why it cannot be used for multihop
paths is that the Unaffiliated BFD Echo packets would be looped back by t he first hop. A full description of paths is that the Unaffiliated BFD Echo packets would be looped back by t he first hop. A full description of
the updates to <xref target="RFC5880"/> is provided in Section 3. the updates to <xref target="RFC5880"/> is provided in <xref target="upda
</t> tes-to-rfc-5880"/>.
</t>
<section title="Conventions Used in This Document"> <section>
<name>Conventions Used in This Document</name>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this documen "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
t are to be interpreted ",
as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
when, and only when, they "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
</section> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
</section> shown here.
</t>
<section title="Unaffiliated BFD Echo Procedures"> </section>
</section>
<t> <section anchor="unaffiliated-bfd-echo-procedures">
<name>Unaffiliated BFD Echo Procedures</name>
<t>
This section specifies the Unaffiliated BFD Echo procedures. This section specifies the Unaffiliated BFD Echo procedures.
</t> </t>
<figure anchor="Figure_1">
<figure anchor="Figure_1" title="Unaffiliated BFD Echo diagram"> <name>Unaffiliated BFD Echo</name>
<artset> <artset>
<artwork type="svg"> <artwork type="svg">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="272" width=" 512" viewBox="0 0 512 272" class="diagram" text-anchor="middle" font-family="mon ospace" font-size="13px" stroke-linecap="round"> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="272" width=" 512" viewBox="0 0 512 272" class="diagram" text-anchor="middle" font-family="mon ospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,240" fill="none" stroke="black"/> <path d="M 8,32 L 8,240" fill="none" stroke="black"/>
<path d="M 40,64 L 40,192" fill="none" stroke="black"/> <path d="M 40,64 L 40,192" fill="none" stroke="black"/>
<path d="M 144,32 L 144,88" fill="none" stroke="black"/> <path d="M 144,32 L 144,88" fill="none" stroke="black"/>
<path d="M 144,104 L 144,136" fill="none" stroke="black"/> <path d="M 144,104 L 144,136" fill="none" stroke="black"/>
<path d="M 144,184 L 144,240" fill="none" stroke="black"/> <path d="M 144,184 L 144,240" fill="none" stroke="black"/>
<path d="M 368,32 L 368,136" fill="none" stroke="black"/> <path d="M 368,32 L 368,136" fill="none" stroke="black"/>
<path d="M 368,184 L 368,240" fill="none" stroke="black"/> <path d="M 368,184 L 368,240" fill="none" stroke="black"/>
<path d="M 384,144 L 384,176" fill="none" stroke="black"/> <path d="M 384,144 L 384,176" fill="none" stroke="black"/>
<path d="M 504,32 L 504,240" fill="none" stroke="black"/> <path d="M 504,32 L 504,240" fill="none" stroke="black"/>
<path d="M 8,32 L 144,32" fill="none" stroke="black"/> <path d="M 8,32 L 144,32" fill="none" stroke="black"/>
<path d="M 368,32 L 504,32" fill="none" stroke="black"/> <path d="M 368,32 L 504,32" fill="none" stroke="black"/>
<path d="M 48,64 L 136,64" fill="none" stroke="black"/> <path d="M 48,64 L 136,64" fill="none" stroke="black"/>
<path d="M 136,96 L 160,96" fill="none" stroke="black"/> <path d="M 136,96 L 160,96" fill="none" stroke="black"/>
<path d="M 136,144 L 376,144" fill="none" stroke="black"/> <path d="M 136,144 L 376,144" fill="none" stroke="black"/>
<path d="M 128,176 L 376,176" fill="none" stroke="black"/> <path d="M 128,176 L 376,176" fill="none" stroke="black"/>
<path d="M 48,192 L 136,192" fill="none" stroke="black"/> <path d="M 48,192 L 136,192" fill="none" stroke="black"/>
<path d="M 8,240 L 144,240" fill="none" stroke="black"/> <path d="M 8,240 L 144,240" fill="none" stroke="black"/>
<path d="M 368,240 L 504,240" fill="none" stroke="black"/> <path d="M 368,240 L 504,240" fill="none" stroke="black"/>
<polygon class="arrowhead" points="168,96 156,90.4 156,101.6" fill="black" <polygon class="arrowhead" points="168,96 156,90.4 156,101.6" fill
transform="rotate(0,160,96)"/> ="black" transform="rotate(0,160,96)"/>
<polygon class="arrowhead" points="136,176 124,170.4 124,181.6" fill="blac <polygon class="arrowhead" points="136,176 124,170.4 124,181.6" fi
k" transform="rotate(180,128,176)"/> ll="black" transform="rotate(180,128,176)"/>
<g class="text"> <g class="text">
<text x="76" y="20">Device A</text> <text x="76" y="20">Device A</text>
<text x="436" y="20">Device B</text> <text x="436" y="20">Device B</text>
<text x="92" y="84">Unaffiliated</text> <text x="92" y="84">Unaffiliated</text>
<text x="84" y="100">BFD Echo</text> <text x="84" y="100">BFD Echo</text>
<text x="80" y="116">Session</text> <text x="80" y="116">Session</text>
<text x="256" y="132">Unaffiliated BFD Echo</text> <text x="256" y="132">Unaffiliated BFD Echo</text>
<text x="408" y="148">BFD</text> <text x="408" y="148">BFD</text>
<text x="144" y="164">|</text> <text x="144" y="164">|</text>
<text x="424" y="164">packets</text> <text x="424" y="164">packets</text>
<text x="420" y="180">looped</text> <text x="420" y="180">looped</text>
<text x="72" y="260">BFD supported</text> <text x="72" y="260">BFD supported</text>
<text x="440" y="260">BFD not supported</text> <text x="440" y="260">BFD not supported</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="left"><![CDATA[ <artwork type="ascii-art" align="left"><![CDATA[
Device A Device B Device A Device B
+----------------+ +----------------+ +----------------+ +----------------+
| | | | | | | |
| |------------| | | | |------------| | |
| |Unaffiliated| | | | |Unaffiliated| | |
| | BFD Echo ---> | | | | BFD Echo ---> | |
| | Session | | | | | Session | | |
| | | Unaffiliated BFD Echo | | | | | Unaffiliated BFD Echo | |
| | -------------------------------| BFD | | | -------------------------------| BFD |
| | | | packets | | | | | packets |
| | <-------------------------------| looped | | | <-------------------------------| looped |
| |------------| | | | |------------| | |
| | | | | | | |
| | | | | | | |
+----------------+ +----------------+ +----------------+ +----------------+
BFD supported BFD not supported BFD supported BFD not supported
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>
<t> As shown in <xref target="Figure_1"/>, device A supports BFD, whereas device
As shown in Figure 1, device A supports BFD, whereas device B is a regular I B is a regular IP forwarder that does not support
P forwarder that does not support
BFD. Device A would send Unaffiliated BFD Echo packets, and after receivi ng the Unaffiliated BFD Echo packets BFD. Device A would send Unaffiliated BFD Echo packets, and after receivi ng the Unaffiliated BFD Echo packets
sent from device A, the one-hop-away BFD peer device B immediately loops them back by normal IP forwarding, this sent from device A, the one-hop-away BFD peer device B immediately loops them back by normal IP forwarding. This
allows device A to rapidly detect a connectivity loss to device B. Note t hat device B would not intercept any allows device A to rapidly detect a connectivity loss to device B. Note t hat device B would not intercept any
received Unaffiliated BFD Echo packet or parse any BFD protocol field wit hin the Unaffiliated BFD Echo packet. received Unaffiliated BFD Echo packet or parse any BFD protocol field wit hin the Unaffiliated BFD Echo packet.
</t> </t>
<t> <t>
An Unaffiliated BFD Echo session is not actually a BFD session because there is no coordination of BFD protocol An Unaffiliated BFD Echo session is not actually a BFD session because there is no coordination of BFD protocol
state between the two link ends: the remote end does not support BFD and state between the two link ends: the remote end does not support BFD and
so cannot engage in a BFD session. The so cannot engage in a BFD session.
<!--[rfced] Please clarify this sentence, especially "from its own
standpoint". Is this about the local end's standpoint?
Original:
The local end as an initiator may regard
the Unaffiliated BFD Echo session as a BFD session from its own
standpoint.
Perhaps:
From the standpoint of the local end (as an initiator),
the Unaffiliated BFD Echo session may be regarded as a BFD session.
Or:
The local end (with the viewpoint of the initiator) may regard
the Unaffiliated BFD Echo session as a BFD session.
-->
The
local end as an initiator may regard the Unaffiliated BFD Echo session as a BFD session from its own standpoint. local end as an initiator may regard the Unaffiliated BFD Echo session as a BFD session from its own standpoint.
</t> </t>
<t> <t>
For the Unaffiliated Echo procedure, an Unaffiliated BFD Echo session is established on device A. The session For the Unaffiliated Echo procedure, an Unaffiliated BFD Echo session is established on device A. The session
MUST adhere to the BFD state machine specified in Section 6.2 of <xref ta rget="RFC5880"/>, with the exception <bcp14>MUST</bcp14> adhere to the BFD state machine specified in <xref se ction="6.2" sectionFormat="of" target="RFC5880"/>, with the exception
that the received state is not derived from BFD Control packets originati ng from the remote system, but rather that the received state is not derived from BFD Control packets originati ng from the remote system, but rather
from packets that are generated by the local system and looped back from the remote system. Consequently, the from packets that are generated by the local system and looped back from the remote system. Consequently, the
AdminDown state is not utilized in Unaffiliated BFD Echo. AdminDown state is not utilized in Unaffiliated BFD Echo.
</t> </t>
<t> <t>
BFD Control packets are transmitted and received as Unaffiliated BFD Echo packets, using UDP destination port BFD Control packets are transmitted and received as Unaffiliated BFD Echo packets, using UDP destination port
3785, as defined in <xref target="RFC5881"/>. The standard procedures for BFD Asynchronous sessions are applied 3785, as defined in <xref target="RFC5881"/>. The standard procedures for BFD Asynchronous sessions are applied
to the looped BFD Control packets, including packet validation and authen tication, in accordance with <xref target="RFC5880"/>. to the looped BFD Control packets, including packet validation and authen tication, in accordance with <xref target="RFC5880"/>.
</t> </t>
<t> <t>
Once an Unaffiliated BFD Echo session is created on device A, it starts s ending Unaffiliated BFD Echo packets. Once an Unaffiliated BFD Echo session is created on device A, it starts s ending Unaffiliated BFD Echo packets.
<!--[rfced] May we update this sentence to two sentences as follows
for clarity? Specifically, the updates are assuming:
- the "once" phrase applies to the latter part.
- "is conformed to" means "conforms to".
Original:
Unaffiliated BFD Echo
packets with zeroed "Your Discriminator" field are demultiplexed to
the proper session based on the source IP address or UDP source port,
once the remote system loops back the local discriminator, all
further received packets are demultiplexed based on the "Your
Discriminator" field only, which is conformed to the procedure
specified in Section 6.3 of [RFC5880].
Perhaps:
Unaffiliated BFD Echo
packets with zeroed "Your Discriminator" field are demultiplexed to
the proper session based on the source IP address or UDP source port.
After the remote system loops back the local discriminator, all
further received packets are demultiplexed based on the "Your
Discriminator" field only, which conforms to the procedure
specified in Section 6.3 of [RFC5880].
-->
Unaffiliated BFD Echo packets with zeroed "Your Discriminator" field are demultiplexed to the proper session based on Unaffiliated BFD Echo packets with zeroed "Your Discriminator" field are demultiplexed to the proper session based on
the source IP address or UDP source port, once the remote system loops ba ck the local discriminator, all further the source IP address or UDP source port, once the remote system loops ba ck the local discriminator, all further
received packets are demultiplexed based on the "Your Discriminator" fiel d only, which is conformed to the procedure received packets are demultiplexed based on the "Your Discriminator" fiel d only, which is conformed to the procedure
specified in Section 6.3 of <xref target="RFC5880"/>. An Unaffiliated BFD specified in <xref section="6.3" sectionFormat="of" target="RFC5880"/>. A
Echo packet follows the same encapsulation n Unaffiliated BFD Echo packet follows the same encapsulation
rules as for a BFD Echo packet as specified in Section 4 of <xref target= rules as for a BFD Echo packet as specified in <xref section="4" sectionF
"RFC5881"/>. All Unaffiliated BFD Echo packets ormat="of" target="RFC5881"/>. All Unaffiliated BFD Echo packets
for the session MUST be sent with a TTL or Hop Limit value of 255. Receiv for the session <bcp14>MUST</bcp14> be sent with a TTL or Hop Limit value
ed packets MUST have a TTL or Hop Limit of 255. Received packets <bcp14>MUST</bcp14> have a TTL or Hop Limit
value of 254 (similar to Appendix A of <xref target="RFC5082"/> to verify value of 254 (similar to <xref section="A" sectionFormat="of" target="RFC
against a configured number of hops); otherwise, 5082"/> to verify against a configured number of hops); otherwise,
the received packets MUST be dropped. the received packets <bcp14>MUST</bcp14> be dropped.
</t> </t>
<t> <t>
<!--[rfced] We note that quotation marks are not used around the
field names in RFC 5880. Do you want to keep the quotation marks
within this document?
Current:
"Your Discriminator" field
"Desired Min TX Interval" [field]
"Required Min RX Interval" field
"Required Min Echo RX Interval" field
-->
In the context of an Unaffiliated BFD Echo packet, the "Desired Min TX In terval" and "Required Min RX Interval" fields, In the context of an Unaffiliated BFD Echo packet, the "Desired Min TX In terval" and "Required Min RX Interval" fields,
as defined in <xref target="RFC5880"/>, MUST be populated with a specific as defined in <xref target="RFC5880"/>, <bcp14>MUST</bcp14> be populated
value to prevent the potential exposure of with a specific value to prevent the potential exposure of
uninitialized memory. It is RECOMMENDED that these fields be set to a val uninitialized memory. It is <bcp14>RECOMMENDED</bcp14> that these fields
ue of 1 second (1,000,000 microseconds). However, be set to a value of 1 second (1,000,000 microseconds). However,
upon receipt, these values MUST be ignored and MUST NOT be used in the ca upon receipt, these values <bcp14>MUST</bcp14> be ignored and <bcp14>MUST
lculation of the Detection Time. NOT</bcp14> be used in the calculation of the Detection Time.
</t> </t>
<t> <t>
The "Required Min Echo RX Interval" field, as defined in <xref target="RF The "Required Min Echo RX Interval" field, as defined in <xref target="RF
C5880"/>, MUST be populated with a specific value C5880"/>, <bcp14>MUST</bcp14> be populated with a specific value
to prevent the potential exposure of uninitialized memory. It is RECOMMEN to prevent the potential exposure of uninitialized memory. It is <bcp14>R
DED that this field be set to 0. However, this value ECOMMENDED</bcp14> that this field be set to 0. However, this value
MUST be ignored upon receipt. The transmission interval for Unaffiliated <bcp14>MUST</bcp14> be ignored upon receipt. The transmission interval fo
BFD Echo packets when in the Up state MUST be r Unaffiliated BFD Echo packets when in the Up state <bcp14>MUST</bcp14> be
provisioned on device A. provisioned on device A.
</t> </t>
<t> <t>
The functionality of the Unaffiliated BFD Echo feature is dependent on de vice B performing IP forwarding. While this capability The functionality of the Unaffiliated BFD Echo feature is dependent on de vice B performing IP forwarding. While this capability
is typically expected to be supported on routers, it may not be enabled b y default on hosts. The method for provisioning device is typically expected to be supported on routers, it may not be enabled b y default on hosts. The method for provisioning device
B to loop back Unaffiliated BFD Echo packets is outside the scope of this document. B to loop back Unaffiliated BFD Echo packets is outside the scope of this document.
</t> </t>
<t> <t>
Similar to what's specified in <xref target="RFC5880"/>, the Unaffiliated BFD Echo session begins with the Similar to what's specified in <xref target="RFC5880"/>, the Unaffiliated BFD Echo session begins with the
periodic, slow transmission of Unaffiliated BFD Echo packets. The slow tr ansmission rate should be no greater than periodic, slow transmission of Unaffiliated BFD Echo packets. The slow tr ansmission rate should be no greater than
one packet per second, until the session on device A is Up. After the ses sion is Up, the provisioned transmission interval is one packet per second, until the session on device A is Up. After the ses sion is Up, the provisioned transmission interval is
used. When the Unaffiliated BFD Echo session on device A goes Down, the s low transmission rate is resumed. The "Detect Mult" used. When the Unaffiliated BFD Echo session on device A goes Down, the s low transmission rate is resumed. The "Detect Mult"
defined in <xref target="RFC5880"/> MUST be set to a value provisioned on device A. When the bfd.SessionState is defined in <xref target="RFC5880"/> <bcp14>MUST</bcp14> be set to a value provisioned on device A. When the bfd.SessionState is
Up and a "Detect Mult" number of Unaffiliated BFD Echo packets have not a rrived at device A as they should, the device Up and a "Detect Mult" number of Unaffiliated BFD Echo packets have not a rrived at device A as they should, the device
A "MUST set bfd.SessionState to Down and bfd.LocalDiag to 2 (Echo Functio A "<bcp14>MUST</bcp14> set bfd.SessionState to Down and bfd.LocalDiag to
n Failed)", as specified in Section 6.8.5 2 (Echo Function Failed)", as specified in
of <xref target="RFC5880"/>. <xref section="6.8.5" sectionFormat="of" target="RFC5880"/>.
</t> </t>
<t> <t>
In summary, the Unaffiliated BFD Echo packet reuses the format of the BFD Control packet defined in <xref target="RFC5880"/>, In summary, the Unaffiliated BFD Echo packet reuses the format of the BFD Control packet defined in <xref target="RFC5880"/>,
and the fields within the Unaffiliated BFD Echo packet are populated as f ollows: and the fields within the Unaffiliated BFD Echo packet are populated as f ollows:
<list style='symbols'> </t>
<t>My Discriminator: MUST be set to the provisioned local discrimina <ul spacing="normal">
tor.</t> <li>
<t>Your Discriminator: MUST initially be set to 0, and then MUST be <t>My Discriminator: <bcp14>MUST</bcp14> be set to the provisioned loc
set to the value of "My Discriminator" looped back al discriminator.</t>
</li>
<li>
<t>Your Discriminator: <bcp14>MUST</bcp14> initially be set to 0, and
then <bcp14>MUST</bcp14> be set to the value of "My Discriminator" looped back
from the remote system.</t> from the remote system.</t>
<t>Desired Min TX Interval: MUST be set to a specific value, with a </li>
suggested value of 1 second (1,000,000 microseconds).</t> <li>
<t>Required Min RX Interval: MUST be set to a specific value, with a <t>Desired Min TX Interval: <bcp14>MUST</bcp14> be set to a specific v
suggested value of 1 second (1,000,000 microseconds).</t> alue, with a suggested value of 1 second (1,000,000 microseconds).</t>
<t>Required Min Echo RX Interval: MUST be set to a specific value, w </li>
ith a suggested value of 0.</t> <li>
<t>Detect Mult: MUST be set to the provisioned maximum allowable num <t>Required Min RX Interval: <bcp14>MUST</bcp14> be set to a specific
ber of consecutively lost Unaffiliated BFD Echo packets.</t> value, with a suggested value of 1 second (1,000,000 microseconds).</t>
</list> </li>
</t> <li>
<t>Required Min Echo RX Interval: <bcp14>MUST</bcp14> be set to a spec
ific value, with a suggested value of 0.</t>
</li>
<li>
<t>Detect Mult: <bcp14>MUST</bcp14> be set to the provisioned maximum
allowable number of consecutively lost Unaffiliated BFD Echo packets.</t>
</li>
</ul>
</section> </section>
<section anchor="updates-to-rfc-5880">
<name>Updates to RFC 5880</name>
<t>
The Unaffiliated BFD Echo described in this document reuses the BFD
Echo function as described in <xref target="RFC5880"/> and <xref
target="RFC5881"/>, but does not require BFD Asynchronous or Demand
mode. In the Unaffiliated BFD Echo operation, only the local system
has the BFD protocol enabled, while the remote system simply loops
back the received BFD Echo packets as ordinary data packets, without
engaging in the BFD protocol.
</t>
<t>
This document updates <xref target="RFC5880"/> with respect to its
descriptions on the BFD Echo function as follows.
</t>
<t>
The 4th paragraph of <xref section="3.2" sectionFormat="of" target="RFC58
80"/> is
updated as below:
</t>
<section title="Updates to RFC 5880"> <t>OLD TEXT</t>
<blockquote>An adjunct to both modes is the Echo function.</blockquote>
<t> <t>NEW TEXT</t>
The Unaffiliated BFD Echo described in this document reuses the BFD Echo <blockquote>An adjunct to both modes is the Echo function, which can also
function as described in <xref target="RFC5880"/> and be running independently.</blockquote>
<xref target="RFC5881"/>, but does not require BFD Asynchronous or Demand
mode. In the Unaffiliated BFD Echo operation, only the
local system has the BFD protocol enabled, while the remote system simply
loops back the received BFD Echo packets as ordinary
data packets, without engaging in the BFD protocol.
</t>
<t> <t>OLD TEXT</t>
This document updates <xref target="RFC5880"/> with respect to its descri <blockquote>Since the Echo function is handling the task of detection,
ptions on the BFD Echo the rate of periodic transmission of Control packets may be reduced (in
function as follows. the case of Asynchronous mode) or eliminated completely (in the case of
</t> Demand mode).</blockquote>
<t> <t>NEW TEXT</t>
The 4th paragraph of Section 3.2 of <xref target="RFC5880"/> is updated a <blockquote>Since the Echo function is handling the task of detection,
s below: the rate of periodic transmission of Control packets may be reduced (in
</t> the case of Asynchronous mode) or eliminated completely (in the case of
Demand mode). The Echo function may also be used independently, with
neither Asynchronous nor Demand mode.</blockquote>
<t> <t>
<list> The 3rd and 9th paragraphs of <xref section="6.1" sectionFormat="of" targ
<t> et="RFC5880"/> are updated as below:
OLD TEXT<br/>An adjunct to both modes is the Echo function. </t>
</t>
<t>
NEW TEXT<br/>An adjunct to both modes is the Echo function, which can als
o be running independently.
</t>
<t>
OLD TEXT<br/>Since the Echo function is handling the task of detection, t
he rate of
periodic transmission of Control packets may be reduced (in the case
of Asynchronous mode) or eliminated completely (in the case of Demand mode).
</t>
<t>
NEW TEXT<br/>Since the Echo function is handling the task of detection, t
he rate of
periodic transmission of Control packets may be reduced (in the case
of Asynchronous mode) or eliminated completely (in the case of Demand mode).
The Echo function may also be used independently, with neither Asynchrono
us nor Demand mode.
</t>
</list>
</t>
<t> <t>OLD TEXT</t>
The 3rd and 9th paragraphs of Section 6.1 of <xref target="RFC5880"/> are <blockquote>Once the BFD session is Up, a system can choose to start the
updated as below: Echo function if it desires and the other system signals that it will
</t> allow it. The rate of transmission of Control packets is typically kept
low when the Echo function is active.</blockquote>
<t> <t>NEW TEXT</t>
<list> <blockquote>When a system is running with Asynchronous or Demand mode,
<t> once the BFD session is Up, it can choose to start the Echo function if
OLD TEXT<br/>Once the BFD session is Up, a system can choose to start the it desires and the other system signals that it will allow it. The rate
Echo of transmission of Control packets is typically kept low for
function if it desires and the other system signals that it will Asynchronous mode or eliminated completely for Demand mode when the Echo
allow it. The rate of transmission of Control packets is typically function is active.</blockquote>
kept low when the Echo function is active.
</t>
<t>
NEW TEXT<br/>When a system is running with Asynchronous or Demand mode,
once the BFD session is Up, it can choose to start the Echo
function if it desires and the other system signals that it will
allow it. The rate of transmission of Control packets is typically
kept low for Asynchronous mode or eliminated completely for Demand mode
when the Echo function is active.
</t>
<t>
OLD TEXT<br/>If the session goes Down, the transmission of Echo packets (
if any)
ceases, and the transmission of Control packets goes back to the slow
rate.
</t>
<t>
NEW TEXT<br/>In Asynchronous mode or Demand mode, if the session goes Dow
n, the transmission
of Echo packets (if any) ceases, and the transmission of Control packets
goes back to the slow rate.
</t>
</list>
</t>
<t> <t>OLD TEXT</t>
The 2nd paragraph of Section 6.4 of <xref target="RFC5880"/> is updated a <blockquote>If the session goes Down, the transmission of Echo packets
s below: (if any) ceases, and the transmission of Control packets goes back to
</t> the slow rate.</blockquote>
<t> <t>NEW TEXT</t>
<list> <blockquote>In Asynchronous mode or Demand mode, if the session goes
<t> Down, the transmission of Echo packets (if any) ceases, and the
OLD TEXT<br/>When a system is using the Echo function, it is advantageous transmission of Control packets goes back to the slow rate.</blockquote>
to
choose a sedate reception rate for Control packets, since liveness
detection is being handled by the Echo packets. This can be controlled
by manipulating the Required Min RX Interval field (see section 6.8.3).
</t>
<t>
NEW TEXT<br/>When a system is using the Echo function with Asynchronous m
ode, it is advantageous to
choose a sedate reception rate for Control packets, since liveness
detection is being handled by the Echo packets. This can be controlled
by manipulating the Required Min RX Interval field (see section 6.8.3).
Note that a system operating in Demand mode would direct the remote syste
m to cease
the periodic transmission of BFD Control packets, by setting the Demand (
D) bit in its
BFD Control packets.
</t>
</list>
</t>
<t> <t>
The 2nd paragraph of Section 6.8 of <xref target="RFC5880"/> is updated a The 2nd paragraph of <xref section="6.4" sectionFormat="of" target="RFC58
s below: 80"/> is updated as below:
</t> </t>
<t> <t>OLD TEXT</t>
<list> <blockquote>When a system is using the Echo function, it is advantageous
<t> to choose a sedate reception rate for Control packets, since liveness
OLD TEXT<br/>When a system is said to have "the Echo function active" it detection is being handled by the Echo packets. This can be controlled
means by manipulating the Required Min RX Interval field (see section 6.8.3).</b
that the system is sending BFD Echo packets, implying that the lockquote>
session is Up and the other system has signaled its willingness to
loop back Echo packets.
</t>
<t>
NEW TEXT<br/>When a system in Asynchronous or Demand mode is said to have
"the Echo function active" it means
that the system is sending BFD Echo packets, implying that the
session is Up and the other system has signaled its willingness to
loop back Echo packets.
</t>
</list>
</t>
<t> <t>NEW TEXT</t>
The 7th paragraph of Section 6.8.3 of <xref target="RFC5880"/> is updated <blockquote>When a system is using the Echo function with Asynchronous
as below: mode, it is advantageous to choose a sedate reception rate for Control
</t> packets, since liveness detection is being handled by the Echo
packets. This can be controlled by manipulating the Required Min RX
Interval field (see section 6.8.3). Note that a system operating in
Demand mode would direct the remote system to cease the periodic
transmission of BFD Control packets, by setting the Demand (D) bit in
its BFD Control packets.</blockquote>
<t> <t>
<list> The 2nd paragraph of <xref section="6.8" sectionFormat="of" target="RFC58
<t> 80"/> is updated as below:
OLD TEXT<br/>When the Echo function is active, a system SHOULD set </t>
bfd.RequiredMinRxInterval to a value of not less than one second
(1,000,000 microseconds). This is intended to keep received BFD
Control traffic at a negligible level, since the actual detection
function is being performed using BFD Echo packets.
</t>
<t>
NEW TEXT<br/>When the Echo function is active with Asynchronous mode, a s
ystem SHOULD set
bfd.RequiredMinRxInterval to a value of not less than one second
(1,000,000 microseconds). This is intended to keep received BFD
Control traffic at a negligible level, since the actual detection
function is being performed using BFD Echo packets. A system operating in
Demand mode would not receive BFD Control traffic.
</t>
</list>
</t>
<t> <t>OLD TEXT</t>
The 1st and 2nd paragraphs of Section 6.8.9 of <xref target="RFC5880"/> a <blockquote>When a system is said to have "the Echo function active" it
re updated as below: means that the system is sending BFD Echo packets, implying that the
</t> session is Up and the other system has signaled its willingness to loop
back Echo packets.</blockquote>
<t> <t>NEW TEXT</t>
<list> <blockquote>When a system in Asynchronous or Demand mode is said to have
<t> "the Echo function active" it means that the system is sending BFD Echo
OLD TEXT<br/>BFD Echo packets MUST NOT be transmitted when bfd.SessionSta packets, implying that the session is Up and the other system has
te is not signaled its willingness to loop back Echo packets.</blockquote>
Up. BFD Echo packets MUST NOT be transmitted unless the last BFD
Control packet received from the remote system contains a nonzero
value in Required Min Echo RX Interval.
</t>
<t>
NEW TEXT<br/>When a system is using the Echo function with either Asynchr
onous or Demand mode,
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
Up, and BFD Echo packets MUST NOT be transmitted unless the last BFD
Control packet received from the remote system contains a nonzero
value in Required Min Echo RX Interval.
</t>
<t>
OLD TEXT<br/>BFD Echo packets MAY be transmitted when bfd.SessionState is
Up. The
interval between transmitted BFD Echo packets MUST NOT be less than
the value advertised by the remote system in Required Min Echo RX
Interval...
</t>
<t>
NEW TEXT<br/>When a system is using the Echo function with either Asynchr
onous or Demand mode,
BFD Echo packets MAY be transmitted when bfd.SessionState is Up, and the
interval between transmitted BFD Echo packets MUST NOT be less than
the value advertised by the remote system in Required Min Echo RX
Interval...
</t>
</list>
</t>
</section> <t>
The 7th paragraph of <xref section="6.8.3" sectionFormat="of" target="RFC
5880"/> is updated as below:
</t>
<section title="Operational Considerations"> <t>OLD TEXT</t>
<blockquote>When the Echo function is active, a system
<bcp14>SHOULD</bcp14> set bfd.RequiredMinRxInterval to a value of not
less than one second (1,000,000 microseconds). This is intended to keep
received BFD Control traffic at a negligible level, since the actual
detection function is being performed using BFD Echo
packets.</blockquote>
<t> <t>NEW TEXT</t>
All Operational Considerations from <xref target="RFC5880"/> apply. Since th <blockquote>When the Echo function is active with Asynchronous mode, a
is mechanism leverages existing BFD machinery, system <bcp14>SHOULD</bcp14> set bfd.RequiredMinRxInterval to a value of
particularly periodic pacing of traffic based on configuration, there's n not less than one second (1,000,000 microseconds). This is intended to
o real possibility to create congestion. Moreover, keep received BFD Control traffic at a negligible level, since the
creating congestion would be counter productive to check the bidirectiona actual detection function is being performed using BFD Echo packets. A
l connectivity. system operating in Demand mode would not receive BFD Control traffic.</bl
</t> ockquote>
<t>
<t>
The 1st and 2nd paragraphs of <xref section="6.8.9" sectionFormat="of" ta
rget="RFC5880"/> are updated as below:
</t>
<!--[rfced] Regarding the updates to Section 6.8.9 of RFC 5880
a) Because these are two contiguous paragraphs in RFC 5880, we suggest
they be together rather than separate. Is this acceptable?
b) Because "except as follows" conveys meaning to the reader (i.e., they
need to read the subsequent text in RFC 5880), we suggest including it in
the OLD and NEW TEXT.
Suggested:
The 1st and 2nd paragraphs of Section 6.8.9 of [RFC5880] are updated
as below:
OLD TEXT
| BFD Echo packets MUST NOT be transmitted when bfd.SessionState is
| not Up. BFD Echo packets MUST NOT be transmitted unless the last
| BFD Control packet received from the remote system contains a
| nonzero value in Required Min Echo RX Interval.
|
| BFD Echo packets MAY be transmitted when bfd.SessionState is Up.
| The interval between transmitted BFD Echo packets MUST NOT be less
| than the value advertised by the remote system in Required Min
| Echo RX Interval, except as follows: [...]
NEW TEXT
| When a system is using the Echo function with either Asynchronous
| or Demand mode, BFD Echo packets MUST NOT be transmitted when
| bfd.SessionState is not Up, and BFD Echo packets MUST NOT be
| transmitted unless the last BFD Control packet received from the
| remote system contains a nonzero value in Required Min Echo RX
| Interval.
|
| When a system is using the Echo function with either Asynchronous
| or Demand mode, BFD Echo packets MAY be transmitted when
| bfd.SessionState is Up, and the interval between transmitted BFD
| Echo packets MUST NOT be less than the value advertised by the
| remote system in Required Min Echo RX Interval, except as follows:
| [...]
-->
<t>OLD TEXT</t>
<blockquote>BFD Echo packets <bcp14>MUST NOT</bcp14> be transmitted when
bfd.SessionState is not Up. BFD Echo packets <bcp14>MUST NOT</bcp14> be
transmitted unless the last BFD Control packet received from the remote
system contains a nonzero value in Required Min Echo RX Interval.</blockqu
ote>
<t>NEW TEXT</t>
<blockquote>When a system is using the Echo function with either
Asynchronous or Demand mode, BFD Echo packets <bcp14>MUST NOT</bcp14> be
transmitted when bfd.SessionState is not Up, and BFD Echo packets
<bcp14>MUST NOT</bcp14> be transmitted unless the last BFD Control
packet received from the remote system contains a nonzero value in
Required Min Echo RX Interval.</blockquote>
<t>OLD TEXT</t>
<blockquote>BFD Echo packets <bcp14>MAY</bcp14> be transmitted when
bfd.SessionState is Up. The interval between transmitted BFD Echo
packets <bcp14>MUST NOT</bcp14> be less than the value advertised by the
remote system in Required Min Echo RX Interval...</blockquote>
<t>NEW TEXT</t>
<blockquote>When a system is using the Echo function with either
Asynchronous or Demand mode, BFD Echo packets <bcp14>MAY</bcp14> be
transmitted when bfd.SessionState is Up, and the interval between
transmitted BFD Echo packets <bcp14>MUST NOT</bcp14> be less than the
value advertised by the remote system in Required Min Echo RX
Interval...</blockquote>
</section>
<section>
<name>Operational Considerations</name>
<t>
All operational considerations from <xref target="RFC5880"/> apply. Since th
is mechanism leverages existing BFD machinery,
particularly periodic pacing of traffic based on configuration, there's n
o real possibility to create congestion.
<!--[rfced] Please clarify this sentence, in particular,
"would be counter productive to check".
Original:
Moreover, creating congestion would be counter
productive to check the bidirectional connectivity.
Perhaps:
Moreover, creating congestion would be
counterproductive to checking the bidirectional connectivity.
-->
Moreover,
creating congestion would be counterproductive to check the bidirectional
connectivity.
</t>
<t>
Some devices that would benefit from the use of BFD may be unable to support the full BFD protocol. Examples of such Some devices that would benefit from the use of BFD may be unable to support the full BFD protocol. Examples of such
devices include servers running virtual machines, or Internet of Things ( IoT) devices. By using Unaffiliated BFD devices include servers running virtual machines, or Internet of Things ( IoT) devices. By using Unaffiliated BFD
Echo, these devices only need to support a basic loopback function. Echo, these devices only need to support a basic loopback function.
</t> </t>
<t> <t>
As specified in Section 2 of this document, some configuration is needed to As specified in <xref target="unaffiliated-bfd-echo-procedures"/> of this do
make the Unaffiliated BFD Echo work, cument, some configuration is needed to make the Unaffiliated BFD Echo work,
although the configuration won't go beyond the scope of <xref target="RFC although the configuration won't go beyond the scope of <xref target="RFC
5880"/>. At a BFD-enabled local system, the 5880"/>.
Unaffiliated BFD Echo session can coexist with other type of BFD session, <!--[rfced] FYI, we updated this sentence to three sentences as follows;
in which scenario the remote system for the please review whether the text conveys the intended meaning. In
Unaffiliated BFD Echo session must be different from the remote system fo particular, please review whether "other BFD system" was intended as
r other type of BFD session, and the local singular (as below) or plural (perhaps you intended "coexist with
system's discriminators for different BFD sessions must be different, at other types of BFD sessions").
the same time it's not necessary for the local
system to differentiate the Unaffiliated BFD Echo session from other type
of BFD session.
</t>
</section>
<section title="Security Considerations"> Original:
At a BFD-
enabled local system, the Unaffiliated BFD Echo session can coexist
with other type of BFD session, in which scenario the remote system
for the Unaffiliated BFD Echo session must be different from the
remote system for other type of BFD session, and the local system's
discriminators for different BFD sessions must be different, at the
same time it's not necessary for the local system to differentiate
the Unaffiliated BFD Echo session from other type of BFD session.
<t> Current:
All Security Considerations from <xref target="RFC5880"/> and <xref targe At a BFD-
t="RFC5881"/> apply. enabled local system, the Unaffiliated BFD Echo session can coexist
</t> with another type of BFD session. In that scenario, the remote
<t> system for the Unaffiliated BFD Echo session must be different from
the remote system for the other type of BFD session, and the local
system's discriminators for different BFD sessions must be different.
At the same time, it's not necessary for the local system to
differentiate the Unaffiliated BFD Echo session from the other type
of BFD session.
-->
At a BFD-enabled local system, the
Unaffiliated BFD Echo session can coexist with another type of BFD sessio
n. In that scenario, the remote system for the
Unaffiliated BFD Echo session must be different from the remote system fo
r the other type of BFD session, and the local
system's discriminators for different BFD sessions must be different. At
the same time, it's not necessary for the local
system to differentiate the Unaffiliated BFD Echo session from the other
type of BFD session.
</t>
</section>
<section>
<name>Security Considerations</name>
<t>
All security considerations from <xref target="RFC5880"/> and <xref targe
t="RFC5881"/> apply.
</t>
<t>
Unaffiliated BFD Echo requires the remote device to loop Unaffiliated BFD Echo packets. In order to provide this Unaffiliated BFD Echo requires the remote device to loop Unaffiliated BFD Echo packets. In order to provide this
service, the remote device cannot make use of Unicast Strict Reverse Path Forwarding (RPF) <xref target="RFC3704"/>, service, the remote device cannot make use of Unicast Strict Reverse Path Forwarding (RPF) <xref target="RFC3704"/>,
otherwise the Unaffiliated BFD Echo packets might not pass the RPF check at the remote device. otherwise the Unaffiliated BFD Echo packets might not pass the RPF check at the remote device.
</t> </t>
<t> <t>
As described in Section 5 of <xref target="RFC5880"/>, BFD Echo packets m As described in <xref section="5" sectionFormat="of" target="RFC5880"/>,
ay be spoofed. Specifically for Unaffiliated BFD Echo packets may be spoofed. Specifically for Unaffiliated
BFD Echo, a DoS attacker may send spoofed Unaffiliated BFD Echo packets t BFD Echo, a DoS attacker may send spoofed Unaffiliated BFD Echo packets t
o the loop-back device, so some form of o the loopback device, so some form of
authentication SHOULD be included. Considering the Unaffiliated BFD Echo authentication <bcp14>SHOULD</bcp14> be included. Considering the Unaffil
packets in this document are also BFD iated BFD Echo packets in this document are also BFD
Control packets, the "Authentication Section" as defined in <xref target= Control packets, the "Authentication Section" as defined in <xref target=
"RFC5880"/> for BFD Control packet is "RFC5880"/> for a BFD Control packet is
RECOMMENDED to be included within the Unaffiliated BFD Echo packet. <bcp14>RECOMMENDED</bcp14> to be included within the Unaffiliated BFD Ech
</t> o packet.
<t> </t>
As stated in Section 2, in order to avoid unset values being a potential <t>
vector for disclosure of uninitialized As stated in <xref target="unaffiliated-bfd-echo-procedures"/>, in order
memory, all fields of the Unaffiliated BFD Echo packet MUST be populated to avoid unset values being a potential vector for disclosure of uninitialized
with a certain value, even if some of the memory, all fields of the Unaffiliated BFD Echo packet <bcp14>MUST</bcp14
> be populated with a certain value, even if some of the
fields are ignored on receipt. fields are ignored on receipt.
</t> </t>
</section> </section>
<section>
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t> This document has no IANA action requested.</t> <t> This document has no IANA actions.</t>
</section> </section>
<section title="Acknowledgements"> </middle>
<t> The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky, San <back>
tosh Pallagatti, Aijun Wang, Eric Vyncke,
Adrian Farrel, Tim Wicinski, Dhruv Dhody, Stephen Farrell, Gunter Van de
Velde, Gyan Mishra, Brian Trammell, Gorry Fairhurst,
Mahesh Jethanandani, John Scudder, Murray Kucherawy, and Zaheduzzaman Sar
ker for their careful review and very helpful comments.</t>
<t> The authors would like to acknowledge Jeff Haas for his guidance, insigh
tful review, and very helpful comments.</t>
<t> The authors would like to acknowledge Erik Auerswald for his insightful
comments during the discussion of this document.</t>
<t> The authors would like to acknowledge Detao Zhao for the very helpful di
scussion.</t>
</section>
<section title="Contributors"> <references>
<t>Liu Aihua<br/>ZTE<br/>Email: liu.aihua@zte.com.cn</t> <name>References</name>
<t>Qian Xin<br/>ZTE<br/>Email: qian.xin2@zte.com.cn</t> <references>
<t>Zhao Yanhua<br/>ZTE<br/>Email: zhao.yanhua3@zte.com.cn</t> <name>Normative References</name>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
880.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
881.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
704.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
082.xml"/>
</middle> <!-- [rfced] FYI, we have updated this reference to match
what was available at the URL, as shown below.
<back> For the URL, would you prefer to use the original
(A) https://www.broadband-forum.org/technical/download/TR-146.pdf
(which redirects to a wiki page titled "Broadband Forum Published
Resources") or
(B) https://www.broadband-forum.org/pdfs/tr-146-1-0-0.pdf
(which is the document itself)?
<references title="Normative References"> Original:
<?rfc include="reference.RFC.2119"?> [BBF-TR-146]
<?rfc include="reference.RFC.8174"?> Broadband Forum, "BBF Technical Report - Subscriber
<?rfc include="reference.RFC.5880"?> Sessions Issue 1", 2013, <https://www.broadband-
<?rfc include="reference.RFC.5881"?> forum.org/technical/download/TR-146.pdf>.
Current:
[BBF-TR-146]
Broadband Forum, "TR-146: Subscriber Sessions", Broadband
Forum Technical Report, TR-146, Issue 1, May 2013,
<https://www.broadband-forum.org/technical/download/TR-
146.pdf>.
-->
<reference anchor="BBF-TR-146" target="https://www.broadband-forum.org/t
echnical/download/TR-146.pdf">
<front>
<title>TR-146: Subscriber Sessions</title>
<author>
<organization>Broadband Forum</organization>
</author>
<date month="May" year="2013"/>
</front>
<refcontent>Broadband Forum Technical Report, TR-146, Issue 1</refconte
nt>
</reference>
</references>
</references> </references>
<references title="Informative References"> <section numbered="false">
<?rfc include="reference.RFC.3704"?> <name>Acknowledgements</name>
<?rfc include="reference.RFC.5082"?>
<reference anchor="BBF-TR-146"
target="https://www.broadband-forum.org/technical/download/TR-1
46.pdf">
<front>
<title>BBF Technical Report - Subscriber Sessions Issue 1</title>
<author> <t> The authors would like to acknowledge <contact fullname="Ketan
<organization>Broadband Forum</organization> Talaulikar"/>, <contact fullname="Greg Mirsky"/>, <contact
</author> fullname="Santosh Pallagatti"/>, <contact fullname="Aijun Wang"/>,
<contact fullname="Éric Vyncke"/>, <contact fullname="Adrian Farrel"/>,
<contact fullname="Tim Wicinski"/>, <contact fullname="Dhruv Dhody"/>,
<contact fullname="Stephen Farrell"/>, <contact fullname="Gunter Van de Ve
lde"/>, <contact fullname="Gyan Mishra"/>, <contact fullname="Brian Trammell"/>,
<contact fullname="Gorry Fairhurst"/>, <contact
fullname="Mahesh Jethanandani"/>, <contact fullname="John Scudder"/>,
<contact fullname="Murray Kucherawy"/>, and <contact
fullname="Zaheduzzaman Sarker"/> for their careful reviews and very
helpful comments.</t>
<t> The authors would like to acknowledge <contact fullname="Jeff Haas"/>
for his guidance, insightful review, and very helpful
comments.</t>
<t> The authors would like to acknowledge <contact fullname="Erik Auerswal
d"/> for his insightful comments during the discussion of this
document.</t>
<t> The authors would like to acknowledge <contact fullname="Detao Zhao"/>
for the very helpful discussion.</t>
</section>
<date year="2013"/> <section numbered="false">
</front> <name>Contributors</name>
</reference> <contact fullname="Liu Aihua">
</references> <organization>ZTE</organization>
<address>
<email>liu.aihua@zte.com.cn</email>
</address>
</contact>
<contact fullname="Qian Xin">
<organization>ZTE</organization>
<address>
<email>qian.xin2@zte.com.cn</email>
</address>
</contact>
<contact fullname="Zhao Yanhua">
<organization>ZTE</organization>
<address>
<email>zhao.yanhua3@zte.com.cn</email>
</address>
</contact>
</section>
</back>
<!-- [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. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back>
</rfc> </rfc>
 End of changes. 102 change blocks. 
555 lines changed or deleted 689 lines changed or added

This html diff was produced by rfcdiff 1.48.