<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ietf-bfd-stability-21" number="9978" updates="" obsoletes="" ipr="trust200902" consensus="true"
    submissionType="IETF"> submissionType="IETF" tocInclude="true" symRefs="true" sortRefs="true" tocDepth="3" version="3" xml:lang="en">

<!-- [rfced] We have updated the title as shown below.  Please let us know if any changes are required.

Original:
      BFD Stability

Current:
      Bidirectional Forwarding Detection (BFD) Stability

-->

  <front>
    <title abbrev="BFD Stability">BFD Stability">Bidirectional Forwarding Detection (BFD) Stability</title>
    <seriesInfo name="RFC" value="9978"/>
    <author fullname="Ashesh Mishra" initials="A" surname="Mishra">
      <organization>Aalyria Technologies</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <phone/>
        <email>ashesh@aalyria.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Mahesh Jethanandani" initials="M" surname="Jethanandani">
      <organization>Arrcus, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone/>
        <facsimile/>
        <email>mjethanandani@gmail.com</email>
      </address>
    </author>
    <author fullname="Ankur Saxena" initials="A" surname="Saxena">
      <organization>Ciena Corporation</organization>
      <address>
        <postal>
          <street>3939 North 1st Street</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone/>
        <facsimile/>
        <email>ankurpsaxena@gmail.com</email>
        <uri>www.ciena.com</uri>
      </address>
    </author>
    <author fullname="Santosh Pallagatti" initials="S" surname="Pallagatti">
      <organization>Zscaler</organization>
      <address>
        <postal>
          <street/>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560103</code>
          <country>India</country>
        </postal>
        <phone/>
        <facsimile/>
        <email>santosh.pallagatti@gmail.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Mach Chen" initials="M" surname="Chen">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <phone/>
        <facsimile/>
        <email>mach.chen@huawei.com</email>
        <uri/>
      </address>
    </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>
      <t>
	This document describes extensions to the Bidirectional
	Forwarding Detection (BFD) protocol to measure BFD
	stability. Specifically, it describes a mechanism for
	the detection of BFD packet loss.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
    <section>
      <name>Introduction</name>

      <t>The Bidirectional Forwarding Detection (<xref
      target="RFC5880">BFD)</xref> (BFD) <xref target="RFC5880"/> protocol 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 Detection Time as defined in <xref
      target="RFC5880">BFD</xref> target="RFC5880"/> is set to the smallest feasible value.</t>
      <t>
	A <xref target="RFC5880">BFD</xref> BFD session will remain in the Up state as long as it receives at
	least one BFD packet within the Detection Time interval. However,
	additional packet loss within that time interval is not noted by the
	BFD state machinery. Noting the other missed packets provides a
	valuable indicator of systemic issues or a deteriorating network that
	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 <xref
	target="RFC9314">YANG YANG Data Model for Bidrectional Forward Detection (BFD)</xref> (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>
	This document proposes an experimental mechanism to detect
	lost packets in a BFD session in addition to the datapath
	fault detection mechanisms of BFD.  Such a mechanism, combined
	with 'received-packet-count' defined in "YANG Data Model for Bidirectional Forwarding Detection (BFD)" <xref target="RFC9314"/> permits operators to measure the
	stability of BFD sessions. The details of the motivation for
	experimental
	the Experimental status of this document can be found in <xref target="experimental-status"/>. Implementations may also do
	additional analysis of the packet loss over a time
	interval. Such an analysis is outside the scope of this
	document.
      </t>
      <t>
	This document does not propose any BFD extension to measure
	data traffic loss or delay on a link or tunnel, and the scope
	is limited to BFD packets.
      </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 title="Terminology">
      <t>The
    <section>
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref
      target="RFC2119">RFC 2119</xref> and target="RFC2119"/> <xref target="RFC8174">RFC
      8174</xref>.</t>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      <t>
	The reader is expected to be familiar with the BFD <xref
	target="RFC5880">BFD</xref>. target="RFC5880"/>. In particular, the term
	'meticulous'
	"meticulous" as specified in <xref
	target="I-D.ietf-bfd-secure-sequence-numbers">Meticulous "Meticulous Keyed ISAAC for BFD Optimized Authentication</xref> Authentication" <xref target="I-D.ietf-bfd-secure-sequence-numbers"/> means that the
	Sequence
	sequence number is incremented on every new packet that is
	sent.
      </t>
    </section>

    <section title="Use Cases">
    <section>
      <name>Use Cases</name>
      <t>
	Bidirectional Forwarding Detection, Detection (BFD), as defined in <xref
	target="RFC5880">BFD</xref> target="RFC5880"/>, cannot detect any BFD packet loss
	if the loss does not last for the Detection Time. This
	document proposes a method to detect dropped packets on the
	receiver. For example, if the receiver receives BFD control
	packet k at time t t, but receives packet k+3 at time t+10ms, t+10 ms, and
	never receives packet k+1 and/or k+2, then it has experienced
	a packet loss.
      </t>

      <t>This
<!-- [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
	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>
      <t>
	In a faulty datapath scenario, an operator can use BFD health
	information to trigger the delay and loss measurement OAM Operations, Administration, and Maintenance (OAM)
	protocol <xref target="Y-1731">Connectivity Connectivity Fault Management
	(CFM)</xref> or
	(CFM) <xref target="RFC6374">Packet Loss target="Y-1731"/> or packet loss and Delay
	Measurement delay measurement for MPLS Networks</xref> networks <xref target="RFC6374"/> to further isolate the
	issue.
      </t>
    </section>

    <section title="Functionality">
      <t>
    <section>
      <name>Functionality</name>
<!-- [rfced] Does "BFD Meticulous" refer "Meticulous Keyed MD5", as registered by 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-parameters-2>.

Original:
   BFD stability measurement requires that a BFD Meticulous
   Authentication type is configured.
-->

      <t>
        BFD stability measurement requires that a BFD Meticulous authentication
        type be configured.
      </t>
      <t>
        The ietf-bfd-stability "ietf-bfd-stability" YANG data model, defined in this document, provides
        the ability to configure the BFD stability measurement for BFD sessions by
        configuring the 'stability' flag. The 'lost-packet-count' 'lost&nbhy;packet&nbhy;count' leaf permits
        monitoring of stability issues as defined in this document for BFD
        sessions that have the stability 'stability' flag enabled.
      </t>
      <t>
        The configuration of the BFD stability measurement and monitoring using
        other methods than the attached YANG data model is out of scope from of this
        document.
      </t>
    </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.

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" title="NULL anchor="null-auth-type">
      <name>NULL Auth Type"> Type</name>
      <t>
	The NULL Authentication Type, authentication type, defined in this document, can be
	used to provide a meticulously increasing sequence number
	BFD <xref target="RFC5880">BFD</xref> target="RFC5880"/> for stability measurement.
	It provides none of the protections desired for authentication
	and is used only to provide BFD stability services to BFD
	sessions that otherwise have no authentication in use.</t>
      <t>If the Authentication Present (A) bit is set in the header
      as defined in <xref target="RFC5880" section="4">BFD</xref>, sectionFormat="of" section="4"/>,
      and the Authentication Type field contains TBD, 6, the
      Authentication section Section has the following format:
      <figure
          align="center" title="NULL
      </t>
      <figure>
        <name>NULL Auth Type">
        <artwork><![CDATA[ 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>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>
      where:
      </t>

      <t>Auth

      <t>where:</t>

      <dl spacing="normal" newline="false">
	<dt>Auth Type (8 bits): The bits):</dt><dd>The Authentication Type, which in this
	case is TBD (NULL, to be assigned by IANA, with a suggested
	value of 6).
      </t>

      <t>Auth 6 (NULL).</dd>
	<dt>Auth Len (8 bits): The bits):</dt><dd>The length of the NULL Auth Type, Type in bytes;
	i.e., 8 bytes
      </t>

      <t>Auth (i.e., 8 bytes).</dd>
	<dt>Auth Key ID (8 bits): The bits):</dt><dd>The authentication key ID in use for this
	packet. MUST It <bcp14>MUST</bcp14> be set to zero and MUST <bcp14>MUST</bcp14> be ignored on receipt.
      </t>

      <t>Reserved receipt.</dd>
	<dt>Reserved (8 bits): This bits):</dt><dd>This byte MUST <bcp14>MUST</bcp14> be set to zero on transmit
	and MUST <bcp14>MUST</bcp14> be ignored on receipt.
      </t>

      <t>Sequence receipt.</dd>
	<dt>Sequence Number (32 bits): The bits):</dt><dd>The sequence number for this
	packet.  This value is incremented for each successive packet
	transmitted for a session.  Implementations will use sequence
	numbers (bfd.XmitAuthSeq) as defined in <xref
	target="RFC5880">BFD</xref>.
      </t> target="RFC5880"/>.</dd>
      </dl>
      <t>
	If bfd.AuthSeqKnown is 1, and the received Sequence Number
	field is not equal to bfd.RcvAuthSeq + 1 (in a circular number
	space), then the loss count is incremented by the difference
	between the received Sequence Number sequence number and bfd.RcvAuthSeq bfd.RcvAuthSeq, and
	bfd.RcvAuthSeq is set to the received Sequence Number. sequence number.
      </t>
      <t>
	Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST <bcp14>MUST</bcp14> be
	set to 1, and bfd.RcvAuthSeq MUST <bcp14>MUST</bcp14> be set to the value of the
	received Sequence Number field as defined in <xref target="RFC5880" sectionFormat="comma"
	section="6.8.1">BFD</xref>, section="6.8.1"/>, and the packet MUST <bcp14>MUST</bcp14>
	be accepted.
      </t>
      <t>
	According to <xref target="RFC5880" sectionFormat="comma"
	section="6.7.3">BFD</xref> sectionFormat="of" section="6.7.3"/>, a receiver MUST <bcp14>MUST</bcp14> discard a received
	packet that lies outside the range of bfd.RcvAuthSeq and
	bfd.RcvAuthSeq + (3 * Detect Multi). If it is within that
	range, but is missing a packet, it can be used to detect a
	loss. In case of NULL authentication where packets containing
	sequence numbers are accepted on receipt, an attacker with an
	unauthenticated sequence number could move the Sequence Number sequence number
	forward. Meanwhile, the actual BFD neighbor that continues to
	send packets will find them discarded and the session would
	drop. To prevent such an attack, the received Sequence Number
	MUST NOT sequence number
	<bcp14>MUST NOT</bcp14> be compared with bfd.RcvAuthSeq for purposes the purpose of
	discarding the BFD packets.
      </t>
    </section>

    <section title="Theory
    <section>
      <name>Theory of Operation"> Operation</name>
      <t>This mechanism allows operators to measure the loss of BFD control
      packets.  A BFD authentication type carrying a meticulously increasing
      sequence number is required to support this loss measurement.
      Authentication types that provide for meticulously increasing sequence
      numbers include:</t>
      <ul>
        <li>
          Meticulously Keyed MD5 and SHA1, defined in
          <xref target="RFC5880"/>.
        </li>
        <li>
          Meticulously Keyed ISAAC, defined in
          <xref target="I-D.ietf-bfd-secure-sequence-numbers"/>.
        </li>
        <li>
          The NULL authentication mechanism, which does not provide for
          authentication but carries a meticulously increasing sequence number, and is
          defined in this document.
        </li>
      </ul>
      <t>
	Other authentication types that provide for meticulously increasing
	sequence numbers appropriate for this mechanism may be defined in future
	specifications.
      </t>

      <section title="Loss Measurement">
      <section>
        <name>Loss Measurement</name>
        <t>
	  Loss measurement counts the number of BFD control packets
	  missed at the receiver during any Detection Time period <xref target="RFC5880" section="6.8.4"
	  sectionFormat="comma">BFD</xref> period. sectionFormat="comma"/>. The loss is detected
	  by comparing the Sequence Number field in successive BFD
	  control packets. The Sequence Number sequence number in each successive
	  control packet generated on a BFD session by the transmitter
	  is incremented by one. This loss count can then be exposed
	  using the YANG module defined in the subsequent section. See
	  discussion on out-of-order packets in <xref target="out-of-order-packets">Out target="out-of-order-packets"/> of
	  Order Packets</xref> later in the this document.
        </t>
        <t>
	  The first BFD authentication section Authentication Section with a non-zero
	  sequence number, in a valid BFD control packet, processed by
	  the receiver, is used for bootstrapping the logic.
        </t>
      </section>
      <section anchor="out-of-order-packets" title="Out of Order Packets"> anchor="out-of-order-packets">
        <name>Out-of-Order Packets</name>
        <t>
	  Some transmission mechanisms - mechanisms, for example, Link Aggregate Groups
	  (LAG),
	  (LAGs) or Equal Cost Multipath (ECMP) - (ECMP), can result in out of order out-of-order
	  packet delivery.  In circumstances where BFD packets are not lost, but
	  are delivered out of order, strict comparison of increasing sequence
	  numbers may result in classifying the out of order out-of-order packets as packet
	  loss.
        </t>
        <t>
	  Implementations MAY <bcp14>MAY</bcp14> provide mechanisms wherein all expected
	  packets received across an expected interval, but delivered
	  out of order order, are not considered lost packets.
        </t>
      </section>
    </section>
    <section anchor="yang-module" title="Stability anchor="yang-module">
      <name>Stability YANG Module"> Module</name>
      <section anchor="data-model-overview" title="Data anchor="data-model-overview">

