<?xml version="1.0"?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5082 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml">
<!ENTITY RFC5880 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC5881 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml">
<!ENTITY RFC5883 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml">
<!ENTITY RFC4271 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC7880 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7880.xml">
<!ENTITY RFC7911 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7911.xml">
<!ENTITY RFC7947 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7947.xml"> nbsp    "&#160;">
  <!ENTITY RFC8446 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"> zwsp   "&#8203;">
  <!ENTITY RFC6241 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"> nbhy   "&#8209;">
  <!ENTITY RFC6242 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY RFC8341 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml">
<!ENTITY RFC8040 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC3688 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC6020 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC8340 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml">
<!ENTITY RFC8342 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml">
<!ENTITY RFC8349 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml">
<!ENTITY RFC9314 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9314.xml">

<!-- <!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9314.xml"> --> wj     "&#8288;">
]>
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>

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

  <!-- xml2rfc v2v3 conversion 3.17.1 -->
  <front>
	<title>Unsolicited
    <title abbrev="Unsolicited BFD for Sessionless Applications">Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications</title>
    <seriesInfo name="RFC" value="9468"/>
    <author fullname="Enke Chen" initials="E." surname="Chen">
      <organization>Palo Alto Networks</organization>
      <address>
        <postal>
		<street></street>
		<city></city>
		<region></region>
		<code></code>
		<country></country>
          <street>3000 Tannery Way</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95054</code>
          <country>United States of America</country>
        </postal>
        <email>enchen@paloaltonetworks.com</email>
      </address>
    </author>
    <author fullname="Naiming Shen" initials="N." surname="Shen">
      <organization>Zededa</organization>
      <address>
	<postal>
	  <street>160 W Santa Clara Street</street>
	  <city>San Jose</city>
	  <region>CA</region>
	  <code>95113</code>
	  <country>United States of America</country>
	</postal>
        <email>naiming@zededa.com</email>
      </address>
    </author>
    <author fullname='Robert Raszuk' initials='R' surname='Raszuk'> fullname="Robert Raszuk" initials="R." surname="Raszuk">
      <organization>Arrcus</organization>
      <address>
        <postal>
          <street>2077 Gateway Place</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95110</code>
            <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>robert@raszuk.net</email>
      </address>
    </author>
    <author fullname="Reshad Rahman" initials="R." surname="Rahman">
	    <organization>Graphiant</organization>
      <organization>Equinix</organization>
      <address>
        <postal>
		<street></street>
		<city></city>
		<region></region>
		<code></code>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Canada</country>
        </postal>
        <email>reshad@yahoo.com</email>
      </address>
    </author>
    <date year="2023" /> month="August"/>
    <area>rtg</area>
    <workgroup>bfd</workgroup>
    <abstract>
      <t>
	    For operational simplification of "sessionless" applications
	    using Bidirectional Forwarding Detection (BFD), in this document document, we present procedures
	    for "unsolicited BFD" that allow a BFD session to be initiated
	    by only one side, side and established without explicit per-session
	    configuration or registration by the other side (subject to certain
	    per-interface or global policies).
      </t>
      <t>
            We also introduce a new YANG module
            to configure and manage "unsolicited BFD". The YANG module in this document
            is based on YANG 1.1 1.1, as defined in RFC 7950 7950, and conforms to the Network Management
            Datastore Architecture (NMDA) (NMDA), as described in RFC 8342. This document augments RFC 9314.
      </t>
    </abstract>

	<note title="Requirements Language">
	    <t>
       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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
       appear in all capitals, as shown here.

	    </t>
	</note>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
            The current implementation and deployment practice for BFD
            (<xref target="RFC5880"/> target="RFC5880" format="default"/> and <xref target="RFC5881"/>) target="RFC5881" format="default"/>)
	    usually requires that BFD sessions be explicitly
            configured or registered on both sides. This requirement is
            not an issue when an application like BGP <xref target="RFC4271"/> target="RFC4271" format="default"/>
            has the concept of a "session" that involves both sides for its
            establishment.
            However, this requirement can be operationally challenging
            when the prerequisite "session" does not
            naturally exist between two endpoints in an application.
            Simultaneous configuration and coordination
            may be required on both sides for BFD to take effect. For example:
      </t>

	    <t>
                <list style="symbols">
	        <t>
      <ul spacing="normal">
        <li>
             When BFD is used to keep track of the "liveness" of the nexthop next hop
             of static routes. Although only one side may need the BFD
             functionality, currently currently, both sides need to be involved in
             specific configuration and coordination coordination, and in some cases cases,
             static routes are created unnecessarily just for BFD.
                </t>

                <t>
                </li>
        <li>
             When BFD is used to keep track of the "liveness" of the
             third-pary nexthop
             third-party next hop of BGP routes received from the Route Server
             <xref target="RFC7947"/> target="RFC7947" format="default"/> at an Internet Exchange Point (IXP).  As the
             third-party nexthop next hop is different from the peering address of
             the Route Server, for BFD to work, currently currently, two routers peering
             with the Route Server need to have routes and nexthops next hops from each
             other (although indirectly via the Route Server).
	        </t>
		</list>
	    </t>
	        </li>
      </ul>
      <t>
            Clearly
            Clearly, it is beneficial and desirable to reduce or eliminate
            unnecessary configurations and coordination in these
            "sessionless" applications using BFD.
      </t>
      <t>
	    In this document document, we present procedures
	    for "unsolicited BFD" that allow a BFD session to be initiated
	    by only one side, side and established without explicit per-session
	    configuration or registration by the other side (subject to certain
	    per-interface or global policies).
      </t>
      <t>Unsolicited BFD impacts only the initiation of BFD sessions. There is no change to all the other procedures specified in
          <xref target="RFC5880"/> target="RFC5880" format="default"/>, such as, but not limited to, the Echo function and Demand mode.</t>
      <t>
	    With "unsolicited BFD" BFD", there is potential risk for
	    excessive resource usage by BFD from "unexpected" remote systems.
	    To mitigate such risks,
	    several mechanisms are recommended in the Security Considerations
	    section.
      </t>
      <t>The procedure described in this document could be applied to BFD for Multihop multihop paths <xref target="RFC5883"/>. target="RFC5883" format="default"/>.
               However, because of security risks, this document applies only to BFD for single IP hops  <xref target="RFC5881"/>.</t> target="RFC5881" format="default"/>.</t>
      <t>
	    Compared to the "Seamless BFD" <xref target="RFC7880"/>, target="RFC7880" format="default"/>, this proposal involves
	    only minor procedural enhancements to the widely deployed BFD itself.
	    Thus, we believe that this proposal is inherently simpler in the
	    protocol itself and deployment.
	    As an example, it does not require the exchange of BFD
	    discriminators over an out-of-band channel before BFD session bring-up.
      </t>
      <t>
	    When BGP Add-Path ADD-PATH <xref target="RFC7911"/> target="RFC7911" format="default"/> is deployed at an IXP using a Route Server,
	    multiple BGP paths (when they exist) can be made available to the clients of the
	    Route Server Server, as described in <xref target="RFC7947"/>. target="RFC7947" format="default"/>.
	    Unsolicited BFD can be used by BGP route selection's Route Resolvability Condition
	    <xref route resolvability condition
	    (<xref target="RFC4271" section="9.1.2.1"/> section="9.1.2.1" sectionFormat="of" format="default"/>) to exclude routes where the NEXT_HOP is not
	    reachable using the procedures specified in this document.
      </t>
      <section numbered="true" toc="default">
      <name>Requirements Language</name>
	        <t>
    The key words "<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 "<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>
      </section>
    </section>
    <section title="Procedures numbered="true" toc="default">
      <name>Procedures for Unsolicited BFD"> BFD</name>
      <t>
	      With "unsolicited BFD", one side takes the "Active role"
	      and the other side takes only the "Passive role" role", as
	      described in <xref target="RFC5880"/>, section 6.1. target="RFC5880" section="6.1" sectionFormat="comma" format="default"/>.
      </t>
      <t>
	      Passive unsolicited BFD support MUST <bcp14>MUST</bcp14> be disabled by default, default and
              MUST
              <bcp14>MUST</bcp14> require explicit configuration to be enabled.
              On the passive side, the following BFD parameters, from <xref target="RFC5880"/> section 6.8.1 SHOULD target="RFC5880" section="6.8.1" sectionFormat="comma" format="default"/>, <bcp14>SHOULD</bcp14> be configurable:
              <list style="symbols">
              <t>bfd.DesiredMinTxInterval</t>
              <t>bfd.RequiredMinRxInterval</t>
              <t>bfd.DetectMult</t>
              </list>
      </t>
      <ul spacing="normal">
        <li>bfd.DesiredMinTxInterval</li>
        <li>bfd.RequiredMinRxInterval</li>
        <li>bfd.DetectMult</li>
      </ul>
      <t>
              The passive side MAY <bcp14>MAY</bcp14> also choose to use the values of the parameters listed above that
	      the active side uses in its BFD Control packets. However, the bfd.LocalDiscr value MUST <bcp14>MUST</bcp14> be selected by the passive side
        to allow multiple unsolicited BFD sessions.
      </t>
      <t>
	       The active side starts sending the BFD Control packets packets, as specified in
         <xref target="RFC5880"/>. target="RFC5880" format="default"/>. The passive side does not send BFD Control packets initially, initially;
         it sends BFD Control packets only after it has received BFD Control packets from the active side.
      </t>
      <t>
	       When the passive side receives a BFD Control packet from the active side
         with 0 as "Your Discriminator" and does not find an existing BFD session,
         the passive side SHOULD <bcp14>SHOULD</bcp14> create a matching BFD session toward the active side,
         unless not permitted by local configuration or policy.</t>
      <t>
             When the passive side receives an incoming BFD Control packet on a numbered interface,
             the source address of that packet MUST <bcp14>MUST</bcp14> belong to the subnet of the interface on which the BFD
             packet is received, else the BFD control Control packet MUST NOT <bcp14>MUST NOT</bcp14> be processed.</t>
      <t>
         The passive side MUST <bcp14>MUST</bcp14> then start sending BFD Control packets and perform the necessary
         procedure for bringing up, maintaining maintaining, and tearing down the BFD session.
         If the BFD session fails to get established within a certain amount of time
         (which is implementation specific but has to be at least equal to the local failure detection time), time)
         or if an established BFD session goes down, the passive side MUST <bcp14>MUST</bcp14> stop
         sending BFD Control packets and SHOULD <bcp14>SHOULD</bcp14> delete the BFD session created until
         BFD Control packets are initiated by the active side again.
      </t>
      <t>
         When an Unsolicited unsolicited BFD session goes down, an implementation may retain
         the session state for a period of time.
         Retaining this state can be useful for operational purposes.
      </t>
    </section>
    <section title="State Variables"> numbered="true" toc="default">
      <name>State Variables</name>
      <t>
      This document defines a new state variable called Role. Role:
      </t>
      <t>
      bfd.Role
      </t>
      <t>
      The
      This is the role of the local system during BFD session initialization, as per <xref target="RFC5880"/>, section 6.1. target="RFC5880" section="6.1" sectionFormat="comma" format="default"/>.
      Possible values are Active or Passive.
      </t>
    </section>
    <section title="YANG numbered="true" toc="default">
      <name>YANG Data Model"> Model</name>
      <t>
            This section extends the YANG data model for BFD <xref target="RFC9314"/> target="RFC9314" format="default"/>
	    to cover unsolicited BFD.
              The new module imports the YANG modules described in <xref target="RFC8349"/> target="RFC8349" format="default"/>
  since the "bfd" container in <xref target="RFC9314"/> target="RFC9314" format="default"/> is under
  "control-plane-protocol".
            The YANG module in this document conforms to the Network Management
            Datastore Architecture (NMDA) <xref target="RFC8342"/>. target="RFC8342" format="default"/>.
      </t>
      <section title="Unsolicited numbered="true" toc="default">
        <name>Unsolicited BFD Hierarchy"> Hierarchy</name>
        <t>Configuration for unsolicited BFD parameters for IP single-hop sessions can be done at 2 levels:
            <list style="symbols">
            <t>Globally, i.e.
        </t>
        <ul spacing="normal">
          <li>globally, i.e., for all interfaces.</t>
            <t>For interfaces</li>
          <li>for specific interfaces. This interfaces (this requires support for the "unsolicited-params-per-interface" feature.</t>
            </list> feature)</li>
        </ul>
        <t>
            If configuration exists at both levels, per-interface configuration takes precedence over global configuration.
        </t>
        <t>For operational data, a new "role" leaf node has been added for BFD IP single-hop sessions.</t>
        <t>The tree diagram below uses the graphical representation of data models, as defined in <xref target="RFC8340"/>.</t>
        <figure align="left">
          <preamble/>

          <artwork align="left"><![CDATA[ target="RFC8340" format="default"/>.</t>
        <t keepWithNext="true"/>
        <sourcecode type="yangtree"><![CDATA[
module: ietf-bfd-unsolicited

  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh:
    +--rw unsolicited?
       +--rw local-multiplier?                 multiplier
       +--rw (interval-config-type)?
          +--:(tx-rx-intervals)
          |  +--rw desired-min-tx-interval?    uint32
          |  +--rw required-min-rx-interval?   uint32
          +--:(single-interval) {single-minimum-interval}?
             +--rw min-interval?               uint32
  augment /rt:routing/rt:control-plane-protocols
          /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
          /bfd-ip-sh:interfaces:
    +--rw unsolicited
       +--rw enabled?                          boolean
       +--rw local-multiplier?
            bfd-types:multiplier
             {bfd-unsol:unsolicited-params-per-interface}?
       +--rw (interval-config-type)?
               {bfd-unsol:unsolicited-params-per-interface}?
          +--:(tx-rx-intervals)
          |  +--rw desired-min-tx-interval?    uint32
          |  +--rw required-min-rx-interval?   uint32
          +--:(single-interval) {bfd-types:single-minimum-interval}?
             +--rw min-interval?               uint32
  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:
    +--ro role?   bfd-unsol:role

             ]]></artwork>
        </figure>
             ]]></sourcecode>
      </section>
      <section title="Unsolicited BFD Module">
        <figure align="left">
	  <preamble/>

          <artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-unsolicited@2023-04-22.yang" numbered="true" toc="default">
        <name>Unsolicited BFD Module</name>
        <t keepWithNext="true"/>
        <sourcecode name="ietf-bfd-unsolicited@2023-08-16.yang" type="yang" markers="true"><![CDATA[
module ietf-bfd-unsolicited {

  yang-version 1.1;

  namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited";

  prefix "bfd-unsol";

  // RFC Ed.: replace occurences of YYYY with actual RFC numbers
  // and remove this note bfd-unsol;

  import ietf-bfd-types {
    prefix "bfd-types"; bfd-types;
    reference
      "RFC 9314: YANG Data Model for Bidirectional Forwarding
       Detection (BFD)";
  }

  import ietf-bfd {
    prefix "bfd"; bfd;
    reference
      "RFC 9314: YANG Data Model for Bidirectional Forwarding
       Detection (BFD)";
  }

  import ietf-bfd-ip-sh {
    prefix "bfd-ip-sh"; bfd-ip-sh;
    reference
      "RFC 9314: YANG Data Model for Bidirectional Forwarding
       Detection (BFD)";
  }

  import ietf-routing {
    prefix "rt"; rt;
    reference
      "RFC 8349: A YANG Data Model for Routing Management
       (NMDA version)"; Version)";
  }

  organization
    "IETF BFD Working Group";

  contact
    "WG Web:   <https://datatracker.ietf.org/wg/bfd/>
     WG List:  <rtg-bfd@ietf.org>

     Editors:  Enke Chen (enchen@paloaltonetworks.com),
               Naiming Shen (naiming@zededa.com),
               Robert Raszuk (robert@raszuk.net),
               Reshad Rahman (reshad@yahoo.com)";

  description
    "This module contains the YANG definition for BFD unsolicited BFD,
     as per RFC YYYY. 9468.

     Copyright (c) 2023 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, the Revised BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC YYYY; 9468; see
     the RFC itself for full legal notices.";

  reference
    "RFC YYYY"; 9468: Unsolicited Bidirectional Forwarding Detection
     (BFD) for Sessionless Applications";

  revision 2023-04-22 2023-08-16 {
    description
      "Initial revision.";
    reference
      "RFC YYYY: 9468: Unsolicited BFD Bidirectional Forwarding Detection (BFD)
       for Sessionless Applications."; Applications";
  }

  /*
   * Feature definitions
   */
  feature unsolicited-params-per-interface {
    description
      "This feature indicates that the server supports per-interface
       parameters for unsolicited sessions.";
    reference
      "RFC YYYY: 9468: Unsolicited BFD Bidirectional Forwarding Detection (BFD)
       for Sessionless Applications."; Applications";
  }

  /*
   * Type Definitions
   */

  identity role {
    description
      "Base identity from which all roles are derived.
       Role of local system during BFD session initialization.";
  }

  identity active {
    base "bfd-unsol:role"; bfd-unsol:role;
    description
      "Active role"; role.";
    reference
      "RFC5880:
      "RFC 5880: Bidirectional Forwarding Detection (BFD),
       Section 6.1";
  }

  identity passive {
    base "bfd-unsol:role"; bfd-unsol:role;
    description
      "Passive role"; role.";
    reference
      "RFC5880:
      "RFC 5880: Bidirectional Forwarding Detection (BFD),
       Section 6.1";
  }

  /*
   * Augments
   */

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" {
    description
      "Augmentation for BFD unsolicited parameters"; BFD parameters.";
    container unsolicited {
      description
        "BFD IP single-hop unsolicited top level container"; top-level container.";
      uses bfd-types:base-cfg-parms;
    }
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
        + "bfd-ip-sh:interfaces" {
    description
      "Augmentation for BFD unsolicited BFD on IP single-hop interface";
       interface.";
    container unsolicited {
      description
        "BFD IP single-hop interface unsolicited top level
          container"; top-level
         container.";
      leaf enabled {
        type boolean;
        default false; "false";
        description
           "BFD unsolicited
          "Unsolicited BFD is enabled on this interface.";
      }
      /*
       * The following is the same as bfd-types:base-cfg-parms, but
       * without default values (for inheritance)
       */
      leaf local-multiplier {
        if-feature bfd-unsol:unsolicited-params-per-interface; "bfd-unsol:unsolicited-params-per-interface";
        type bfd-types:multiplier;
        description
          "Multiplier transmitted by the local system.  Defaults to
           ../../unsolicited/local-multiplier.
           A multiplier configured under an interface takes
           precedence over the mulitiplier multiplier configured at the global
           level.";
      }
      choice interval-config-type {
        if-feature bfd-unsol:unsolicited-params-per-interface; "bfd-unsol:unsolicited-params-per-interface";
        description
          "Two interval values or one value used for both transmit
           and receive.  Defaults to
           ../../unsolicited/interval-config-type.  An interval
           configured under an interface takes precedence over any
           interval configured at the global level.";
        case tx-rx-intervals {
          leaf desired-min-tx-interval {
            type uint32;
            units "microseconds";
            description
              "Desired minimum transmit interval of control
               packets.";
          }
          leaf required-min-rx-interval {
            type uint32;
            units "microseconds";
            description
              "Required minimum receive interval of control
               packets.";
          }
        }
        case single-interval {
          if-feature "bfd-types:single-minimum-interval";
          leaf min-interval {
            type uint32;
            units "microseconds";
            description
              "Desired minimum transmit interval and required
               minimum receive interval of control packets.";
          }
        }
      }
    }
  }

  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" {
    description
      "Augmentation for BFD unsolicited BFD on IP single-hop session"; session.";
    leaf role {
      type identityref {
        base "bfd-unsol:role"; bfd-unsol:role;
      }
      config false;
      description
        "Role.";
    }
  }
}
<CODE ENDS>
        ]]></artwork>
        </figure>
]]></sourcecode>
      </section>
      <section title="Data numbered="true" toc="default">
        <name>Data Model Example"> Example</name>
        <t>This section shows an example on how to configure the passive end of unsolicited BFD:
       <list style="symbols">
       <t>We
        </t>
        <ul spacing="normal">
          <li>We have global BFD IP single-hop unsolicited configuration with a local-multiplier of 2 and min-interval at 50ms</t>
       <t>BFD 50 ms.</li>
          <li>BFD IP single-hop unsolicited is enabled on interface eth0, eth0 with a local-multiplier of 3 and min-interval at 250 ms</t>
       <t>BFD ms.</li>
          <li>BFD IP single-hop unsolicited is enabled on interface eth1. Since there is no parameter configuration for eth1, it inherits from the global configuration.</t>
       </list>
  </t>
          <figure align="left">
	  <preamble/>

          <artwork align="left"><![CDATA[ configuration.</li>
        </ul>
        <t keepWithNext="true"/>
        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
  <interface>
    <name>eth0</name>
    <type
        xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
        xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
         ianaift:ethernetCsmacd</type>
  </interface>
  <interface>
    <name>eth1</name>
    <type
        xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
        xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
         ianaift:ethernetCsmacd</type>
  </interface>
</interfaces>
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
  <control-plane-protocols>
    <control-plane-protocol>
      <type
          xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types">bfd-types:bfdv1</type> xmlns:bfd-types=
        "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
         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">
          <unsolicited>
            <local-multiplier>2</local-multiplier>
            <min-interval>50000</min-interval>
          </unsolicited>
          <interfaces>
              <interface>eth0</interface>
              <unsolicited>
                <enabled>true</enabled>
                <local-multiplier>3</local-multiplier>
                <min-interval>250000</min-interval>
              </unsolicited>
          </interfaces>
          <interfaces>
              <interface>eth1</interface>
              <unsolicited>
                <enabled>true</enabled>
              </unsolicited>
          </interfaces>
        </ip-sh>
      </bfd>
    </control-plane-protocol>
  </control-plane-protocols>
</routing>
</config>
        ]]></artwork>
        </figure>
        ]]></sourcecode>
      </section>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
            This document registers
            IANA has registered the following namespace URI in the "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688"/>: target="RFC3688" format="default"/>:
      </t>
            <t>URI:  urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited</t>
            <t>Registrant Contact:  The IESG.</t>
            <t>XML:  N/A;
      <dl newline="false" spacing="compact">
      <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited</dd>
      <dt>Registrant Contact:</dt>  <dd>The IESG.</dd>
      <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</t> namespace.</dd>
      </dl>
      <t>
            This document registers
            IANA has registered the following YANG module in the "YANG Module Names" registry <xref target="RFC6020"/>: target="RFC6020" format="default"/>:
      </t>
            <t>Name:  ietf-bfd-unsolicited</t>
            <t>Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited</t>
            <t>Prefix:  bfd-unsol</t>
            <t>Reference:  RFC YYYY</t>
	</section>

	<section title="Acknowledgments">

	<t>Authors would like to thank Acee Lindem, Alvaro Retana, Dan Romascanu, Derek Atkins, Greg Mirsky, Gyan Mishra, Henning Rogge, Jeffrey Haas,
      John Scudder, Lars Eggert, Magnus Westerlund, Mahesh Jethanandani, Murray Kucherawy, Raj Chetan, Robert Wilton, Roman Danyliw, Tom Petch,
      and Zaheduzzaman Sarker for their review and valuable input.</t>
      <dl newline="false" spacing="compact">
      <dt>Name:</dt>  <dd>ietf-bfd-unsolicited</dd>
      <dt>Maintained by IANA:</dt><dd>N</dd>
      <dt>Namespace:</dt>  <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited</dd>
      <dt>Prefix:</dt>  <dd>bfd-unsol</dd>
      <dt>Reference:</dt>  <dd>RFC 9468</dd>
      </dl>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <section anchor="BFD-Security" title="BFD numbered="true" toc="default">
        <name>BFD Protocol Security Considerations"> Considerations</name>
        <t>
	    The same security considerations and protection measures as those described
      in <xref target="RFC5880"/> target="RFC5880" format="default"/> and <xref target="RFC5881"/> target="RFC5881" format="default"/> apply
      to this document.

	    In addition, with "unsolicited BFD" BFD", there is potential risk for excessive resource usage
      by BFD from "unexpected" remote systems. To mitigate such risks, implementations of unsolicited BFD MUST: <bcp14>MUST</bcp14>:
        </t>

	   <t>
     <list style="symbols">
	   <t>
        <ul spacing="normal">
          <li>
     Limit the feature to specific interfaces, interfaces and to single-hop BFD sessions using the procedures from
     <xref target="RFC5082"/>. target="RFC5082" format="default"/>.  See <xref target="RFC5881" section="5"/> section="5" format="default"/> for the details of these procedures.
     </t>
     <t>
     </li>
          <li>
     Apply policy to process BFD packets only from certain subnets or hosts.
      </t>
	    <t>
      </li>
          <li>
     Deploy the feature only in an environment that does not
     offer anonymous participation. Examples include an IXP,
     where the IXP operator will have a business relationship with
     all IXP participants, or between a provider and its customers.
	   </t>
	   </list>
	    </t>
	   </li>
        </ul>
      </section>
      <section title="BFD numbered="true" toc="default">
        <name>BFD Protocol Authentication Considerations"> Considerations</name>
        <t>
     Implementations of unsolicited BFD are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to
     use BFD authentication; see <xref target="RFC5880"/>. target="RFC5880" format="default"/>.
     If BFD authentication is used, the strongest BFD authentication mechanism that is supported MUST <bcp14>MUST</bcp14> be used.
        </t>
        <t>
     In some environments, such as an Internet Exchange Points (IXPs), IXPs, BFD authentication cannot be used because of the lack of coordination for the operation of the two endpoints of the BFD session.
        </t>
        <t>
     In other environments, such as when BFD is used to track the next hop of static routes, it is possible to use BFD authentication. This comes with the extra cost of configuring matching keychains key chains between the two endpoints.
        </t>
      </section>

