rfc9978xml2.original.xml   rfc9978.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?> <!DOCTYPE rfc [
<?rfc sortrefs="yes" ?> <!ENTITY nbsp "&#160;">
<?rfc tocompact="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocdepth="3"?> <!ENTITY nbhy "&#8209;">
<?rfc tocindent="yes"?> <!ENTITY wj "&#8288;">
<?rfc comments="yes"?> ]>
<?rfc inline="yes"?>
<?rfc compact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie
<?rfc subcompact="no"?> tf-bfd-stability-21" number="9978" updates="" obsoletes="" ipr="trust200902" con
<rfc sensus="true" submissionType="IETF" tocInclude="true" symRefs="true" sortRefs="t
category="exp" rue" tocDepth="3" version="3" xml:lang="en">
docName="draft-ietf-bfd-stability-21"
ipr="trust200902" <!-- [rfced] We have updated the title as shown below. Please let us know if an
consensus="true" y changes are required.
submissionType="IETF">
Original:
BFD Stability
Current:
Bidirectional Forwarding Detection (BFD) Stability
-->
<front> <front>
<title abbrev="BFD Stability">BFD Stability</title> <title abbrev="BFD Stability">Bidirectional Forwarding Detection (BFD) Stabi
lity</title>
<seriesInfo name="RFC" value="9978"/>
<author fullname="Ashesh Mishra" initials="A" surname="Mishra"> <author fullname="Ashesh Mishra" initials="A" surname="Mishra">
<organization>Aalyria Technologies</organization> <organization>Aalyria Technologies</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<email>ashesh@aalyria.com</email> <email>ashesh@aalyria.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Mahesh Jethanandani" initials="M" surname="Jethanandani">
<author fullname="Mahesh Jethanandani"
initials="M"
surname="Jethanandani">
<organization>Arrcus, Inc.</organization> <organization>Arrcus, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<city/>
<region/>
<code/>
<country>USA</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>mjethanandani@gmail.com</email> <email>mjethanandani@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Ankur Saxena" initials="A" surname="Saxena"> <author fullname="Ankur Saxena" initials="A" surname="Saxena">
<organization>Ciena Corporation</organization> <organization>Ciena Corporation</organization>
<address> <address>
<postal> <postal>
<street>3939 North 1st Street</street> <street>3939 North 1st Street</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>ankurpsaxena@gmail.com</email> <email>ankurpsaxena@gmail.com</email>
<uri>www.ciena.com</uri> <uri>www.ciena.com</uri>
</address> </address>
</author> </author>
<author fullname="Santosh Pallagatti" initials="S" surname="Pallagatti"> <author fullname="Santosh Pallagatti" initials="S" surname="Pallagatti">
<organization>Zscaler</organization> <organization>Zscaler</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560103</code> <code>560103</code>
<country>India</country> <country>India</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>santosh.pallagatti@gmail.com</email> <email>santosh.pallagatti@gmail.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Mach Chen" initials="M" surname="Chen"> <author fullname="Mach Chen" initials="M" surname="Chen">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>mach.chen@huawei.com</email> <email>mach.chen@huawei.com</email>
<uri/>
</address> </address>
</author> </author>
<date/> <date month="May" year="2026"/>
<area>RTG</area>
<workgroup>bfd</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t> <t>
This document describes extensions to the Bidirectional This document describes extensions to the Bidirectional
Forwarding Detection (BFD) protocol to measure BFD Forwarding Detection (BFD) protocol to measure BFD
stability. Specifically, it describes a mechanism for stability. Specifically, it describes a mechanism for
the detection of BFD packet loss.</t> the detection of BFD packet loss.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section>
<t>The Bidirectional Forwarding Detection (<xref <name>Introduction</name>
target="RFC5880">BFD)</xref> protocol operates by transmitting and
receiving BFD control packets, generally at high frequency, over the
datapath being monitored. In order to prevent significant data loss due
to a datapath failure, BFD session detection time as defined in <xref
target="RFC5880">BFD</xref> is set to the smallest feasible value.</t>
<t>The Bidirectional Forwarding Detection (BFD) <xref target="RFC5880"/> p
rotocol operates by transmitting and
receiving BFD control packets, generally at a high frequency, over the
datapath being monitored. In order to prevent significant data loss due
to a datapath failure, BFD session Detection Time as defined in <xref targ
et="RFC5880"/> is set to the smallest feasible value.</t>
<t> <t>
A <xref target="RFC5880">BFD</xref> session will remain in the A BFD session will remain in the Up state as long as it receives at
Up state as long as it receives at least one BFD packet within the least one BFD packet within the Detection Time interval. However,
Detection Time interval. However, additional packet loss additional packet loss within that time interval is not noted by the
within that time interval is not noted by the BFD state BFD state machinery. Noting the other missed packets provides a
machinery. Noting the other missed packets provides a valuable valuable indicator of systemic issues or a deteriorating network that
indicator of systemic issues or a deteriorating network that
may warrant preventive action. may warrant preventive action.
</t> </t>
<!-- [rfced] In the text below, may we replace "in addition to" with a verb
(such as "describes" or similar) to clarify the purpose of the document?
Original:
This document proposes an experimental mechanism to detect lost
packets in a BFD session in addition to the datapath fault detection
mechanisms of BFD.
Perhaps:
This document proposes an experimental mechanism to detect lost
packets in a BFD session and describes the datapath fault detection
mechanisms of BFD.
-->
<!-- [rfced] In the instances below, may we update "received-packet-count" to
"receive-packet-count" to match usage in RFC 9314?
Original (Introduction):
Such a mechanism, combined with 'received-packet-count' defined in
the YANG Data Model for Bidrectional Forward Detection (BFD) [RFC9314]
permits operators to measure the stability of BFD sessions.
Original (Appendix A):
The experiment will use the packet lost count
and the 'received-packet-count' defined in the YANG Data Model for
Bidirectional Forward Detection (BFD) [RFC9314] to determine how
stable is the session.
-->
<t> <t>
This document proposes an experimental mechanism to detect This document proposes an experimental mechanism to detect
lost packets in a BFD session in addition to the datapath lost packets in a BFD session in addition to the datapath
fault detection mechanisms of BFD. Such a mechanism, combined fault detection mechanisms of BFD. Such a mechanism, combined
with 'received-packet-count' defined in the <xref with 'received-packet-count' defined in "YANG Data Model for Bidirectiona
target="RFC9314">YANG Data Model for Bidrectional Forward l Forwarding Detection (BFD)" <xref target="RFC9314"/> permits operators to meas
Detection (BFD)</xref> permits operators to measure the ure the
stability of BFD sessions. The details of the motivation for stability of BFD sessions. The details of the motivation for
experimental status can be found in <xref the Experimental status of this document can be found in <xref target="ex
target="experimental-status"/>. Implementations may also do perimental-status"/>. Implementations may also do
additional analysis of the packet loss over a time additional analysis of the packet loss over a time
interval. Such an analysis is outside the scope of this interval. Such an analysis is outside the scope of this
document. document.
</t> </t>
<t> <t>
This document does not propose any BFD extension to measure This document does not propose any BFD extension to measure
data traffic loss or delay on a link or tunnel, and the scope data traffic loss or delay on a link or tunnel, and the scope
is limited to BFD packets. is limited to BFD packets.
</t> </t>
<section title="Note to the RFC Editor">
<t>
This document uses several placeholder values throughout the
document. Please replace them as follows and remove this
section before publication.
</t>
<t>
RFC XXXX, where XXXX is the number assigned to this document
at the time of publication.
</t>
<t>
2025-10-30, with the actual date of the publication of this
document.
</t>
</section>
</section> </section>
<section>
<section title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in <xref "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
target="RFC2119">RFC 2119</xref> and <xref target="RFC8174">RFC ",
8174</xref>.</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t> <t>
The reader is expected to be familiar with the <xref The reader is expected to be familiar with BFD <xref target="RFC5880"/>.
target="RFC5880">BFD</xref>. In particular, the term In particular, the term
'meticulous' specified in <xref "meticulous" as specified in "Meticulous Keyed ISAAC for BFD Optimized Au
target="I-D.ietf-bfd-secure-sequence-numbers">Meticulous Keyed thentication" <xref target="I-D.ietf-bfd-secure-sequence-numbers"/> means that t
ISAAC for BFD Optimized Authentication</xref> means that the he
Sequence number is incremented on every new packet that is sequence number is incremented on every new packet that is
sent. sent.
</t> </t>
</section> </section>
<section>
<section title="Use Cases"> <name>Use Cases</name>
<t> <t>
Bidirectional Forwarding Detection, as defined in <xref Bidirectional Forwarding Detection (BFD), as defined in <xref target="RFC
target="RFC5880">BFD</xref> cannot detect any BFD packet loss 5880"/>, cannot detect any BFD packet loss
if the loss does not last for the Detection Time. This if the loss does not last for the Detection Time. This
document proposes a method to detect dropped packets on the document proposes a method to detect dropped packets on the
receiver. For example, if the receiver receives BFD control receiver. For example, if the receiver receives BFD control
packet k at time t but receives packet k+3 at time t+10ms, and packet k at time t, but receives packet k+3 at time t+10 ms, and
never receives packet k+1 and/or k+2, then it has experienced never receives packet k+1 and/or k+2, then it has experienced
a packet loss. a packet loss.
</t> </t>
<!-- [rfced] FYI - For readability, we broke the text below into two
separate sentences. Please review.
Original:
This proposal enables BFD implementations to generate diagnostic
information on the health of each BFD session that could be used to
preempt probability of a failure on a datapath that BFD was
monitoring by allowing time for a corrective action to be taken.
Current:
This proposal enables BFD implementations to generate diagnostic
information on the health of each BFD session. This information could be used
to preempt the probability of a failure on a datapath that BFD was
monitoring by allowing time for a corrective action to be taken.
-->
<t>This proposal enables BFD implementations to generate <t>This proposal enables BFD implementations to generate
diagnostic information on the health of each BFD session that diagnostic information on the health of each BFD session. This informatio
could be used to preempt probability of a failure on a n
could be used to preempt the probability of a failure on a
datapath that BFD was monitoring by allowing time for a datapath that BFD was monitoring by allowing time for a
corrective action to be taken. corrective action to be taken.
</t> </t>
<t> <t>
In a faulty datapath scenario, an operator can use BFD health In a faulty datapath scenario, an operator can use BFD health
information to trigger the delay and loss measurement OAM information to trigger the delay and loss measurement Operations, Adminis
protocol <xref target="Y-1731">Connectivity Fault Management tration, and Maintenance (OAM)
(CFM)</xref> or <xref target="RFC6374">Packet Loss and Delay protocol Connectivity Fault Management
Measurement for MPLS Networks</xref> to further isolate the (CFM) <xref target="Y-1731"/> or packet loss and delay measurement for MP
LS networks <xref target="RFC6374"/> to further isolate the
issue. issue.
</t> </t>
</section> </section>
<section>
<name>Functionality</name>
<!-- [rfced] Does "BFD Meticulous" refer "Meticulous Keyed MD5", as registered b
y IANA? Should the text be udpated to refer to march the IANA name?
See <https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml#bfd-pa
rameters-2>.
Original:
BFD stability measurement requires that a BFD Meticulous
Authentication type is configured.
-->
<section title="Functionality">
<t> <t>
BFD stability measurement requires that a BFD Meticulous Authentication BFD stability measurement requires that a BFD Meticulous authentication
type is configured. type be configured.
</t> </t>
<t> <t>
The ietf-bfd-stability YANG model, defined in this document, provides The "ietf-bfd-stability" YANG data model, defined in this document, prov
the ability to configure BFD stability measurement for BFD sessions by ides
configuring the 'stability' flag. The 'lost-packet-count' leaf permits the ability to configure the BFD stability measurement for BFD sessions
by
configuring the 'stability' flag. The 'lost&nbhy;packet&nbhy;count' leaf
permits
monitoring of stability issues as defined in this document for BFD monitoring of stability issues as defined in this document for BFD
sessions that have the stability flag enabled. sessions that have the 'stability' flag enabled.
</t> </t>
<t> <t>
The configuration of BFD stability measurement and monitoring using The configuration of the BFD stability measurement and monitoring using
other methods than the attached YANG model is out of scope from this other methods than the attached YANG data model is out of scope of this
document. document.
</t> </t>
</section> </section>
<!-- [rfced] FYI - We have removed "BFD" from the text below for clarity,
because we believe it was meant to function as a citation (rather than a
part of the sentence's meaning). Please review to confirm this change is
accurate.
<section anchor="null-auth-type" title="NULL Auth Type"> Original:
The NULL Authentication Type, defined in this document, can be used
to provide a meticulously increasing sequence number BFD [RFC5880]
for stability measurement.
Current:
The NULL authentication type, defined in this document, can be used
to provide a meticulously increasing sequence number [RFC5880]
for stability measurement.
-->
<section anchor="null-auth-type">
<name>NULL Auth Type</name>
<t> <t>
The NULL Authentication Type, defined in this document, can be The NULL authentication type, defined in this document, can be
used to provide a meticulously increasing sequence number used to provide a meticulously increasing sequence number
<xref target="RFC5880">BFD</xref> for stability measurement. BFD <xref target="RFC5880"/> for stability measurement.
It provides none of the protections desired for authentication It provides none of the protections desired for authentication
and is used only to provide BFD stability services to BFD and is used only to provide BFD stability services to BFD
sessions that otherwise have no authentication in use.</t> sessions that otherwise have no authentication in use.</t>
<t>If the Authentication Present (A) bit is set in the header <t>If the Authentication Present (A) bit is set in the header
as defined in <xref target="RFC5880" section="4">BFD</xref>, as defined in <xref target="RFC5880" sectionFormat="of" section="4"/>,
and the Authentication Type field contains TBD, the and the Authentication Type field contains 6, the
Authentication section has the following format: Authentication Section has the following format:
<figure
align="center" title="NULL Auth Type">
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
where:
</t>
<t>Auth Type (8 bits): The Authentication Type, which in this
case is TBD (NULL, to be assigned by IANA, with a suggested
value of 6).
</t>
<t>Auth Len (8 bits): The length of the NULL Auth Type, in bytes;
i.e., 8 bytes
</t>
<t>Auth Key ID (8 bits): The authentication key ID in use for this
packet. MUST be set to zero and MUST be ignored on receipt.
</t> </t>
<figure>
<name>NULL Auth Type</name>
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Reserved (8 bits): This byte MUST be set to zero on transmit <t>where:</t>
and MUST be ignored on receipt.
</t>
<t>Sequence Number (32 bits): The sequence number for this <dl spacing="normal" newline="false">
<dt>Auth Type (8 bits):</dt><dd>The Authentication Type, which in this
case is 6 (NULL).</dd>
<dt>Auth Len (8 bits):</dt><dd>The length of the NULL Auth Type in bytes
(i.e., 8 bytes).</dd>
<dt>Auth Key ID (8 bits):</dt><dd>The authentication key ID in use for th
is
packet. It <bcp14>MUST</bcp14> be set to zero and <bcp14>MUST</bcp14> be
ignored on receipt.</dd>
<dt>Reserved (8 bits):</dt><dd>This byte <bcp14>MUST</bcp14> be set to ze
ro on transmit
and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>Sequence Number (32 bits):</dt><dd>The sequence number for this
packet. This value is incremented for each successive packet packet. This value is incremented for each successive packet
transmitted for a session. Implementations will use sequence transmitted for a session. Implementations will use sequence
numbers (bfd.XmitAuthSeq) as defined in <xref numbers (bfd.XmitAuthSeq) as defined in <xref target="RFC5880"/>.</dd>
target="RFC5880">BFD</xref>. </dl>
</t>
<t> <t>
If bfd.AuthSeqKnown is 1, and the received Sequence Number If bfd.AuthSeqKnown is 1, and the received Sequence Number
field is not equal to bfd.RcvAuthSeq + 1 (in a circular number field is not equal to bfd.RcvAuthSeq + 1 (in a circular number
space), then the loss count is incremented by the difference space), then the loss count is incremented by the difference
between the received Sequence Number and bfd.RcvAuthSeq and between the received sequence number and bfd.RcvAuthSeq, and
bfd.RcvAuthSeq is set to the received Sequence Number. bfd.RcvAuthSeq is set to the received sequence number.
</t> </t>
<t> <t>
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown <bcp14>MUST</bcp14> b
set to 1, and bfd.RcvAuthSeq MUST be set to the value of the e
received Sequence Number field as defined in <xref set to 1, and bfd.RcvAuthSeq <bcp14>MUST</bcp14> be set to the value of t
target="RFC5880" sectionFormat="comma" he
section="6.8.1">BFD</xref>, and the packet MUST received Sequence Number field as defined in <xref target="RFC5880" secti
onFormat="comma" section="6.8.1"/>, and the packet <bcp14>MUST</bcp14>
be accepted. be accepted.
</t> </t>
<t> <t>
According to <xref target="RFC5880" sectionFormat="comma" According to <xref target="RFC5880" sectionFormat="of" section="6.7.3"/>,
section="6.7.3">BFD</xref> a receiver MUST discard a received a receiver <bcp14>MUST</bcp14> discard a received
packet that lies outside the range of bfd.RcvAuthSeq and packet that lies outside the range of bfd.RcvAuthSeq and
bfd.RcvAuthSeq + (3 * Detect Multi). If it is within that bfd.RcvAuthSeq + (3 * Detect Multi). If it is within that
range, but is missing a packet, it can be used to detect a range, but is missing a packet, it can be used to detect a
loss. In case of NULL authentication where packets containing loss. In case of NULL authentication where packets containing
sequence numbers are accepted on receipt, an attacker with sequence numbers are accepted on receipt, an attacker with an
unauthenticated sequence number could move the Sequence Number unauthenticated sequence number could move the sequence number
forward. Meanwhile, the actual BFD neighbor that continues to forward. Meanwhile, the actual BFD neighbor that continues to
send packets will find them discarded and the session would send packets will find them discarded and the session would
drop. To prevent such an attack, the received Sequence Number drop. To prevent such an attack, the received sequence number
MUST NOT be compared with bfd.RcvAuthSeq for purposes of <bcp14>MUST NOT</bcp14> be compared with bfd.RcvAuthSeq for the purpose o
f
discarding the BFD packets. discarding the BFD packets.
</t> </t>
</section> </section>
<section>
<section title="Theory of Operation"> <name>Theory of Operation</name>
<t>This mechanism allows operators to measure the loss of BFD control <t>This mechanism allows operators to measure the loss of BFD control
packets. A BFD authentication type carrying a meticulously increasing packets. A BFD authentication type carrying a meticulously increasing
sequence number is required to support this loss measurement. sequence number is required to support this loss measurement.
Authentication types that provide for meticulously increasing sequence Authentication types that provide for meticulously increasing sequence
numbers include:</t> numbers include:</t>
<ul> <ul>
<li> <li>
Meticulously Keyed MD5 and SHA1, defined in Meticulously Keyed MD5 and SHA1, defined in
<xref target="RFC5880"/>. <xref target="RFC5880"/>.
</li> </li>
<li> <li>
Meticulously Keyed ISAAC, defined in Meticulously Keyed ISAAC, defined in
<xref target="I-D.ietf-bfd-secure-sequence-numbers"/>. <xref target="I-D.ietf-bfd-secure-sequence-numbers"/>.
</li> </li>
<li> <li>
The NULL authentication mechanism, which does not provide for The NULL authentication mechanism, which does not provide for
authentication but carries a meticulously increasing sequence number, authentication but carries a meticulously increasing sequence number, and is
defined in this document. defined in this document.
</li> </li>
</ul> </ul>
<t> <t>
Other authentication types that provide for meticulously increasing Other authentication types that provide for meticulously increasing
sequence numbers appropriate for this mechanism may be defined in future sequence numbers appropriate for this mechanism may be defined in future
specifications. specifications.
</t> </t>
<section>
<section title="Loss Measurement"> <name>Loss Measurement</name>
<t> <t>
Loss measurement counts the number of BFD control packets Loss measurement counts the number of BFD control packets
missed at the receiver during any Detection Time <xref missed at the receiver during any Detection Time period <xref target="R
target="RFC5880" section="6.8.4" FC5880" section="6.8.4" sectionFormat="comma"/>. The loss is detected
sectionFormat="comma">BFD</xref> period. The loss is detected
by comparing the Sequence Number field in successive BFD by comparing the Sequence Number field in successive BFD
control packets. The Sequence Number in each successive control packets. The sequence number in each successive
control packet generated on a BFD session by the transmitter control packet generated on a BFD session by the transmitter
is incremented by one. This loss count can then be exposed is incremented by one. This loss count can then be exposed
using the YANG module defined in the subsequent section. See using the YANG module defined in the subsequent section. See
discussion on <xref target="out-of-order-packets">Out of discussion on out-of-order packets in <xref target="out-of-order-packet
Order Packets</xref> later in the document. s"/> of this document.
</t> </t>
<t> <t>
The first BFD authentication section with a non-zero The first BFD Authentication Section with a non-zero
sequence number, in a valid BFD control packet, processed by sequence number, in a valid BFD control packet, processed by
the receiver, is used for bootstrapping the logic. the receiver, is used for bootstrapping the logic.
</t> </t>
</section> </section>
<section anchor="out-of-order-packets">
<section anchor="out-of-order-packets" title="Out of Order Packets"> <name>Out-of-Order Packets</name>
<t> <t>
Some transmission mechanisms - for example, Link Aggregate Groups Some transmission mechanisms, for example, Link Aggregate Groups
(LAG), or Equal Cost Multipath (ECMP) - can result in out of order (LAGs) or Equal Cost Multipath (ECMP), can result in out-of-order
packet delivery. In circumstances where BFD packets are not lost, but packet delivery. In circumstances where BFD packets are not lost, but
are delivered out of order, strict comparison of increasing sequence are delivered out of order, strict comparison of increasing sequence
numbers may result in classifying the out of order packets as packet numbers may result in classifying the out-of-order packets as packet
loss. loss.
</t> </t>
<t> <t>
Implementations MAY provide mechanisms wherein all expected Implementations <bcp14>MAY</bcp14> provide mechanisms wherein all expec
ted
packets received across an expected interval, but delivered packets received across an expected interval, but delivered
out of order are not considered lost packets. out of order, are not considered lost packets.
</t> </t>
</section> </section>
</section> </section>
<section anchor="yang-module">
<name>Stability YANG Module</name>
<section anchor="data-model-overview">
<section anchor="yang-module" title="Stability YANG Module"> <!-- [rfced] What does "lsp" refer to in the text below? How may we clarify
<section anchor="data-model-overview" title="Data Model Overview"> how it relates to the rest of the sentence?
Original:
In addition, a loss count per-session or lsp for BFD packets that are lost
has also been added in this model.
-->
<name>Data Model Overview</name>
<t> <t>
This YANG module augments the base BFD YANG module to add This YANG module augments the base BFD YANG module to add
attributes such as the flag 'stability' related attributes such as the 'stability' flag related
to the experiment of BFD Stability. The feature statement to the experiment of BFD stability. The feature statement
'stability' needs to be enabled to indicate that BFD 'stability' needs to be enabled to indicate that BFD
Stability is supported by the implementation. In addition, a stability is supported by the implementation. In addition, a
loss count per-session or lsp for BFD packets that are lost loss count per-session or lsp for BFD packets that are lost
has also been added in this model. has also been added in this model.
</t> </t>
<sourcecode type="yangtree"><![CDATA[
<t>
<figure>
<artwork><![CDATA[
module: ietf-bfd-stability module: ietf-bfd-stability
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session: /bfd-ip-sh:sessions/bfd-ip-sh:session:
+--rw stability? boolean {stability}? +--rw stability? boolean {stability}?
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh /rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
/bfd-ip-mh:session-groups/bfd-ip-mh:session-group: /bfd-ip-mh:session-groups/bfd-ip-mh:session-group:
+--rw stability? boolean {stability}? +--rw stability? boolean {stability}?
skipping to change at line 448 skipping to change at line 450
+--ro lost-packet-count? yang:counter64 {stability}? +--ro lost-packet-count? yang:counter64 {stability}?
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-lag:lag /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
/bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links /bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links
/bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics: /bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics:
+--ro lost-packet-count? yang:counter64 {stability}? +--ro lost-packet-count? yang:counter64 {stability}?
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls /rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
/bfd-mpls:session-groups/bfd-mpls:session-group /bfd-mpls:session-groups/bfd-mpls:session-group
/bfd-mpls:sessions/bfd-mpls:session-statistics: /bfd-mpls:sessions/bfd-mpls:session-statistics:
+--ro lost-packet-count? yang:counter64 {stability}? +--ro lost-packet-count? yang:counter64 {stability}?]]></sourcecode>
]]>
</artwork>
</figure>
</t>
</section> </section>
<section>
<name>YANG Module</name>
<section title="YANG Module"> <!-- [rfced] Section 7.2: We note that RFC 8177 ("YANG Data Model for Key
<t> Chains") is referenced in the YANG module that appears in this section, but it
This YANG module imports modules defined in <xref is not included in the references section of this document or in the text that
target="RFC6991">Common YANG Types</xref>, <xref introduces this YANG module (see below).
target="RFC8349">A YANG Data Model for Routing</xref>, and
<xref target="RFC9314">YANG Data Model for Bidirectional May we add a reference to RFC 8177 in the references section and in the text
Forwading Detection (BFD)</xref>. below?
</t>
Original:
This YANG module imports modules defined in Common YANG Types
[RFC6991], A YANG Data Model for Routing [RFC8349], and YANG Data
Model for Bidirectional Forwading Detection (BFD) [RFC9314].
Perhaps:
This YANG module imports modules defined in "Common YANG Data Types"
[RFC6991], "YANG Data Model for Key Chains" [RFC8177], "A YANG Data Model for
Routing Management (NMDA Version)" [RFC8349], and "YANG Data Model for
Bidirectional Forwarding Detection (BFD)" [RFC9314].
-->
<t> <t>
<figure> This YANG module imports modules defined in "Common YANG Data Types" <x
<artwork><![CDATA[ ref target="RFC6991"/>, "A YANG Data Model for Routing Management (NMDA Version)
<CODE BEGINS> file "ietf-bfd-stability@2025-10-30.yang" " <xref target="RFC8349"/>, and "YANG Data Model for Bidirectional Forwarding De
tection (BFD)" <xref target="RFC9314"/>.
</t>
<!-- [rfced] We have updated the YANG module to match the format output when usi
ng the formatting option of pyang. See the formatting (only) updates in this fi
le:
https://www.rfc-editor.org/authors/ietf-bfd-stability@2026-05-05-rfcdiff.html
-->
<sourcecode type="yang" markers="true" name="ietf-bfd-stability@2026-05-
05.yang"><![CDATA[
module ietf-bfd-stability { module ietf-bfd-stability {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-stability"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-stability";
prefix "bfd-s"; prefix bfd-s;
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA Version)";
} }
import ietf-bfd { import ietf-bfd {
prefix bfd; prefix bfd;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection."; Forwarding Detection.";
} }
import ietf-bfd-ip-sh { import ietf-bfd-ip-sh {
prefix bfd-ip-sh; prefix bfd-ip-sh;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection."; Forwarding Detection (BFD)";
} }
import ietf-bfd-ip-mh { import ietf-bfd-ip-mh {
prefix bfd-ip-mh; prefix bfd-ip-mh;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection."; Forwarding Detection (BFD)";
} }
import ietf-bfd-lag { import ietf-bfd-lag {
prefix bfd-lag; prefix bfd-lag;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection."; Forwarding Detection (BFD)";
} }
import ietf-bfd-mpls { import ietf-bfd-mpls {
prefix bfd-mpls; prefix bfd-mpls;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection."; Forwarding Detection (BFD)";
} }
import ietf-key-chain { import ietf-key-chain {
prefix key-chain; prefix key-chain;
reference reference
"RFC 8177: YANG Key Chain."; "RFC 8177: YANG Data Model for Key Chains";
} }
organization organization
"IETF BFD Working Group"; "IETF BFD Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/bfd> "WG Web: <http://tools.ietf.org/wg/bfd>
WG List: <rtg-bfd@ietf.org> WG List: <rtg-bfd@ietf.org>
Authors: Mahesh Jethanandani (mjethanandani@gmail.com) Authors: Mahesh Jethanandani (mjethanandani@gmail.com)
Ashesh Mishra (mishra.ashesh@gmail.com) Ashesh Mishra (mishra.ashesh@gmail.com)
Ankur Saxena (ankurpsaxena@gmail.com) Ankur Saxena (ankurpsaxena@gmail.com)
Santosh Pallagatti (santosh.pallagati@gmail.com) Santosh Pallagatti (santosh.pallagati@gmail.com)
Mach Chen (mach.chen@huawei.com)."; Mach Chen (mach.chen@huawei.com).";
description description
"This YANG module augments the base BFD YANG model to add "This YANG module augments the base BFD YANG data model to add
experimental attributes related to BFD Stability. experimental attributes related to BFD stability.
In particular, it adds a per-session count for BFD packets In particular, it adds a per-session count for BFD packets
that are lost. that are lost.
Copyright (c) 2025 IETF Trust and the persons identified as The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC 9978; see the
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself RFC itself for full legal notices.";
for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision "2025-10-30" { revision 2026-05-05 {
description description
"Initial Version."; "Initial version.";
reference reference
"RFC XXXX: BFD Stability."; "RFC 9978: Bidirectional Forwarding Detection (BFD) Stability";
} }
feature stability { feature stability {
description description
"This feature enables BFD sessions to be monitored for lost "This feature enables BFD sessions to be monitored for lost
packets."; packets.";
} }
identity null-auth { identity null-auth {
base key-chain:crypto-algorithm; base key-chain:crypto-algorithm;
description description
"BFD Null Auth type defined in this draft."; "BFD NULL Auth type defined in this document.";
reference reference
"RFC XXXX: BFD Stability."; "RFC 9978: Bidirectional Forwarding Detection (BFD) Stability";
} }
grouping lost-packet-count { grouping lost-packet-count {
leaf lost-packet-count { leaf lost-packet-count {
if-feature "stability"; if-feature "stability";
type yang:counter64; type yang:counter64;
description description
"Number of BFD packets that were lost, where loss is "Number of BFD packets that were lost, where loss is
determined by the fact that the sequence number is determined by the fact that the sequence number is
not consecutive. This counter should be present only if not consecutive. This counter should be present only if
stability is configured."; stability is configured.";
} }
description description
"Grouping of statistics related to BFD stability."; "Grouping of statistics related to BFD stability.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
"bfd-ip-sh:sessions/bfd-ip-sh:session" { + "bfd-ip-sh:sessions/bfd-ip-sh:session" {
leaf stability { leaf stability {
if-feature "stability"; if-feature "stability";
type boolean; type boolean;
must "../bfd-ip-sh:authentication/bfd-ip-sh:meticulous = " + must "../bfd-ip-sh:authentication/bfd-ip-sh:meticulous = "
"'true'"; + "'true'";
default false; default "false";
description description
"If set to true, this enables the BFD session to monitor "If set to true, this enables the BFD session to monitor
for stability, i.e., to watch how many packets are getting for stability, i.e., to watch how many packets are getting
dropped."; dropped.";
} }
description description
"Augment the 'bfd' container to add attributes related to BFD "Augment the 'bfd' container to add attributes related to BFD
stability for IP Single Hop Sessions."; stability for IP Single Hop sessions.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/" + + "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
"bfd-ip-mh:session-groups/bfd-ip-mh:session-group" { + "bfd-ip-mh:session-groups/bfd-ip-mh:session-group" {
leaf stability { leaf stability {
if-feature "stability"; if-feature "stability";
type boolean; type boolean;
must "../bfd-ip-mh:authentication/bfd-ip-mh:meticulous = " + must "../bfd-ip-mh:authentication/bfd-ip-mh:meticulous = "
"'true'"; + "'true'";
default false; default "false";
description description
"If set to true, this enables the BFD session to monitor "If set to true, this enables the BFD session to monitor
for stability, i.e., to watch how many packets are getting for stability, i.e., to watch how many packets are getting
dropped."; dropped.";
} }
description description
"Augment the 'bfd' container to add attributes related to BFD "Augment the 'bfd' container to add attributes related to BFD
stability for Multi Hop Sessions."; stability for Multi Hop sessions.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/" + + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
"bfd-lag:sessions/bfd-lag:session" { + "bfd-lag:sessions/bfd-lag:session" {
leaf stability { leaf stability {
if-feature "stability"; if-feature "stability";
type boolean; type boolean;
must "../bfd-lag:authentication/bfd-lag:meticulous = " + must "../bfd-lag:authentication/bfd-lag:meticulous = "
"'true'"; + "'true'";
default false; default "false";
description description
"If set to true, this enables the BFD session to monitor "If set to true, this enables the BFD session to monitor
for stability, i.e., to watch how many packets are getting for stability, i.e., to watch how many packets are getting
dropped."; dropped.";
} }
description description
"Augment the 'bfd' container to add attributes related to BFD "Augment the 'bfd' container to add attributes related to BFD
stability for LAG session."; stability for LAG session.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/" + + "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
"bfd-mpls:session-groups/bfd-mpls:session-group" { + "bfd-mpls:session-groups/bfd-mpls:session-group" {
leaf stability { leaf stability {
if-feature "stability"; if-feature "stability";
type boolean; type boolean;
must "../bfd-mpls:authentication/bfd-mpls:meticulous = " + must "../bfd-mpls:authentication/bfd-mpls:meticulous = "
"'true'"; + "'true'";
default false; default "false";
description description
"If set to true, this enables the BFD session to monitor "If set to true, this enables the BFD session to monitor
for stability, i.e., to watch how many packets are getting for stability, i.e., to watch how many packets are getting
dropped."; dropped.";
} }
description description
"Augment the 'bfd' container to add attributes related to BFD "Augment the 'bfd' container to add attributes related to BFD
stability for MPLS."; stability for MPLS.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
"bfd-ip-sh:sessions/bfd-ip-sh:session/" + + "bfd-ip-sh:sessions/bfd-ip-sh:session/"
"bfd-ip-sh:session-statistics" { + "bfd-ip-sh:session-statistics" {
uses lost-packet-count; uses lost-packet-count;
description description
"Augment the 'bfd' container to add statistics related to BFD "Augment the 'bfd' container to add statistics related to BFD
stability for IP Single Hop Sessions."; stability for IP Single Hop sessions.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/" + + "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
"bfd-ip-mh:session-groups/bfd-ip-mh:session-group/" + + "bfd-ip-mh:session-groups/bfd-ip-mh:session-group/"
"bfd-ip-mh:sessions/bfd-ip-mh:session-statistics" { + "bfd-ip-mh:sessions/bfd-ip-mh:session-statistics" {
uses lost-packet-count; uses lost-packet-count;
description description
"Augment the 'bfd' container to add statistics related to BFD "Augment the 'bfd' container to add statistics related to BFD
stability for IP Multi Hop Sessions."; stability for IP Multi Hop sessions.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/" + + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
"bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/" + + "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/"
"bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics" { + "bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics" {
uses lost-packet-count; uses lost-packet-count;
description description
"Augment the 'bfd' container to add statistics related to BFD "Augment the 'bfd' container to add statistics related to BFD
stability for Micro BFD sessions for IPv4."; stability for Micro BFD sessions for IPv4.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/" + + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
"bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/" + + "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/"
"bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics" { + "bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics" {
uses lost-packet-count; uses lost-packet-count;
description description
"Augment the 'bfd' container to add statistics related to BFD "Augment the 'bfd' container to add statistics related to BFD
stability for Micro BFD sessions for IPv6."; stability for Micro BFD sessions for IPv6.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/" + + "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
"bfd-mpls:session-groups/bfd-mpls:session-group/" + + "bfd-mpls:session-groups/bfd-mpls:session-group/"
"bfd-mpls:sessions/bfd-mpls:session-statistics" { + "bfd-mpls:sessions/bfd-mpls:session-statistics" {
uses lost-packet-count; uses lost-packet-count;
description description
"Augment the 'bfd' container to add statistics related to BFD "Augment the 'bfd' container to add statistics related to BFD
stability for MPLS sessions."; stability for MPLS sessions.";
} }
} }]]></sourcecode>
<CODE ENDS>
]]>
</artwork>
</figure>
</t>
</section> </section>
</section> </section>
<section>
<name>IANA Considerations</name>
<!-- [rfced] We have updated the introductory paragraph in the IANA Consideratio
ns to also mention registration of the YANG module name. Please review and let
us know if updates are required.
<section title="IANA Considerations"> Original:
<t>This document requests one new authentication type and This document requests one new authentication type and registers one
registers one URIs in the "ns" subregistry of the "IETF XML" URIs in the "ns" subregistry of the "IETF XML" registry [RFC3688].
registry <xref target="RFC3688"/>.</t>
<section anchor="auth-type" title="Auth Type"> Current:
<t> This document registers a new authentication type, a new URI in the
This document requests an update to the registry titled "BFD "ns" registry within the "IETF XML" registry group [RFC3688], and a
Authentication Types". IANA is requested to assign a new YANG module in the "YANG Module Names" registry.
BFD AuthType: -->
<ul>
<li> <t>This document registers a new authentication type,
NULL Auth Type, with a suggested value of 6. a new URI in the "ns" registry within the "IETF XML"
</li> registry group <xref target="RFC3688"/>, and a YANG module in the "YANG Mo
</ul> dule Names" registry.</t>
</t> <section anchor="auth-type">
<name>Auth Type</name>
<t>
IANA has registered the following BFD Auth Type in the "BFD Authenticat
ion Types" registry:
</t>
<dl spacing="compact" newline="false">
<dt>Address:</dt><dd>6</dd>
<dt>BFD Authentication Type Name:</dt><dd>NULL</dd>
<dt>Reference</dt><dd>RFC 9978</dd>
</dl>
</section> </section>
<section anchor="ietf-xml-registry" title="IETF XML Registry"> <section anchor="ietf-xml-registry">
<t>Following the format in <xref target="RFC3688"/>, the following <name>IETF XML Registry</name>
registrations are requested:</t> <t>IANA has registered the following URI in the "ns" registry <xref targ
<t> et="RFC3688"/>:</t>
<figure> <dl spacing="compact" newline="false">
<artwork><![CDATA[URI: urn:ietf:params:xml:ns:yang:ietf-bfd-stability <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-stability</dd>
Registrant Contact: The IESG <dt>Registrant Contact:</dt><dd>The IESG</dd>
XML: N/A, the requested URI is an XML namespace. <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
]]> </dl>
</artwork>
</figure>
</t>
</section> </section>
<section>
<section title="The &quot;YANG Module Names&quot; Registry"> <name>The "YANG Module Names" Registry</name>
<t> <t>
This document registers one YANG module in the "YANG Module IANA has registered the following YANG module in the "YANG Module
Names" registry <xref target="RFC6020"/>. Following the Names" registry <xref target="RFC6020"/>:
format in <xref target="RFC6020"/>, the following
registrations are requested:
</t> </t>
<dl spacing="compact" newline="false">
<t><figure> <dt>Name:</dt><dd>ietf-bfd-stability</dd>
<artwork><![CDATA[ <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-stability</dd>
name: ietf-bfd-stability <dt>Prefix:</dt><dd>bfd-s</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-stability <dt>Reference:</dt><dd>RFC 9978</dd>
prefix: bfd-s </dl>
reference: RFC XXXX
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section>
<section title="Security Considerations"> <name>Security Considerations</name>
<section title="BFD NULL Auth Security Considerations"> <section>
<t> <name>BFD NULL Auth Security Considerations</name>
<t>
The use of a BFD authentication mechanism that protects the The use of a BFD authentication mechanism that protects the
BFD packets is RECOMMENDED. BFD packets is <bcp14>RECOMMENDED</bcp14>.
</t> </t>
<!-- [rfced] FYI - We have replaced the comma in the text below with "with"
for clarity. Please review.
Original:
It is intended to provide BFD sessions that otherwise would not use
authentication, a sequence number that can be used for purposes of
detecting lost packets.
Current:
It is intended to provide BFD sessions that otherwise would not use
authentication with a sequence number that can be used for the purpose of
detecting lost packets.
-->
<t> <t>
The Security Considerations of <xref target="RFC5880"/> for The security considerations of <xref target="RFC5880"/> for
unauthenticated BFD all apply to the new NULL authentication unauthenticated BFD all apply to the new NULL authentication
type. The NULL Authentication type, defined in this type. The NULL authentication type, defined in this
document, provides none of the properties desired for document, provides none of the properties desired for
authenticating BFD packets. It is intended to provide BFD authenticating BFD packets. It is intended to provide BFD
sessions that otherwise would not use authentication, a sessions that otherwise would not use authentication with a
sequence number that can be used for purposes of detecting sequence number that can be used for the purpose of detecting
lost packets. lost packets.
</t> </t>
<t>
<t>
The lack of a computed AuthKey/Digest over the BFD packet, The lack of a computed AuthKey/Digest over the BFD packet,
but the presence of a Sequence Number makes this but the presence of a sequence number, makes this
authentication type susceptible to injection attacks. BFD authentication type susceptible to injection attacks. BFD
without authentication is vulnerable to session resets; the without authentication is vulnerable to session resets; the
NULL Auth type does not change this.</t> NULL Auth type does not change this.</t>
<t>
<t> When the NULL authentication type is used for BFD stability
When the NULL Authentication type is used for BFD Stability
purposes, maliciously injected packets that do not reset the purposes, maliciously injected packets that do not reset the
BFD session can resemble high packet loss. Sessions such as BFD session can resemble high packet loss. Sessions such as
multi-hop routed paths, tunnels without authentication, or multi-hop routed paths, tunnels without authentication, or
MPLS LSP, therefore, have security guarantees that are MPLS Label Switched Paths (LSPs), therefore, have security guarantees t hat are
identical to situations where BFD is run without identical to situations where BFD is run without
authentication. authentication.
</t> </t>
</section> <!-- [rfced] Section 9.2 (YANG Security Considerations): We note some difference
<section title="YANG Security Considerations"> s from the
template in the OPs wiki. Please refer to the template at <https://wiki.ietf.or
g/en/group/ops/yang-security-guidelines>.
a) We have updated the first three paragraphs of this section to match the
template. Please review and let us know any objections.
b) In addition, we have updated this paragraph to match what is defined in the t
emplate. Please review and let us know if any updates are needed.
Original:
The only readable data nodes in YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes.
Current:
Some of the readable data nodes in this YANG module may be
considered sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or notification)
to these data nodes. Specifically, the following subtrees and data nodes have
particular sensitivities/vulnerabilities:
c) In general, please review the Security Considerations and let us know
if any additional changes are required.
d) FYI - Note that we have added RFC 9907 to the Informative References
section of this document.
-->
</section>
<section>
<name>YANG Security Considerations</name>
<t> <t>
The YANG module specified in this document defines a schema This section is modeled after the template described in <xref
for data that is designed to be accessed via network target="RFC9907" sectionFormat="of" section="3.7.1"/>.
management protocols such as <xref
target="RFC6241">NETCONF</xref> or <xref
target="RFC8040">RESTCONF</xref>. These YANG-based
management protocols have to use a secure transport layer
(e.g., <xref target="RFC4252">SSH</xref>, <xref
target="RFC8446">TLS</xref>, and <xref
target="RFC9000">QUIC</xref>) and have to use mutual
authentication.
</t> </t>
<t> <t>
The <xref target="RFC8341">NETCONF Access Control Model The "ietf-bfd-stability" YANG module defines a data model that is
(NACM)</xref> provides the means to restrict access for designed to be accessed via YANG-based management protocols, such as
particular NETCONF or RESTCONF users to a preconfigured Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> and R
subset of all available NETCONF or RESTCONF protocol ESTCONF
operations and content. <xref target="RFC8040"/>. These YANG-based management protocols (1) hav
e to use a
secure transport layer (e.g., Secure Shell (SSH) <xref target="RFC4252"
/>, TLS <xref target="RFC8446"/>, and QUIC
<xref target="RFC9000"/>) and (2) have to use mutual authentication.
</t> </t>
<t>
<t> The Network Configuration Access Control Model (NACM) <xref
target="RFC8341"/> provides the means to restrict access for
particular NETCONF or RESTCONF users to a preconfigured subset of
all available NETCONF or RESTCONF protocol operations and content.
</t>
<t>
The YANG module does not define any The YANG module does not define any
writeable/creatable/deletable data nodes that can have an writeable/creatable/deletable data nodes that can have an
adverse impact on a BFD session. adverse impact on a BFD session.
</t> </t>
<t>
<t> Some of the readable data nodes in this YANG module may be considered
The only readable data nodes in YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to
sensitive or vulnerable in some network environments. It is control read access (e.g., via get, get-config, or notification) to these dat
thus important to control read access (e.g., via get, a
get-config, or notification) to these data nodes. nodes. Specifically, the following subtrees and data nodes have particular
</t> sensitivities/vulnerabilities:
</t>
<t> <t>
The model defines a read-only node to indicate the number of The model defines a read-only node to indicate the number of
packets that were lost. Access to this information may allow packets that were lost. Access to this information may allow
a malicious user information on which links are experiencing a malicious user information on which links are experiencing
issues. In addition, and as stated in <xref issues. In addition, and as stated in <xref target="out-of-order-packet
target="out-of-order-packets">Out of Order Packets</xref>, s"/>,
on links such as LAG or ECMP, there is a possibility of on links such as LAG or ECMP, there is a possibility of
packets being delivered out-of-order. A strict comparison of packets being delivered out-of-order. A strict comparison of
increasing sequence numbers may result in classifying those increasing sequence numbers may result in classifying those
out of order packets as packet loss. out-of-order packets as packet loss.
</t> </t>
<t>The YANG module does not define any RPC operations.</t>
<t>The YANG module does not define any RPC operations.</t>
</section> </section>
</section> </section>
<section title="Contributors">
<t>
The authors of this document would like to acknowledge Jeff
Haas as a contributor to this document. His contribution lead
to a significant improvement of the document. In addition,
Manav Bhatia contributed to this document.
</t>
</section>
<section title="Acknowledgements">
<t>
Authors would like to thank Nobo Akiya, Dileep Singh, Basil
Saji, Sagar Soni, Albert Fu, Peng Fang, and Mallik Mudigonda
who contributed to this document. Thanks to Christian Huitema
for the SECDIR and Ebben Aries for the YANG Doctors review.
</t>
<t>
Thanks to Reshad Rehman for being the shepherd of the
document.
</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-bfd-secure-sequence-numbers" to="BFD-ISAA
<?rfc include='reference.RFC.2119.xml'?> C"/>
<references>
<?rfc include='reference.RFC.3688.xml'?> <name>References</name>
<references>
<?rfc include='reference.RFC.4252.xml'?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.5880.xml'?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<?rfc include='reference.RFC.6020.xml'?> 688.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
252.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.6
020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
991.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.8
341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
349.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
314.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
241.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
374.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
000.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
907.xml"/>
<?rfc include='reference.RFC.6991.xml'?> <!-- [I-D.ietf-bfd-secure-sequence-numbers]
draft-ietf-bfd-secure-sequence-numbers-27
IESG State: RFC-ED queue
Check if RFC number is available when this doc completes AUTH48. -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-bfd-secure-sequence-numbers.xml"/>
<?rfc include='reference.RFC.8174.xml'?> <!-- [rfced] Regarding reference [Y-1731], the version of ITU-T Recommendation G .8013/Y.1731 referenced in this document has been superseded (https://www.itu.in t/rec/T-REC-G.8013-201311-S/en).
<?rfc include='reference.RFC.8341.xml'?> The most current "in force" version was published in June 2023
(https://www.itu.int/rec/T-REC-G.8013-202306-I/en). May we update this
reference to point to the most current version?
<?rfc include='reference.RFC.8349.xml'?> Current:
[Y-1731] ITU-T, "OAM functions and mechanisms for Ethernet based
networks", ITU-T Recommendation G.8013/Y.1731, November
2013,
<https://www.itu.int/rec/T-REC-G.8013-201311-S/en>.
Perhaps:
[Y-1731]
ITU-T, "Operation, administration and maintenance (OAM)
functions and mechanisms for Ethernet-based networks",
ITU-T Recommendation G.8013/Y.1731, June 2023,
<https://www.itu.int/rec/T-REC-G.8013-202306-I/en>.
-->
<reference anchor="Y-1731" target="https://www.itu.int/rec/T-REC-G.8013-
201311-S/en">
<front>
<title>OAM functions and mechanisms for Ethernet based networks
</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="November" year="2013"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="G.8013/Y.1731"/>
</reference>
<?rfc include='reference.RFC.9314.xml'?> <!-- potential ref update
Updated XML for [Y-1731]
<reference anchor="Y-1731" target="https://www.itu.int/rec/T-REC-G.8013-
202306-I/en">
<front>
<title>Operation, administration and maintenance (OAM) functions and
mechanisms for Ethernet-based networks
</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="June" year="2023"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="G.8013/Y.1731"/>
</reference>
-->
</references>
</references> </references>
<references title="Informative References"> <section anchor="experimental-status">
<?rfc include='reference.RFC.6241.xml'?> <name>Experimental Status</name>
<?rfc include='reference.RFC.6374.xml'?>
<?rfc include='reference.RFC.8040.xml'?>
<?rfc include='reference.RFC.8446.xml'?>
<?rfc include='reference.RFC.9000.xml'?>
<?rfc include='reference.I-D.ietf-bfd-secure-sequence-numbers.xml'?>
<reference anchor="Y-1731">
<front>
<title>
OAM Functions and Mechanisms for Ethernet-based Networks
</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="November" year="2013"/>
</front>
<seriesInfo name="Recommendation" value="G.8013/Y.1731"/>
</reference>
</references>
<section anchor="experimental-status" title="Experimental Status">
<t> <t>
This document describes an experiment that will present a This document describes an experiment that will present a
candidate solution to predict whether a given <xref candidate solution to predict whether a given BFD <xref target="RFC5880"/
target="RFC5880">BFD</xref> session will continue to be > session will continue to be
stable. The experiment will use the packet lost count and the stable. The experiment will use the packet lost count and the
'received-packet-count' defined in the <xref 'received-packet-count' defined in "YANG Data Model for Bidirectional For
target="RFC9314">YANG Data Model for Bidirectional Forward warding Detection (BFD)" <xref target="RFC9314"/> to determine how stable the
Detection (BFD)</xref> to determine how stable is the session is. The reason this document is on the Experimental track is beca
session. The reason why this document is on an use there are no known
Experimental track is because there are no known implementations or proof of concept. As a result, the authors
implementations or proof-of-concept. As a result, the authors
are not clear whether a simple lost count is enough to predict are not clear whether a simple lost count is enough to predict
the stability or there will be a need to have a more granular the stability or if there will be a need to be a more granular
count. count.
</t> </t>
<t> <t>
This document is classified as Experimental and is not part of This document is classified as Experimental and is not part of
the IETF Standards Track. the IETF Standards Track.
</t> </t>
</section> </section>
<section anchor="examples" title="Examples"> <section anchor="examples">
<name>Examples</name>
<t> <t>
This section tries to show some examples in how the model can This section tries to show some examples of how the model can
be configured for stability. be configured for stability.
</t> </t>
<section anchor="example-a.1.1" title="Single Hop BFD Configuration"> <section anchor="example-a.1.1">
<t> <name>Single-Hop BFD Configuration</name>
This example demonstrates how a Single Hop BFD session can <t>
This example demonstrates how a single-hop BFD session can
be configured to enable monitoring of a session for be configured to enable monitoring of a session for
stability. stability.
</t> </t>
<t> <sourcecode><![CDATA[
<figure>
<artwork><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 =============== =============== NOTE: '\' line wrapping per RFC 8792 ===============
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<key-chains <key-chains
xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain" xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
xmlns:kc="urn:ietf:params:xml:ns:yang:ietf-key-chain"> xmlns:kc="urn:ietf:params:xml:ns:yang:ietf-key-chain">
<key-chain> <key-chain>
<name>bfd-stability-config</name> <name>bfd-stability-config</name>
<description>"An example for BFD Stabalized configuration."</de\ <description>"An example for BFD stabilized configuration."</de\
scription> scription>
<key> <key>
<key-id>55</key-id> <key-id>55</key-id>
<lifetime> <lifetime>
<send-lifetime> <send-lifetime>
<start-date-time>2025-01-01T00:00:00Z</start-date-time> <start-date-time>2025-01-01T00:00:00Z</start-date-time>
<end-date-time>2025-02-01T00:00:00Z</end-date-time> <end-date-time>2025-02-01T00:00:00Z</end-date-time>
</send-lifetime> </send-lifetime>
<accept-lifetime> <accept-lifetime>
<start-date-time>2024-12-31T23:59:55Z</start-date-time> <start-date-time>2024-12-31T23:59:55Z</start-date-time>
skipping to change at line 1036 skipping to change at line 1083
<authentication> <authentication>
<key-chain>bfd-stability-config</key-chain> <key-chain>bfd-stability-config</key-chain>
<meticulous>true</meticulous> <meticulous>true</meticulous>
</authentication> </authentication>
</session> </session>
</sessions> </sessions>
</ip-sh> </ip-sh>
</bfd> </bfd>
</control-plane-protocol> </control-plane-protocol>
</control-plane-protocols> </control-plane-protocols>
</routing> </routing>]]></sourcecode>
]]>
</artwork>
</figure>
</t>
</section> </section>
<section anchor="example-a.1.2" title="Use of NULL Auth"> <section anchor="example-a.1.2">
<t> <name>Use of NULL Auth</name>
<t>
This example demonstrates how to configure NULL Auth This example demonstrates how to configure NULL Auth
to enable monitoring of a session for stability. to enable monitoring of a session for stability.
</t> </t>
<t> <sourcecode><![CDATA[
<figure>
<artwork><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 =============== =============== NOTE: '\' line wrapping per RFC 8792 ===============
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<key-chains <key-chains
xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain" xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\ xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
"> ">
<key-chain> <key-chain>
<name>bfd-stability-config</name> <name>bfd-stability-config</name>
<description>"An example for BFD Stability configuration."</des\ <description>"An example for BFD stability configuration."</des\
cription> cription>
<key> <key>
<key-id>55</key-id> <key-id>55</key-id>
<lifetime> <lifetime>
<send-lifetime> <send-lifetime>
<start-date-time>2025-01-01T00:00:00Z</start-date-time> <start-date-time>2025-01-01T00:00:00Z</start-date-time>
<end-date-time>2025-02-01T00:00:00Z</end-date-time> <end-date-time>2025-02-01T00:00:00Z</end-date-time>
</send-lifetime> </send-lifetime>
<accept-lifetime> <accept-lifetime>
<start-date-time>2024-12-31T23:59:55Z</start-date-time> <start-date-time>2024-12-31T23:59:55Z</start-date-time>
skipping to change at line 1116 skipping to change at line 1158
<authentication> <authentication>
<key-chain>bfd-stability-config</key-chain> <key-chain>bfd-stability-config</key-chain>
<meticulous>true</meticulous> <meticulous>true</meticulous>
</authentication> </authentication>
</session> </session>
</sessions> </sessions>
</ip-sh> </ip-sh>
</bfd> </bfd>
</control-plane-protocol> </control-plane-protocol>
</control-plane-protocols> </control-plane-protocols>
</routing> </routing>]]></sourcecode>
]]>
</artwork>
</figure>
</t>
</section> </section>
</section> </section>
<section numbered="false">
<name>Acknowledgements</name>
<t>
The authors would like to thank <contact fullname="Nobo Akiya"/>, <contac
t
fullname="Dileep Singh"/>, <contact fullname="Basil Saji"/>, <contact
fullname="Sagar Soni"/>, <contact fullname="Albert Fu"/>, <contact
fullname="Peng Fang"/>, and <contact fullname="Mallik Mudigonda"/> for
contributing to this document. Thanks to <contact fullname="Christian
Huitema"/> for the SECDIR review and <contact fullname="Ebben Aries"/> fo
r
the YANG Doctors review.
</t>
<t>
Thanks to <contact fullname="Reshad Rehman"/> for being the shepherd
of the document.
</t>
</section>
<section numbered="false">
<name>Contributors</name>
<t>
The authors would like to acknowledge <contact fullname="Jeff
Haas"/> as a contributor to this document. His contribution lead
to significant improvements of the document. In addition,
<contact fullname="Manav Bhatia"/> contributed to this document.
</t>
</section>
</back> </back>
</rfc> </rfc>
<!-- [rfced] Please review the following questions and changes regarding the
terminology used in this document:
a) Should instances of "NULL Auth" be updated to "NULL authentication type" (i.e
., spell out "Authentication") for clarity and consistency with other uses in th
e document?
NULL Auth type
NULL Auth Type
NULL Auth
Note that "authentication type" (lowercase) is used except where the text explic
itly refers to the field (Auth Type field or Authentication Type field).
Please let us know if any updates are needed.
b) To align with RFC 5880, we have updated the following terms. Please review a
nd let us know if any updates are required.
- "sequence number" (lowercase) except where the text explicitly refers to the
field (i.e., Sequence Number field).
- "authentication type" (lowercase) except where the text explicitly refers to t
he field (Auth Type field or Authentication Type field).
- Authentication Section (initial capitalization)
- "session Detection Time"
- Per guidance from Benoit Claise and the YANG Doctors, we updated instances of
"YANG model" to "YANG data model". However, please be sure to review and ensure
"model" and "module" are used correctly.
- We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Operations, Administration, and Maintenance (OAM)
Label Switched Paths (LSPs)
-->
 End of changes. 180 change blocks. 
520 lines changed or deleted 668 lines changed or added

This html diff was produced by rfcdiff 1.48.