<!-- [rfced] What does "lsp" refer to in the text below? How may we clarify
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"> Overview</name>
        <t>
	  This YANG module augments the base BFD YANG module to add
	  attributes such as the flag 'stability' flag related
	  to the experiment of BFD Stability. stability. The feature statement
	  'stability' needs to be enabled to indicate that BFD
	  Stability
	  stability is supported by the implementation. In addition, a
	  loss count per-session or lsp for BFD packets that are lost
	  has also been added in this model.
        </t>

        <t>
	  <figure>
            <artwork><![CDATA[
        <sourcecode type="yangtree"><![CDATA[
module: ietf-bfd-stability

  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
            /bfd-ip-sh:sessions/bfd-ip-sh:session:
    +--rw stability?   boolean {stability}?
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
            /bfd-ip-mh:session-groups/bfd-ip-mh:session-group:
    +--rw stability?   boolean {stability}?
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
            /bfd-lag:sessions/bfd-lag:session:
    +--rw stability?   boolean {stability}?
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
            /bfd-mpls:session-groups/bfd-mpls:session-group:
    +--rw stability?   boolean {stability}?
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
            /bfd-ip-sh:sessions/bfd-ip-sh:session
            /bfd-ip-sh:session-statistics:
    +--ro lost-packet-count?   yang:counter64 {stability}?
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
            /bfd-ip-mh:session-groups/bfd-ip-mh:session-group
            /bfd-ip-mh:sessions/bfd-ip-mh:session-statistics:
    +--ro lost-packet-count?   yang:counter64 {stability}?
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
            /bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links
            /bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics:
    +--ro lost-packet-count?   yang:counter64 {stability}?
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
            /bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links
            /bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics:
    +--ro lost-packet-count?   yang:counter64 {stability}?
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
            /bfd-mpls:session-groups/bfd-mpls:session-group
            /bfd-mpls:sessions/bfd-mpls:session-statistics:
    +--ro lost-packet-count?   yang:counter64 {stability}?
]]>
	    </artwork>
          </figure>
	</t> {stability}?]]></sourcecode>
      </section>

      <section title="YANG Module">
      <section>
        <name>YANG Module</name>