<!--[rfced] *[AD] We note that the fifth paragraph of the YANG
Security Considerations boilerplate at
<https://wiki.ietf.org/group/ops/yang-security-guidelines> is not
included. Please review and confirm that this paragraph is not
necessary.
-->

      <section title="YANG numbered="true" toc="default">
        <name>YANG Module Security Considerations"> Considerations</name>
<!-- DNE begins -->
        <t>The YANG module specified in this document defines a schema for data
      that is designed to be accessed via network management protocols such as
      NETCONF <xref target="RFC6241"/> target="RFC6241" format="default"/> or RESTCONF <xref target="RFC8040"/>. target="RFC8040" format="default"/>.
      The lowest NETCONF layer is the secure transport layer, and the
      mandatory-to-implement secure transport is Secure Shell (SSH) <xref
      target="RFC6242"/>. target="RFC6242" format="default"/>. The lowest RESTCONF layer is HTTPS, and the
      mandatory-to-implement secure transport is TLS <xref
      target="RFC8446"/>.</t> target="RFC8446" format="default"/>.</t>
        <t>The NETCONF access control model Network Configuration Access Control Mode (NACM) <xref target="RFC8341"/> target="RFC8341" format="default"/> 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>There are a number of data nodes defined in this YANG module that are
      writable/creatable/deletable (i.e., config true, which is the default).
      These data nodes may be considered sensitive or vulnerable in some
      network environments. Write operations (e.g., edit-config) to these data
      nodes without proper protection can have a negative effect on network
      operations. These are the subtrees and data nodes and their
	sensitivity/vulnerability:</t>

      <t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
