rfc9468xml2.original.xml   rfc9468.xml 
<?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!ENTITY nbsp "&#160;">
.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC5082 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!ENTITY nbhy "&#8209;">
.5082.xml"> <!ENTITY wj "&#8288;">
<!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">
<!ENTITY RFC8446 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8446.xml">
<!ENTITY RFC6241 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6241.xml">
<!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/referenc
e.RFC.9314.xml"> -->
]> ]>
<?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" ipr="trust200902" docName="draft-ietf-bfd-unsolicited-16" su
bmissionType="IETF">
<front>
<title>Unsolicited BFD for Sessionless Applications</title>
<author fullname="Enke Chen" initials="E." surname="Chen"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<organization>Palo Alto Networks</organization> -ietf-bfd-unsolicited-16" number="9468" submissionType="IETF" category="std" con
<address> sensus="true" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="tru
<postal> e" tocInclude="true" tocDepth="3" version="3">
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>enchen@paloaltonetworks.com</email>
</address>
</author>
<author fullname="Naiming Shen" initials="N." surname="Shen"> <!-- xml2rfc v2v3 conversion 3.17.1 -->
<organization>Zededa</organization> <front>
<address> <title abbrev="Unsolicited BFD for Sessionless Applications">Unsolicited Bid
<email>naiming@zededa.com</email> irectional Forwarding Detection (BFD) for Sessionless Applications</title>
</address> <seriesInfo name="RFC" value="9468"/>
</author> <author fullname="Enke Chen" initials="E." surname="Chen">
<author fullname='Robert Raszuk' initials='R' surname='Raszuk'> <organization>Palo Alto Networks</organization>
<organization>Arrcus</organization> <address>
<address>
<postal> <postal>
<street>2077 Gateway Place</street> <street>3000 Tannery Way</street>
<city>San Jose</city> <city>Santa Clara</city>
<region>CA</region> <region>CA</region>
<code>95110</code> <code>95054</code>
<country>USA</country> <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">
<organization>Arrcus</organization>
<address>
<postal>
<street>2077 Gateway Place</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>United States of America</country>
</postal> </postal>
<email>robert@raszuk.net</email> <email>robert@raszuk.net</email>
</address> </address>
</author> </author>
<author fullname="Reshad Rahman" initials="R." surname="Rahman"> <author fullname="Reshad Rahman" initials="R." surname="Rahman">
<organization>Graphiant</organization> <organization>Equinix</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<region></region> <region/>
<code></code> <code/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>reshad@yahoo.com</email> <email>reshad@yahoo.com</email>
</address> </address>
</author> </author>
<date year="2023" /> <date year="2023" month="August"/>
<area>rtg</area>
<abstract> <workgroup>bfd</workgroup>
<t> <abstract>
<t>
For operational simplification of "sessionless" applications For operational simplification of "sessionless" applications
using Bidirectional Forwarding Detection (BFD), in this document we p resent procedures using Bidirectional Forwarding Detection (BFD), in this document, we present procedures
for "unsolicited BFD" that allow a BFD session to be initiated for "unsolicited BFD" that allow a BFD session to be initiated
by only one side, and established without explicit per-session by only one side and established without explicit per-session
configuration or registration by the other side (subject to certain configuration or registration by the other side (subject to certain
per-interface or global policies). per-interface or global policies).
</t> </t>
<t> <t>
We also introduce a new YANG module We also introduce a new YANG module
to configure and manage "unsolicited BFD". The YANG module in this d ocument to configure and manage "unsolicited BFD". The YANG module in this d ocument
is based on YANG 1.1 as defined in RFC 7950 and conforms to the Netw is based on YANG 1.1, as defined in RFC 7950, and conforms to the Ne
ork Management twork Management
Datastore Architecture (NMDA) as described in RFC 8342. This documen Datastore Architecture (NMDA), as described in RFC 8342. This docume
t augments RFC 9314. nt augments RFC 9314.
</t> </t>
</abstract> </abstract>
</front>
<note title="Requirements Language"> <middle>
<t> <section anchor="intro" numbered="true" toc="default">
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <name>Introduction</name>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <t>
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> whe
n, and only when, they
appear in all capitals, as shown here.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
The current implementation and deployment practice for BFD The current implementation and deployment practice for BFD
(<xref target="RFC5880"/> and <xref target="RFC5881"/>) (<xref target="RFC5880" format="default"/> and <xref target="RFC5881
usually requires BFD sessions be explicitly " format="default"/>)
usually requires that BFD sessions be explicitly
configured or registered on both sides. This requirement is configured or registered on both sides. This requirement is
not an issue when an application like BGP <xref target="RFC4271"/> not an issue when an application like BGP <xref target="RFC4271" for mat="default"/>
has the concept of a "session" that involves both sides for its has the concept of a "session" that involves both sides for its
establishment. establishment.
However, this requirement can be operationally challenging However, this requirement can be operationally challenging
when the prerequisite "session" does not when the prerequisite "session" does not
naturally exist between two endpoints in an application. naturally exist between two endpoints in an application.
Simultaneous configuration and coordination Simultaneous configuration and coordination
may be required on both sides for BFD to take effect. For example: may be required on both sides for BFD to take effect. For example:
</t> </t>
<ul spacing="normal">
<t> <li>
<list style="symbols"> When BFD is used to keep track of the "liveness" of the next hop
<t>
When BFD is used to keep track of the "liveness" of the nexthop
of static routes. Although only one side may need the BFD of static routes. Although only one side may need the BFD
functionality, currently both sides need to be involved in functionality, currently, both sides need to be involved in
specific configuration and coordination and in some cases specific configuration and coordination, and in some cases,
static routes are created unnecessarily just for BFD. static routes are created unnecessarily just for BFD.
</t> </li>
<li>
<t>
When BFD is used to keep track of the "liveness" of the When BFD is used to keep track of the "liveness" of the
third-pary nexthop of BGP routes received from the Route Server third-party next hop of BGP routes received from the Route Server
<xref target="RFC7947"/> at an Internet Exchange Point (IXP). As t <xref target="RFC7947" format="default"/> at an Internet Exchange P
he oint (IXP). As the
third-party nexthop is different from the peering address of third-party next hop is different from the peering address of
the Route Server, for BFD to work, currently two routers peering the Route Server, for BFD to work, currently, two routers peering
with the Route Server need to have routes and nexthops from each with the Route Server need to have routes and next hops from each
other (although indirectly via the Route Server). other (although indirectly via the Route Server).
</t> </li>
</list> </ul>
</t> <t>
Clearly, it is beneficial and desirable to reduce or eliminate
<t>
Clearly it is beneficial and desirable to reduce or eliminate
unnecessary configurations and coordination in these unnecessary configurations and coordination in these
"sessionless" applications using BFD. "sessionless" applications using BFD.
</t> </t>
<t>
<t> In this document, we present procedures
In this document we present procedures
for "unsolicited BFD" that allow a BFD session to be initiated for "unsolicited BFD" that allow a BFD session to be initiated
by only one side, and established without explicit per-session by only one side and established without explicit per-session
configuration or registration by the other side (subject to certain configuration or registration by the other side (subject to certain
per-interface or global policies). per-interface or global policies).
</t> </t>
<t>Unsolicited BFD impacts only the initiation of BFD sessions. There is <t>Unsolicited BFD impacts only the initiation of BFD sessions. There is n
no change to all the other procedures specified in o change to all the other procedures specified in
<xref target="RFC5880"/> such as, but not limited to, the Echo functio <xref target="RFC5880" format="default"/>, such as, but not limited to
n and Demand mode.</t> , the Echo function and Demand mode.</t>
<t>
<t> With "unsolicited BFD", there is potential risk for
With "unsolicited BFD" there is potential risk for
excessive resource usage by BFD from "unexpected" remote systems. excessive resource usage by BFD from "unexpected" remote systems.
To mitigate such risks, To mitigate such risks,
several mechanisms are recommended in the Security Considerations several mechanisms are recommended in the Security Considerations
section. section.
</t> </t>
<t>The procedure described in this document could be applied to BFD <t>The procedure described in this document could be applied to BFD for mu
for Multihop paths <xref target="RFC5883"/>. ltihop paths <xref target="RFC5883" format="default"/>.
However, because of security risks, this document applies only to However, because of security risks, this document applies only to
BFD for single IP hops <xref target="RFC5881"/>.</t> BFD for single IP hops <xref target="RFC5881" format="default"/>.</t>
<t>
<t> Compared to the "Seamless BFD" <xref target="RFC7880" format="default
Compared to the "Seamless BFD" <xref target="RFC7880"/>, this proposa "/>, this proposal involves
l involves
only minor procedural enhancements to the widely deployed BFD itself. only minor procedural enhancements to the widely deployed BFD itself.
Thus, we believe that this proposal is inherently simpler in the Thus, we believe that this proposal is inherently simpler in the
protocol itself and deployment. protocol itself and deployment.
As an example, it does not require the exchange of BFD As an example, it does not require the exchange of BFD
discriminators over an out-of-band channel before BFD session bring-u p. discriminators over an out-of-band channel before BFD session bring-u p.
</t> </t>
<t>
<t> When BGP ADD-PATH <xref target="RFC7911" format="default"/> is deploy
When BGP Add-Path <xref target="RFC7911"/> is deployed at an IXP usin ed at an IXP using a Route Server,
g a Route Server,
multiple BGP paths (when they exist) can be made available to the cli ents of the multiple BGP paths (when they exist) can be made available to the cli ents of the
Route Server as described in <xref target="RFC7947"/>. Route Server, as described in <xref target="RFC7947" format="default"
Unsolicited BFD can be used by BGP route selection's Route Resolvabil />.
ity Condition Unsolicited BFD can be used by BGP route selection's route resolvabil
<xref target="RFC4271" section="9.1.2.1"/> to exclude routes where th ity condition
e NEXT_HOP is not (<xref target="RFC4271" 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. reachable using the procedures specified in this document.
</t> </t>
</section> <section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Procedures for Unsolicited BFD"> <t>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 numbered="true" toc="default">
<name>Procedures for Unsolicited BFD</name>
<t>
With "unsolicited BFD", one side takes the "Active role" With "unsolicited BFD", one side takes the "Active role"
and the other side takes only the "Passive role" as and the other side takes the "Passive role", as
described in <xref target="RFC5880"/>, section 6.1. described in <xref target="RFC5880" section="6.1" sectionFormat="co
</t> mma" format="default"/>.
</t>
<t> <t>
Passive unsolicited BFD support MUST be disabled by default, and Passive unsolicited BFD support <bcp14>MUST</bcp14> be disabled by
MUST require explicit configuration to be enabled. default and
On the passive side, the following BFD parameters, from <xref targ <bcp14>MUST</bcp14> require explicit configuration to be enabled.
et="RFC5880"/> section 6.8.1 SHOULD be configurable: On the passive side, the following BFD parameters, from <xref targ
<list style="symbols"> et="RFC5880" section="6.8.1" sectionFormat="comma" format="default"/>, <bcp14>SH
<t>bfd.DesiredMinTxInterval</t> OULD</bcp14> be configurable:
<t>bfd.RequiredMinRxInterval</t> </t>
<t>bfd.DetectMult</t> <ul spacing="normal">
</list> <li>bfd.DesiredMinTxInterval</li>
The passive side MAY also choose to use the values of the paramete <li>bfd.RequiredMinRxInterval</li>
rs above that <li>bfd.DetectMult</li>
the active side uses in its BFD Control packets. However, the bfd.L </ul>
ocalDiscr value MUST be selected by the passive side <t>
The passive side <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.L
ocalDiscr value <bcp14>MUST</bcp14> be selected by the passive side
to allow multiple unsolicited BFD sessions. to allow multiple unsolicited BFD sessions.
</t> </t>
<t>
<t> The active side starts sending the BFD Control packets, as specifi
The active side starts sending the BFD Control packets as specifie ed in
d in <xref target="RFC5880" format="default"/>. The passive side does not se
<xref target="RFC5880"/>. The passive side does not send BFD Control pa nd BFD Control packets initially;
ckets initially,
it sends BFD Control packets only after it has received BFD Control pac kets from the active side. it sends BFD Control packets only after it has received BFD Control pac kets from the active side.
</t> </t>
<t>
<t>
When the passive side receives a BFD Control packet from the activ e side When the passive side receives a BFD Control packet from the activ e side
with 0 as "Your Discriminator" and does not find an existing BFD sessio n, with 0 as "Your Discriminator" and does not find an existing BFD sessio n,
the passive side SHOULD create a matching BFD session toward the active side, the passive side <bcp14>SHOULD</bcp14> create a matching BFD session to ward the active side,
unless not permitted by local configuration or policy.</t> unless not permitted by local configuration or policy.</t>
<t> <t>
When the passive side receives an incoming BFD Control packet on a numbered interface, When the passive side receives an incoming BFD Control packet on a numbered interface,
the source address of that packet MUST belong to the subnet of the the source address of that packet <bcp14>MUST</bcp14> belong to the
interface on which the BFD subnet of the interface on which the BFD
packet is received, else the BFD control packet MUST NOT be process packet is received, else the BFD Control packet <bcp14>MUST NOT</bc
ed.</t> p14> be processed.</t>
<t>
<t> The passive side <bcp14>MUST</bcp14> then start sending BFD Control pac
The passive side MUST then start sending BFD Control packets and perfor kets and perform the necessary
m the necessary procedure for bringing up, maintaining, and tearing down the BFD sessio
procedure for bringing up, maintaining and tearing down the BFD session n.
.
If the BFD session fails to get established within a certain amount of time 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 l (which is implementation specific but has to be at least equal to the l
ocal failure detection time), ocal failure detection time)
or if an established BFD session goes down, the passive side MUST stop or if an established BFD session goes down, the passive side <bcp14>MUS
sending BFD Control packets and SHOULD delete the BFD session created u T</bcp14> stop
ntil sending BFD Control packets and <bcp14>SHOULD</bcp14> delete the BFD se
ssion created until
BFD Control packets are initiated by the active side again. BFD Control packets are initiated by the active side again.
</t> </t>
<t>
<t> When an unsolicited BFD session goes down, an implementation may retain
When an Unsolicited BFD session goes down, an implementation may retain
the session state for a period of time. the session state for a period of time.
Retaining this state can be useful for operational purposes. Retaining this state can be useful for operational purposes.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="State Variables"> <name>State Variables</name>
<t>
<t> This document defines a new state variable called Role:
This document defines a new state variable called Role. </t>
</t> <t>
<t>
bfd.Role bfd.Role
</t> </t>
<t> <t>
The role of the local system during BFD session initialization, as per <xr This is the role of the local system during BFD session initialization, as
ef target="RFC5880"/>, section 6.1. per <xref target="RFC5880" section="6.1" sectionFormat="comma" format="default"
/>.
Possible values are Active or Passive. Possible values are Active or Passive.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>YANG Data Model</name>
<section title="YANG Data Model"> <t>
<t> This section extends the YANG data model for BFD <xref target="RFC93
This section extends the YANG data model for BFD <xref target="RFC93 14" format="default"/>
14"/> to cover unsolicited BFD.
to cover unsolicited BFD. The new module imports <xref target="RFC834 The new module imports the YANG modules described in <xref target=
9"/> since the "bfd" "RFC8349" format="default"/>
container in <xref target="RFC9314"/> is under "control-plane-protoc since the "bfd" container in <xref target="RFC9314" format="default"/> is unde
ol". r
"control-plane-protocol".
The YANG module in this document conforms to the Network Management The YANG module in this document conforms to the Network Management
Datastore Architecture (NMDA) <xref target="RFC8342"/>. Datastore Architecture (NMDA) <xref target="RFC8342" format="default
</t> "/>.
</t>
<section title="Unsolicited BFD Hierarchy"> <section numbered="true" toc="default">
<t>Configuration for unsolicited BFD parameters for IP single-hop se <name>Unsolicited BFD Hierarchy</name>
ssions can be done at 2 levels: <t>Configuration for unsolicited BFD parameters for IP single-hop sessio
<list style="symbols"> ns can be done at 2 levels:
<t>Globally, i.e. for all interfaces.</t> </t>
<t>For specific interfaces. This requires support for the "unsolicit <ul spacing="normal">
ed-params-per-interface" feature.</t> <li>globally, i.e., for all interfaces</li>
</list> <li>for specific interfaces (this requires support for the "unsolicite
d-params-per-interface" feature)</li>
</ul>
<t>
If configuration exists at both levels, per-interface configuration takes precedence over global configuration. If configuration exists at both levels, per-interface configuration takes precedence over global configuration.
</t> </t>
<t>For operational data, a new "role" leaf node has been added for B <t>For operational data, a new "role" leaf node has been added for BFD I
FD IP single-hop sessions.</t> P single-hop sessions.</t>
<t>The tree diagram below uses the graphical representation of data <t>The tree diagram below uses the graphical representation of data mode
models, as defined in <xref target="RFC8340"/>.</t> ls, as defined in <xref target="RFC8340" format="default"/>.</t>
<figure align="left"> <t keepWithNext="true"/>
<preamble/> <sourcecode type="yangtree"><![CDATA[
<artwork align="left"><![CDATA[
module: ietf-bfd-unsolicited module: ietf-bfd-unsolicited
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh: /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh:
+--rw unsolicited? +--rw unsolicited?
+--rw local-multiplier? multiplier +--rw local-multiplier? multiplier
+--rw (interval-config-type)? +--rw (interval-config-type)?
+--:(tx-rx-intervals) +--:(tx-rx-intervals)
| +--rw desired-min-tx-interval? uint32 | +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32 | +--rw required-min-rx-interval? uint32
+--:(single-interval) {single-minimum-interval}? +--:(single-interval) {single-minimum-interval}?
+--rw min-interval? uint32 +--rw min-interval? uint32
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:interfaces: /bfd-ip-sh:interfaces:
+--rw unsolicited +--rw unsolicited
+--rw enabled? boolean +--rw enabled? boolean
+--rw local-multiplier? bfd-types:multiplier {bfd-unsol:u +--rw local-multiplier?
nsolicited-params-per-interface}? bfd-types:multiplier
+--rw (interval-config-type)? {bfd-unsol:unsolicited-params-per-interface {bfd-unsol:unsolicited-params-per-interface}?
}? +--rw (interval-config-type)?
{bfd-unsol:unsolicited-params-per-interface}?
+--:(tx-rx-intervals) +--:(tx-rx-intervals)
| +--rw desired-min-tx-interval? uint32 | +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32 | +--rw required-min-rx-interval? uint32
+--:(single-interval) {bfd-types:single-minimum-interval}? +--:(single-interval) {bfd-types:single-minimum-interval}?
+--rw min-interval? uint32 +--rw min-interval? uint32
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session: /bfd-ip-sh:sessions/bfd-ip-sh:session:
+--ro role? bfd-unsol:role +--ro role? bfd-unsol:role
]]></sourcecode>
]]></artwork> </section>
</figure> <section numbered="true" toc="default">
</section> <name>Unsolicited BFD Module</name>
<t keepWithNext="true"/>
<section title="Unsolicited BFD Module"> <sourcecode name="ietf-bfd-unsolicited@2023-08-16.yang" type="yang" mark
<figure align="left"> ers="true"><![CDATA[
<preamble/>
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-unsolicited@2023-04-22.yang"
module ietf-bfd-unsolicited { module ietf-bfd-unsolicited {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited";
prefix "bfd-unsol"; prefix bfd-unsol;
// RFC Ed.: replace occurences of YYYY with actual RFC numbers
// and remove this note
import ietf-bfd-types { import ietf-bfd-types {
prefix "bfd-types"; prefix bfd-types;
reference reference
"RFC 9314: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix "bfd"; prefix bfd;
reference reference
"RFC 9314: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-bfd-ip-sh { import ietf-bfd-ip-sh {
prefix "bfd-ip-sh"; prefix bfd-ip-sh;
reference reference
"RFC 9314: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA Version)";
} }
organization "IETF BFD Working Group"; organization
"IETF BFD Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/bfd/> "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org> WG List: <rtg-bfd@ietf.org>
Editors: Enke Chen (enchen@paloaltonetworks.com), Editors: Enke Chen (enchen@paloaltonetworks.com),
Naiming Shen (naiming@zededa.com), Naiming Shen (naiming@zededa.com),
Robert Raszuk (robert@raszuk.net), Robert Raszuk (robert@raszuk.net),
Reshad Rahman (reshad@yahoo.com)"; Reshad Rahman (reshad@yahoo.com)";
description description
"This module contains the YANG definition for BFD unsolicited "This module contains the YANG definition for unsolicited BFD,
as per RFC YYYY. as per RFC 9468.
Copyright (c) 2023 IETF Trust and the persons Copyright (c) 2023 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC YYYY; see This version of this YANG module is part of RFC 9468; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
reference "RFC YYYY"; reference
"RFC 9468: Unsolicited Bidirectional Forwarding Detection
(BFD) for Sessionless Applications";
revision 2023-04-22 { revision 2023-08-16 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC YYYY: Unsolicited BFD for Sessionless Applications."; "RFC 9468: Unsolicited Bidirectional Forwarding Detection (BFD)
for Sessionless Applications";
} }
/* /*
* Feature definitions * Feature definitions
*/ */
feature unsolicited-params-per-interface { feature unsolicited-params-per-interface {
description description
"This feature indicates that the server supports per-interface "This feature indicates that the server supports per-interface
parameters for unsolicited sessions."; parameters for unsolicited sessions.";
reference reference
"RFC YYYY: Unsolicited BFD for Sessionless Applications."; "RFC 9468: Unsolicited Bidirectional Forwarding Detection (BFD)
for Sessionless Applications";
} }
/* /*
* Type Definitions * Type Definitions
*/ */
identity role { identity role {
description description
"Base identity from which all roles are derived. "Base identity from which all roles are derived.
Role of local system during BFD session initialization."; Role of local system during BFD session initialization.";
} }
identity active { identity active {
base "bfd-unsol:role"; base bfd-unsol:role;
description "Active role"; description
"Active role.";
reference reference
"RFC5880: Bidirectional Forwarding Detection (BFD), "RFC 5880: Bidirectional Forwarding Detection (BFD),
Section 6.1"; Section 6.1";
} }
identity passive { identity passive {
base "bfd-unsol:role"; base bfd-unsol:role;
description "Passive role"; description
"Passive role.";
reference reference
"RFC5880: Bidirectional Forwarding Detection (BFD), "RFC 5880: Bidirectional Forwarding Detection (BFD),
Section 6.1"; Section 6.1";
} }
/* /*
* Augments * 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";
container unsolicited {
description
"BFD IP single-hop unsolicited top level container";
uses bfd-types:base-cfg-parms;
}
}
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" {
+ "bfd-ip-sh:interfaces" { description
description "Augmentation for unsolicited BFD parameters.";
"Augmentation for BFD unsolicited on IP single-hop interface"; container unsolicited {
container unsolicited { description
description "BFD IP single-hop unsolicited top-level container.";
"BFD IP single-hop interface unsolicited top level uses bfd-types:base-cfg-parms;
container"; }
leaf enabled { }
type boolean;
default false;
description
"BFD unsolicited 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;
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 configured at the global level.";
}
choice interval-config-type { augment "/rt:routing/rt:control-plane-protocols/"
if-feature bfd-unsol:unsolicited-params-per-interface; + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
description + "bfd-ip-sh:interfaces" {
"Two interval values or one value used for both transmit and description
receive. Defaults to ../../unsolicited/interval-config-type. "Augmentation for unsolicited BFD on IP single-hop
An interval configured under an interface takes precedence interface.";
over any interval configured at the global level."; container unsolicited {
case tx-rx-intervals { description
leaf desired-min-tx-interval { "BFD IP single-hop interface unsolicited top-level
type uint32; container.";
units "microseconds"; leaf enabled {
description type boolean;
"Desired minimum transmit interval of control packets."; default "false";
} description
leaf required-min-rx-interval { "Unsolicited BFD is enabled on this interface.";
type uint32; }
units "microseconds"; /*
description * The following is the same as bfd-types:base-cfg-parms, but
"Required minimum receive interval of control packets."; * without default values (for inheritance)
} */
} leaf local-multiplier {
case single-interval { if-feature "bfd-unsol:unsolicited-params-per-interface";
if-feature "bfd-types:single-minimum-interval"; type bfd-types:multiplier;
leaf min-interval { description
type uint32; "Multiplier transmitted by the local system. Defaults to
units "microseconds"; ../../unsolicited/local-multiplier.
description A multiplier configured under an interface takes
"Desired minimum transmit interval and required precedence over the multiplier configured at the global
minimum receive interval of control packets."; level.";
} }
} choice interval-config-type {
} if-feature "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/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:sessions/bfd-ip-sh:session" { + "bfd-ip-sh:sessions/bfd-ip-sh:session" {
description description
"Augmentation for BFD unsolicited on IP single-hop session"; "Augmentation for unsolicited BFD on IP single-hop session.";
leaf role { leaf role {
type identityref { type identityref {
base "bfd-unsol:role"; base bfd-unsol:role;
}
config false;
description "Role.";
} }
config false;
description
"Role.";
}
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork> </section>
</figure> <section numbered="true" toc="default">
</section> <name>Data Model Example</name>
<section title="Data Model Example"> <t>This section shows an example on how to configure the passive end of
<t>This section shows an example on how to configure the passive end of unsoli unsolicited BFD:
cited BFD: </t>
<list style="symbols"> <ul spacing="normal">
<t>We have global BFD IP single-hop unsolicited configuration with a loca <li>We have global BFD IP single-hop unsolicited configuration with a
l-multiplier of 2 and min-interval at 50ms</t> local-multiplier of 2 and min-interval at 50 ms.</li>
<t>BFD IP single-hop unsolicited is enabled on interface eth0, with a loc <li>BFD IP single-hop unsolicited is enabled on interface eth0 with a
al-multiplier of 3 and min-interval at 250 ms</t> local-multiplier of 3 and min-interval at 250 ms.</li>
<t>BFD IP single-hop unsolicited is enabled on interface eth1. Since ther <li>BFD IP single-hop unsolicited is enabled on interface eth1. Since
e is no parameter configuration for eth1, it inherits from the global configurat there is no parameter configuration for eth1, it inherits from the global config
ion.</t> uration.</li>
</list> </ul>
</t> <t keepWithNext="true"/>
<figure align="left"> <sourcecode type="xml"><![CDATA[
<preamble/>
<artwork align="left"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<type <type
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:etherne xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
tCsmacd</type> ianaift:ethernetCsmacd</type>
</interface> </interface>
<interface> <interface>
<name>eth1</name> <name>eth1</name>
<type <type
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:etherne xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
tCsmacd</type> ianaift:ethernetCsmacd</type>
</interface> </interface>
</interfaces> </interfaces>
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"> <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<control-plane-protocols> <control-plane-protocols>
<control-plane-protocol> <control-plane-protocol>
<type <type xmlns:bfd-types=
xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types">bfd-types "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
:bfdv1</type> bfd-types:bfdv1</type>
<name>name:BFD</name> <name>name:BFD</name>
<bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd"> <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
<ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh"> <ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
<unsolicited> <unsolicited>
<local-multiplier>2</local-multiplier> <local-multiplier>2</local-multiplier>
<min-interval>50000</min-interval> <min-interval>50000</min-interval>
</unsolicited> </unsolicited>
<interfaces> <interfaces>
<interface>eth0</interface> <interface>eth0</interface>
<unsolicited> <unsolicited>
skipping to change at line 599 skipping to change at line 576
<unsolicited> <unsolicited>
<enabled>true</enabled> <enabled>true</enabled>
</unsolicited> </unsolicited>
</interfaces> </interfaces>
</ip-sh> </ip-sh>
</bfd> </bfd>
</control-plane-protocol> </control-plane-protocol>
</control-plane-protocols> </control-plane-protocols>
</routing> </routing>
</config> </config>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<t>
<section title="IANA Considerations"> IANA has registered the following namespace URI in the "ns" subregis
<t> try within the "IETF XML Registry" <xref target="RFC3688" format="default"/>:
This document registers the following namespace URI in the "IETF XML </t>
Registry" <xref target="RFC3688"/>: <dl newline="false" spacing="compact">
</t> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited</dd>
<t>URI: urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited</t> <dt>Registrant Contact:</dt> <dd>The IESG.</dd>
<t>Registrant Contact: The IESG.</t> <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
<t>XML: N/A; the requested URI is an XML namespace.</t> </dl>
<t> <t>
This document registers the following YANG module in the "YANG Modul IANA has registered the following YANG module in the "YANG Module Na
e Names" registry <xref target="RFC6020"/>: mes" registry <xref target="RFC6020" format="default"/>:
</t> </t>
<t>Name: ietf-bfd-unsolicited</t> <dl newline="false" spacing="compact">
<t>Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited</t> <dt>Name:</dt> <dd>ietf-bfd-unsolicited</dd>
<t>Prefix: bfd-unsol</t> <dt>Maintained by IANA:</dt><dd>N</dd>
<t>Reference: RFC YYYY</t> <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited<
</section> /dd>
<dt>Prefix:</dt> <dd>bfd-unsol</dd>
<section title="Acknowledgments"> <dt>Reference:</dt> <dd>RFC 9468</dd>
</dl>
<t>Authors would like to thank Acee Lindem, Alvaro Retana, Dan Romascanu, </section>
Derek Atkins, Greg Mirsky, Gyan Mishra, Henning Rogge, Jeffrey Haas, <section numbered="true" toc="default">
John Scudder, Lars Eggert, Magnus Westerlund, Mahesh Jethanandani, Murray <name>Security Considerations</name>
Kucherawy, Raj Chetan, Robert Wilton, Roman Danyliw, Tom Petch, <section anchor="BFD-Security" numbered="true" toc="default">
and Zaheduzzaman Sarker for their review and valuable input.</t> <name>BFD Protocol Security Considerations</name>
<t>
</section>
<section title="Security Considerations">
<section anchor="BFD-Security" title="BFD Protocol Security Considerat
ions">
<t>
The same security considerations and protection measures as those des cribed The same security considerations and protection measures as those des cribed
in <xref target="RFC5880"/> and <xref target="RFC5881"/> apply in <xref target="RFC5880" format="default"/> and <xref target="RFC5881" fo rmat="default"/> apply
to this document. to this document.
In addition, with "unsolicited BFD" there is potential risk for exces In addition, with "unsolicited BFD", there is potential risk for exce
sive resource usage ssive resource usage
by BFD from "unexpected" remote systems. To mitigate such risks, implement by BFD from "unexpected" remote systems. To mitigate such risks, implement
ations of unsolicited BFD MUST: ations of unsolicited BFD <bcp14>MUST</bcp14>:
</t> </t>
<ul spacing="normal">
<t> <li>
<list style="symbols"> Limit the feature to specific interfaces and to single-hop BFD sessions usi
<t> ng the procedures from
Limit the feature to specific interfaces, and to single-hop BFD sessions us <xref target="RFC5082" format="default"/>. See <xref target="RFC5881" sect
ing the procedures from ion="5" format="default"/> for the details of these procedures.
<xref target="RFC5082"/>. See <xref target="RFC5881" section="5"/> for the </li>
details of these procedures. <li>
</t>
<t>
Apply policy to process BFD packets only from certain subnets or hosts. Apply policy to process BFD packets only from certain subnets or hosts.
</t> </li>
<t> <li>
Deploy the feature only in an environment that does not Deploy the feature only in an environment that does not
offer anonymous participation. Examples include an IXP, offer anonymous participation. Examples include an IXP,
where the IXP operator will have a business relationship with where the IXP operator will have a business relationship with
all IXP participants, or between a provider and its customers. all IXP participants, or between a provider and its customers.
</t> </li>
</list> </ul>
</t> </section>
</section> <section numbered="true" toc="default">
<section title="BFD Protocol Authentication Considerations"> <name>BFD Protocol Authentication Considerations</name>
<t> <t>
Implementations of unsolicited BFD are RECOMMENDED to Implementations of unsolicited BFD are <bcp14>RECOMMENDED</bcp14> to
use BFD authentication; see <xref target="RFC5880"/>. use BFD authentication; see <xref target="RFC5880" format="default"/>.
If BFD authentication is used, the strongest BFD authentication mechanism t If BFD authentication is used, the strongest BFD authentication mechanism t
hat is supported MUST be used. hat is supported <bcp14>MUST</bcp14> be used.
</t> </t>
<t> <t>
In some environments, such as an Internet Exchange Points (IXPs), BFD authe In some environments, such as IXPs, BFD authentication cannot be used becau
ntication cannot be used because of the lack of coordination for the operation o se of the lack of coordination for the operation of the two endpoints of the BFD
f the two endpoints of the BFD session. session.
</t> </t>
<t> <t>
In other environments, such as when BFD is used to track the next hop of st In other environments, such as when BFD is used to track the next hop of st
atic routes, it is possible to use BFD authentication. This comes with the extra atic routes, it is possible to use BFD authentication. This comes with the extra
cost of configuring matching keychains between the two endpoints. cost of configuring matching key chains between the two endpoints.
</t> </t>
</section> </section>
<section title="YANG Module Security Considerations">
<t>The YANG module specified in this document defines a schema for data <!--[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 numbered="true" toc="default">
<name>YANG Module Security 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 that is designed to be accessed via network management protocols such as
NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref target ="RFC8040" format="default"/>.
The lowest NETCONF layer is the secure transport layer, and the The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH) <xref mandatory-to-implement secure transport is Secure Shell (SSH) <xref target
target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the ="RFC6242" format="default"/>. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS <xref mandatory-to-implement secure transport is TLS <xref target="RFC8446" form
target="RFC8446"/>.</t> at="default"/>.</t>
<t>The Network Configuration Access Control Mode (NACM) <xref target="RF
<t>The NETCONF access control model <xref target="RFC8341"/> provides C8341" format="default"/> provides
the means to restrict access for particular NETCONF or RESTCONF users to the means to restrict access for particular NETCONF or RESTCONF users to
a preconfigured subset of all available NETCONF or RESTCONF protocol a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.</t> operations and content.</t>
<t>There are a number of data nodes defined in this YANG module that are
<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). writable/creatable/deletable (i.e., config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., edit-config) to these data network environments. Write operations (e.g., edit-config) to these data
nodes without proper protection can have a negative effect on network nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:</t> sensitivity/vulnerability:</t>
<!-- DNE ends -->
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh <dl newline="true" spacing="normal">
<dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
/unsolicited: /unsolicited:
<list style="symbols"> </dt>
<t>data node "enabled" enables creation of unsolicited BFD IP single-hop s <dd>
essions globally, i.e. on all interfaces. <ul spacing="normal">
See <xref target="BFD-Security"/>.</t> <li>Data node "enabled" enables creation of unsolicited BFD IP single-
<t>data nodes local-multiplier, desired-min-tx-interval, hop sessions globally, i.e., on all interfaces.
required-min-rx-interval and min-interval all impact the parameters of the See <xref target="BFD-Security" format="default"/>.</li>
unsolicited <li>Data nodes "local-multiplier", "desired-min-tx-interval",
"required-min-rx-interval", and "min-interval" all impact the parameters o
f the unsolicited
BFD IP single-hop sessions. Write operations to these nodes change the 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 rates of BFD packet generation and detection time of the failures of a
BFD session.</t> BFD session.</li>
</list> </ul>
</t> </dd>
<dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
/interfaces/interface/unsolicited: /interfaces/interface/unsolicited:
<list style="symbols"> </dt>
<t>data node "enabled" enables creation of unsolicited BFD IP single-hop s <dd>
essions on a specific interface. <ul spacing="normal">
See <xref target="BFD-Security"/>.</t> <li>Data node "enabled" enables the creation of unsolicited BFD IP sin
<t>data nodes local-multiplier, desired-min-tx-interval, gle-hop sessions on a specific interface.
required-min-rx-interval and min-interval all impact the parameters of the See <xref target="BFD-Security" format="default"/>.</li>
unsolicited <li>Data nodes "local-multiplier", "desired-min-tx-interval",
BFD IP single-hop sessions on the interface.</t> "required-min-rx-interval", and "min-interval" all impact the parameters o
</list> f the unsolicited
</t> BFD IP single-hop sessions on the interface.</li>
</ul>
<t>Some of the readable data nodes in this YANG module may be considered </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 sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data nodes notification) to these data nodes. These are the subtrees and data nodes
and their sensitivity/vulnerability:</t> and their sensitivity/vulnerability:</t>
<!-- DNE ends -->
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh <dl newline="true" spacing="normal">
/sessions/session/role: <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
access to this information discloses the role of the local system in the c /sessions/session/role:</dt>
reation of the unsolicited BFD session.</t> <dd>Access to this information discloses the role of the local system in
the creation of the unsolicited BFD session.</dd>
</section> </dl>
</section> </section>
</section>
</middle> </middle>
<back>
<back> <references>
<references title="Normative References"> <name>References</name>
&RFC2119; <references>
&RFC3688; <name>Normative References</name>
&RFC5082; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC5880; 119.xml"/>
&RFC5881; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
&RFC6020; 688.xml"/>
&RFC6241; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
&RFC6242; 082.xml"/>
&RFC8040; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
&RFC8174; 880.xml"/>
&RFC8340; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
&RFC8341; 881.xml"/>
&RFC8349; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
&RFC8446; 020.xml"/>
&RFC9314; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</references> 241.xml"/>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
&RFC4271; 242.xml"/>
&RFC5883; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC7880; 040.xml"/>
&RFC7911; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC7947; 174.xml"/>
&RFC8342; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</references> 340.xml"/>
</back> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
349.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
314.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
883.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
880.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
911.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
947.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
342.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Acee Lindem"/>, <con
tact fullname="Alvaro Retana"/>, <contact fullname="Dan Romascanu"/>, <contact f
ullname="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"/>, <co
ntact fullname="Magnus Westerlund"/>, <contact fullname="Mahesh Jethanandani"/>,
<contact fullname="Murray Kucherawy"/>, <contact fullname="Raj Chetan"/>, <cont
act fullname="Robert Wilton"/>, <contact fullname="Roman Danyliw"/>, <contact fu
llname="Tom Petch"/>,
and <contact fullname="Zaheduzzaman Sarker"/> for their reviews and valuab
le input.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 81 change blocks. 
593 lines changed or deleted 602 lines changed or added

This html diff was produced by rfcdiff 1.48.