<!-- [rfced] Section 7.2: We note that RFC 8177 ("YANG Data Model for Key
Chains") is referenced in the YANG module that appears in this section, but it
is not included in the references section of this document or in the text that
introduces this YANG module (see below).

May we add a reference to RFC 8177 in the references section and in the text
below?

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>
	  This YANG module imports modules defined in <xref
	  target="RFC6991">Common "Common YANG Types</xref>, Data Types" <xref
	  target="RFC8349">A target="RFC6991"/>, "A YANG Data Model for Routing</xref>, and Routing Management (NMDA Version)" <xref target="RFC9314">YANG target="RFC8349"/>, and "YANG Data Model for Bidirectional
	  Forwading Forwarding Detection (BFD)</xref>. (BFD)" <xref target="RFC9314"/>.
        </t>

        <t>
	  <figure>
            <artwork><![CDATA[
	    <CODE BEGINS> file "ietf-bfd-stability@2025-10-30.yang"
<!-- [rfced] We have updated the YANG module to match the format output when using the formatting option of pyang.  See the formatting (only) updates in this file:
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 {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-stability";
  prefix "bfd-s"; bfd-s;

  import ietf-yang-types {
    prefix "yang"; yang;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-routing {
    prefix "rt"; rt;
    reference
      "RFC 8349: A YANG Data Model for Routing Management
       (NMDA version)"; Version)";
  }
  import ietf-bfd {
    prefix bfd;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection.";
  }
  import ietf-bfd-ip-sh {
    prefix bfd-ip-sh;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection."; Detection (BFD)";
  }
  import ietf-bfd-ip-mh {
    prefix bfd-ip-mh;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection."; Detection (BFD)";
  }
  import ietf-bfd-lag {
    prefix bfd-lag;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection."; Detection (BFD)";
  }
  import ietf-bfd-mpls {
    prefix bfd-mpls;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection."; Detection (BFD)";
  }
  import ietf-key-chain {
    prefix key-chain;
    reference
      "RFC 8177: YANG Data Model for Key Chain."; Chains";
  }

  organization
    "IETF BFD Working Group";
  contact
    "WG Web:   <http://tools.ietf.org/wg/bfd>
     WG List:  <rtg-bfd@ietf.org>

     Authors: Mahesh Jethanandani (mjethanandani@gmail.com)
              Ashesh Mishra (mishra.ashesh@gmail.com)
              Ankur Saxena (ankurpsaxena@gmail.com)
              Santosh Pallagatti (santosh.pallagati@gmail.com)
              Mach Chen (mach.chen@huawei.com).";
  description
    "This YANG module augments the base BFD YANG data model to add
     experimental attributes related to BFD Stability. stability.
     In particular, it adds a per-session count for BFD packets
     that are lost.

     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) 2025 2026 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); 9978; see the
     RFC itself 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."; notices.";

  revision "2025-10-30" 2026-05-05 {
    description
      "Initial Version."; version.";
    reference
      "RFC XXXX: BFD Stability."; 9978: Bidirectional Forwarding Detection (BFD) Stability";
  }

  feature stability {
    description
      "This feature enables BFD sessions to be monitored for lost
       packets.";
  }

  identity null-auth {
    base key-chain:crypto-algorithm;
    description
      "BFD Null NULL Auth type defined in this draft."; document.";
    reference
      "RFC XXXX: BFD Stability."; 9978: Bidirectional Forwarding Detection (BFD) Stability";
  }

  grouping lost-packet-count {
    leaf lost-packet-count {
      if-feature "stability";
      type yang:counter64;
      description
        "Number of BFD packets that were lost, where loss is
         determined by the fact that the sequence number is
         not consecutive.  This counter should be present only if
         stability is configured.";
    }
    description
      "Grouping of statistics related to BFD stability.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
        + "bfd-ip-sh:sessions/bfd-ip-sh:session" {
    leaf stability {
      if-feature "stability";
      type boolean;
      must "../bfd-ip-sh:authentication/bfd-ip-sh:meticulous = "
         + "'true'";
      default false; "false";
      description
        "If set to true, this enables the BFD session to monitor
         for stability, i.e., to watch how many packets are getting
         dropped.";
    }
    description
      "Augment the 'bfd' container to add attributes related to BFD
       stability for IP Single Hop Sessions."; sessions.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
        + "bfd-ip-mh:session-groups/bfd-ip-mh:session-group" {
    leaf stability {
      if-feature "stability";
      type boolean;
      must "../bfd-ip-mh:authentication/bfd-ip-mh:meticulous = "
         + "'true'";
      default false; "false";
      description
        "If set to true, this enables the BFD session to monitor
         for stability, i.e., to watch how many packets are getting
         dropped.";
    }
    description
      "Augment the 'bfd' container to add attributes related to BFD
       stability for Multi Hop Sessions."; sessions.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
        + "bfd-lag:sessions/bfd-lag:session" {
    leaf stability {
      if-feature "stability";
      type boolean;
      must "../bfd-lag:authentication/bfd-lag:meticulous = "
         + "'true'";
      default false; "false";
      description
        "If set to true, this enables the BFD session to monitor
         for stability, i.e., to watch how many packets are getting
         dropped.";
    }
    description
      "Augment the 'bfd' container to add attributes related to BFD
       stability for LAG session.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
        + "bfd-mpls:session-groups/bfd-mpls:session-group" {
    leaf stability {
      if-feature "stability";
      type boolean;
      must "../bfd-mpls:authentication/bfd-mpls:meticulous = "
         + "'true'";
      default false; "false";
      description
        "If set to true, this enables the BFD session to monitor
         for stability, i.e., to watch how many packets are getting
         dropped.";
    }
    description
      "Augment the 'bfd' container to add attributes related to BFD
       stability for MPLS.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
        + "bfd-ip-sh:sessions/bfd-ip-sh:session/"
        + "bfd-ip-sh:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       stability for IP Single Hop Sessions."; sessions.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
        + "bfd-ip-mh:session-groups/bfd-ip-mh:session-group/"
        + "bfd-ip-mh:sessions/bfd-ip-mh:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       stability for IP Multi Hop Sessions."; sessions.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
        + "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/"
        + "bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       stability for Micro BFD sessions for IPv4.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
        + "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/"
        + "bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       stability for Micro BFD sessions for IPv6.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
        + "bfd-mpls:session-groups/bfd-mpls:session-group/"
        + "bfd-mpls:sessions/bfd-mpls:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       stability for MPLS sessions.";
  }
}
	    <CODE ENDS>
	    ]]>
	    </artwork>
          </figure>
	</t>
}]]></sourcecode>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>This
    <section>
      <name>IANA Considerations</name>
<!-- [rfced] We have updated the introductory paragraph in the IANA Considerations to also mention registration of the YANG module name.  Please review and let us know if updates are required.

Original:
   This document requests one new authentication type and registers one
   URIs in the "ns" subregistry of the "IETF XML" registry <xref target="RFC3688"/>.</t>

      <section anchor="auth-type" title="Auth Type">
	<t> [RFC3688].

Current:
   This document requests an update to registers a new authentication type, a new URI in the
   "ns" registry titled "BFD
	  Authentication Types". IANA is requested to assign within the "IETF XML" registry group [RFC3688], and a
   YANG module in the "YANG Module Names" registry.
-->

      <t>This document registers a new authentication type,
      a new URI in the "ns" registry within the "IETF XML"
      registry group <xref target="RFC3688"/>, and a YANG module in the "YANG Module Names" registry.</t>
      <section anchor="auth-type">
        <name>Auth Type</name>
        <t>
	  IANA has registered the following BFD AuthType:
	  <ul>
	    <li>
	      NULL Auth Type, with a suggested value of 6.
	    </li>
	  </ul> Type in the "BFD Authentication 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 anchor="ietf-xml-registry" title="IETF anchor="ietf-xml-registry">
        <name>IETF XML Registry">
	<t>Following Registry</name>
        <t>IANA has registered the format following URI in <xref target="RFC3688"/>, the following
	registrations are requested:</t>
	<t>
	  <figure>
	    <artwork><![CDATA[URI: urn:ietf:params:xml:ns:yang:ietf-bfd-stability
Registrant Contact: The IESG
XML: N/A, "ns" registry <xref target="RFC3688"/>:</t>
<dl spacing="compact" newline="false">
  <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-stability</dd>
  <dt>Registrant Contact:</dt><dd>The IESG</dd>
  <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.
]]>
	    </artwork>
	  </figure>
	</t> namespace.</dd>
</dl>
      </section>

      <section title="The &quot;YANG
      <section>
        <name>The "YANG Module Names&quot; Registry"> Names" Registry</name>
        <t>
	  This document registers one
	  IANA has registered the following YANG module in the "YANG Module
	  Names" registry <xref target="RFC6020"/>. Following the
	  format in <xref target="RFC6020"/>, the following
	  registrations are requested: target="RFC6020"/>:
        </t>

        <t><figure>
            <artwork><![CDATA[
name:         ietf-bfd-stability
namespace:    urn:ietf:params:xml:ns:yang:ietf-bfd-stability
prefix:       bfd-s
reference:    RFC XXXX
]]></artwork>
          </figure></t>
<dl spacing="compact" newline="false">
  <dt>Name:</dt><dd>ietf-bfd-stability</dd>
  <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-stability</dd>
  <dt>Prefix:</dt><dd>bfd-s</dd>
  <dt>Reference:</dt><dd>RFC 9978</dd>
</dl>
      </section>
    </section>

    <section title="Security Considerations">
      <section title="BFD
    <section>
      <name>Security Considerations</name>
      <section>
        <name>BFD NULL Auth Security Considerations"> Considerations</name>
        <t>
	  The use of a BFD authentication mechanism that protects the
	  BFD packets is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
        </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>
	  The Security Considerations security considerations of <xref target="RFC5880"/> for
	  unauthenticated BFD all apply to the new NULL authentication
	  type.  The NULL Authentication authentication type, defined in this
	  document, provides none of the properties desired for
	  authenticating BFD packets.  It is intended to provide BFD
	  sessions that otherwise would not use authentication, authentication with a
	  sequence number that can be used for purposes the purpose of detecting
	  lost packets.
        </t>
        <t>
	  The lack of a computed AuthKey/Digest over the BFD packet,
	  but the presence of a Sequence Number sequence number, makes this
	  authentication type susceptible to injection attacks.  BFD
	  without authentication is vulnerable to session resets; the
	  NULL Auth type does not change this.</t>
        <t>
	  When the NULL Authentication authentication type is used for BFD Stability stability
	  purposes, maliciously injected packets that do not reset the
	  BFD session can resemble high packet loss. Sessions such as
	  multi-hop routed paths, tunnels without authentication, or
	  MPLS LSP, Label Switched Paths (LSPs), therefore, have security guarantees that are
	  identical to situations where BFD is run without
	  authentication.
        </t>
      </section>
      <section title="YANG
<!-- [rfced] Section 9.2 (YANG Security Considerations">
	<t> Considerations): We note some differences from the
template in the OPs wiki.  Please refer to the template at <https://wiki.ietf.org/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 template.  Please review and let us know if any updates are needed.

Original:
   The only readable data nodes in YANG module specified 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 document 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>
	  This section is modeled after the template described in <xref
	  target="RFC9907" sectionFormat="of" section="3.7.1"/>.
	</t>
	<t>
	  The "ietf-bfd-stability" YANG module defines a schema
	  for data model that is
	  designed to be accessed via network YANG-based management protocols protocols, such as
	  Network Configuration Protocol (NETCONF) <xref
	  target="RFC6241">NETCONF</xref> or target="RFC6241"/> and RESTCONF
	  <xref
	  target="RFC8040">RESTCONF</xref>. target="RFC8040"/>. These YANG-based management protocols (1) have to use a
	  secure transport layer (e.g., Secure Shell (SSH) <xref target="RFC4252">SSH</xref>, target="RFC4252"/>, TLS <xref
	  target="RFC8446">TLS</xref>, target="RFC8446"/>, and QUIC
	  <xref
	  target="RFC9000">QUIC</xref>) target="RFC9000"/>) and (2) have to use mutual authentication.
	</t>
        <t>
	  The <xref target="RFC8341">NETCONF Network Configuration Access Control Model
	  (NACM)</xref> (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
	  writeable/creatable/deletable data nodes that can have an
	  adverse impact on a BFD session.
        </t>
        <t>
	  The only
   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:
        </t>
        <t>
	  The model defines a read-only node to indicate the number of
	  packets that were lost. Access to this information may allow
	  a malicious user information on which links are experiencing
	  issues. In addition, and as stated in <xref
	  target="out-of-order-packets">Out of Order Packets</xref>, target="out-of-order-packets"/>,
	  on links such as LAG or ECMP, there is a possibility of
	  packets being delivered out-of-order. A strict comparison of
	  increasing sequence numbers may result in classifying those
	  out of order
	  out-of-order packets as packet loss.
        </t>
        <t>The YANG module does not define any RPC operations.</t>
      </section>
    </section>

    <section title="Contributors">
      <t>
	The authors

  </middle>
  <back>
    <displayreference target="I-D.ietf-bfd-secure-sequence-numbers" to="BFD-ISAAC"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9314.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9907.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"/>

<!-- [rfced] Regarding reference [Y-1731], the version of ITU-T Recommendation G.8013/Y.1731 referenced in 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 has been superseded (https://www.itu.int/rec/T-REC-G.8013-201311-S/en).

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 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
reference to this document. Thanks point to Christian Huitema
	for the SECDIR most current version?

Current:
   [Y-1731]   ITU-T, "OAM functions and Ebben Aries mechanisms for the YANG Doctors review.
      </t>
      <t>
	Thanks to Reshad Rehman 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 being the shepherd of the
	document.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119.xml'?>

      <?rfc include='reference.RFC.3688.xml'?>

      <?rfc include='reference.RFC.4252.xml'?>

      <?rfc include='reference.RFC.5880.xml'?>

      <?rfc include='reference.RFC.6020.xml'?>

      <?rfc include='reference.RFC.6991.xml'?>

      <?rfc include='reference.RFC.8174.xml'?>

      <?rfc include='reference.RFC.8341.xml'?>

      <?rfc include='reference.RFC.8349.xml'?>

      <?rfc include='reference.RFC.9314.xml'?>
    </references>
    <references title="Informative References">
      <?rfc include='reference.RFC.6241.xml'?>
      <?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'?> 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"> anchor="Y-1731" target="https://www.itu.int/rec/T-REC-G.8013-201311-S/en">
          <front>
          <title>
	    OAM Functions
            <title>OAM functions and Mechanisms mechanisms for Ethernet-based Networks Ethernet based networks
            </title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date month="November" year="2013"/>
          </front>
          <seriesInfo name="Recommendation" name="ITU-T Recommendation" value="G.8013/Y.1731"/>
        </reference>

<!-- 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>
    <section anchor="experimental-status" title="Experimental Status"> anchor="experimental-status">
      <name>Experimental Status</name>

      <t>
	This document describes an experiment that will present a
	candidate solution to predict whether a given BFD <xref
	target="RFC5880">BFD</xref> target="RFC5880"/> session will continue to be
	stable. The experiment will use the packet lost count and the
	'received-packet-count' defined in the <xref
	target="RFC9314">YANG "YANG Data Model for Bidirectional Forward Forwarding Detection (BFD)</xref> (BFD)" <xref target="RFC9314"/> to determine how stable is the
	session.
	session is. The reason why this document is on an the Experimental track is because there are no known
	implementations or proof-of-concept. proof of concept. As a result, the authors
	are not clear whether a simple lost count is enough to predict
	the stability or if there will be a need to have be a more granular
	count.
      </t>
      <t>
	This document is classified as Experimental and is not part of
	the IETF Standards Track.
      </t>
    </section>
    <section anchor="examples" title="Examples"> anchor="examples">
      <name>Examples</name>
      <t>
	This section tries to show some examples in of how the model can
	be configured for stability.
      </t>
      <section anchor="example-a.1.1" title="Single Hop anchor="example-a.1.1">
        <name>Single-Hop BFD Configuration"> Configuration</name>
        <t>
          This example demonstrates how a Single Hop single-hop BFD session can
          be configured to enable monitoring of a session for
          stability.
        </t>
	<t>
          <figure>
            <artwork><![CDATA[
        <sourcecode><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ===============

<?xml version="1.0" encoding="UTF-8"?>
<key-chains
    xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
    xmlns:kc="urn:ietf:params:xml:ns:yang:ietf-key-chain">
  <key-chain>
    <name>bfd-stability-config</name>
    <description>"An example for BFD Stabalized stabilized configuration."</de\
scription>
    <key>
      <key-id>55</key-id>
      <lifetime>
        <send-lifetime>
          <start-date-time>2025-01-01T00:00:00Z</start-date-time>
          <end-date-time>2025-02-01T00:00:00Z</end-date-time>
        </send-lifetime>
        <accept-lifetime>
          <start-date-time>2024-12-31T23:59:55Z</start-date-time>
          <end-date-time>2025-02-01T00:00:05Z</end-date-time>
        </accept-lifetime>
      </lifetime>
      <crypto-algorithm>kc:sha-1</crypto-algorithm>
    </key>
  </key-chain>
</key-chains>
<interfaces
    xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
    xmlns:if-type="urn:ietf:params:xml:ns:yang:iana-if-type">
  <interface>
    <name>eth0</name>
    <type>if-type:ethernetCsmacd</type>
  </interface>
</interfaces>
<routing
    xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"
    xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types"
    xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
">
  <control-plane-protocols>
    <control-plane-protocol>
      <type>bfd-types:bfdv1</type>
      <name>name:BFD</name>
      <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
        <ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
          <sessions>
            <session>
              <interface>eth0</interface>
              <dest-addr>2001:db8:0:113::101</dest-addr>
              <desired-min-tx-interval>10000</desired-min-tx-interv\
al>
              <required-min-rx-interval>
                10000
              </required-min-rx-interval>
              <stability:stability>true</stability:stability>
              <authentication>
                <key-chain>bfd-stability-config</key-chain>
                <meticulous>true</meticulous>
              </authentication>
            </session>
          </sessions>
        </ip-sh>
      </bfd>
    </control-plane-protocol>
  </control-plane-protocols>
</routing>
            ]]>
            </artwork>
          </figure>
	</t>
</routing>]]></sourcecode>
      </section>
      <section anchor="example-a.1.2" title="Use anchor="example-a.1.2">
        <name>Use of NULL Auth"> Auth</name>
        <t>
          This example demonstrates how to configure NULL Auth
          to enable monitoring of a session for stability.
        </t>
	<t>
          <figure>
            <artwork><![CDATA[
        <sourcecode><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ===============

<?xml version="1.0" encoding="UTF-8"?>
<key-chains
    xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
    xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
">
  <key-chain>
    <name>bfd-stability-config</name>
    <description>"An example for BFD Stability stability configuration."</des\
cription>
    <key>
      <key-id>55</key-id>
      <lifetime>
        <send-lifetime>
          <start-date-time>2025-01-01T00:00:00Z</start-date-time>
          <end-date-time>2025-02-01T00:00:00Z</end-date-time>
        </send-lifetime>
        <accept-lifetime>
          <start-date-time>2024-12-31T23:59:55Z</start-date-time>
          <end-date-time>2025-02-01T00:00:05Z</end-date-time>
        </accept-lifetime>
      </lifetime>
      <crypto-algorithm>stability:null-auth</crypto-algorithm>
    </key>
  </key-chain>
</key-chains>
<interfaces
    xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
    xmlns:if-type="urn:ietf:params:xml:ns:yang:iana-if-type">
  <interface>
    <name>eth0</name>
    <type>if-type:ethernetCsmacd</type>
  </interface>
</interfaces>
<routing
    xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"
    xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types"
    xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
">
  <control-plane-protocols>
    <control-plane-protocol>
      <type>bfd-types:bfdv1</type>
      <name>name:BFD</name>
      <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
        <ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
          <sessions>
            <session>
              <interface>eth0</interface>
              <dest-addr>2001:db8:0:113::101</dest-addr>
              <desired-min-tx-interval>10000</desired-min-tx-interv\
al>
              <required-min-rx-interval>
                10000
              </required-min-rx-interval>
              <stability:stability>true</stability:stability>
              <authentication>
                <key-chain>bfd-stability-config</key-chain>
                <meticulous>true</meticulous>
              </authentication>
            </session>
          </sessions>
        </ip-sh>
      </bfd>
    </control-plane-protocol>
  </control-plane-protocols>
</routing>
            ]]>
            </artwork>
          </figure>
</routing>]]></sourcecode>

      </section>
    </section>

    <section numbered="false">
      <name>Acknowledgements</name>
      <t>
	The authors would like to thank <contact fullname="Nobo Akiya"/>, <contact
	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"/> for
	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>
</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 the document?

NULL Auth type
NULL Auth Type
NULL Auth

Note that "authentication type" (lowercase) is used except where the text explicitly 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 and 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 the 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)
-->