<!-- DNE ends -->
	<dl newline="true" spacing="normal">
        <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
         /unsolicited:
      <list style="symbols">
      <t>data
        </dt>
	<dd>
        <ul spacing="normal">
          <li>Data node "enabled" enables creation of unsolicited BFD IP single-hop sessions globally, i.e. i.e., on all interfaces.
         See <xref target="BFD-Security"/>.</t>
      <t>data target="BFD-Security" format="default"/>.</li>
          <li>Data nodes local-multiplier, desired-min-tx-interval,
      required-min-rx-interval "local-multiplier", "desired-min-tx-interval",
      "required-min-rx-interval", and min-interval "min-interval" all impact the parameters of the unsolicited
      BFD IP single-hop sessions. Write operations to these nodes change the
      rates of BFD packet generation and detection time of the failures of a
      BFD session.</t>
      </list>
      </t>

      <t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh session.</li>
        </ul>
	</dd>
        <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
         /interfaces/interface/unsolicited:
      <list style="symbols">
      <t>data
        </dt>
	<dd>
        <ul spacing="normal">
          <li>Data node "enabled" enables the creation of unsolicited BFD IP single-hop sessions on a specific interface.
         See <xref target="BFD-Security"/>.</t>
      <t>data target="BFD-Security" format="default"/>.</li>
          <li>Data nodes local-multiplier, desired-min-tx-interval,
      required-min-rx-interval "local-multiplier", "desired-min-tx-interval",
      "required-min-rx-interval", and min-interval "min-interval" all impact the parameters of the unsolicited
      BFD IP single-hop sessions on the interface.</t>
      </list>
      </t> interface.</li>
        </ul>
	</dd></dl>
