rfc9127xml2.original.xml   rfc9127.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc symrefs="yes"?> docName="draft-ietf-bfd-yang-17" number="9127" ipr="trust200902"
<?rfc sortrefs="yes"?> obsoletes="" updates="" submissionType="IETF" category="std"
<rfc category="std" docName="draft-ietf-bfd-yang-17" ipr="trust200902"> consensus="true" xml:lang="en" tocInclude="true" tocDepth="6"
symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.47.0 -->
<front> <front>
<title abbrev="BFD YANG">YANG Data Model for Bidirectional Forwarding <title abbrev="BFD YANG">YANG Data Model for Bidirectional Forwarding
Detection (BFD)</title> Detection (BFD)</title>
<seriesInfo name="RFC" value="9127"/>
<author fullname="Reshad Rahman" initials="R." role="editor" <author fullname="Reshad Rahman" initials="R." role="editor" surname="Rahman
surname="Rahman"> ">
<organization>Cisco Systems</organization> <organization></organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>reshad@yahoo.com</email>
<email>rrahman@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Lianshu Zheng" initials="L." role="editor" surname="Zheng"
<author fullname="Lianshu Zheng" initials="L." role="editor" >
surname="Zheng">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>veronique_cheng@hotmail.com</email>
<email>vero.zheng@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Mahesh Jethanandani" initials="M." role="editor" surname="
<author fullname="Mahesh Jethanandani" initials="M." role="editor" Jethanandani">
surname="Jethanandani">
<organization>Xoriant Corporation</organization> <organization>Xoriant Corporation</organization>
<address> <address>
<postal> <postal>
<street>1248 Reamwood Ave</street> <street>1248 Reamwood Ave</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>California</region> <region>California</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>mjethanandani@gmail.com</email> <email>mjethanandani@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Santosh Pallagatti" initials="S." surname="Pallagatti"> <author fullname="Santosh Pallagatti" initials="S." surname="Pallagatti">
<organization>Rtbrick</organization> <organization>VMware</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>santosh.pallagatti@gmail.com</email> <email>santosh.pallagatti@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky"> <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>ZTE Corporation</organization> <organization>Ericsson</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<date month="October" year="2021"/>
<date day="1" month="August" year="2018"/> <keyword>Liveliness check</keyword>
<keyword>BGP</keyword>
<keyword>OSPF</keyword>
<keyword>IS-IS</keyword>
<keyword>TCP-AO</keyword>
<keyword>MD5</keyword>
<abstract> <abstract>
<t>This document defines a YANG data model that can be used to configure <t>This document defines a YANG data model that can be used to configure
and manage Bidirectional Forwarding Detection (BFD).</t> and manage Bidirectional Forwarding Detection (BFD).</t>
<t>The YANG modules in this document conform to the Network Management <t>The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA).</t> Datastore Architecture (NMDA) (RFC 8342).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>This document defines a YANG data model that can be used to configure <t>This document defines a YANG data model that can be used to configure
and manage Bidirectional Forwarding Detection <xref and manage Bidirectional Forwarding Detection (BFD) <xref target="RFC5880"
target="RFC5880">(BFD) </xref>. BFD is a network protocol which is used format="default"></xref>. BFD is a network protocol that is used
for liveness detection of arbitrary paths between systems. Some examples for liveness detection of arbitrary paths between systems. Some examples
of different types of paths over which we have BFD:</t> of different types of paths over which we have BFD are as follows:</t>
<t>1) Two systems directly connected via IP. This is known as BFD over
single-hop IP, a.k.a. <xref target="RFC5881">BFD for IPv4 and IPv6
</xref></t>
<t>2) Two systems connected via multiple hops as described in <xref
target="RFC5883">BFD for Multiple Hops.</xref></t>
<t>3) Two systems connected via MPLS Label Switched Paths (LSPs) as
described in <xref target="RFC5884">BFD for MPLS LSP </xref></t>
<t>4) Two systems connected via a Link Aggregation Group (LAG) interface
as described in <xref target="RFC7130">BFD on LAG Interfaces </xref></t>
<t>5) Two systems connected via pseudowires (PWs), this is known as
Virtual Circuit Connectivity Verification (VCCV) as described in <xref
target="RFC5885">BFD for PW VCCV </xref>. This is not addressed in this
document.</t>
<ol spacing="normal" type="1">
<li>Two systems directly connected via IP. This is known as BFD over
single-hop IP, a.k.a.&nbsp;<xref target="RFC5881" format="default">BFD for
IPv4 and IPv6</xref>.</li>
<li>Two systems connected via multiple hops as described in <xref
target="RFC5883" format="default">"Bidirectional Forwarding Detection
(BFD) for Multihop Paths"</xref>.</li>
<li>Two systems connected via MPLS Label Switched Paths (LSPs) as
described in <xref target="RFC5884" format="default">"Bidirectional
Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)"</xref>.</
li>
<li>Two systems connected via a Link Aggregation Group (LAG) interface
as described in <xref target="RFC7130" format="default">"Bidirectional
Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces"</xr
ef>.</li>
<li>Two systems connected via pseudowires (PWs). This is known as
Virtual Circuit Connectivity Verification (VCCV), as described in <xref
target="RFC5885" format="default">"Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)"</xref>. This scenario is not
addressed in this document.</li>
</ol>
<t>BFD typically does not operate on its own. Various control protocols, <t>BFD typically does not operate on its own. Various control protocols,
also known as BFD clients, use the services provided by BFD for their also known as BFD clients, use the services provided by BFD for their
own operation as described in <xref target="RFC5882">Generic Application own operation, as described in <xref target="RFC5882"
of BFD </xref>. The obvious candidates which use BFD are those which do format="default">"Generic Application of Bidirectional Forwarding
not have "hellos" to detect failures, e.g. static routes, and routing Detection (BFD)"</xref>. The obvious
protocols whose "hellos" do not support sub-second failure detection, candidates that use BFD are those that do not have "hellos" to detect
e.g. OSPF and IS-IS.</t> failures, e.g., static routes, and routing protocols whose "hellos" do
not support sub-second failure detection, e.g., OSPF and IS-IS.</t>
<t>The YANG modules in this document conform to the <xref <t>The YANG modules in this document conform to the <xref
target="RFC8342">Network Management Datastore Architecture (NMDA)</xref>. target="RFC8342" format="default">Network Management Datastore
This means that the data models do not have Architecture (NMDA)</xref>. This means that the data models do not have
separate top-level or sibling containers for configuration and separate top-level or sibling containers for configuration data and
operational state data.</t> operational state data.</t>
<section title="Requirements Language"> <section numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Tree Diagrams</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this <t>This document uses the graphical representation of data models, as de
document are to be interpreted as described in BCP 14 <xref fined in
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they <xref target="RFC8340" format="default"/>.</t>
appear in all capitals, as shown here.</t>
</section>
<section title="Tree Diagrams">
<t>This document uses the graphical representation of data models defin
ed in
<xref target="RFC8340"/>.</t>
</section> </section>
</section> </section>
<section anchor="DESIGN-DATA" numbered="true" toc="default">
<section anchor="DESIGN-DATA" title="Design of the Data Model"> <name>Design of the Data Model</name>
<t>Since BFD is used for liveliness detection of various forwarding <t>Since BFD is used for liveness detection of various forwarding
paths, there is no uniform key to identify a BFD session, and so the BFD paths, there is no uniform key to identify a BFD session, and so the BFD
data model is split in multiple YANG modules where each module data model is split into multiple YANG modules where each module
corresponds to one type of forwarding path. For example, BFD for IP corresponds to one type of forwarding path. For example, BFD for IP
single-hop is in one YANG module and BFD for MPLS-TE is in another YANG single-hop is in one YANG module, and BFD for MPLS is in another YANG
module. The main difference between these modules is how a BFD session module. The main difference between these modules is how a BFD session
is uniquely identified, i.e the key for the list containing the BFD is uniquely identified, i.e., the key for the list containing the BFD
sessions for that forwarding path. To avoid duplication of BFD sessions for that forwarding path. To avoid duplication of BFD
definitions, we have common types and groupings which are used by all definitions, we have common types and groupings that are used by all
the modules.</t> the modules.</t>
<t>A new control-plane protocol, "bfdv1", is defined, and a "bfd" containe
<t>A new control-plane protocol "bfdv1" is defined and a "bfd" container r
is created under control-plane-protocol as specified in <xref is created under "control-plane-protocol" as specified in <xref
target="RFC8349">"A YANG Data Model for Routing target="RFC8349" format="default">"A YANG Data Model for Routing
Management (NMDA Version)"</xref>. This new "bfd" container is augmented Management (NMDA Version)"</xref>. This new "bfd" container is augmented
by all the YANG modules for their respective specific information:<list by the following YANG modules for their respective specific information:
style="numbers"> </t>
<t>ietf-bfd-ip-sh.yang augments <ol spacing="normal" type="1">
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with <li>The "ietf-bfd-ip-sh" module (<xref target="bfd-ip-single-hop-module"
the "ip-sh" container for BFD sessions over IP single-hop.</t> />) augments
<t>ietf-bfd-ip-mh.yang augments
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with "/routing/control-plane-protocols/control-plane-protocol/bfd/" with
the "ip-mh" container for BFD sessions over IP multi-hop.</t> the "ip-sh" container for BFD sessions over IP single-hop.</li>
<li>The "ietf-bfd-ip-mh" module (<xref target="bfd-ip-multihop-module"/>
<t>ietf-bfd-lag.yang augments ) augments
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with "/routing/control-plane-protocols/control-plane-protocol/bfd/" with
the "lag" container for BFD sessions over LAG.</t> the "ip-mh" container for BFD sessions over IP multihop.</li>
<li>The "ietf-bfd-lag" module (<xref target="bfd-over-lag-module"/>) aug
<t>ietf-bfd-mpls.yang augments ments
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with "/routing/control-plane-protocols/control-plane-protocol/bfd/" with
the "mpls" container for BFD over MPLS LSPs.</t> the "lag" container for BFD sessions over a LAG.</li>
<li>The "ietf-bfd-mpls" module (<xref target="bfd-over-mpls-module"/>) a
<t>ietf-bfd-mpls-te.yang augments ugments
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with "/routing/control-plane-protocols/control-plane-protocol/bfd/" with
the "mpls-te" container for BFD over MPLS-TE.</t> the "mpls" container for BFD-over-MPLS LSPs.</li>
</list></t> </ol>
<t>BFD can operate in the following contexts:</t>
<t>BFD can operate in the following contexts: <list style="numbers"> <ol spacing="normal" type="1">
<t>At the network device level</t> <li>At the network device level.</li>
<li>In logical network elements (LNEs) as described in <xref
<t>In Logical Network Elements as described in <xref target="RFC8530" format="default">"YANG Model for Logical Network Elemen
target="I-D.ietf-rtgwg-lne-model">YANG Logical Network ts"</xref>.</li>
Element</xref></t> <li>In network instances as described in <xref
target="RFC8529" format="default">"YANG Data Model for Network Instances
<t>In Network Instances as described in <xref "</xref>.</li>
target="I-D.ietf-rtgwg-ni-model">YANG Logical Network </ol>
Element</xref></t> <t> When used at the network device level, the BFD YANG data model is
</list> When used at the network device level, the BFD YANG model is used "as is". When the BFD YANG data model is used in an LNE or network
used "as-is". When the BFD YANG model is used in a Logical Network instance, the BFD YANG data model augments
Element or in a Network Instance, then the BFD YANG model augments the mounted routing model for the LNE or network instance.</t>
the mounted routing model for the Logical Network Element or the <section anchor="CFG-MODEL" numbered="true" toc="default">
Network Instance.</t> <name>Design of the Configuration Model</name>
<section anchor="CFG-MODEL" title="Design of Configuration Model">
<t>The configuration model consists mainly of the parameters specified <t>The configuration model consists mainly of the parameters specified
in <xref target="RFC5880">BFD</xref>. Some examples are desired in <xref target="RFC5880" format="default">BFD</xref> -- for example, de
minimum transmit interval, required minimum receive interval, sired
detection multiplier, etc</t> minimum transmit interval, required minimum receive interval, and
detection multiplier.</t>
<t>BFD clients are applications that use BFD for fast detection of <t>BFD clients are applications that use BFD for fast detection of
failures. Some implementations have BFD session configuration under failures. Some implementations have BFD session configuration under
the BFD clients. For example, BFD session configuration under routing the BFD clients -- for example, BFD session configuration under routing
applications such as OSPF, IS-IS, BGP etc. Other implementations have applications such as OSPF, IS-IS, or BGP. Other implementations have
BFD session configuration centralized under BFD, i.e. outside the BFD session configuration centralized under BFD, i.e., outside the
multiple BFD clients.</t> multiple BFD clients.</t>
<t>The main BFD parameters of interest to a BFD client are those
<t>The BFD parameters of interest to a BFD client are mainly the related to the
multiplier and interval(s) since those parameters impact the multiplier and interval(s), since those parameters impact the
convergence time of the BFD clients when a failure occurs. Other convergence time of the BFD clients when a failure occurs. Other
parameters such as BFD authentication are not specific to the parameters, such as BFD authentication, are not specific to the
requirements of the BFD client. Ideally all configuration should be requirements of the BFD client. Configuration of BFD for all
centralized under BFD. However, this is a problem for clients of BFD clients should be centralized. However, this is a problem for BFD client
which auto-discover their peers. For example, IGPs do not have the s
peer address configured, instead the IGP is enabled on an interface that auto-discover their peers. For example, IGPs do not have the
and the IGP peers are auto-discovered. So for an operator to configure peer address configured; instead, the IGP is enabled on an interface,
and the IGP peers are auto-discovered. So, for an operator to configure
BFD to an IGP peer, the operator would first have to determine the BFD to an IGP peer, the operator would first have to determine the
peer addresses. And when a new peer is discovered, BFD configuration peer addresses. And when a new peer is discovered, BFD configuration
would need to be added. To avoid this issue, we define grouping would need to be added. To avoid this issue, we define the grouping
client-cfg-parms in <xref target="BFD-TYPES"/> for BFD clients to "client-cfg-parms" in <xref target="BFD-TYPES" format="default"/> for BF
configure BFD: this allows BFD clients such as the IGPs to have D clients to
configure BFD: this allows BFD clients, such as the IGPs, to have
configuration (multiplier and intervals) for the BFD sessions they configuration (multiplier and intervals) for the BFD sessions they
need. For example, when a new IGP peer is discovered, the IGP would need. For example, when a new IGP peer is discovered, the IGP would
create a BFD session to the newly discovered peer and similarly when create a BFD session to the newly discovered peer; similarly, when
an IGP peer goes away, the IGP would remove the BFD session to that an IGP peer goes away, the IGP would remove the BFD session to that
peer. The mechanism how the BFD sessions are created and removed by peer. The mechanism for how the BFD sessions are created and removed by
the BFD clients is outside the scope of this document, but typically the BFD clients is outside the scope of this document, but
this would be done by use of an API implemented by the BFD module on this would typically be done by using an API implemented by the BFD modu
the system. For BFD clients which create BFD sessions via their own le on
the system. In the case of BFD clients that create BFD sessions via thei
r own
configuration, authentication parameters (if required) are still configuration, authentication parameters (if required) are still
specified in BFD.</t> specified in BFD.</t>
<section anchor="BFD-COMMON-CFG" numbered="true" toc="default">
<section anchor="BFD-COMMON-CFG" <name>Common BFD Configuration Parameters</name>
title="Common BFD configuration parameters"> <t>The basic BFD configuration parameters are as follows:</t>
<t>The basic BFD configuration parameters are: <list hangIndent="8" <dl newline="true" spacing="normal">
style="hanging"> <dt>local-multiplier</dt>
<t hangText="local-multiplier"><vspace/>This is the detection <dd>This is the detection time multiplier as defined in <xref
time multiplier as defined in <xref target="RFC5880" format="default">BFD</xref>.</dd>
target="RFC5880">BFD</xref>.</t> <dt>desired-min-tx-interval</dt>
<dd>This is the Desired Min TX Interval as defined in <xref
<t hangText="desired-min-tx-interval"><vspace/>This is the target="RFC5880" format="default">BFD</xref>.</dd>
Desired Min TX Interval as defined in <xref <dt>required-min-rx-interval</dt>
target="RFC5880">BFD</xref>.</t> <dd>This is the Required Min RX Interval as defined in <xref
target="RFC5880" format="default">BFD</xref>.</dd>
<t hangText="required-min-rx-interval"><vspace/>This is the </dl>
Required Min RX Interval as defined in <xref <t>Although <xref target="RFC5880" format="default">BFD</xref>
target="RFC5880">BFD</xref>.</t> allows for different values for transmit and receive intervals, some
</list>Although <xref target="RFC5880">BFD</xref> allows for implementations allow users to specify just one interval that is
different values for transmit and receive intervals, some used for both transmit and receive intervals, or separate values for
implementations allow users to specify just one interval which is transmit and receive intervals. The BFD YANG data model supports this:
used for both transmit and receive intervals or separate values for
transmit and receive intervals. The BFD YANG model supports this:
there is a choice between "min-interval", used for both transmit and there is a choice between "min-interval", used for both transmit and
receive intervals, and "desired-min-tx-interval" and receive intervals, and "desired-min-tx-interval" and
"required-min-rx-interval". This is supported via a grouping which "required-min-rx-interval". This is supported via the
"base-cfg-parms" grouping (<xref target="BFD-TYPES"/>), which
is used by the YANG modules for the various forwarding paths.</t> is used by the YANG modules for the various forwarding paths.</t>
<t>For BFD authentication, we have the following:</t>
<t>For BFD authentication we have: <list hangIndent="8" <dl newline="true" spacing="normal">
style="hanging"> <dt>key-chain</dt>
<t hangText="key-chain"><vspace/>This is a reference to <dd>This is a reference to "key-chain" as defined in <xref
key-chain defined in <xref target="RFC8177">YANG Data Model for target="RFC8177" format="default">"YANG Data Model for Key
Key Chains </xref>. The keys, cryptographic algorithms, key Chains"</xref>. The keys, cryptographic algorithms, key lifetime,
lifetime etc are all defined in the key-chain model.</t> etc. are all defined in the "key-chain" model.</dd>
<dt>meticulous</dt>
<t hangText="meticulous"><vspace/>This enables meticulous mode <dd>This enables a meticulous mode as per <xref target="RFC5880"
as per <xref target="RFC5880">BFD </xref>.</t> format="default">BFD </xref>.</dd>
</list></t> </dl>
</section> </section>
<section anchor="IP-SH-CFG" numbered="true" toc="default">
<section anchor="IP-SH-CFG" title="Single-hop IP"> <name>Single-Hop IP</name>
<t>For single-hop IP, there is an augment of the "bfd" data node in <t>For single-hop IP, there is an augment of the "bfd" data node, as
<xref target="DESIGN-DATA"/>. The "ip-sh" node contains a list of IP described in
single-hop sessions where each session is uniquely identified by the <xref target="DESIGN-DATA" format="default"/>. The "ip-sh" node
interface and destination address pair. For the configuration contains a list of IP single-hop sessions where each session is
parameters we use what is defined in <xref uniquely identified by the interface and destination address
target="BFD-COMMON-CFG"/>. The "ip-sh" node also contains a list of pair. We use the configuration parameters defined in
interfaces, this is used to specify authentication parameters for <xref target="BFD-COMMON-CFG" format="default"/>. The "ip-sh" node
BFD sessions which are created by BFD clients, see <xref also contains a list of interfaces and is used to specify
target="CFG-MODEL"/>.</t> authentication parameters for BFD sessions that are created by BFD
clients. See <xref target="CFG-MODEL" format="default"/>.</t>
<t><xref target="RFC5880"/> and <xref target="RFC5881"/> do not <t><xref target="RFC5880" format="default"/> and <xref
specify whether echo function is continuous or on demand. Therefore target="RFC5881" format="default"/> do not specify whether
the mechanism used to start and stop echo function is implementation the Echo function operates continuously or on demand. Therefore, the m
specific and should be done by augmentation: <list> echanism used to
<t>1) Configuration. This is suitable for continuous echo start and stop the Echo function is implementation specific and should
function. An example is provided in <xref be done by augmentation:</t>
target="ECHO-CONFIG"/>.</t> <ol spacing="normal" type="1">
<li>Configuration. This is suitable for an Echo function that
<t>2) RPC. This is suitable for on-demand echo function.</t> operates continuously. An example is provided in <xref target="ECHO-
</list></t> CONFIG"
format="default"/>.</li>
<li>RPC. This is suitable for an Echo function that operates
on demand.</li>
</ol>
</section> </section>
<section numbered="true" toc="default">
<section title="Multihop IP"> <name>Multihop IP</name>
<t>For multihop IP, there is an augment of the "bfd" data node in <t>For multihop IP, there is an augment of the "bfd" data node, as des
<xref target="DESIGN-DATA"/>.</t> cribed in
<xref target="DESIGN-DATA" format="default"/>.</t>
<t>Because of multiple paths, there could be multiple multihop IP <t>Because of multiple paths, there could be multiple multihop IP
sessions between a source and a destination address. We identify sessions between a source and a destination address. We identify
this as a "session-group". The key for each "session-group" consists this set of sessions as a "session-group". The key for each "session-g
of: <list hangIndent="8" style="hanging"> roup" consists
<t hangText="source address"><vspace/>Address belonging to the of the following:</t>
local system as per <xref target="RFC5883">BFD for Multiple Hops <dl newline="true" spacing="normal">
</xref></t> <dt>Source address</dt>
<dd>Address belonging to the local system as per <xref
<t hangText="destination address"><vspace/>Address belonging to target="RFC5883" format="default">"Bidirectional Forwarding
the remote system as per <xref target="RFC5883">BFD for Multiple Detection (BFD) for Multihop Paths"</xref>.</dd>
Hops </xref></t> <dt>Destination address</dt>
</list></t> <dd>Address belonging to the remote system as per <xref
target="RFC5883" format="default"></xref>.</dd>
<t>For the configuration parameters we use what is defined in <xref </dl>
target="BFD-COMMON-CFG"/></t> <t>We use the configuration parameters defined in <xref
target="BFD-COMMON-CFG" format="default"/>.</t>
<t>Here are some extra parameters: <list hangIndent="8" <t>This document also provides the following parameters:</t>
style="hanging"> <dl newline="true" spacing="normal">
<t hangText="tx-ttl"><vspace/>TTL of outgoing BFD control <dt>tx-ttl</dt>
packets.</t> <dd>TTL of outgoing BFD control packets.</dd>
<dt>rx-ttl</dt>
<t hangText="rx-ttl"><vspace/>Minimum TTL of incoming BFD <dd>Minimum TTL of incoming BFD control packets.</dd>
control packets.</t> </dl>
</list></t>
</section>
<section anchor="BFD-MPLS-TE-CFG"
title="MPLS Traffic Engineering Tunnels">
<t>For MPLS-TE tunnels, BFD is configured under the MPLS-TE tunnel
since the desired failure detection parameters are a property of the
MPLS-TE tunnel. This is achieved by augmenting the MPLS-TE data
model in <xref target="I-D.ietf-teas-yang-te">YANG Data Model for TE
Topologies </xref>. For BFD parameters which are specific to the TE
application, e.g. whether to tear down the tunnel in the event of a
BFD session failure, these parameters will be defined in the YANG
model of the MPLS-TE application.</t>
<t>On top of the usual BFD parameters, we have the following per
MPLS-TE tunnel: <list hangIndent="8" style="hanging">
<t hangText="encap"><vspace/>Encapsulation for the BFD packets:
choice between IP, G-ACh and IP with G-ACh as per <xref
target="RFC5586">MPLS Generic Associated Channel </xref></t>
</list></t>
<t>For general MPLS-TE data, "mpls-te" data node is added under the
"bfd" node in <xref target="DESIGN-DATA"/>. Since some MPLS-TE
tunnels are uni-directional there is no MPLS-TE configuration for
these tunnels on the egress node (note that this does not apply to
bi-directional MPLS-TP tunnels). The BFD parameters for the egress
node are added under "mpls-te".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="MPLS Label Switched Paths"> <name>MPLS Label Switched Paths</name>
<t>Here we address MPLS LSPs whose FEC is an IP address. The "bfd" <t>Here, we address MPLS LSPs whose
node in <xref target="DESIGN-DATA"/> is augmented with "mpls" which Forwarding Equivalence Class (FEC) <xref target="RFC3031"/> is an IP
contains a list of sessions uniquely identified by an IP prefix. address. The "bfd"
Because of multiple paths, there could be multiple MPLS sessions to node (<xref target="DESIGN-DATA" format="default"/>) is augmented
an MPLS FEC. We identify this as a "session-group".</t> with "mpls", which contains a list of sessions uniquely identified by
an IP prefix. Because of multiple paths, there could be multiple
<t>Since these LSPs are uni-directional there is no LSP MPLS sessions to an MPLS FEC. We identify this set of sessions as a
"session-group".</t>
<t>Since these LSPs are unidirectional, there is no LSP
configuration on the egress node.</t> configuration on the egress node.</t>
<t>The BFD parameters for the egress node are added under <t>The BFD parameters for the egress node are added under
"mpls".</t> "mpls".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Link Aggregation Groups"> <name>Link Aggregation Groups</name>
<t>Per <xref target="RFC7130">BFD on LAG Interfaces </xref>, <t>Per <xref target="RFC7130" format="default">"Bidirectional
configuring BFD on LAG consists of having micro-BFD sessions on each Forwarding Detection (BFD) on Link Aggregation Group (LAG)
LAG member link. Since the BFD parameters are an attribute of the Interfaces"</xref>, configuring BFD on a LAG consists of having micro-
LAG, they should be under the LAG. However there is no LAG YANG BFD
model which we can augment. So a "lag" data node is added to the sessions on each LAG member link. Since the BFD parameters are an
"bfd" node in <xref target="DESIGN-DATA"/>, the configuration is attribute of the LAG, they should be under the LAG. However, there is
per-LAG: we have a list of LAGs. The destination IP address of the no LAG YANG data model that we can augment. So, a "lag" data node is
micro-BFD sessions is configured per-LAG and per address-family added to the "bfd" node; see <xref target="DESIGN-DATA"
(IPv4 and IPv6)</t> format="default"/>. The configuration is per LAG: we have a list of
LAGs. The destination IP address of the micro-BFD sessions is
configured per LAG and per address family (IPv4 and IPv6).</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Design of Operational State Model"> <name>Design of the Operational State Model</name>
<t>The operational state model contains both the overall statistics of <t>The operational state model contains both the overall statistics for
BFD sessions running on the device and the per session operational the BFD sessions running on the device and the per-session operational
information.</t> information.</t>
<t>The overall statistics for the BFD sessions consist of the number of
BFD
sessions, the number of BFD sessions that are up, etc. This information
is available
globally (i.e., for all BFD sessions) under the "bfd" node
(<xref target="DESIGN-DATA" format="default"/>) and also per type of
forwarding path.</t>
<t>For each BFD session, three main categories of operational state
data are shown.</t>
<t>The overall statistics of BFD sessions consist of number of BFD <ol spacing="normal" type="1">
sessions, number of BFD sessions up etc. This information is available <li>The first category includes fundamental information regarding a BFD s
globally (i.e. for all BFD sessions) under the "bfd" node in <xref ession, such as
target="DESIGN-DATA"/> and also per type of forwarding path.</t> the local discriminator, the remote discriminator, and the ability to
support Demand mode.</li>
<t>For each BFD session, mainly three categories of operational state <li>The
data are shown. The fundamental information of a BFD session such as second category includes BFD "session-running" information, e.g., the
the local discriminator, remote discriminator and the capability of
supporting demand detect mode are shown in the first category. The
second category includes a BFD session running information, e.g. the
remote BFD state and the diagnostic code received. Another example is remote BFD state and the diagnostic code received. Another example is
the actual transmit interval between the control packets, which may be the actual transmit interval between the control packets, which may be
different from the desired minimum transmit interval configured, is different from the configured desired minimum transmit
shown in this category. Similar examples are actual received interval interval. Similar examples include the actual receive interval
between the control packets and the actual transmit interval between between the control packets and the actual transmit interval between
the echo packets. The third category contains the detailed statistics the Echo packets.</li>
of the session, e.g. when the session transitioned up/down and how <li> The third category contains the detailed statistics
long it has been in that state.</t> for the session, e.g., when the session transitioned up/down and how
long it has been in that state.</li>
</ol>
<t>For some path types, there may be more than 1 session on the <t>For some path types, there may be more than one session on the
virtual path to the destination. For example, with IP multihop and virtual path to the destination. For example, with IP multihop and
MPLS LSPs, there could be multiple BFD sessions from the source to the MPLS LSPs, there could be multiple BFD sessions from the source to the
same destination to test the various paths (ECMP) to the destination. same destination to test the various paths (ECMP) to the destination.
This is represented by having multiple "sessions" under each This is represented by having multiple "sessions" under each
"session-group".</t> "session-group".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Notifications"> <name>Notifications</name>
<t>This YANG model defines notifications to inform end-users of <t>This YANG data model defines notifications to inform end users of
important events detected during the protocol operation. Pair of local important events detected during the protocol operation. The
and remote discriminator identifies a BFD session on local system. local discriminator identifies the corresponding BFD session on the
Notifications also give more important details about BFD sessions; local system, and the remote discriminator identifies the BFD session
e.g. new state, time in previous state, network-instance and the on the remote system.
Notifications also give more important details about BFD sessions,
e.g., new state, time in previous state, network instance, and the
reason that the BFD session state changed. The notifications are reason that the BFD session state changed. The notifications are
defined for each type of forwarding path but use groupings for common defined for each type of forwarding path but use groupings for common
information.</t> information.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="RPC Operations"> <name>RPC Operations</name>
<t>None.</t> <t>None.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="BFD top level hierarchy"> <name>BFD Top-Level Hierarchy</name>
<t>At the "bfd" node under control-plane-protocol, there is no <t>At the "bfd" node under "control-plane-protocol", there is no
configuration data, only operational state data. The operational state configuration data -- only operational state data. The operational state
data consist of overall BFD session statistics, i.e. for BFD on all data consists of overall BFD session statistics, i.e., for BFD on all
types of forwarding paths.</t> types of forwarding paths.</t>
<sourcecode type="yangtree"><![CDATA[
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
module: ietf-bfd module: ietf-bfd
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol: /rt:control-plane-protocol:
+--rw bfd +--rw bfd
+--ro summary +--ro summary
+--ro number-of-sessions? yang:gauge32 +--ro number-of-sessions? yang:gauge32
+--ro number-of-sessions-up? yang:gauge32 +--ro number-of-sessions-up? yang:gauge32
+--ro number-of-sessions-down? yang:gauge32 +--ro number-of-sessions-down? yang:gauge32
+--ro number-of-sessions-admin-down? yang:gauge32 +--ro number-of-sessions-admin-down? yang:gauge32
]]></artwork> ]]></sourcecode>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="BFD IP single-hop hierarchy"> <name>BFD IP Single-Hop Hierarchy</name>
<t>An "ip-sh" node is added under "bfd" node in <t>An "ip-sh" node is added under the "bfd" node in
control-plane-protocol. The configuration and operational state data "control-plane-protocol". The configuration data and operational state d
for each BFD IP single-hop session is under this "ip-sh" node.</t> ata
for each BFD IP single-hop session are under this "ip-sh" node.</t>
<figure align="left"> <sourcecode type="yangtree"><![CDATA[
<preamble/>
<artwork align="left"><![CDATA[
module: ietf-bfd-ip-sh module: ietf-bfd-ip-sh
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd: /rt:control-plane-protocol/bfd:bfd:
+--rw ip-sh +--rw ip-sh
+--ro summary +--ro summary
| +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions? yang:gauge32
| +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32
| +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32
| +--ro number-of-sessions-admin-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32
+--rw sessions +--rw sessions
skipping to change at line 520 skipping to change at line 429
| +--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
| +--rw demand-enabled? boolean | +--rw demand-enabled? boolean
| | {demand-mode}? | | {demand-mode}?
| +--rw admin-down? boolean | +--rw admin-down? boolean
| +--rw authentication! {authentication}? | +--rw authentication! {authentication}?
| | +--rw key-chain? kc:key-chain-ref | | +--rw key-chain? key-chain:key-chain-ref
| | +--rw meticulous? boolean | | +--rw meticulous? boolean
| +--ro path-type? identityref | +--ro path-type? identityref
| +--ro ip-encapsulation? boolean | +--ro ip-encapsulation? boolean
| +--ro local-discriminator? discriminator | +--ro local-discriminator? discriminator
| +--ro remote-discriminator? discriminator | +--ro remote-discriminator? discriminator
| +--ro remote-multiplier? multiplier | +--ro remote-multiplier? multiplier
| +--ro demand-capability? boolean | +--ro demand-capability? boolean
| | {demand-mode}? | | {demand-mode}?
| +--ro source-port? inet:port-number | +--ro source-port? inet:port-number
| +--ro dest-port? inet:port-number | +--ro dest-port? inet:port-number
skipping to change at line 564 skipping to change at line 473
| | yang:date-and-time | | yang:date-and-time
| +--ro down-count? yang:counter32 | +--ro down-count? yang:counter32
| +--ro admin-down-count? yang:counter32 | +--ro admin-down-count? yang:counter32
| +--ro receive-packet-count? yang:counter64 | +--ro receive-packet-count? yang:counter64
| +--ro send-packet-count? yang:counter64 | +--ro send-packet-count? yang:counter64
| +--ro receive-invalid-packet-count? yang:counter64 | +--ro receive-invalid-packet-count? yang:counter64
| +--ro send-failed-packet-count? yang:counter64 | +--ro send-failed-packet-count? yang:counter64
+--rw interfaces* [interface] +--rw interfaces* [interface]
+--rw interface if:interface-ref +--rw interface if:interface-ref
+--rw authentication! {authentication}? +--rw authentication! {authentication}?
+--rw key-chain? kc:key-chain-ref +--rw key-chain? key-chain:key-chain-ref
+--rw meticulous? boolean +--rw meticulous? boolean
notifications: notifications:
+---n singlehop-notification +---n singlehop-notification
+--ro local-discr? discriminator +--ro local-discr? discriminator
+--ro remote-discr? discriminator +--ro remote-discr? discriminator
+--ro new-state? state +--ro new-state? state
+--ro state-change-reason? iana-bfd-types:diagnostic +--ro state-change-reason? iana-bfd-types:diagnostic
+--ro time-of-last-state-change? yang:date-and-time +--ro time-of-last-state-change? yang:date-and-time
+--ro dest-addr? inet:ip-address +--ro dest-addr? inet:ip-address
+--ro source-addr? inet:ip-address +--ro source-addr? inet:ip-address
+--ro session-index? uint32 +--ro session-index? uint32
+--ro path-type? identityref +--ro path-type? identityref
+--ro interface? if:interface-ref +--ro interface? if:interface-ref
+--ro echo-enabled? boolean +--ro echo-enabled? boolean
]]></sourcecode>
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="BFD IP multihop hierarchy"> <name>BFD IP Multihop Hierarchy</name>
<t>An "ip-mh" node is added under the "bfd" node in <t>An "ip-mh" node is added under the "bfd" node in
cntrol-plane-protocol. The configuration and operational state data "control-plane-protocol". The configuration data and operational state d
for each BFD IP multihop session is under this "ip-mh" node. In the ata
operational state model we support multiple BFD multihop sessions per for each BFD IP multihop session are under this "ip-mh" node. In the
remote address (ECMP), the local discriminator is used as key.</t> operational state model, we support multiple BFD multihop sessions per
remote address (ECMP); the local discriminator is used as the key.</t>
<figure align="left"> <sourcecode type="yangtree"><![CDATA[
<preamble/>
<artwork align="left"><![CDATA[
module: ietf-bfd-ip-mh module: ietf-bfd-ip-mh
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd: /rt:control-plane-protocol/bfd:bfd:
+--rw ip-mh +--rw ip-mh
+--ro summary +--ro summary
| +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions? yang:gauge32
| +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32
| +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32
| +--ro number-of-sessions-admin-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32
+--rw session-groups +--rw session-groups
skipping to change at line 621 skipping to change at line 523
+--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
+--rw demand-enabled? boolean +--rw demand-enabled? boolean
| {demand-mode}? | {demand-mode}?
+--rw admin-down? boolean +--rw admin-down? boolean
+--rw authentication! {authentication}? +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| +--rw meticulous? boolean | +--rw meticulous? boolean
+--rw tx-ttl? bfd-types:hops +--rw tx-ttl? bfd-types:hops
+--rw rx-ttl bfd-types:hops +--rw rx-ttl bfd-types:hops
+--ro sessions* [] +--ro sessions* []
+--ro path-type? identityref +--ro path-type? identityref
+--ro ip-encapsulation? boolean +--ro ip-encapsulation? boolean
+--ro local-discriminator? discriminator +--ro local-discriminator? discriminator
+--ro remote-discriminator? discriminator +--ro remote-discriminator? discriminator
+--ro remote-multiplier? multiplier +--ro remote-multiplier? multiplier
+--ro demand-capability? boolean {demand-mode}? +--ro demand-capability? boolean {demand-mode}?
skipping to change at line 682 skipping to change at line 584
+---n multihop-notification +---n multihop-notification
+--ro local-discr? discriminator +--ro local-discr? discriminator
+--ro remote-discr? discriminator +--ro remote-discr? discriminator
+--ro new-state? state +--ro new-state? state
+--ro state-change-reason? iana-bfd-types:diagnostic +--ro state-change-reason? iana-bfd-types:diagnostic
+--ro time-of-last-state-change? yang:date-and-time +--ro time-of-last-state-change? yang:date-and-time
+--ro dest-addr? inet:ip-address +--ro dest-addr? inet:ip-address
+--ro source-addr? inet:ip-address +--ro source-addr? inet:ip-address
+--ro session-index? uint32 +--ro session-index? uint32
+--ro path-type? identityref +--ro path-type? identityref
]]></artwork> ]]></sourcecode>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="BFD over LAG hierarchy"> <name>BFD-over-LAG Hierarchy</name>
<t>A "lag" node is added under the "bfd" node in <t>A "lag" node is added under the "bfd" node in
control-plane-protocol. The configuration and operational state data "control-plane-protocol". The configuration data and operational state d
for each BFD LAG session is under this "lag" node.</t> ata
for each BFD LAG session are under this "lag" node.</t>
<figure align="left"> <sourcecode type="yangtree"><![CDATA[
<preamble/>
<artwork align="left"><![CDATA[
module: ietf-bfd-lag module: ietf-bfd-lag
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd: /rt:control-plane-protocol/bfd:bfd:
+--rw lag +--rw lag
+--rw micro-bfd-ipv4-session-statistics +--rw micro-bfd-ipv4-session-statistics
| +--ro summary | +--ro summary
| +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions? yang:gauge32
| +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32
| +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32
| +--ro number-of-sessions-admin-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32
skipping to change at line 730 skipping to change at line 626
+--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
+--rw demand-enabled? boolean +--rw demand-enabled? boolean
| {demand-mode}? | {demand-mode}?
+--rw admin-down? boolean +--rw admin-down? boolean
+--rw authentication! {authentication}? +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| +--rw meticulous? boolean | +--rw meticulous? boolean
+--rw use-ipv4? boolean +--rw use-ipv4? boolean
+--rw use-ipv6? boolean +--rw use-ipv6? boolean
+--ro member-links* [member-link] +--ro member-links* [member-link]
+--ro member-link if:interface-ref +--ro member-link if:interface-ref
+--ro micro-bfd-ipv4 +--ro micro-bfd-ipv4
| +--ro path-type? identityref | +--ro path-type? identityref
| +--ro ip-encapsulation? boolean | +--ro ip-encapsulation? boolean
| +--ro local-discriminator? discriminator | +--ro local-discriminator? discriminator
| +--ro remote-discriminator? discriminator | +--ro remote-discriminator? discriminator
skipping to change at line 844 skipping to change at line 740
+--ro remote-discr? discriminator +--ro remote-discr? discriminator
+--ro new-state? state +--ro new-state? state
+--ro state-change-reason? iana-bfd-types:diagnostic +--ro state-change-reason? iana-bfd-types:diagnostic
+--ro time-of-last-state-change? yang:date-and-time +--ro time-of-last-state-change? yang:date-and-time
+--ro dest-addr? inet:ip-address +--ro dest-addr? inet:ip-address
+--ro source-addr? inet:ip-address +--ro source-addr? inet:ip-address
+--ro session-index? uint32 +--ro session-index? uint32
+--ro path-type? identityref +--ro path-type? identityref
+--ro lag-name? if:interface-ref +--ro lag-name? if:interface-ref
+--ro member-link? if:interface-ref +--ro member-link? if:interface-ref
]]></artwork> ]]></sourcecode>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="BFD over MPLS LSPs hierarchy"> <name>BFD-over-MPLS-LSPs Hierarchy</name>
<t>An "mpls" node is added under the "bfd" node in <t>An "mpls" node is added under the "bfd" node in
control-plane-protocol. The configuration is per MPLS FEC under this "control-plane-protocol". The configuration is per MPLS FEC under this
"mpls" node. In the operational state model we support multiple BFD "mpls" node. In the operational state model, we support multiple BFD
sessions per MPLS FEC (ECMP), the local discriminator is used as key. sessions per MPLS FEC (ECMP); the local discriminator is used as the key
The "mpls" node can be used in a network device (top-level), or .
mounted in an LNE or in a network instance.</t> The "mpls" node can be used in a network device (top level) or can be
mounted in an LNE or network instance.</t>
<figure align="left"> <sourcecode type="yangtree"><![CDATA[
<preamble/>
<artwork align="left"><![CDATA[
module: ietf-bfd-mpls module: ietf-bfd-mpls
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd: /rt:control-plane-protocol/bfd:bfd:
+--rw mpls +--rw mpls
+--ro summary +--ro summary
| +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions? yang:gauge32
| +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32
| +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32
| +--ro number-of-sessions-admin-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32
+--rw egress +--rw egress
| +--rw enable? boolean | +--rw enabled? boolean
| +--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
| +--rw authentication! {authentication}? | +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| +--rw meticulous? boolean | +--rw meticulous? boolean
+--rw session-groups +--rw session-groups
+--rw session-group* [mpls-fec] +--rw session-group* [mpls-fec]
+--rw mpls-fec inet:ip-prefix +--rw mpls-fec inet:ip-prefix
+--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
+--rw demand-enabled? boolean +--rw demand-enabled? boolean
| {demand-mode}? | {demand-mode}?
+--rw admin-down? boolean +--rw admin-down? boolean
+--rw authentication! {authentication}? +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| +--rw meticulous? boolean | +--rw meticulous? boolean
+--ro sessions* [] +--ro sessions* []
+--ro path-type? identityref +--ro path-type? identityref
+--ro ip-encapsulation? boolean +--ro ip-encapsulation? boolean
+--ro local-discriminator? discriminator +--ro local-discriminator? discriminator
+--ro remote-discriminator? discriminator +--ro remote-discriminator? discriminator
+--ro remote-multiplier? multiplier +--ro remote-multiplier? multiplier
+--ro demand-capability? boolean {demand-mode}? +--ro demand-capability? boolean {demand-mode}?
+--ro source-port? inet:port-number +--ro source-port? inet:port-number
+--ro dest-port? inet:port-number +--ro dest-port? inet:port-number
skipping to change at line 957 skipping to change at line 847
+--ro local-discr? discriminator +--ro local-discr? discriminator
+--ro remote-discr? discriminator +--ro remote-discr? discriminator
+--ro new-state? state +--ro new-state? state
+--ro state-change-reason? iana-bfd-types:diagnostic +--ro state-change-reason? iana-bfd-types:diagnostic
+--ro time-of-last-state-change? yang:date-and-time +--ro time-of-last-state-change? yang:date-and-time
+--ro dest-addr? inet:ip-address +--ro dest-addr? inet:ip-address
+--ro source-addr? inet:ip-address +--ro source-addr? inet:ip-address
+--ro session-index? uint32 +--ro session-index? uint32
+--ro path-type? identityref +--ro path-type? identityref
+--ro mpls-dest-address? inet:ip-address +--ro mpls-dest-address? inet:ip-address
]]></artwork> ]]></sourcecode>
</figure>
</section>
<section title="BFD over MPLS-TE hierarchy">
<t><xref target="I-D.ietf-teas-yang-te">YANG Data Model for TE
Topologies </xref> is augmented. BFD is configured per MPLS-TE tunnel,
and BFD session operational state data is provided per MPLS-TE
LSP.</t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
module: ietf-bfd-mpls-te
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd:
+--rw mpls-te
+--rw egress
| +--rw enable? boolean
| +--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
| +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref
| +--rw meticulous? boolean
+--ro summary
+--ro number-of-sessions? yang:gauge32
+--ro number-of-sessions-up? yang:gauge32
+--ro number-of-sessions-down? yang:gauge32
+--ro number-of-sessions-admin-down? yang:gauge32
augment /te:te/te:tunnels/te:tunnel:
+--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
+--rw demand-enabled? boolean {demand-mode}?
+--rw admin-down? boolean
+--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref
| +--rw meticulous? boolean
+--rw encap? identityref
augment /te:te/te:lsps-state/te:lsp:
+--ro path-type? identityref
+--ro ip-encapsulation? boolean
+--ro local-discriminator? discriminator
+--ro remote-discriminator? discriminator
+--ro remote-multiplier? multiplier
+--ro demand-capability? boolean {demand-mode}?
+--ro source-port? inet:port-number
+--ro dest-port? inet:port-number
+--ro session-running
| +--ro session-index? uint32
| +--ro local-state? state
| +--ro remote-state? state
| +--ro local-diagnostic? iana-bfd-types:diagnostic
| +--ro remote-diagnostic? iana-bfd-types:diagnostic
| +--ro remote-authenticated? boolean
| +--ro remote-authentication-type? iana-bfd-types:auth-type
| | {authentication}?
| +--ro detection-mode? enumeration
| +--ro negotiated-tx-interval? uint32
| +--ro negotiated-rx-interval? uint32
| +--ro detection-time? uint32
| +--ro echo-tx-interval-in-use? uint32 {echo-mode}?
+--ro session-statistics
| +--ro create-time? yang:date-and-time
| +--ro last-down-time? yang:date-and-time
| +--ro last-up-time? yang:date-and-time
| +--ro down-count? yang:counter32
| +--ro admin-down-count? yang:counter32
| +--ro receive-packet-count? yang:counter64
| +--ro send-packet-count? yang:counter64
| +--ro receive-invalid-packet-count? yang:counter64
| +--ro send-failed-packet-count? yang:counter64
+--ro mpls-dest-address? inet:ip-address
notifications:
+---n mpls-te-notification
+--ro local-discr? discriminator
+--ro remote-discr? discriminator
+--ro new-state? state
+--ro state-change-reason? iana-bfd-types:diagnostic
+--ro time-of-last-state-change? yang:date-and-time
+--ro dest-addr? inet:ip-address
+--ro source-addr? inet:ip-address
+--ro session-index? uint32
+--ro path-type? identityref
+--ro mpls-dest-address? inet:ip-address
+--ro tunnel-name? string
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Interaction with other YANG modules"> <name>Interaction with Other YANG Modules</name>
<t><xref target="I-D.ietf-lime-yang-connectionless-oam">Generic YANG <t><xref target="RFC8532"
Data Model for Connectionless OAM protocols </xref> describes how the format="default">"Generic YANG Data Model for the Management
LIME connectionless OAM model could be extended to support BFD.</t> of Operations, Administration, and Maintenance (OAM) Protocols That
Use Connectionless Communications"</xref> describes how the
Layer-Independent OAM Management in the Multi-Layer Environment (LIME)
connectionless OAM model could be extended to support BFD.</t>
<t>Also, the operation of the BFD data model depends on configuration <t>Also, the operation of the BFD data model depends on configuration
parameters that are defined in other YANG modules.</t> parameters that are defined in other YANG modules.</t>
<section numbered="true" toc="default">
<section title="Module ietf-interfaces"> <name>&quot;ietf-interfaces&quot; Module</name>
<t>The following boolean configuration is defined in <xref <t>The following boolean configuration is defined in <xref
target="RFC8343">A YANG Data Model for Interface target="RFC8343" format="default">"A YANG Data Model for Interface Man
Management </xref>: <list hangIndent="8" style="hanging"> agement"</xref>:</t>
<t hangText="/if:interfaces/if:interface/if:enabled"><vspace/>If <dl newline="true" spacing="normal">
this configuration is set to "false", no BFD packets can be <dt>/if:interfaces/if:interface/if:enabled</dt>
transmitted or received on that interface.</t> <dd>If this configuration is set to "false", no BFD packets can be
</list></t> transmitted or received on that interface.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Module ietf-ip"> <name>&quot;ietf-ip&quot; Module</name>
<t>The following boolean configuration is defined in <xref <t>The following boolean configuration is defined in <xref
target="RFC8344">A YANG Data Model for IP target="RFC8344" format="default">"A YANG Data Model for IP Management
Management </xref>: <list hangIndent="8" style="hanging"> "</xref>:</t>
<t <dl newline="true" spacing="normal">
hangText="/if:interfaces/if:interface/ip:ipv4/ip:enabled"><vspace/ <dt>/if:interfaces/if:interface/ip:ipv4/ip:enabled</dt>
>If <dd>If this configuration is set to "false", no BFD IPv4 packets
this configuration is set to "false", no BFD IPv4 packets can be can be transmitted or received on that interface.</dd>
transmitted or received on that interface.</t> <dt>/if:interfaces/if:interface/ip:ipv4/ip:forwarding</dt>
<dd>If this configuration is set to "false", no BFD IPv4 packets
<t can be transmitted or received on that interface.</dd>
hangText="/if:interfaces/if:interface/ip:ipv4/ip:forwarding"><vspa <dt>/if:interfaces/if:interface/ip:ipv6/ip:enabled</dt>
ce/>If <dd>If this configuration is set to "false", no BFD IPv6 packets
this configuration is set to "false", no BFD IPv4 packets can be can be transmitted or received on that interface.</dd>
transmitted or received on that interface.</t> <dt>/if:interfaces/if:interface/ip:ipv6/ip:forwarding</dt>
<dd>If this configuration is set to "false", no BFD IPv6 packets
<t can be transmitted or received on that interface.</dd>
hangText="/if:interfaces/if:interface/ip:ipv6/ip:enabled"><vspace/ </dl>
>If
this configuration is set to "false", no BFD IPv6 packets can be
transmitted or received on that interface.</t>
<t
hangText="/if:interfaces/if:interface/ip:ipv6/ip:forwarding"><vspa
ce/>If
this configuration is set to "false", no BFD IPv6 packets can be
transmitted or received on that interface.</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Module ietf-mpls"> <name>&quot;ietf-mpls&quot; Module</name>
<t>The following boolean configuration is defined in <xref <t>The following boolean configuration is defined in <xref
target="I-D.ietf-mpls-base-yang">A YANG Data Model for MPLS Base target="RFC8960" format="default">"A YANG Data Model for MPLS Base"</x
</xref>: <list hangIndent="8" style="hanging"> ref>:</t>
<t <dl newline="true" spacing="normal">
hangText="/rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:en <dt>/rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/mpls:mpls&nb
abled"><vspace/>If hy;enabled</dt>
this configuration is set to "false", no BFD MPLS packets can be <dd>If this configuration is set to "false", no BFD MPLS packets
transmitted or received on that interface.</t> can be transmitted or received on that interface.</dd>
</list></t> </dl>
</section>
<section title="Module ietf-te">
<t>The following configuration is defined in the "ietf-te" YANG
module <xref target="I-D.ietf-teas-yang-te">YANG Data Model for TE
Topology </xref>: <list hangIndent="8" style="hanging">
<t
hangText="/ietf-te:te/ietf-te:tunnels/ietf-te:tunnel/ietf-te:confi
g/ietf-te:admin-status"><vspace/>If
this configuration is not set to "state-up", no BFD MPLS packets
can be transmitted or received on that tunnel.</t>
</list></t>
</section> </section>
</section> </section>
<section title="IANA BFD YANG Module"> <section numbered="true" toc="default">
<figure align="left"> <name>IANA BFD YANG Module</name>
<preamble/>
<artwork align="left"><![CDATA[<CODE BEGINS> file "iana-bfd-types@2018 <t>This YANG module imports definitions from <xref target="RFC5880"/>.
-08-01.yang" It
references <xref target="RFC5880"/> and <xref target="RFC6428"/>.</t>
<sourcecode name="iana-bfd-types@2021-09-03.yang" type="yang" markers="t rue"><![CDATA[
module iana-bfd-types { module iana-bfd-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-bfd-types"; namespace "urn:ietf:params:xml:ns:yang:iana-bfd-types";
prefix iana-bfd-types;
prefix "iana-bfd-types"; organization
"IANA";
organization "IANA";
contact contact
" Internet Assigned Numbers Authority "Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Tel: +1 310 823 9358
<mailto:iana@iana.org>";
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Tel: +1 310 301 5800
<mailto:iana@iana.org>";
description description
"This module defines YANG data types for IANA-registered "This module defines YANG data types for IANA-registered
BFD parameters. BFD parameters.
This YANG module is maintained by IANA and reflects the This YANG module is maintained by IANA and reflects the
'BFD Diagnostic Codes' and 'BFD Authentication Types' registries. 'BFD Diagnostic Codes' and 'BFD Authentication Types'
registries.
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2021 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove
// this note
reference "RFC XXXX"; This version of this YANG module is part of RFC 9127; see the
RFC itself for full legal notices.";
reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
revision 2018-08-01 { revision 2021-09-03 {
description "Initial revision."; description
reference "RFC XXXX: IANA BFD YANG Data Types."; "Initial revision.";
reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
/* /*
* Type Definitions * Type definitions
*/ */
typedef diagnostic { typedef diagnostic {
type enumeration { type enumeration {
enum none { enum none {
value 0; value 0;
description "None"; description
"No Diagnostic.";
} }
enum control-expiry { enum control-expiry {
value 1; value 1;
description "Control timer expiry"; description
"Control Detection Time Expired.";
} }
enum echo-failed { enum echo-failed {
value 2; value 2;
description "Echo failure"; description
"Echo Function Failed.";
} }
enum neighbor-down { enum neighbor-down {
value 3; value 3;
description "Neighbor down"; description
"Neighbor Signaled Session Down.";
} }
enum forwarding-reset { enum forwarding-reset {
value 4; value 4;
description "Forwarding reset"; description
"Forwarding Plane Reset.";
} }
enum path-down { enum path-down {
value 5; value 5;
description "Path down"; description
"Path Down.";
} }
enum concatenated-path-down { enum concatenated-path-down {
value 6; value 6;
description "Concatenated path down"; description
"Concatenated Path Down.";
} }
enum admin-down { enum admin-down {
value 7; value 7;
description "Admin down"; description
"Administratively Down.";
} }
enum reverse-concatenated-path-down { enum reverse-concatenated-path-down {
value 8; value 8;
description "Reverse concatenated path down"; description
"Reverse Concatenated Path Down.";
} }
enum mis-connectivity-defect { enum mis-connectivity-defect {
value 9; value 9;
description "Mis-connectivity defect as specified in RFC6428"; description
"Mis-connectivity defect.";
reference
"RFC 5880: Bidirectional Forwarding Detection (BFD)
RFC 6428: Proactive Connectivity Verification, Continuity
Check, and Remote Defect Indication for the MPLS Transport
Profile";
} }
} }
description description
"BFD diagnostic as defined in RFC 5880, values are maintained in "BFD diagnostic codes as defined in RFC 5880. Values are
the 'BFD Diagnostic Codes' IANA registry. Range is 0 to 31."; maintained in the 'BFD Diagnostic Codes' IANA registry.
Range is 0 to 31.";
reference
"RFC 5880: Bidirectional Forwarding Detection (BFD)";
} }
typedef auth-type { typedef auth-type {
type enumeration { type enumeration {
enum reserved { enum reserved {
value 0; value 0;
description "Reserved"; description
"Reserved.";
} }
enum simple-password { enum simple-password {
value 1; value 1;
description "Simple password"; description
"Simple Password.";
} }
enum keyed-md5 { enum keyed-md5 {
value 2; value 2;
description "Keyed MD5"; description
"Keyed MD5.";
} }
enum meticulous-keyed-md5 { enum meticulous-keyed-md5 {
value 3; value 3;
description "Meticulous keyed MD5"; description
"Meticulous Keyed MD5.";
} }
enum keyed-sha1 { enum keyed-sha1 {
value 4; value 4;
description "Keyed SHA1"; description
"Keyed SHA1.";
} }
enum meticulous-keyed-sha1 { enum meticulous-keyed-sha1 {
value 5; value 5;
description "Meticulous keyed SHA1"; description
"Meticulous Keyed SHA1.";
} }
} }
description description
"BFD authentication type as defined in RFC 5880, values are "BFD authentication type as defined in RFC 5880. Values are
maintained in the 'BFD Authentication Types' IANA registry. maintained in the 'BFD Authentication Types' IANA registry.
Range is 0 to 255."; Range is 0 to 255.";
reference
"RFC 5880: Bidirectional Forwarding Detection (BFD)";
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
<section anchor="BFD-TYPES" numbered="true" toc="default">
<name>BFD Types YANG Module</name>
<t>This YANG module imports typedefs from <xref target="RFC6991"
format="default"/> and <xref target="RFC8177" format="default"/>.
It also imports definitions from
<xref target="RFC5880"/>, <xref target="RFC5881"/>,
<xref target="RFC5883"/>, <xref target="RFC5884"/>, and
<xref target="RFC7130"/>, as well as the
"control-plane-protocol" identity from
<xref target="RFC8349"/>.
<section anchor="BFD-TYPES" title="BFD types YANG Module"> </t>
<t>This YANG module imports typedefs from <xref target="RFC6991"/>, <xr <sourcecode name="ietf-bfd-types@2021-09-03.yang" type="yang" markers="t
ef target="RFC8177"/> and rue"><![CDATA[
the "control-plane-protocol" identity from <xref
target="RFC8349"/>.</t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-types@2019-11-19.yang"
module ietf-bfd-types { module ietf-bfd-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-types";
prefix bfd-types;
prefix "bfd-types";
// RFC Ed.: replace occurences of XXXX with actual RFC number and
// remove this note
import iana-bfd-types { import iana-bfd-types {
prefix "iana-bfd-types"; prefix iana-bfd-types;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix inet;
reference "RFC 6991: Common YANG Data Types"; reference
"RFC 6991: Common YANG Data Types";
} }
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix yang;
reference "RFC 6991: Common YANG Data Types"; reference
"RFC 6991: Common YANG Data Types";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA Version)";
} }
import ietf-key-chain { import ietf-key-chain {
prefix "kc"; prefix key-chain;
reference "RFC 8177: YANG Data Model for Key Chains"; reference
"RFC 8177: YANG Data Model for Key Chains";
} }
organization "IETF BFD Working Group"; organization
"IETF BFD Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/bfd> "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org> WG List: <mailto:rtg-bfd@ietf.org>
Editors: Reshad Rahman (rrahman@cisco.com), Editor: Reshad Rahman
Lianshu Zheng (vero.zheng@huawei.com), <mailto:reshad@yahoo.com>
Mahesh Jethanandani (mjethanandani@gmail.com)";
Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>";
description description
"This module contains a collection of BFD specific YANG data type "This module contains a collection of BFD-specific YANG data type
definitions, as per RFC 5880, and also groupings which are common definitions, as per RFC 5880, and also groupings that are common
to other BFD YANG modules. to other BFD YANG modules.
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2021 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
reference "RFC XXXX"; This version of this YANG module is part of RFC 9127; see the
RFC itself for full legal notices.";
reference
"RFC 5880: Bidirectional Forwarding Detection (BFD)
RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
revision 2019-11-19 { revision 2021-09-03 {
description "Initial revision."; description
reference "RFC XXXX: YANG Data Model for BFD"; "Initial revision.";
reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
/* /*
* Feature definitions * Feature definitions
*/ */
feature single-minimum-interval { feature single-minimum-interval {
description description
"This feature indicates that the server supports configuration "This feature indicates that the server supports configuration
of one minimum interval value which is used for both transmit and of one minimum interval value that is used for both transmit
receive minimum intervals."; and receive minimum intervals.";
} }
feature authentication { feature authentication {
description description
"This feature indicates that the server supports BFD "This feature indicates that the server supports BFD
authentication."; authentication.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection (BFD), "RFC 5880: Bidirectional Forwarding Detection (BFD),
section 6.7."; Section 6.7";
} }
feature demand-mode { feature demand-mode {
description description
"This feature indicates that the server supports BFD demand "This feature indicates that the server supports BFD Demand
mode."; mode.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection (BFD), "RFC 5880: Bidirectional Forwarding Detection (BFD),
section 6.6."; Section 6.6";
} }
feature echo-mode { feature echo-mode {
description description
"This feature indicates that the server supports BFD echo "This feature indicates that the server supports BFD Echo
mode."; mode.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection (BFD), "RFC 5880: Bidirectional Forwarding Detection (BFD),
section 6.4."; Section 6.4";
} }
/* /*
* Identity definitions * Identity definitions
*/ */
identity bfdv1 { identity bfdv1 {
base "rt:control-plane-protocol"; base rt:control-plane-protocol;
description "BFD protocol version 1."; description
"BFD protocol version 1.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection (BFD)."; "RFC 5880: Bidirectional Forwarding Detection (BFD)";
} }
identity path-type { identity path-type {
description description
"Base identity for BFD path type. The path type indicates "Base identity for the BFD path type. The path type indicates
the type of path on which BFD is running."; the type of path on which BFD is running.";
} }
identity path-ip-sh { identity path-ip-sh {
base path-type; base path-type;
description "BFD on IP single hop."; description
"BFD on IP single-hop.";
reference reference
"RFC 5881: Bidirectional Forwarding Detection (BFD) "RFC 5881: Bidirectional Forwarding Detection (BFD)
for IPv4 and IPv6 (Single Hop)."; for IPv4 and IPv6 (Single Hop)";
} }
identity path-ip-mh { identity path-ip-mh {
base path-type; base path-type;
description "BFD on IP multihop paths."; description
"BFD on IP multihop paths.";
reference reference
"RFC 5883: Bidirectional Forwarding Detection (BFD) for "RFC 5883: Bidirectional Forwarding Detection (BFD) for
Multihop Paths."; Multihop Paths";
} }
identity path-mpls-te { identity path-mpls-te {
base path-type; base path-type;
description description
"BFD on MPLS Traffic Engineering."; "BFD on MPLS Traffic Engineering.";
reference reference
"RFC 5884: Bidirectional Forwarding Detection (BFD) "RFC 5884: Bidirectional Forwarding Detection (BFD)
for MPLS Label Switched Paths (LSPs)."; for MPLS Label Switched Paths (LSPs)";
} }
identity path-mpls-lsp { identity path-mpls-lsp {
base path-type; base path-type;
description description
"BFD on MPLS Label Switched Path."; "BFD on an MPLS Label Switched Path.";
reference reference
"RFC 5884: Bidirectional Forwarding Detection (BFD) "RFC 5884: Bidirectional Forwarding Detection (BFD)
for MPLS Label Switched Paths (LSPs)."; for MPLS Label Switched Paths (LSPs)";
} }
identity path-lag { identity path-lag {
base path-type; base path-type;
description description
"Micro-BFD on LAG member links."; "Micro-BFD on LAG member links.";
reference reference
"RFC 7130: Bidirectional Forwarding Detection (BFD) on "RFC 7130: Bidirectional Forwarding Detection (BFD) on
Link Aggregation Group (LAG) Interfaces."; Link Aggregation Group (LAG) Interfaces";
} }
identity encap-type { identity encap-type {
description description
"Base identity for BFD encapsulation type."; "Base identity for BFD encapsulation type.";
} }
identity encap-ip { identity encap-ip {
base encap-type; base encap-type;
description "BFD with IP encapsulation."; description
"BFD with IP encapsulation.";
} }
/* /*
* Type Definitions * Type definitions
*/ */
typedef discriminator { typedef discriminator {
type uint32; type uint32;
description "BFD discriminator as described in RFC 5880."; description
"BFD Discriminator as described in RFC 5880.";
reference
"RFC 5880: Bidirectional Forwarding Detection (BFD)";
} }
typedef state { typedef state {
type enumeration { type enumeration {
enum adminDown { enum adminDown {
value 0; value 0;
description "admindown"; description
"'adminDown' state.";
} }
enum down { enum down {
value 1; value 1;
description "down"; description
"'Down' state.";
} }
enum init { enum init {
value 2; value 2;
description "init"; description
"'Init' state.";
} }
enum up { enum up {
value 3; value 3;
description "up"; description
"'Up' state.";
} }
} }
description "BFD state as defined in RFC 5880."; description
"BFD states as defined in RFC 5880.";
} }
typedef multiplier { typedef multiplier {
type uint8 { type uint8 {
range 1..255; range "1..255";
} }
description "BFD multiplier as described in RFC 5880."; description
"BFD multiplier as described in RFC 5880.";
} }
typedef hops { typedef hops {
type uint8 { type uint8 {
range 1..255; range "1..255";
} }
description description
"This corresponds to Time To Live for IPv4 and corresponds to hop "This corresponds to Time To Live for IPv4 and corresponds to
limit for IPv6."; the hop limit for IPv6.";
} }
/* /*
* Groupings * Groupings
*/ */
grouping auth-parms { grouping auth-parms {
description description
"Grouping for BFD authentication parameters "Grouping for BFD authentication parameters
(see section 6.7 of RFC 5880)."; (see Section 6.7 of RFC 5880).";
container authentication { container authentication {
if-feature authentication; if-feature "authentication";
presence presence "Enables BFD authentication (see Section 6.7
"Enables BFD authentication (see section 6.7 of RFC 5880)."; of RFC 5880).";
description "Parameters for BFD authentication."; description
"Parameters for BFD authentication.";
reference
"RFC 5880: Bidirectional Forwarding Detection (BFD),
Section 6.7";
leaf key-chain { leaf key-chain {
type kc:key-chain-ref; type key-chain:key-chain-ref;
description "Name of the key-chain as per RFC 8177."; description
"Name of the 'key-chain' as per RFC 8177.";
} }
leaf meticulous { leaf meticulous {
type boolean; type boolean;
description description
"Enables meticulous mode as described in section 6.7 " + "Enables a meticulous mode as per Section 6.7 of
"of RFC 5880."; RFC 5880.";
} }
} }
} }
grouping base-cfg-parms { grouping base-cfg-parms {
description "BFD grouping for base config parameters."; description
"BFD grouping for base configuration parameters.";
leaf local-multiplier { leaf local-multiplier {
type multiplier; type multiplier;
default 3; default "3";
description "Multiplier transmitted by local system."; description
"Multiplier transmitted by the local system.";
} }
choice interval-config-type { choice interval-config-type {
default tx-rx-intervals; default "tx-rx-intervals";
description description
"Two interval values or one value used for both transmit and "Two interval values or one value used for both transmit and
receive."; receive.";
case tx-rx-intervals { case tx-rx-intervals {
leaf desired-min-tx-interval { leaf desired-min-tx-interval {
type uint32; type uint32;
units microseconds; units "microseconds";
default 1000000; default "1000000";
description description
"Desired minimum transmit interval of control packets."; "Desired minimum transmit interval of control packets.";
} }
leaf required-min-rx-interval { leaf required-min-rx-interval {
type uint32; type uint32;
units microseconds; units "microseconds";
default 1000000; default "1000000";
description description
"Required minimum receive interval of control packets."; "Required minimum receive interval of control packets.";
} }
} }
case single-interval { case single-interval {
if-feature single-minimum-interval; if-feature "single-minimum-interval";
leaf min-interval { leaf min-interval {
type uint32; type uint32;
units microseconds; units "microseconds";
default 1000000; default "1000000";
description description
"Desired minimum transmit interval and required " + "Desired minimum transmit interval and required
"minimum receive interval of control packets."; minimum receive interval of control packets.";
} }
} }
} }
} }
grouping client-cfg-parms { grouping client-cfg-parms {
description description
"BFD grouping for configuration parameters "BFD grouping for configuration parameters
used by clients of BFD, e.g. IGP or MPLS."; used by BFD clients, e.g., IGP or MPLS.";
leaf enabled {
leaf enable {
type boolean; type boolean;
default false; default "false";
description description
"Indicates whether the BFD is enabled."; "Indicates whether BFD is enabled.";
} }
uses base-cfg-parms; uses base-cfg-parms;
} }
grouping common-cfg-parms { grouping common-cfg-parms {
description description
"BFD grouping for common configuration parameters."; "BFD grouping for common configuration parameters.";
uses base-cfg-parms; uses base-cfg-parms;
leaf demand-enabled { leaf demand-enabled {
if-feature demand-mode; if-feature "demand-mode";
type boolean; type boolean;
default false; default "false";
description description
"To enable demand mode."; "To enable Demand mode.";
} }
leaf admin-down { leaf admin-down {
type boolean; type boolean;
default false; default "false";
description description
"Is the BFD session administratively down."; "Indicates whether the BFD session is administratively
down.";
} }
uses auth-parms; uses auth-parms;
} }
grouping all-session { grouping all-session {
description "BFD session operational information"; description
"BFD session operational information.";
leaf path-type { leaf path-type {
type identityref { type identityref {
base path-type; base path-type;
} }
config "false"; config false;
description description
"BFD path type, this indicates the path type that BFD is "BFD path type. This indicates the path type that BFD is
running on."; running on.";
} }
leaf ip-encapsulation { leaf ip-encapsulation {
type boolean; type boolean;
config "false"; config false;
description "Whether BFD encapsulation uses IP."; description
"Indicates whether BFD encapsulation uses IP.";
} }
leaf local-discriminator { leaf local-discriminator {
type discriminator; type discriminator;
config "false"; config false;
description "Local discriminator."; description
"Local discriminator.";
} }
leaf remote-discriminator { leaf remote-discriminator {
type discriminator; type discriminator;
config "false"; config false;
description "Remote discriminator."; description
"Remote discriminator.";
} }
leaf remote-multiplier { leaf remote-multiplier {
type multiplier; type multiplier;
config "false"; config false;
description "Remote multiplier."; description
"Remote multiplier.";
} }
leaf demand-capability { leaf demand-capability {
if-feature demand-mode; if-feature "demand-mode";
type boolean; type boolean;
config "false"; config false;
description "Local demand mode capability."; description
"Local Demand mode capability.";
} }
leaf source-port { leaf source-port {
when "../ip-encapsulation = 'true'" { when "../ip-encapsulation = 'true'" {
description description
"Source port valid only when IP encapsulation is used."; "Source port valid only when IP encapsulation is used.";
} }
type inet:port-number; type inet:port-number;
config "false"; config false;
description "Source UDP port"; description
"Source UDP port.";
} }
leaf dest-port { leaf dest-port {
when "../ip-encapsulation = 'true'" { when "../ip-encapsulation = 'true'" {
description description
"Destination port valid only when IP encapsulation is used."; "Destination port valid only when IP encapsulation
is used.";
} }
type inet:port-number; type inet:port-number;
config "false"; config false;
description "Destination UDP port."; description
"Destination UDP port.";
} }
container session-running { container session-running {
config "false"; config false;
description "BFD session running information."; description
"BFD 'session-running' information.";
leaf session-index { leaf session-index {
type uint32; type uint32;
description description
"An index used to uniquely identify BFD sessions."; "An index used to uniquely identify BFD sessions.";
} }
leaf local-state { leaf local-state {
type state; type state;
description "Local state."; description
"Local state.";
} }
leaf remote-state { leaf remote-state {
type state; type state;
description "Remote state."; description
"Remote state.";
} }
leaf local-diagnostic { leaf local-diagnostic {
type iana-bfd-types:diagnostic; type iana-bfd-types:diagnostic;
description "Local diagnostic."; description
"Local diagnostic.";
} }
leaf remote-diagnostic { leaf remote-diagnostic {
type iana-bfd-types:diagnostic; type iana-bfd-types:diagnostic;
description "Remote diagnostic."; description
"Remote diagnostic.";
} }
leaf remote-authenticated { leaf remote-authenticated {
type boolean; type boolean;
description description
"Indicates whether incoming BFD control packets are "Indicates whether incoming BFD control packets are
authenticated."; authenticated.";
} }
leaf remote-authentication-type { leaf remote-authentication-type {
when "../remote-authenticated = 'true'" { when "../remote-authenticated = 'true'" {
description description
"Only valid when incoming BFD control packets are "Only valid when incoming BFD control packets are
authenticated."; authenticated.";
} }
if-feature authentication; if-feature "authentication";
type iana-bfd-types:auth-type; type iana-bfd-types:auth-type;
description description
"Authentication type of incoming BFD control packets."; "Authentication type of incoming BFD control packets.";
} }
leaf detection-mode { leaf detection-mode {
type enumeration { type enumeration {
enum async-with-echo { enum async-with-echo {
value "1"; value 1;
description "Async with echo."; description
"Async with echo.";
} }
enum async-without-echo { enum async-without-echo {
value "2"; value 2;
description "Async without echo."; description
"Async without echo.";
} }
enum demand-with-echo { enum demand-with-echo {
value "3"; value 3;
description "Demand with echo."; description
"Demand with echo.";
} }
enum demand-without-echo { enum demand-without-echo {
value "4"; value 4;
description "Demand without echo."; description
"Demand without echo.";
} }
} }
description "Detection mode."; description
"Detection mode.";
} }
leaf negotiated-tx-interval { leaf negotiated-tx-interval {
type uint32; type uint32;
units microseconds; units "microseconds";
description "Negotiated transmit interval."; description
"Negotiated transmit interval.";
} }
leaf negotiated-rx-interval { leaf negotiated-rx-interval {
type uint32; type uint32;
units microseconds; units "microseconds";
description "Negotiated receive interval."; description
"Negotiated receive interval.";
} }
leaf detection-time { leaf detection-time {
type uint32; type uint32;
units microseconds; units "microseconds";
description "Detection time."; description
"Detection time.";
} }
leaf echo-tx-interval-in-use { leaf echo-tx-interval-in-use {
when "../../path-type = 'bfd-types:path-ip-sh'" { when "../../path-type = 'bfd-types:path-ip-sh'" {
description description
"Echo is supported for IP single-hop only."; "Echo is supported for IP single-hop only.";
} }
if-feature echo-mode; if-feature "echo-mode";
type uint32; type uint32;
units microseconds; units "microseconds";
description "Echo transmit interval in use."; description
"Echo transmit interval in use.";
} }
} }
container session-statistics { container session-statistics {
config "false"; config false;
description "BFD per-session statistics."; description
"BFD per-session statistics.";
leaf create-time { leaf create-time {
type yang:date-and-time; type yang:date-and-time;
description description
"Time and date when this session was created."; "Time and date when this session was created.";
} }
leaf last-down-time { leaf last-down-time {
type yang:date-and-time; type yang:date-and-time;
description description
"Time and date of last time this session went down."; "Time and date of the last time this session went down.";
} }
leaf last-up-time { leaf last-up-time {
type yang:date-and-time; type yang:date-and-time;
description description
"Time and date of last time this session went up."; "Time and date of the last time this session went up.";
} }
leaf down-count { leaf down-count {
type yang:counter32; type yang:counter32;
description description
"The number of times this session has transitioned in the "The number of times this session has transitioned to the
down state."; 'down' state.";
} }
leaf admin-down-count { leaf admin-down-count {
type yang:counter32; type yang:counter32;
description description
"The number of times this session has transitioned in the "The number of times this session has transitioned to the
admin-down state."; 'admin-down' state.";
} }
leaf receive-packet-count { leaf receive-packet-count {
type yang:counter64; type yang:counter64;
description description
"Count of received packets in this session. This includes "Count of received packets in this session. This includes
valid and invalid received packets."; valid and invalid received packets.";
} }
leaf send-packet-count { leaf send-packet-count {
type yang:counter64; type yang:counter64;
description "Count of sent packets in this session."; description
"Count of sent packets in this session.";
} }
leaf receive-invalid-packet-count { leaf receive-invalid-packet-count {
type yang:counter64; type yang:counter64;
description description
"Count of invalid received packets in this session."; "Count of invalid received packets in this session.";
} }
leaf send-failed-packet-count { leaf send-failed-packet-count {
type yang:counter64; type yang:counter64;
description description
"Count of packets which failed to be sent in this session."; "Count of packets that failed to be sent in this session.";
} }
} }
} }
grouping session-statistics-summary { grouping session-statistics-summary {
description "Grouping for session statistics summary."; description
"Grouping for session statistics summary.";
container summary { container summary {
config false; config false;
description "BFD session statistics summary."; description
"BFD session statistics summary.";
leaf number-of-sessions { leaf number-of-sessions {
type yang:gauge32; type yang:gauge32;
description "Number of BFD sessions."; description
"Number of BFD sessions.";
} }
leaf number-of-sessions-up { leaf number-of-sessions-up {
type yang:gauge32; type yang:gauge32;
description description
"Number of BFD sessions currently in up state (as defined "Number of BFD sessions currently in the 'Up' state
in RFC 5880)."; (as defined in RFC 5880).";
} }
leaf number-of-sessions-down { leaf number-of-sessions-down {
type yang:gauge32; type yang:gauge32;
description description
"Number of BFD sessions currently in down or init state "Number of BFD sessions currently in the 'Down' or 'Init'
but not admin-down (as defined in RFC 5880)."; state but not 'adminDown' (as defined in RFC 5880).";
} }
leaf number-of-sessions-admin-down { leaf number-of-sessions-admin-down {
type yang:gauge32; type yang:gauge32;
description description
"Number of BFD sessions currently in admin-down state (as "Number of BFD sessions currently in the 'adminDown' state
defined in RFC 5880)."; (as defined in RFC 5880).";
} }
} }
} }
grouping notification-parms { grouping notification-parms {
description description
"This group describes common parameters that will be sent " + "This group describes common parameters that will be sent
"as part of BFD notification."; as part of BFD notifications.";
leaf local-discr { leaf local-discr {
type discriminator; type discriminator;
description "BFD local discriminator."; description
"BFD local discriminator.";
} }
leaf remote-discr { leaf remote-discr {
type discriminator; type discriminator;
description "BFD remote discriminator."; description
"BFD remote discriminator.";
} }
leaf new-state { leaf new-state {
type state; type state;
description "Current BFD state."; description
"Current BFD state.";
} }
leaf state-change-reason { leaf state-change-reason {
type iana-bfd-types:diagnostic; type iana-bfd-types:diagnostic;
description "BFD state change reason."; description
"Reason for the BFD state change.";
} }
leaf time-of-last-state-change { leaf time-of-last-state-change {
type yang:date-and-time; type yang:date-and-time;
description description
"Calendar time of previous state change."; "Calendar time of the most recent previous state change.";
} }
leaf dest-addr { leaf dest-addr {
type inet:ip-address; type inet:ip-address;
description "BFD peer address."; description
"BFD peer address.";
} }
leaf source-addr { leaf source-addr {
type inet:ip-address; type inet:ip-address;
description "BFD local address."; description
"BFD local address.";
} }
leaf session-index { leaf session-index {
type uint32; type uint32;
description "An index used to uniquely identify BFD sessions."; description
"An index used to uniquely identify BFD sessions.";
} }
leaf path-type { leaf path-type {
type identityref { type identityref {
base path-type; base path-type;
} }
description "BFD path type."; description
"BFD path type.";
} }
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="BFD top-level YANG Module"> <name>BFD Top-Level YANG Module</name>
<t>This YANG module imports and augments <t>This YANG module imports and augments
"/routing/control-plane-protocols/control-plane-protocol" from <xref "/routing/control-plane-protocols/control-plane-protocol" from <xref
target="RFC8349"/>.</t> target="RFC8349" format="default"/>. It also references
<xref target="RFC5880"/>.</t>
<figure align="left"> <sourcecode name="ietf-bfd@2021-09-03.yang" type="yang" markers="true"><
<preamble/> ![CDATA[
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd@2018-08-01.yang"
module ietf-bfd { module ietf-bfd {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd";
prefix bfd;
prefix "bfd";
// RFC Ed.: replace occurences of XXXX with actual RFC number and
// remove this note
import ietf-bfd-types { import ietf-bfd-types {
prefix "bfd-types"; prefix bfd-types;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
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: <http://tools.ietf.org/wg/bfd> "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org> WG List: <mailto:rtg-bfd@ietf.org>
Editors: Reshad Rahman (rrahman@cisco.com), Editor: Reshad Rahman
Lianshu Zheng (vero.zheng@huawei.com), <mailto:reshad@yahoo.com>
Mahesh Jethanandani (mjethanandani@gmail.com)";
Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>";
description description
"This module contains the YANG definition for BFD parameters as "This module contains the YANG definition for BFD parameters as
per RFC 5880. per RFC 5880.
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2021 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
reference "RFC XXXX"; This version of this YANG module is part of RFC 9127; see the
RFC itself for full legal notices.";
reference
"RFC 5880: Bidirectional Forwarding Detection (BFD)
RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
revision 2018-08-01 { revision 2021-09-03 {
description "Initial revision."; description
reference "RFC XXXX: YANG Data Model for BFD"; "Initial revision.";
reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol" { + "rt:control-plane-protocol" {
when "derived-from-or-self(rt:type, 'bfd-types:bfdv1')" { when "derived-from-or-self(rt:type, 'bfd-types:bfdv1')" {
description description
"This augmentation is only valid for a control-plane protocol "This augmentation is only valid for a control-plane protocol
instance of BFD (type 'bfdv1')."; instance of BFD (type 'bfdv1').";
} }
description "BFD augmentation."; description
"BFD augmentation.";
container bfd { container bfd {
description "BFD top level container."; description
"BFD top-level container.";
uses bfd-types:session-statistics-summary; uses bfd-types:session-statistics-summary;
} }
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
<section anchor="bfd-ip-single-hop-module" numbered="true" toc="default">
<section title="BFD IP single-hop YANG Module"> <name>BFD IP Single-Hop YANG Module</name>
<t>This YANG module imports "interface-ref" from <xref <t>This YANG module imports "interface-ref" from <xref
target="RFC8343"/>, typedefs from <xref target="RFC8343" format="default"/> and typedefs from <xref
target="RFC6991"/> and augments target="RFC6991" format="default"/>. It also imports and augments
"/routing/control-plane-protocols/control-plane-protocol" from <xref "/routing/control-plane-protocols/control-plane-protocol" from <xref
target="RFC8349"/>.</t> target="RFC8349" format="default"/>, and it references
<xref target="RFC5881"/>.</t>
<figure align="left"> <sourcecode name="ietf-bfd-ip-sh@2021-09-03.yang" type="yang" markers="t
<preamble/> rue"><![CDATA[
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-ip-sh@2018-08-01.yang"
module ietf-bfd-ip-sh { module ietf-bfd-ip-sh {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh";
prefix bfd-ip-sh;
prefix "bfd-ip-sh";
// RFC Ed.: replace occurences of XXXX with actual RFC number and
// remove this note
import ietf-bfd-types { import ietf-bfd-types {
prefix "bfd-types"; prefix bfd-types;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix "bfd"; prefix bfd;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
import ietf-interfaces { import ietf-interfaces {
prefix "if"; prefix if;
reference reference
"RFC 8343: A YANG Data Model for Interface Management"; "RFC 8343: A YANG Data Model for Interface Management";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix inet;
reference "RFC 6991: Common YANG Data Types"; reference
"RFC 6991: Common YANG Data Types";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA Version)";
} }
organization "IETF BFD Working Group"; organization
"IETF BFD Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/bfd> "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org> WG List: <mailto:rtg-bfd@ietf.org>
Editors: Reshad Rahman (rrahman@cisco.com), Editor: Reshad Rahman
Lianshu Zheng (vero.zheng@huawei.com), <mailto:reshad@yahoo.com>
Mahesh Jethanandani (mjethanandani@gmail.com)";
Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>";
description description
"This module contains the YANG definition for BFD IP single-hop "This module contains the YANG definition for BFD IP single-hop
as per RFC 5881. as per RFC 5881.
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2021 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
reference "RFC XXXX"; This version of this YANG module is part of RFC 9127; see the
RFC itself for full legal notices.";
reference
"RFC 5881: Bidirectional Forwarding Detection (BFD)
for IPv4 and IPv6 (Single Hop)
RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
revision 2018-08-01 { revision 2021-09-03 {
description "Initial revision."; description
reference "RFC XXXX: A YANG data model for BFD IP single-hop"; "Initial revision.";
reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
/* /*
* Augments * Augments
*/ */
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd" { + "rt:control-plane-protocol/bfd:bfd" {
description "BFD augmentation for IP single-hop"; description
"BFD augmentation for IP single-hop.";
container ip-sh { container ip-sh {
description "BFD IP single-hop top level container"; description
"BFD IP single-hop top-level container.";
uses bfd-types:session-statistics-summary; uses bfd-types:session-statistics-summary;
container sessions { container sessions {
description description
"BFD IP single-hop sessions."; "BFD IP single-hop sessions.";
list session { list session {
key "interface dest-addr"; key "interface dest-addr";
description "List of IP single-hop sessions."; description
"List of IP single-hop sessions.";
leaf interface { leaf interface {
type if:interface-ref; type if:interface-ref;
description description
"Interface on which the BFD session is running."; "Interface on which the BFD session is running.";
} }
leaf dest-addr { leaf dest-addr {
type inet:ip-address; type inet:ip-address;
description "IP address of the peer."; description
"IP address of the peer.";
} }
leaf source-addr { leaf source-addr {
type inet:ip-address; type inet:ip-address;
description "Local IP address."; description
"Local IP address.";
} }
uses bfd-types:common-cfg-parms; uses bfd-types:common-cfg-parms;
uses bfd-types:all-session; uses bfd-types:all-session;
} }
} }
list interfaces { list interfaces {
key "interface"; key "interface";
description "List of interfaces."; description
"List of interfaces.";
leaf interface { leaf interface {
type if:interface-ref; type if:interface-ref;
description description
"BFD information for this interface."; "BFD information for this interface.";
} }
uses bfd-types:auth-parms; uses bfd-types:auth-parms;
} }
} }
} }
/* /*
* Notifications * Notifications
*/ */
notification singlehop-notification { notification singlehop-notification {
description description
"Notification for BFD single-hop session state change. An " + "Notification for BFD single-hop session state change. An
"implementation may rate-limit notifications, e.g. when a " + implementation may rate-limit notifications, e.g., when a
"session is continuously changing state."; session is continuously changing state.";
uses bfd-types:notification-parms; uses bfd-types:notification-parms;
leaf interface { leaf interface {
type if:interface-ref; type if:interface-ref;
description "Interface to which this BFD session belongs to."; description
"Interface to which this BFD session belongs.";
} }
leaf echo-enabled { leaf echo-enabled {
type boolean; type boolean;
description "Was echo enabled for BFD."; description
"Indicates whether Echo was enabled for BFD.";
} }
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
<section anchor="bfd-ip-multihop-module" numbered="true" toc="default">
<section title="BFD IP multihop YANG Module"> <name>BFD IP Multihop YANG Module</name>
<t>This YANG module imports typedefs from <xref <t>This YANG module imports typedefs from
target="RFC6991"/> and augments <xref target="RFC6991" format="default"/>. It also imports and augments
"/routing/control-plane-protocols/control-plane-protocol" from <xref "/routing/control-plane-protocols/control-plane-protocol" from <xref
target="RFC8349"/>.</t> target="RFC8349" format="default"/>, and it references
<xref target="RFC5883"/>.</t>
<figure align="left"> <sourcecode name="ietf-bfd-ip-mh@2021-09-03.yang" type="yang" markers="t
<preamble/> rue"><![CDATA[
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-ip-mh@2018-08-01.yang"
module ietf-bfd-ip-mh { module ietf-bfd-ip-mh {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh";
prefix bfd-ip-mh;
prefix "bfd-ip-mh";
// RFC Ed.: replace occurences of XXXX with actual RFC number and
// remove this note
import ietf-bfd-types { import ietf-bfd-types {
prefix "bfd-types"; prefix bfd-types;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix "bfd"; prefix bfd;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix inet;
reference "RFC 6991: Common YANG Data Types"; reference
"RFC 6991: Common YANG Data Types";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA Version)";
} }
organization "IETF BFD Working Group"; organization
"IETF BFD Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/bfd> "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org> WG List: <mailto:rtg-bfd@ietf.org>
Editors: Reshad Rahman (rrahman@cisco.com), Editor: Reshad Rahman
Lianshu Zheng (vero.zheng@huawei.com), <mailto:reshad@yahoo.com>
Mahesh Jethanandani (mjethanandani@gmail.com)";
Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>";
description description
"This module contains the YANG definition for BFD IP multi-hop "This module contains the YANG definition for BFD IP multihop
as per RFC 5883. as per RFC 5883.
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2021 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
reference "RFC XXXX"; This version of this YANG module is part of RFC 9127; see the
RFC itself for full legal notices.";
reference
"RFC 5883: Bidirectional Forwarding Detection (BFD) for
Multihop Paths
RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
revision 2018-08-01 { revision 2021-09-03 {
description "Initial revision."; description
reference "RFC XXXX: A YANG data model for BFD IP multihop."; "Initial revision.";
reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
/* /*
* Augments * Augments
*/ */
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd" { + "rt:control-plane-protocol/bfd:bfd" {
description "BFD augmentation for IP multihop."; description
"BFD augmentation for IP multihop.";
container ip-mh { container ip-mh {
description "BFD IP multihop top level container."; description
"BFD IP multihop top-level container.";
uses bfd-types:session-statistics-summary; uses bfd-types:session-statistics-summary;
container session-groups { container session-groups {
description description
"BFD IP multi-hop session groups."; "BFD IP multihop session groups.";
list session-group { list session-group {
key "source-addr dest-addr"; key "source-addr dest-addr";
description description
"Group of BFD IP multi-hop sessions (for ECMP). A " + "Group of BFD IP multihop sessions (for ECMP). A
"group of sessions is between 1 source and 1 " + group of sessions is between one source and one
"destination, each session has a different field " + destination. Each session has a different field
"in UDP/IP hdr for ECMP."; in the UDP/IP header for ECMP.";
leaf source-addr { leaf source-addr {
type inet:ip-address; type inet:ip-address;
description description
"Local IP address."; "Local IP address.";
} }
leaf dest-addr { leaf dest-addr {
type inet:ip-address; type inet:ip-address;
description description
"IP address of the peer."; "IP address of the peer.";
} }
skipping to change at line 2268 skipping to change at line 2108
type inet:ip-address; type inet:ip-address;
description description
"Local IP address."; "Local IP address.";
} }
leaf dest-addr { leaf dest-addr {
type inet:ip-address; type inet:ip-address;
description description
"IP address of the peer."; "IP address of the peer.";
} }
uses bfd-types:common-cfg-parms; uses bfd-types:common-cfg-parms;
leaf tx-ttl { leaf tx-ttl {
type bfd-types:hops; type bfd-types:hops;
default 255; default "255";
description "Hop count of outgoing BFD control packets."; description
"Hop count of outgoing BFD control packets.";
} }
leaf rx-ttl { leaf rx-ttl {
type bfd-types:hops; type bfd-types:hops;
mandatory true; mandatory true;
description description
"Minimum allowed hop count value for incoming BFD control "Minimum allowed hop count value for incoming BFD
packets. Control packets whose hop count is lower than control packets. Control packets whose hop count is
this value are dropped."; lower than this value are dropped.";
} }
list sessions { list sessions {
config false; config false;
description description
"The multiple BFD sessions between a source and a " + "The multiple BFD sessions between a source and a
"destination."; destination.";
uses bfd-types:all-session; uses bfd-types:all-session;
} }
} }
} }
} }
} }
/* /*
* Notifications * Notifications
*/ */
skipping to change at line 2297 skipping to change at line 2137
uses bfd-types:all-session; uses bfd-types:all-session;
} }
} }
} }
} }
} }
/* /*
* Notifications * Notifications
*/ */
notification multihop-notification { notification multihop-notification {
description description
"Notification for BFD multi-hop session state change. An " + "Notification for BFD multihop session state change. An
"implementation may rate-limit notifications, e.g. when a " + implementation may rate-limit notifications, e.g., when a
"session is continuously changing state."; session is continuously changing state.";
uses bfd-types:notification-parms; uses bfd-types:notification-parms;
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
<section anchor="bfd-over-lag-module" numbered="true" toc="default">
<section title="BFD over LAG YANG Module"> <name>BFD-over-LAG YANG Module</name>
<t>This YANG module imports "interface-ref" from <xref <t>This YANG module imports "interface-ref" from <xref
target="RFC8343"/>, typedefs from <xref target="RFC8343" format="default"/> and typedefs from <xref
target="RFC6991"/> and augments target="RFC6991" format="default"/>. It also imports and augments
"/routing/control-plane-protocols/control-plane-protocol" from <xref "/routing/control-plane-protocols/control-plane-protocol" from <xref
target="RFC8349"/>.</t> target="RFC8349" format="default"/>. Additionally, it references
<xref target="RFC7130"/>.</t>
<figure align="left"> <sourcecode name="ietf-bfd-lag@2021-09-03.yang" type="yang" markers="tru
<preamble/> e"><![CDATA[
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-lag@2018-08-01.yang"
module ietf-bfd-lag { module ietf-bfd-lag {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-lag"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-lag";
prefix bfd-lag;
prefix "bfd-lag";
// RFC Ed.: replace occurences of XXXX with actual RFC number and
// remove this note
import ietf-bfd-types { import ietf-bfd-types {
prefix "bfd-types"; prefix bfd-types;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix "bfd"; prefix bfd;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
import ietf-interfaces { import ietf-interfaces {
prefix "if"; prefix if;
reference reference
"RFC 8343: A YANG Data Model for Interface Management"; "RFC 8343: A YANG Data Model for Interface Management";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix inet;
reference "RFC 6991: Common YANG Data Types"; reference
"RFC 6991: Common YANG Data Types";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA Version)";
} }
organization "IETF BFD Working Group"; organization
"IETF BFD Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/bfd> "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org> WG List: <mailto:rtg-bfd@ietf.org>
Editors: Reshad Rahman (rrahman@cisco.com), Editor: Reshad Rahman
Lianshu Zheng vero.zheng@huawei.com), <mailto:reshad@yahoo.com>
Mahesh Jethanandani (mjethanandani@gmail.com)";
Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>";
description description
"This module contains the YANG definition for BFD over LAG "This module contains the YANG definition for BFD-over-LAG
interfaces as per RFC7130. interfaces as per RFC 7130.
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2021 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
reference "RFC XXXX"; This version of this YANG module is part of RFC 9127; see the
RFC itself for full legal notices.";
reference
"RFC 7130: Bidirectional Forwarding Detection (BFD) on
Link Aggregation Group (LAG) Interfaces
RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
revision 2018-08-01 { revision 2021-09-03 {
description "Initial revision."; description
reference "RFC XXXX: A YANG data model for BFD over LAG"; "Initial revision.";
reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
/* /*
* Augments * Augments
*/ */
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd" { + "rt:control-plane-protocol/bfd:bfd" {
description "BFD augmentation for LAG"; description
"BFD augmentation for a LAG.";
container lag { container lag {
description "BFD over LAG top level container"; description
"BFD-over-LAG top-level container.";
container micro-bfd-ipv4-session-statistics { container micro-bfd-ipv4-session-statistics {
description "Micro-BFD IPv4 session counters."; description
"Micro-BFD IPv4 session counters.";
uses bfd-types:session-statistics-summary; uses bfd-types:session-statistics-summary;
} }
container micro-bfd-ipv6-session-statistics { container micro-bfd-ipv6-session-statistics {
description "Micro-BFD IPv6 session counters."; description
"Micro-BFD IPv6 session counters.";
uses bfd-types:session-statistics-summary; uses bfd-types:session-statistics-summary;
} }
container sessions { container sessions {
description description
"BFD over LAG sessions"; "BFD-over-LAG sessions.";
list session { list session {
key "lag-name"; key "lag-name";
description "List of BFD over LAG sessions."; description
"List of BFD-over-LAG sessions.";
leaf lag-name { leaf lag-name {
type if:interface-ref ; type if:interface-ref;
description "Name of the LAG"; description
"Name of the LAG.";
} }
leaf ipv4-dest-addr { leaf ipv4-dest-addr {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the peer, for IPv4 micro-BFD."; "IPv4 address of the peer, for IPv4 micro-BFD.";
} }
leaf ipv6-dest-addr { leaf ipv6-dest-addr {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 address of the peer, for IPv6 micro-BFD."; "IPv6 address of the peer, for IPv6 micro-BFD.";
skipping to change at line 2437 skipping to change at line 2279
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the peer, for IPv4 micro-BFD."; "IPv4 address of the peer, for IPv4 micro-BFD.";
} }
leaf ipv6-dest-addr { leaf ipv6-dest-addr {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 address of the peer, for IPv6 micro-BFD."; "IPv6 address of the peer, for IPv6 micro-BFD.";
} }
uses bfd-types:common-cfg-parms; uses bfd-types:common-cfg-parms;
leaf use-ipv4 { leaf use-ipv4 {
type boolean; type boolean;
description "Using IPv4 micro-BFD."; description
"Using IPv4 micro-BFD.";
} }
leaf use-ipv6 { leaf use-ipv6 {
type boolean; type boolean;
description "Using IPv6 micro-BFD."; description
"Using IPv6 micro-BFD.";
} }
list member-links { list member-links {
key "member-link"; key "member-link";
config false; config false;
description description
"Micro-BFD over LAG. This represents one member link."; "Micro-BFD over a LAG. This represents one
member link.";
leaf member-link { leaf member-link {
type if:interface-ref; type if:interface-ref;
description description
"Member link on which micro-BFD is running."; "Member link on which micro-BFD is running.";
} }
container micro-bfd-ipv4 { container micro-bfd-ipv4 {
when "../../use-ipv4 = 'true'" { when "../../use-ipv4 = 'true'" {
description "Needed only if IPv4 is used."; description
"Needed only if IPv4 is used.";
} }
description description
"Micro-BFD IPv4 session state on member link."; "Micro-BFD IPv4 session state on a member link.";
uses bfd-types:all-session; uses bfd-types:all-session;
} }
container micro-bfd-ipv6 { container micro-bfd-ipv6 {
when "../../use-ipv6 = 'true'" { when "../../use-ipv6 = 'true'" {
description "Needed only if IPv6 is used."; description
"Needed only if IPv6 is used.";
} }
description description
"Micro-BFD IPv6 session state on member link."; "Micro-BFD IPv6 session state on a member link.";
uses bfd-types:all-session; uses bfd-types:all-session;
} }
} }
} }
} }
} }
} }
/* /*
* Notifications * Notifications
skipping to change at line 2483 skipping to change at line 2327
} }
} }
} }
} }
} }
} }
/* /*
* Notifications * Notifications
*/ */
notification lag-notification { notification lag-notification {
description description
"Notification for BFD over LAG session state change. " + "Notification for BFD-over-LAG session state change.
"An implementation may rate-limit notifications, e.g. when a " + An implementation may rate-limit notifications, e.g., when a
"session is continuously changing state."; session is continuously changing state.";
uses bfd-types:notification-parms; uses bfd-types:notification-parms;
leaf lag-name { leaf lag-name {
type if:interface-ref; type if:interface-ref;
description "LAG interface name."; description
"LAG interface name.";
} }
leaf member-link { leaf member-link {
type if:interface-ref; type if:interface-ref;
description "Member link on which BFD is running."; description
"Member link on which BFD is running.";
} }
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
<section anchor="bfd-over-mpls-module" numbered="true" toc="default">
<section title="BFD over MPLS YANG Module"> <name>BFD-over-MPLS YANG Module</name>
<t>This YANG module imports typedefs from <xref <t>This YANG module imports typedefs from <xref target="RFC6991"
target="RFC6991"/> and augments format="default"/>. It also imports and augments
"/routing/control-plane-protocols/control-plane-protocol" from <xref "/routing/control-plane-protocols/control-plane-protocol" from <xref
target="RFC8349"/>.</t> target="RFC8349" format="default"/>.
Additionally, it references <xref target="RFC5586"/> and
<figure align="left"> <xref target="RFC5884"/>.</t>
<preamble/> <sourcecode name="ietf-bfd-mpls@2021-09-03.yang" type="yang" markers="tr
ue"><![CDATA[
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-mpls@2018-08-01.yang"
module ietf-bfd-mpls { module ietf-bfd-mpls {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls";
prefix bfd-mpls;
prefix "bfd-mpls";
// RFC Ed.: replace occurences of XXXX with actual RFC number and
// remove this note
import ietf-bfd-types { import ietf-bfd-types {
prefix "bfd-types"; prefix bfd-types;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix "bfd"; prefix bfd;
reference "RFC XXXX: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix inet;
reference "RFC 6991: Common YANG Data Types"; reference
"RFC 6991: Common YANG Data Types";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA Version)";
} }
organization "IETF BFD Working Group"; organization
"IETF BFD Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/bfd> "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org> WG List: <mailto:rtg-bfd@ietf.org>
Editors: Reshad Rahman (rrahman@cisco.com), Editor: Reshad Rahman
Lianshu Zheng (vero.zheng@huawei.com), <mailto:reshad@yahoo.com>
Mahesh Jethanandani (mjethanandani@gmail.com)";
Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>";
description description
"This module contains the YANG definition for BFD parameters for "This module contains the YANG definition for BFD parameters for
MPLS LSPs as per RFC 5884. MPLS LSPs as per RFC 5884.
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2021 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
reference "RFC XXXX"; This version of this YANG module is part of RFC 9127; see the
RFC itself for full legal notices.";
reference
"RFC 5884: Bidirectional Forwarding Detection (BFD)
for MPLS Label Switched Paths (LSPs)
RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
revision 2018-08-01 { revision 2021-09-03 {
description "Initial revision."; description
reference "RFC XXXX: A YANG data model for BFD over MPLS LSPs"; "Initial revision.";
reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
} }
/* /*
* Identity definitions * Identity definitions
*/ */
identity encap-gach { identity encap-gach {
base bfd-types:encap-type; base bfd-types:encap-type;
description description
"BFD with G-ACh encapsulation as per RFC 5586."; "BFD with G-ACh encapsulation as per RFC 5586.";
reference
"RFC 5586: MPLS Generic Associated Channel";
} }
identity encap-ip-gach { identity encap-ip-gach {
base bfd-types:encap-type; base bfd-types:encap-type;
description description
"BFD with IP and G-ACh encapsulation as per RFC 5586."; "BFD with IP and G-ACh encapsulation as per RFC 5586.";
} }
/* /*
* Groupings * Groupings
*/ */
grouping encap-cfg {
description "Configuration for BFD encapsulation";
grouping encap-cfg {
description
"Configuration for BFD encapsulation.";
leaf encap { leaf encap {
type identityref { type identityref {
base bfd-types:encap-type; base bfd-types:encap-type;
} }
default bfd-types:encap-ip; default "bfd-types:encap-ip";
description "BFD encapsulation"; description
"BFD encapsulation.";
} }
} }
grouping mpls-dest-address { grouping mpls-dest-address {
description "Destination address as per RFC 5884."; description
"Destination address as per RFC 5884.";
reference
"RFC 5884: Bidirectional Forwarding Detection (BFD)
for MPLS Label Switched Paths (LSPs)";
leaf mpls-dest-address { leaf mpls-dest-address {
type inet:ip-address; type inet:ip-address;
config "false"; config false;
description description
"Destination address as per RFC 5884. "Destination address as per RFC 5884.
Needed if IP encapsulation is used."; Needed if IP encapsulation is used.";
} }
} }
/* /*
* Augments * Augments
*/ */
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd" { + "rt:control-plane-protocol/bfd:bfd" {
description "BFD augmentation for MPLS."; description
"BFD augmentation for MPLS.";
container mpls { container mpls {
description "BFD MPLS top level container."; description
"BFD MPLS top-level container.";
uses bfd-types:session-statistics-summary; uses bfd-types:session-statistics-summary;
container egress { container egress {
description "Egress configuration."; description
"Egress configuration.";
uses bfd-types:client-cfg-parms; uses bfd-types:client-cfg-parms;
uses bfd-types:auth-parms; uses bfd-types:auth-parms;
} }
container session-groups { container session-groups {
description description
"BFD over MPLS session groups."; "BFD-over-MPLS session groups.";
list session-group { list session-group {
key "mpls-fec"; key "mpls-fec";
description description
"Group of BFD MPLS sessions (for ECMP). A group of " + "Group of BFD MPLS sessions (for ECMP). A group of
"sessions is for 1 FEC, each session has a different " + sessions is for one FEC. Each session has a different
"field in UDP/IP hdr for ECMP."; field in the UDP/IP header for ECMP.";
leaf mpls-fec { leaf mpls-fec {
type inet:ip-prefix; type inet:ip-prefix;
description "MPLS FEC."; description
"MPLS FEC.";
} }
uses bfd-types:common-cfg-parms; uses bfd-types:common-cfg-parms;
list sessions { list sessions {
config false; config false;
description description
"The BFD sessions for an MPLS FEC. Local " + "The BFD sessions for an MPLS FEC. The local
"discriminator is unique for each session in the " + discriminator is unique for each session in the
"group."; group.";
uses bfd-types:all-session; uses bfd-types:all-session;
uses bfd-mpls:mpls-dest-address; uses bfd-mpls:mpls-dest-address;
} }
} }
} }
} }
} }
/* /*
* Notifications * Notifications
*/ */
skipping to change at line 2682 skipping to change at line 2530
uses bfd-mpls:mpls-dest-address; uses bfd-mpls:mpls-dest-address;
} }
} }
} }
} }
} }
/* /*
* Notifications * Notifications
*/ */
notification mpls-notification { notification mpls-notification {
description description
"Notification for BFD over MPLS FEC session state change. " + "Notification for BFD-over-MPLS FEC session state change.
"An implementation may rate-limit notifications, e.g. when a " + An implementation may rate-limit notifications, e.g., when a
"session is continuously changing state."; session is continuously changing state.";
uses bfd-types:notification-parms; uses bfd-types:notification-parms;
leaf mpls-dest-address { leaf mpls-dest-address {
type inet:ip-address; type inet:ip-address;
description description
"Destination address as per RFC 5884. "Destination address as per RFC 5884.
Needed if IP encapsulation is used."; Needed if IP encapsulation is used.";
} }
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section title="BFD over MPLS-TE YANG Module">
<t>This YANG module imports and augments "/te/tunnels/tunnel" from
<xref target="I-D.ietf-teas-yang-te"/>.</t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-mpls-te@2018-08-01.yang"
module ietf-bfd-mpls-te {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te";
prefix "bfd-mpls-te";
// RFC Ed.: replace occurences of XXXX with actual RFC number and
// remove this note
import ietf-bfd-types {
prefix "bfd-types";
reference "RFC XXXX: YANG Data Model for BFD";
}
import ietf-bfd {
prefix "bfd";
reference "RFC XXXX: YANG Data Model for BFD";
}
import ietf-bfd-mpls {
prefix "bfd-mpls";
reference "RFC XXXX: YANG Data Model for BFD";
}
import ietf-te {
prefix "te";
// RFC Ed.: replace YYYY with actual RFC number of
// draft-ietf-teas-yang-te and remove this note.
reference
"RFC YYYY: A YANG Data Model for Traffic Engineering Tunnels and
Interfaces";
}
import ietf-routing {
prefix "rt";
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA version)";
}
organization "IETF BFD Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/bfd>
WG List: <rtg-bfd@ietf.org>
Editors: Reshad Rahman (rrahman@cisco.com),
Lianshu Zheng (vero.zheng@huawei.com),
Mahesh Jethanandani (mjethanandani@gmail.com)";
description
"This module contains the YANG definition for BFD parameters for
MPLS Traffic Engineering as per RFC 5884.
Copyright (c) 2018 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 Simplified 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 XXXX; see
the RFC itself for full legal notices.";
reference "RFC XXXX";
revision 2018-08-01 {
description "Initial revision.";
reference "RFC XXXX: A YANG data model for BFD over MPLS-TE";
}
/*
* Augments
*/
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd" {
description "BFD augmentation for MPLS-TE.";
container mpls-te {
description "BFD MPLS-TE top level container.";
container egress {
description "Egress configuration.";
uses bfd-types:client-cfg-parms;
uses bfd-types:auth-parms;
}
uses bfd-types:session-statistics-summary;
}
}
augment "/te:te/te:tunnels/te:tunnel" {
description "BFD configuration on MPLS-TE tunnel.";
uses bfd-types:common-cfg-parms;
uses bfd-mpls:encap-cfg;
}
augment "/te:te/te:lsps-state/te:lsp" {
when "/te:te/te:lsps-state/te:lsp/te:origin-type != 'transit'" {
description "BFD information not needed at transit points.";
}
description "BFD state information on MPLS-TE LSP.";
uses bfd-types:all-session;
uses bfd-mpls:mpls-dest-address;
}
/*
* Notifications
*/
notification mpls-te-notification {
description
"Notification for BFD over MPLS-TE session state change. " +
"An implementation may rate-limit notifications, e.g. when a " +
"session is continuously changing state.";
uses bfd-types:notification-parms;
uses bfd-mpls:mpls-dest-address;
leaf tunnel-name {
type string;
description "MPLS-TE tunnel on which BFD was running.";
}
}
}
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Data Model examples"> <name>Data Model Examples</name>
<t>This section presents some simple and illustrative examples on how to <t>This section presents some simple and illustrative examples of how to
configure BFD.</t> configure BFD.</t>
<t>The examples are represented in XML <xref target="W3C.REC-xml-20081126"
<section title="IP single-hop"> />.</t>
<section numbered="true" toc="default">
<name>IP Single-Hop</name>
<t>The following is an example configuration for a BFD IP single-hop <t>The following is an example configuration for a BFD IP single-hop
session. The desired transmit interval and the required receive session. The desired transmit interval and the required receive
interval are both set to 10ms.</t> interval are both set to 10 ms.</t>
<sourcecode type="xml"><![CDATA[
<figure align="left">
<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 xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"> <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
ianaift:ethernetCsmacd ianaift:ethernetCsmacd
</type> </type>
</interface> </interface>
</interfaces> </interfaces>
skipping to change at line 2893 skipping to change at line 2583
"urn:ietf:params:xml:ns:yang:ietf-bfd-types"> "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
bfd-types:bfdv1 bfd-types:bfdv1
</type> </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">
<sessions> <sessions>
<session> <session>
<interface>eth0</interface> <interface>eth0</interface>
<dest-addr>2001:db8:0:113::101</dest-addr> <dest-addr>2001:db8:0:113::101</dest-addr>
<desired-min-tx-interval>10000</desired-min-tx-interval> <desired-min-tx-interval>
10000
</desired-min-tx-interval>
<required-min-rx-interval> <required-min-rx-interval>
10000 10000
</required-min-rx-interval> </required-min-rx-interval>
</session> </session>
</sessions> </sessions>
</ip-sh> </ip-sh>
</bfd> </bfd>
</control-plane-protocol> </control-plane-protocol>
</control-plane-protocols> </control-plane-protocols>
</routing> </routing>
</config> </config>
]]></sourcecode>
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="IP multihop"> <name>IP Multihop</name>
<t>The following is an example configuration for a BFD IP multihop <t>The following is an example configuration for a BFD IP multihop
session group. The desired transmit interval and the required receive session group. The desired transmit interval and the required receive
interval are both set to 150ms.</t> interval are both set to 150 ms.</t>
<sourcecode type="xml"><![CDATA[
<figure align="left">
<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">
<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 xmlns:bfd-types= <type xmlns:bfd-types=
"urn:ietf:params:xml:ns:yang:ietf-bfd-types"> "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
bfd-types:bfdv1 bfd-types:bfdv1
</type> </type>
<name>name:BFD</name> <name>name:BFD</name>
skipping to change at line 2950 skipping to change at line 2636
</required-min-rx-interval> </required-min-rx-interval>
<rx-ttl>240</rx-ttl> <rx-ttl>240</rx-ttl>
</session-group> </session-group>
</session-groups> </session-groups>
</ip-mh> </ip-mh>
</bfd> </bfd>
</control-plane-protocol> </control-plane-protocol>
</control-plane-protocols> </control-plane-protocols>
</routing> </routing>
</config> </config>
]]></artwork> ]]></sourcecode>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="LAG"> <name>LAG</name>
<t>The following is an example of BFD configuration for a LAG session. <t>The following is an example of BFD configuration for a LAG session.
In this case, an interface named "Bundle-Ether1" of interface type In this case, an interface named "Bundle-Ether1" of interface type
"ieee802eadLag" has a desired transmit and required receive interval "ieee8023adLag" has a desired transmit interval and required receive int
set to 10ms. </t> erval
set to 10 ms.</t>
<t><figure> <sourcecode type="xml"><![CDATA[
<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>Bundle-Ether1</name> <name>Bundle-Ether1</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"> <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
ianaift:ieee8023adLag ianaift:ieee8023adLag
</type> </type>
</interface> </interface>
</interfaces> </interfaces>
skipping to change at line 3001 skipping to change at line 2684
</required-min-rx-interval> </required-min-rx-interval>
<use-ipv6>true</use-ipv6> <use-ipv6>true</use-ipv6>
</session> </session>
</sessions> </sessions>
</lag> </lag>
</bfd> </bfd>
</control-plane-protocol> </control-plane-protocol>
</control-plane-protocols> </control-plane-protocols>
</routing> </routing>
</config> </config>
]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
<section numbered="true" toc="default">
<section title="MPLS"> <name>MPLS</name>
<t>The following is an example of BFD configured for an MPLS LSP. In <t>The following is an example of BFD configured for an MPLS LSP. In
this case, the desired transmit and required receive interval set to this case, the desired transmit interval and required receive interval
250ms.</t> are both set to 250 ms.</t>
<sourcecode type="xml"><![CDATA[
<t><figure>
<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">
<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 xmlns:bfd-types= <type xmlns:bfd-types=
"urn:ietf:params:xml:ns:yang:ietf-bfd-types"> "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
bfd-types:bfdv1 bfd-types:bfdv1
</type> </type>
<name>name:BFD</name> <name>name:BFD</name>
skipping to change at line 3042 skipping to change at line 2721
250000 250000
</required-min-rx-interval> </required-min-rx-interval>
</session-group> </session-group>
</session-groups> </session-groups>
</mpls> </mpls>
</bfd> </bfd>
</control-plane-protocol> </control-plane-protocol>
</control-plane-protocols> </control-plane-protocols>
</routing> </routing>
</config> </config>
]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>The YANG module specified in this document defines a schema for data <!-- Begin YANG security DNE paragraphs 1 and 2 (fixed per boilerplate) -->
that is designed to be accessed via network management protocols such as <t>The YANG modules specified in this document define a schema for data
NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. that is designed to be accessed via network management protocols such
The lowest NETCONF layer is the secure transport layer, and the as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
mandatory-to-implement secure transport is Secure Shell (SSH) <xref The lowest NETCONF layer is the secure transport layer, and the
target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is Secure Shell (SSH)
mandatory-to-implement secure transport is TLS <xref <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the
target="RFC5246"/>.</t> mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="RFC8
<t>The NETCONF access control model <xref target="RFC6536"/> provides 341"/>
the means to restrict access for particular NETCONF or RESTCONF users to provides the means to restrict access for particular NETCONF or RESTCONF users
a preconfigured subset of all available NETCONF or RESTCONF protocol to a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.</t> operations and content.</t>
<!-- End YANG security DNE text (paragraphs 1 and 2) -->
<t>There are a number of data nodes defined in this YANG module that are <!-- Begin YANG security DNE paragraph 3 (OK) -->
writable/creatable/deletable (i.e., config true, which is the default). <t>There are a number of data nodes defined in these YANG modules that are
These data nodes may be considered sensitive or vulnerable in some writable/creatable/deletable (i.e., config true, which is the default). These
network environments. Write operations (e.g., edit-config) to these data data nodes may be considered sensitive or vulnerable in some network
nodes without proper protection can have a negative effect on network environments. Write operations (e.g., edit-config) to these data nodes without
operations. These are the subtrees and data nodes and their proper protection can have a negative effect on network operations. These are
sensitivity/vulnerability:</t> the subtrees and data nodes and their sensitivity/vulnerability from a write acc
ess perspective:</t>
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessi <!-- End YANG security DNE paragraph 3 -->
ons: <dl newline="true" spacing="normal">
the list specifies the IP single-hop BFD sessions.</t> <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sess
ions:</dt>
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessi <dd><t>This list specifies the IP single-hop BFD sessions.</t>
ons: <t>Data nodes "local-multiplier", "desired-min-tx-interval",
data nodes local-multiplier, desired-min-tx-interval, "required-min-rx-interval", and "min-interval" all impact the
required-min-rx-interval and min-interval all impact the BFD IP single-hop session. The "source-addr" and "dest-addr" data nodes ca
BFD IP single-hop session. The source-addr and dest-addr data nodes can be n be used to
used to send BFD packets to unwitting recipients. <xref target="RFC5880"
send BFD packets to unwitting recipients, <xref target="RFC5880"/> describ format="default"/> describes how BFD mitigates such
es how threats. Authentication data nodes "key-chain" and "meticulous" impact the
BFD mitigates against such threats. Authentication data nodes key-chain an security of the BFD IP single-hop session.</t></dd>
d meticulous <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/sess
impact the security of the BFD IP single-hop session.</t> ion-group:</dt>
<dd><t>This list specifies the IP multihop BFD session groups.</t>
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/sessi <t>Data nodes "local-multiplier", "desired-min-tx-interval",
on-group: "required-min-rx-interval", and "min-interval" all impact the
the list specifies the IP multi-hop BFD session groups.</t> BFD IP multihop session. The "source-addr" and "dest-addr" data nodes can
be used to
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/sessi send BFD packets to unwitting recipients. <xref target="RFC5880"
on-group: format="default"/> describes how BFD mitigates such
data nodes local-multiplier, desired-min-tx-interval, threats. Authentication data nodes "key-chain" and "meticulous" impact the
required-min-rx-interval and min-interval all impact the security of the BFD IP multihop session.</t></dd>
BFD IP multi-hop session. The source-addr and dest-addr data nodes can be <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessio
used to ns:</dt>
send BFD packets to unwitting recipients, <xref target="RFC5880"/> describ <dd><t>This list specifies the BFD sessions over a LAG.</t>
es how <t>Data nodes "local-multiplier", "desired-min-tx-interval",
BFD mitigates against such threats. Authentication data nodes key-chain an "required-min-rx-interval", and "min-interval" all impact the BFD-over-LAG
d meticulous session. The "ipv4-dest-addr" and "ipv6-dest-addr" data nodes can be used
impact the security of the BFD IP multi-hop session.</t> to
send BFD packets to unwitting recipients. <xref target="RFC5880"
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/session format="default"/> describes how BFD mitigates such
s: threats. Authentication data nodes "key-chain" and "meticulous" impact the
the list specifies the BFD sessions over LAG.</t> security of the BFD-over-LAG session.</t></dd>
<dt>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/sessi
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/session on-group:</dt>
s: <dd><t>This list specifies the session groups for BFD over MPLS.</t>
data nodes local-multiplier, desired-min-tx-interval, <t>Data nodes "local-multiplier", "desired-min-tx-interval",
required-min-rx-interval and min-interval all impact the "required-min-rx-interval", and "min-interval" all impact the
BFD over LAG session. The ipv4-dest-addr and ipv6-dest-addr data nodes can BFD-over-MPLS-LSPs session. Authentication data nodes "key-chain" and "met
be used to iculous" impact
send BFD packets to unwitting recipients, <xref target="RFC5880"/> describ the security of the BFD-over-MPLS-LSPs session.</t></dd>
es how <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/egres
BFD mitigates against such threats. Authentication data nodes key-chain an s:</dt>
d meticulous <dd>Data nodes "local-multiplier", "desired-min-tx-interval",
impact the security of the BFD over LAG session.</t> "required-min-rx-interval", and "min-interval" all impact the
BFD-over-MPLS-LSPs sessions for which this device is an MPLS LSP egress
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/sessio node. Authentication data nodes "key-chain" and "meticulous" impact the
n-group: security of the BFD-over-MPLS-LSPs sessions for which this device is an
the list specifies the session groups for BFD over MPLS.</t> MPLS LSP egress node.</dd>
</dl>
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/sessio <t>The YANG modules have writable data nodes that can be used for the
n-group: creation of BFD sessions and the modification of BFD session parameters. T
data nodes local-multiplier, desired-min-tx-interval, he
required-min-rx-interval, and min-interval all impact the system should "police" the creation of BFD sessions to prevent new session
BFD over MPLS LSPs session. Authentication data nodes key-chain and meticu s
lous from causing existing BFD sessions to fail. In the case of BFD session
impact the security of the BFD over MPLS LSPs session.</t> modification, the BFD protocol has mechanisms in place that allow for
in-service modification.</t>
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/egress
:
data nodes local-multiplier, desired-min-tx-interval,
required-min-rx-interval and min-interval all impact the
BFD over MPLS LSPs sessions for which this device is an MPLS LSP egress
node. Authentication data nodes key-chain and meticulous
impact the security of the BFD over MPLS LSPs sessions for which this devi
ce is
an MPLS LSP egress node</t>
<t>/te/tunnels/tunnel: data nodes local-multiplier,
desired-min-tx-interval, required-min-rx-interval and min-interval
all impact the BFD session over the MPLS-TE tunnel. Authentication
data nodes key-chain and meticulous impact the security of the BFD session
over
the MPLS-TE tunnel.</t>
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls-te/egr
ess:
data nodes local-multiplier, desired-min-tx-interval,
required-min-rx-interval and min-interval all impact the
BFD over MPLS-TE sessions for which this device is an MPLS-TE egress
node. Authentication data nodes key-chain and meticulous impact the securi
ty of the
BFD over MPLS-TE sessions for which this device is an MPLS-TE egress
node.</t>
<t/>
<t>The YANG module has writeable data nodes which can be used for
creation of BFD sessions and modification of BFD session parameters. The
system should "police" creation of BFD sessions to prevent new sessions
from causing existing BFD sessions to fail. For BFD session
modification, the BFD protocol has mechanisms in place which allow for
in service modification.</t>
<t>When BFD clients are used to modify BFD configuration (as described <t>When BFD clients are used to modify BFD configuration (as described
in <xref target="CFG-MODEL"/>), the BFD clients need to be included in an in <xref target="CFG-MODEL" format="default"/>), the BFD clients need to
analysis of the security properties of the BFD-using system (e.g., when be included in an analysis of the security properties of the system that
considering the authentication and authorization of control actions). uses BFD (e.g., when considering the authentication and authorization of
In many cases, BFD is not the most vulnerable portion of such a composite control actions). In many cases, BFD is not the most vulnerable portion
system, since BFD is limited to generating well-defined traffic at a fixed of such a composite system, since BFD is limited to generating
rate on a given path; in the case of an IGP as BFD client, attacking the well-defined traffic at a fixed rate on a given path; in the case of an
IGP could cause more broad-scale disruption than (de)configuring a BFD IGP acting as a BFD client, attacking the IGP could cause more broad-scale
session could cause.</t> disruption than would (de)configuring a BFD session.</t>
<!-- Begin YANG security DNE paragraph 4 (OK) -->
<t>Some of the readable data nodes in this YANG module may be considered <t>Some of the readable data nodes in these YANG modules 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 from a read access perspective:</t>
<!-- End YANG security DNE paragraph 4 -->
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/summa <dl newline="true" spacing="normal">
ry: <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/summ
access to this information discloses the number of BFD IP single-hop ary:</dt>
sessions which are up, down and admin-down. The counters include BFD <dd>Access to this information discloses the number of BFD IP single-hop
sessions for which the user does not have read-access.</t> sessions that are in the "up", "down", or "admin-down" state. The counters
include BFD
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessi sessions for which the user does not have read access.</dd>
ons/session/: <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sess
access to data nodes local-discriminator and remote-discriminator ions/session/:</dt>
<dd>Access to data nodes "local-discriminator" and "remote-discriminator"
(combined with the data nodes in the authentication container) provides th e (combined with the data nodes in the authentication container) provides th e
ability to spoof BFD IP single-hop packets.</t> ability to spoof BFD IP single-hop packets.</dd>
<dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/summ
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/summa ary:</dt>
ry: <dd>Access to this information discloses the number of BFD IP multihop
access to this information discloses the number of BFD IP multi-hop sessions that are in the "up", "down", or "admin-down" state. The counters
sessions which are up, down and admin-down. The counters include BFD include BFD
sessions for which the user does not have read-access.</t> sessions for which the user does not have read access.</dd>
<dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/sess
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/sessi ion-groups/session-group/sessions:</dt>
on-groups/session-group/sessions: <dd>Access to data nodes "local-discriminator" and "remote-discriminator"
access to data nodes local-discriminator and remote-discriminator (combined with the data nodes in the session group's authentication contai
(combined with the data nodes in the session-group's authentication contai ner) provides the
ner) provides the ability to spoof BFD IP multihop packets.</dd>
ability to spoof BFD IP multi-hop packets.</t> <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-
bfd-ipv4-session-statistics/summary:</dt>
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-b <dd>Access to this information discloses the number of micro-BFD IPv4 LAG
fd-ipv4-session-statistics/summary: sessions that are in the "up", "down", or "admin-down" state. The counters
access to this information discloses the number of micro BFD IPv4 LAG include BFD
sessions which are up, down and admin-down. The counters include BFD sessions for which the user does not have read access.</dd>
sessions for which the user does not have read-access.</t> <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessio
ns/session/member-links/member-link/micro-bfd-ipv4:</dt>
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/session <dd>Access to data nodes "local-discriminator" and "remote-discriminator"
s/session/member-links/member-link/micro-bfd-ipv4:
access to data nodes local-discriminator and remote-discriminator
(combined with the data nodes in the session's authentication container) p rovides the (combined with the data nodes in the session's authentication container) p rovides the
ability to spoof BFD IPv4 LAG packets.</t> ability to spoof BFD IPv4 LAG packets.</dd>
<dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-b bfd-ipv6-session-statistics/summary:</dt>
fd-ipv6-session-statistics/summary: <dd>Access to this information discloses the number of micro-BFD IPv6 LAG
access to this information discloses the number of micro BFD IPv6 LAG sessions that are in the "up", "down", or "admin-down" state. The counters
sessions which are up, down and admin-down. The counters include BFD include BFD
sessions for which the user does not have read-access.</t> sessions for which the user does not have read access.</dd>
<dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessio
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/session ns/session/member-links/member-link/micro-bfd-ipv6:</dt>
s/session/member-links/member-link/micro-bfd-ipv6: <dd>Access to data nodes "local-discriminator" and "remote-discriminator"
access to data nodes local-discriminator and remote-discriminator
(combined with the data nodes in the session's authentication container) p rovides the (combined with the data nodes in the session's authentication container) p rovides the
ability to spoof BFD IPv6 LAG packets.</t> ability to spoof BFD IPv6 LAG packets.</dd>
<dt>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/summa
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/summar ry:</dt>
y: <dd>Access to this information discloses the number of BFD sessions over
access to this information discloses the number of BFD sessions over MPLS LSPs that are in the "up", "down", or "admin-down" state. The counter
MPLS LSPs which are up, down and admin-down. The counters include BFD s include BFD
sessions for which the user does not have read-access.</t> sessions for which the user does not have read access.</dd>
<dt>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/sessi
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/sessio on-groups/session-group/sessions:</dt>
n-groups/session-group/sessions: <dd>Access to data nodes "local-discriminator" and "remote-discriminator"
access to data nodes local-discriminator and remote-discriminator (combined with the data nodes in the session group's authentication contai
(combined with the data nodes in the session-group's authentication contai ner) provides the
ner) provides the ability to spoof BFD-over-MPLS-LSPs packets.</dd>
ability to spoof BFD over MPLS LSPs packets.</t> </dl>
<t>This document does not define any RPC operations.</t>
<t>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls-te/sum
mary:
access to this information discloses the number of BFD sessions over
MPLS-TE which are up, down and admin-down. The counters include BFD
sessions for which the user does not have read-access.</t>
<t>/te/lsps-state/lsp: access to data nodes local-discriminator and remote
-discriminator
(combined with the data nodes in the tunnel's authentication container) pr
ovides the
ability to spoof BFD over MPLS-TE packets.</t>
</section> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has registered the following namespace URIs in the "IETF XML
Registry" <xref target="RFC3688" format="default"/>:</t>
<section title="IANA Considerations"> <dl newline="false" spacing="compact">
<t>This document registers the following namespace URIs in the IETF XML <dt>URI:</dt>
registry <xref target="RFC3688"/>:</t> <dd>urn:ietf:params:xml:ns:yang:iana-bfd-types</dd>
<dt>Registrant Contact:</dt>
<t/> <dd>The IESG.</dd>
<dt>XML:</dt>
<t>--------------------------------------------------------------------</t <dd>N/A; the requested URI is an XML namespace.</dd>
> </dl>
<t>URI: urn:ietf:params:xml:ns:yang:iana-bfd-types</t>
<t>Registrant Contact: The IESG.</t>
<t>XML: N/A, the requested URI is an XML namespace.</t>
<t>--------------------------------------------------------------------</t
>
<t>--------------------------------------------------------------------</t
>
<t>URI: urn:ietf:params:xml:ns:yang:ietf-bfd-types</t>
<t>Registrant Contact: The IESG.</t>
<t>XML: N/A, the requested URI is an XML namespace.</t>
<t>--------------------------------------------------------------------</t
>
<t/>
<t>--------------------------------------------------------------------</t
>
<t>URI: urn:ietf:params:xml:ns:yang:ietf-bfd</t>
<t>Registrant Contact: The IESG.</t>
<t>XML: N/A, the requested URI is an XML namespace.</t>
<t>--------------------------------------------------------------------</t
>
<t/>
<t>--------------------------------------------------------------------</t
>
<t>URI: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh</t>
<t>Registrant Contact: The IESG.</t>
<t>XML: N/A, the requested URI is an XML namespace.</t>
<t>--------------------------------------------------------------------</t
>
<t/>
<t>--------------------------------------------------------------------</t
>
<t>URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mh</t>
<t>Registrant Contact: The IESG.</t>
<t>XML: N/A, the requested URI is an XML namespace.</t>
<t>--------------------------------------------------------------------</t
>
<t/>
<t>--------------------------------------------------------------------</t
>
<t>URI: urn:ietf:params:xml:ns:yang:ietf-bfd-lag</t>
<t>Registrant Contact: The IESG.</t>
<t>XML: N/A, the requested URI is an XML namespace.</t>
<t>--------------------------------------------------------------------</t
>
<t/>
<t>--------------------------------------------------------------------</t
>
<t>URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls</t>
<t>Registrant Contact: The IESG.</t>
<t>XML: N/A, the requested URI is an XML namespace.</t>
<t>--------------------------------------------------------------------</t
>
<t/>
<t>--------------------------------------------------------------------</t <dl newline="false" spacing="compact">
> <dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-bfd-types</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<t>URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te</t> <dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-bfd</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<t>Registrant Contact: The IESG.</t> <dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<t>XML: N/A, the requested URI is an XML namespace.</t> <dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<t>--------------------------------------------------------------------</t <dl newline="false" spacing="compact">
> <dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-bfd-lag</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<t>This document registers the following YANG modules in the YANG Module N <dl newline="false" spacing="compact">
ames <dt>URI:</dt>
registry <xref target="RFC6020"/>:</t> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-mpls</dd>
<t>RFC Editor: Replace RFC XXXX with actual RFC number and remove this not <dt>Registrant Contact:</dt>
e.</t> <dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<t>--------------------------------------------------------------------</t <t>IANA has registered the following YANG modules in the "YANG Module Name
> s"
<t>Name: iana-bfd-types</t> registry <xref target="RFC6020" format="default"/>:</t>
<t>Namespace: urn:ietf:params:xml:ns:yang:iana-bfd-types</t> <dl newline="false" spacing="compact">
<t>Prefix: iana-bfd-types</t> <dt>Name:</dt>
<t>Reference: RFC XXXX</t> <dd>iana-bfd-types</dd>
<t>--------------------------------------------------------------------</t <dt>Namespace:</dt>
> <dd>urn:ietf:params:xml:ns:yang:iana-bfd-types</dd>
<dt>Prefix:</dt>
<dd>iana-bfd-types</dd>
<dt>Reference:</dt>
<dd>RFC 9127</dd>
</dl>
<t>--------------------------------------------------------------------</t <dl newline="false" spacing="compact">
> <dt>Name:</dt>
<t>Name: ietf-bfd-types</t> <dd>ietf-bfd-types</dd>
<t>Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-types</t> <dt>Namespace:</dt>
<t>Prefix: bfd-types</t> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-types</dd>
<t>Reference: RFC XXXX</t> <dt>Prefix:</dt>
<t>--------------------------------------------------------------------</t <dd>bfd-types</dd>
> <dt>Reference:</dt>
<dd>RFC 9127</dd>
</dl>
<t>--------------------------------------------------------------------</t <dl newline="false" spacing="compact">
> <dt>Name:</dt>
<t>Name: ietf-bfd</t> <dd>ietf-bfd</dd>
<t>Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd</t> <dt>Namespace:</dt>
<t>Prefix: bfd</t> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd</dd>
<t>Reference: RFC XXXX</t> <dt>Prefix:</dt>
<t>--------------------------------------------------------------------</t <dd>bfd</dd>
> <dt>Reference:</dt>
<dd>RFC 9127</dd>
</dl>
<t>--------------------------------------------------------------------</t <dl newline="false" spacing="compact">
> <dt>Name:</dt>
<t>Name: ietf-bfd-ip-sh</t> <dd>ietf-bfd-ip-sh</dd>
<t>Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh</t> <dt>Namespace:</dt>
<t>Prefix: bfd-ip-sh</t> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh</dd>
<t>Reference: RFC XXXX</t> <dt>Prefix:</dt>
<t>--------------------------------------------------------------------</t <dd>bfd-ip-sh</dd>
> <dt>Reference:</dt>
<dd>RFC 9127</dd>
</dl>
<t>--------------------------------------------------------------------</t <dl newline="false" spacing="compact">
> <dt>Name:</dt>
<t>Name: ietf-bfd-ip-mh</t> <dd>ietf-bfd-ip-mh</dd>
<t>Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh</t> <dt>Namespace:</dt>
<t>Prefix: bfd-ip-mh</t> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh</dd>
<t>Reference: RFC XXXX</t> <dt>Prefix:</dt>
<t>--------------------------------------------------------------------</t <dd>bfd-ip-mh</dd>
> <dt>Reference:</dt>
<dd>RFC 9127</dd>
</dl>
<t>--------------------------------------------------------------------</t <dl newline="false" spacing="compact">
> <dt>Name:</dt>
<t>Name: ietf-bfd-lag</t> <dd>ietf-bfd-lag</dd>
<t>Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-lag</t> <dt>Namespace:</dt>
<t>Prefix: bfd-lag</t> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-lag</dd>
<t>Reference: RFC XXXX</t> <dt>Prefix:</dt>
<t>--------------------------------------------------------------------</t <dd>bfd-lag</dd>
> <dt>Reference:</dt>
<dd>RFC 9127</dd>
</dl>
<t>--------------------------------------------------------------------</t <dl newline="false" spacing="compact">
> <dt>Name:</dt>
<t>Name: ietf-bfd-mpls</t> <dd>ietf-bfd-mpls</dd>
<t>Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls</t> <dt>Namespace:</dt>
<t>Prefix: bfd-mpls</t> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-mpls</dd>
<t>Reference: RFC XXXX</t> <dt>Prefix:</dt>
<t>--------------------------------------------------------------------</t <dd>bfd-mpls</dd>
> <dt>Reference:</dt>
<dd>RFC 9127</dd>
</dl>
<t>--------------------------------------------------------------------</t <section numbered="true" toc="default">
> <name>IANA-Maintained &quot;iana-bfd-types&quot; Module</name>
<t>Name: ietf-bfd-mpls-te</t>
<t>Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te</t>
<t>Prefix: bfd-mpls-te</t>
<t>Reference: RFC XXXX</t>
<t>--------------------------------------------------------------------</t
>
<section title="IANA-Maintained iana-bfd-types module">
<t>This document defines the initial version of the IANA-maintained <t>This document defines the initial version of the IANA-maintained
iana-bfd-types YANG module.</t> "iana-bfd-types" YANG module.</t>
<t>The "iana-bfd-types" YANG module mirrors the "BFD Diagnostic Codes"
<t>The iana-bfd-types YANG module mirrors the "BFD and "BFD Authentication Types" registries at
Diagnostic Codes" registry and "BFD Authentication Types" registry at <eref target="https://www.iana.org/assignments/bfd-parameters/" brackets
https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml. ="angle"/>. Whenever
Whenever that registry changes, IANA must update the iana-bfd-types YANG these registries change, IANA must update the "iana-bfd-types" YANG
module.</t> module.</t>
</section> </section>
</section> </section>
<section title="Acknowledgements">
<t>We would also like to thank Nobo Akiya and Jeff Haas for their
encouragement on this work. We would also like to thank Rakesh Gandhi
and Tarek Saad for their help on the MPLS-TE model. We would also like
to thank Acee Lindem for his guidance.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>References</name>
<references>
<?rfc include="reference.RFC.3688"?> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5246'?> FC.3688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5880'?> FC.5880.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5881'?> FC.5881.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5882'?> FC.5882.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5883'?> FC.5883.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5884'?> FC.5884.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5885'?> FC.5885.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5586'?> FC.5586.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6020'?> FC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6241'?> FC.6241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6242'?> FC.6242.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6536'?> FC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6991'?> FC.7130.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7130'?> FC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8040'?> FC.8177.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8174"?> FC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8177"?> FC.8341.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8340"?> FC.8343.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8343"?> FC.8344.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8344"?> FC.8349.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8349"?> FC.8446.xml"/>
<?rfc include="reference.I-D.ietf-mpls-base-yang"?>
<?rfc include="reference.I-D.ietf-teas-yang-te"?> <!-- draft-ietf-mpls-base-yang (RFC 8960) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8960.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3031.
xml"/>
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6428. xml"/>
<references title="Informative References"> <!-- draft-ietf-rtgwg-ni-model (RFC 8529) -->
<?rfc include="reference.I-D.ietf-rtgwg-ni-model"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8529.
xml"/>
<?rfc include="reference.I-D.ietf-rtgwg-lne-model"?> <!-- draft-ietf-rtgwg-lne-model (RFC 8530) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8530.
xml"/>
<?rfc include="reference.I-D.ietf-lime-yang-connectionless-oam"?> <!-- draft-ietf-lime-yang-connectionless-oam (RFC 8532) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8532.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8342.xml"/>
<?rfc include="reference.RFC.8342"?> <reference anchor='W3C.REC-xml-20081126'
target='https://www.w3.org/TR/2008/REC-xml-20081126'>
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials='T.' surname='Bray' fullname='Tim Bray'>
<organization />
</author>
<author initials='J.' surname='Paoli' fullname='Jean Paoli'>
<organization />
</author>
<author initials='M.' surname='Sperberg-McQueen' fullname='Michael Sperberg
-McQueen'>
<organization />
</author>
<author initials='E.' surname='Maler' fullname='Eve Maler'>
<organization />
</author>
<author initials='F.' surname='Yergeau' fullname='Francois Yergeau'>
<organization />
</author>
<date month='November' year='2008' />
</front>
<refcontent>World Wide Web Consortium Recommendation REC-xml-20081126</refc
ontent>
</reference>
</references>
</references> </references>
<section anchor="ECHO-CONFIG" numbered="true" toc="default">
<section anchor="ECHO-CONFIG" title="Echo function configuration example"> <name>Echo Function Configuration Example</name>
<t>As mentioned in <xref target="IP-SH-CFG"/>, the mechanism to start <t>As mentioned in <xref target="IP-SH-CFG" format="default"/>, the mechan
and stop the echo function, as defined in <xref target="RFC5880"/> and ism to start
<xref target="RFC5881"/>, is implementation specific. In this section we and stop the Echo function, as defined in <xref target="RFC5880"
provide an example of how the echo function can be implemented via format="default"/> and discussed in
<xref target="RFC5881" format="default"/>, is implementation specific. In
this appendix, we
provide an example of how the Echo function can be implemented via
configuration.</t> configuration.</t>
<sourcecode type="yangtree"><![CDATA[
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
module: example-bfd-echo module: example-bfd-echo
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:sessions:
+--rw echo {bfd-types:echo-mode}? +--rw echo {bfd-types:echo-mode}?
+--rw desired-min-echo-tx-interval? uint32 +--rw desired-min-echo-tx-interval? uint32
+--rw required-min-echo-rx-interval? uint32 +--rw required-min-echo-rx-interval? uint32
]]></artwork> ]]></sourcecode>
</figure> <section numbered="true" toc="default">
<name>Example YANG Module for BFD Echo Function Configuration</name>
<section title="Example YANG module for BFD echo function configuration"> <t>This appendix provides an example YANG module for
<figure align="left"> configuration of the BFD Echo function. It imports and augments
<preamble/> "/routing/control-plane-protocols/control-plane-protocol" from
<xref target="RFC8349"/>, and it references <xref target="RFC5880"/>.
<artwork align="left"><![CDATA[ </t>
<sourcecode type="yang"><![CDATA[
module example-bfd-echo { module example-bfd-echo {
namespace "tag:example.com,2018:example-bfd-echo"; namespace "tag:example.com,2021:example-bfd-echo";
prefix example-bfd-echo;
prefix "example-bfd-echo";
import ietf-bfd-types { import ietf-bfd-types {
prefix "bfd-types"; prefix bfd-types;
} }
import ietf-bfd { import ietf-bfd {
prefix "bfd"; prefix bfd;
} }
import ietf-bfd-ip-sh { import ietf-bfd-ip-sh {
prefix "bfd-ip-sh"; prefix bfd-ip-sh;
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
} }
organization "IETF BFD Working Group"; organization
"IETF BFD Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/bfd> "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org> WG List: <mailto:rtg-bfd@ietf.org>
Editors: Reshad Rahman (rrahman@cisco.com), Editor: Reshad Rahman
Lianshu Zheng (vero.zheng@huawei.com), <mailto:reshad@yahoo.com>
Mahesh Jethanandani (mjethanandani@gmail.com)";
Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>";
description description
"This module contains an example YANG augmentation for configuration "This module contains an example YANG augmentation for
of BFD echo function. configuration of the BFD Echo function.
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2021 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9127; see the
the RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2018-08-01 { revision 2021-09-03 {
description "Initial revision."; description
"Initial revision.";
reference reference
"RFC XXXX: A YANG data model example augmentation for BFD echo "RFC 9127: YANG Data Model for Bidirectional Forwarding
function"; Detection (BFD)";
} }
// RFC Ed.: replace XXXX with actual RFC number and remove this
// note
/* /*
* Groupings * Groupings
*/ */
grouping echo-cfg-parms { grouping echo-cfg-parms {
description "BFD grouping for echo config parameters"; description
"BFD grouping for Echo configuration parameters.";
leaf desired-min-echo-tx-interval { leaf desired-min-echo-tx-interval {
type uint32; type uint32;
units microseconds; units "microseconds";
default 0; default "0";
description description
"This is the minimum interval that the local system would like "This is the minimum interval that the local system would
to use when transmitting BFD echo packets. If 0, the echo like to use when transmitting BFD Echo packets. If 0,
function as defined in BFD [RFC5880] is disabled."; the Echo function as defined in BFD (RFC 5880) is
disabled.";
} }
leaf required-min-echo-rx-interval { leaf required-min-echo-rx-interval {
type uint32; type uint32;
units microseconds; units "microseconds";
default 0; default "0";
description description
"This is the Required Min Echo RX Interval as defined in BFD "This is the Required Min Echo RX Interval as defined in BFD
[RFC5880]."; (RFC 5880).";
} }
} }
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:sessions" {
description "Augmentation for BFD echo function."; description
"Augmentation for the BFD Echo function.";
container echo { container echo {
if-feature bfd-types:echo-mode; if-feature "bfd-types:echo-mode";
description
description "BFD echo function container"; "BFD Echo function container.";
uses echo-cfg-parms; uses echo-cfg-parms;
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure>
</section> </section>
</section> </section>
<section numbered="false" toc="default">
<section title="Change log"> <name>Acknowledgments</name>
<t>RFC Editor: Remove this section upon publication as an RFC.</t> <t>We would like to thank <contact fullname="Nobo Akiya"/> and
<contact fullname="Jeff Haas"/> for their encouragement on this work.
<section title="Changes between versions -16 and -17"> We would also like to thank <contact fullname="Tom Petch"/> for his
<t><list style="symbols"> comments on the document. We would also like to thank
<t>Addressed IESG comments.</t> <contact fullname="Acee Lindem"/> for his guidance. Thanks also to
</list></t> <contact fullname="Jürgen Schönwälder"/>, who was instrumental in improvin
</section> g the YANG
modules.</t>
<section title="Changes between versions -15 and -16">
<t><list style="symbols">
<t>Added list of modules for YANG module registry.</t>
</list></t>
</section>
<section title="Changes between versions -14 and -15">
<t><list style="symbols">
<t>Added missing ietf-bfd-types in XML registry.</t>
</list></t>
</section>
<section title="Changes between versions -13 and -14">
<t><list style="symbols">
<t>Addressed missing/incorrect references in import statements.</t>
</list></t>
</section>
<section title="Changes between versions -12 and -13">
<t><list style="symbols">
<t>Updated references for drafts which became RFCs recently.</t>
</list></t>
</section>
<section title="Changes between versions -11 and -12">
<t><list style="symbols">
<t>Addressed comments from YANG Doctor review of rev11.</t>
</list></t>
</section>
<section title="Changes between versions -10 and -11">
<t><list style="symbols">
<t>Added 2 examples.</t>
<t>Added a container around some lists.</t>
<t>Fixed some indentation nits.</t>
</list></t>
</section>
<section title="Changes between versions -09 and -10">
<t><list style="symbols">
<t>Addressed comments from YANG Doctor review.</t>
<t>Addressed comments from WGLC.</t>
</list></t>
</section>
<section title="Changes between versions -08 and -09">
<t><list style="symbols">
<t>Mostly cosmetic changes to abide by
draft-ietf-netmod-rfc6087bis.</t>
<t>Specified yang-version 1.1.</t>
<t>Added data model examples.</t>
<t>Some minor changes.</t>
</list></t>
</section>
<section title="Changes between versions -07 and -08">
<t><list style="symbols">
<t>Timer intervals in client-cfg-parms are not mandatory
anymore.</t>
<t>Added list of interfaces under "ip-sh" node for authentication
parameters.</t>
<t>Renamed replay-protection to meticulous.</t>
</list></t>
</section>
<section title="Changes between versions -06 and -07">
<t><list style="symbols">
<t>New ietf-bfd-types module.</t>
<t>Grouping for BFD clients to have BFD multiplier and interval
values.</t>
<t>Change in ietf-bfd-mpls-te since MPLS-TE model changed.</t>
<t>Removed bfd- prefix from many names.</t>
</list></t>
</section>
<section title="Changes between versions -05 and -06">
<t><list style="symbols">
<t>Adhere to NMDA-guidelines.</t>
<t>Echo function config moved to appendix as example.</t>
<t>Added IANA YANG modules.</t>
<t>Addressed various comments.</t>
</list></t>
</section>
<section title="Changes between versions -04 and -05">
<t><list style="symbols">
<t>"bfd" node in augment of control-plane-protocol.</t>
<t>Removed augment of network-instance. Replaced by
schema-mount.</t>
<t>Added information on interaction with other YANG modules.</t>
</list></t>
</section>
<section title="Changes between versions -03 and -04">
<t><list style="symbols">
<t>Updated author information.</t>
<t>Fixed YANG compile error in ietf-bfd-lag.yang which was due to
incorrect when statement.</t>
</list></t>
</section>
<section title="Changes between versions -02 and -03">
<t><list style="symbols">
<t>Fixed YANG compilation warning due to incorrect revision date
in ietf-bfd-ip-sh module.</t>
</list></t>
</section>
<section title="Changes between versions -01 and -02">
<t><list style="symbols">
<t>Replace routing-instance with network-instance from <xref
target="I-D.ietf-rtgwg-ni-model">YANG Network Instances</xref></t>
</list></t>
</section>
<section title="Changes between versions -00 and -01">
<t><list style="symbols">
<t>Remove BFD configuration parameters from BFD clients, all BFD
configuration parameters in BFD</t>
<t>YANG module split in multiple YANG modules (one per type of
forwarding path)</t>
<t>For BFD over MPLS-TE we augment MPLS-TE model</t>
<t>For BFD authentication we now use <xref target="RFC8177">YANG
Data Model for Key Chains</xref></t>
</list></t>
</section>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 569 change blocks. 
2113 lines changed or deleted 1612 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/