<!-- DNE begins -->
        <t>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. These are the subtrees and data nodes
	and their sensitivity/vulnerability:</t>

      <t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
         /sessions/session/role:
      access
<!-- DNE ends -->
	<dl newline="true" spacing="normal">
        <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
         /sessions/session/role:</dt>
	 <dd>Access to this information discloses the role of the local system in the creation of the unsolicited BFD session.</t> session.</dd>
       </dl>
      </section>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	    &RFC2119;
	    &RFC3688;
	    &RFC5082;
	    &RFC5880;
	    &RFC5881;
	    &RFC6020;
	    &RFC6241;
	    &RFC6242;
	    &RFC8040;
	    &RFC8174;
	    &RFC8340;
	    &RFC8341;
	    &RFC8349;
	    &RFC8446;
	    &RFC9314;
    <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.5082.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.5881.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.6241.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.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.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.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.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9314.xml"/>
      </references>
	<references title="Informative References">
	    &RFC4271;
	    &RFC5883;
	    &RFC7880;
	    &RFC7911;
	    &RFC7947;
	    &RFC8342;
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7880.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7911.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7947.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>
      </references>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank <contact fullname="Acee Lindem"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Dan Romascanu"/>, <contact fullname="Derek Atkins"/>, <contact fullname="Greg Mirsky"/>, <contact fullname="Gyan Mishra"/>, <contact fullname="Henning Rogge"/>, <contact fullname="Jeffrey Haas"/>,
      <contact fullname="John Scudder"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Magnus Westerlund"/>, <contact fullname="Mahesh Jethanandani"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Raj Chetan"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Tom Petch"/>,
      and <contact fullname="Zaheduzzaman Sarker"/> for their reviews and valuable input.</t>
    </section>
  </back>
</rfc>