rfc9314xml2.original.xml   rfc9314.xml 
<?xml version='1.0' encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="no"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="6"?> <!ENTITY zwsp "&#8203;">
<?rfc symrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc sortrefs="yes"?> <!ENTITY wj "&#8288;">
<rfc category="std" docName="draft-ietf-bfd-rfc9127-bis-04" ipr="trust200902" up ]>
dates="9127" submissionType="IETF" consensus="true">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bfd-rfc9127-
bis-04" number="9314" ipr="trust200902" updates="9127" obsoletes="" submissionTy
pe="IETF" category="std"
consensus="true" tocInclude="true" symRefs="true" xml:lang="en" version="3">
<front> <front>
<title abbrev="BFD YANG">YANG Data Model for Bidirectional Forwarding Detect ion (BFD)</title> <title abbrev="BFD YANG">YANG Data Model for Bidirectional Forwarding Detect ion (BFD)</title>
<seriesInfo name="RFC" value="9314"/>
<author fullname="Mahesh Jethanandani" initials="M." role="editor" surname=" Jethanandani"> <author fullname="Mahesh Jethanandani" initials="M." role="editor" surname=" Jethanandani">
<organization showOnFrontPage="true">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>CA</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>mjethanandani@gmail.com</email> <email>mjethanandani@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Reshad Rahman" initials="R." role="editor" surname="Rahman "> <author fullname="Reshad Rahman" initials="R." role="editor" surname="Rahman ">
<organization showOnFrontPage="true"/> <organization/>
<address> <address>
<postal> <postal>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>reshad@yahoo.com</email> <email>reshad@yahoo.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 showOnFrontPage="true">Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<country>China</country> <country>China</country>
</postal> </postal>
<email>veronique_cheng@hotmail.com</email> <email>veronique_cheng@hotmail.com</email>
</address> </address>
</author> </author>
<author fullname="Santosh Pallagatti" initials="S." surname="Pallagatti"> <author fullname="Santosh Pallagatti" initials="S." surname="Pallagatti">
<organization showOnFrontPage="true">VMware</organization> <organization>VMware</organization>
<address> <address>
<postal> <postal>
<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 showOnFrontPage="true">Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<date/> <date year="2022" month="September" />
<keyword>Liveliness check</keyword> <keyword>Liveliness check</keyword>
<keyword>BGP</keyword> <keyword>BGP</keyword>
<keyword>OSPF</keyword> <keyword>OSPF</keyword>
<keyword>IS-IS</keyword> <keyword>IS-IS</keyword>
<keyword>TCP-AO</keyword> <keyword>TCP-AO</keyword>
<keyword>MD5</keyword> <keyword>MD5</keyword>
<abstract pn="section-abstract"> <abstract>
<t indent="0" pn="section-abstract-1">This document defines a YANG data mo <t>This document defines a YANG data model that can be used to configure
del that can be used to configure
and manage Bidirectional Forwarding Detection (BFD).</t> and manage Bidirectional Forwarding Detection (BFD).</t>
<t indent="0" pn="section-abstract-2">The YANG modules in this document co <t>The YANG modules in this document conform to the Network Management
nform to the Network Management Datastore Architecture (NMDA) (RFC 8342). This document updates "YANG Data
Datastore Architecture (NMDA) (RFC 8342). This document updates YANG Data Model for Bidirectional Forwarding Detection (BFD)" (RFC 9127).</t>
Model for Bidirectional Forwarding Detection (BFD) (RFC 9127).</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9127" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tr
ee-diagrams">Tree Diagrams</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-design-of-the-data-model">Design o
f the Data Model</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent=
"2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-design-of-the-configur
ation">Design of the Configuration Model</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.1.2">
<li pn="section-toc.1-1.2.2.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.
2.1.1"><xref derivedContent="2.1.1" format="counter" sectionFormat="of" target="
section-2.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" tar
get="name-common-bfd-configuration-pa">Common BFD Configuration Parameters</xref
></t>
</li>
<li pn="section-toc.1-1.2.2.1.2.2">
<t indent="0" pn="section-toc.1-1.2.2.1.2.2.1"><xref derived
Content="2.1.2" format="counter" sectionFormat="of" target="section-2.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-single-hop
-ip">Single-Hop IP</xref></t>
</li>
<li pn="section-toc.1-1.2.2.1.2.3">
<t indent="0" pn="section-toc.1-1.2.2.1.2.3.1"><xref derived
Content="2.1.3" format="counter" sectionFormat="of" target="section-2.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-multihop-i
p">Multihop IP</xref></t>
</li>
<li pn="section-toc.1-1.2.2.1.2.4">
<t indent="0" pn="section-toc.1-1.2.2.1.2.4.1"><xref derived
Content="2.1.4" format="counter" sectionFormat="of" target="section-2.1.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-mpls-label
-switched-paths">MPLS Label Switched Paths</xref></t>
</li>
<li pn="section-toc.1-1.2.2.1.2.5">
<t indent="0" pn="section-toc.1-1.2.2.1.2.5.1"><xref derived
Content="2.1.5" format="counter" sectionFormat="of" target="section-2.1.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-link-aggre
gation-groups">Link Aggregation Groups</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent=
"2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-design-of-the-operatio
nal-s">Design of the Operational State Model</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-notifications">Notific
ations</xref></t>
</li>
<li pn="section-toc.1-1.2.2.4">
<t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent=
"2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rpc-operations">RPC Op
erations</xref></t>
</li>
<li pn="section-toc.1-1.2.2.5">
<t indent="0" pn="section-toc.1-1.2.2.5.1"><xref derivedContent=
"2.5" format="counter" sectionFormat="of" target="section-2.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-bfd-top-level-hierarch
y">BFD Top-Level Hierarchy</xref></t>
</li>
<li pn="section-toc.1-1.2.2.6">
<t indent="0" pn="section-toc.1-1.2.2.6.1"><xref derivedContent=
"2.6" format="counter" sectionFormat="of" target="section-2.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-bfd-ip-single-hop-hier
archy">BFD IP Single-Hop Hierarchy</xref></t>
</li>
<li pn="section-toc.1-1.2.2.7">
<t indent="0" pn="section-toc.1-1.2.2.7.1"><xref derivedContent=
"2.7" format="counter" sectionFormat="of" target="section-2.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-bfd-ip-multihop-hierar
chy">BFD IP Multihop Hierarchy</xref></t>
</li>
<li pn="section-toc.1-1.2.2.8">
<t indent="0" pn="section-toc.1-1.2.2.8.1"><xref derivedContent=
"2.8" format="counter" sectionFormat="of" target="section-2.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-bfd-over-lag-hierarchy
">BFD-over-LAG Hierarchy</xref></t>
</li>
<li pn="section-toc.1-1.2.2.9">
<t indent="0" pn="section-toc.1-1.2.2.9.1"><xref derivedContent=
"2.9" format="counter" sectionFormat="of" target="section-2.9"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-bfd-over-mpls-lsps-hie
rarch">BFD-over-MPLS-LSPs Hierarchy</xref></t>
</li>
<li pn="section-toc.1-1.2.2.10">
<t indent="0" pn="section-toc.1-1.2.2.10.1"><xref derivedContent
="2.10" format="counter" sectionFormat="of" target="section-2.10"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-interaction-with-oth
er-yang">Interaction with other YANG Modules</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.10.2">
<li pn="section-toc.1-1.2.2.10.2.1">
<t indent="0" pn="section-toc.1-1.2.2.10.2.1.1"><xref derive
dContent="2.10.1" format="counter" sectionFormat="of" target="section-2.10.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-in
terfaces-module">"ietf-interfaces" Module</xref></t>
</li>
<li pn="section-toc.1-1.2.2.10.2.2">
<t indent="0" pn="section-toc.1-1.2.2.10.2.2.1"><xref derive
dContent="2.10.2" format="counter" sectionFormat="of" target="section-2.10.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-ip
-module">"ietf-ip" Module</xref></t>
</li>
<li pn="section-toc.1-1.2.2.10.2.3">
<t indent="0" pn="section-toc.1-1.2.2.10.2.3.1"><xref derive
dContent="2.10.3" format="counter" sectionFormat="of" target="section-2.10.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-mp
ls-module">"ietf-mpls" Module</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2.2.12">
<t indent="0" pn="section-toc.1-1.2.2.12.1"><xref derivedContent
="2.12" format="counter" sectionFormat="of" target="section-2.11"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-bfd-types-yang-modul
e">BFD Types YANG Module</xref></t>
</li>
<li pn="section-toc.1-1.2.2.13">
<t indent="0" pn="section-toc.1-1.2.2.13.1"><xref derivedContent
="2.13" format="counter" sectionFormat="of" target="section-2.12"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-bfd-top-level-yang-m
odule">BFD Top-Level YANG Module</xref></t>
</li>
<li pn="section-toc.1-1.2.2.14">
<t indent="0" pn="section-toc.1-1.2.2.14.1"><xref derivedContent
="2.14" format="counter" sectionFormat="of" target="section-2.13"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-bfd-ip-single-hop-ya
ng-modu">BFD IP Single-Hop YANG Module</xref></t>
</li>
<li pn="section-toc.1-1.2.2.15">
<t indent="0" pn="section-toc.1-1.2.2.15.1"><xref derivedContent
="2.15" format="counter" sectionFormat="of" target="section-2.14"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-bfd-ip-multihop-yang
-module">BFD IP Multihop YANG Module</xref></t>
</li>
<li pn="section-toc.1-1.2.2.16">
<t indent="0" pn="section-toc.1-1.2.2.16.1"><xref derivedContent
="2.16" format="counter" sectionFormat="of" target="section-2.15"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-bfd-over-lag-yang-mo
dule">BFD-over-LAG YANG Module</xref></t>
</li>
<li pn="section-toc.1-1.2.2.17">
<t indent="0" pn="section-toc.1-1.2.2.17.1"><xref derivedContent
="2.17" format="counter" sectionFormat="of" target="section-2.16"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-bfd-over-mpls-yang-m
odule">BFD-over-MPLS YANG Module</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-data-model-examples">Data Model Ex
amples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ip-single-hop">IP Sing
le-Hop</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ip-multihop">IP Multih
op</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-lag">LAG</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4">
<t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
"3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-mpls">MPLS</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="Appendi
x A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref d
erivedContent="" format="title" sectionFormat="of" target="name-echo-function-co
nfiguration">Echo Function Configuration Example</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"A.1" format="counter" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-example-yang-mo
dule-for-bfd">Example YANG Module for BFD Echo Function Configuration</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments
</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent=""
format="title" sectionFormat="of" target="updates-since-rfc-9127">Updates since
RFC 9127</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1"> <section>
<name slugifiedName="name-introduction">Introduction</name> <name>Introduction</name>
<t indent="0" pn="section-1-1">This document defines a YANG data model tha <t>This document defines a YANG data model that can be used to configure
t can be used to configure and manage Bidirectional Forwarding Detection (BFD) <xref target="RFC5880"
and manage Bidirectional Forwarding Detection (BFD) <xref target="RFC5880" />. BFD is a network protocol that is used
format="default" sectionFormat="of" derivedContent="RFC5880"/>. BFD is a networ
k 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 are as follows:</t> of different types of paths over which we have BFD are as follows:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-2" <ol spacing="normal">
> <li>Two systems directly connected via IP. This is known as BFD over
<li pn="section-1-2.1" derivedCounter="1.">Two systems directly connected single-hop IP, which is also known as <xref target="RFC5881">BFD for
via IP. This is known as BFD over
single-hop IP, a.k.a. <xref target="RFC5881" format="default" sectionForma
t="of" derivedContent="RFC5881">BFD for
IPv4 and IPv6</xref>.</li> IPv4 and IPv6</xref>.</li>
<li pn="section-1-2.2" derivedCounter="2.">Two systems connected via mul tiple hops as described in <xref target="RFC5883" format="default" sectionFormat ="of" derivedContent="RFC5883">"Bidirectional Forwarding Detection <li>Two systems connected via multiple hops as described in <xref target ="RFC5883">"Bidirectional Forwarding Detection
(BFD) for Multihop Paths"</xref>.</li> (BFD) for Multihop Paths"</xref>.</li>
<li pn="section-1-2.3" derivedCounter="3.">Two systems connected via MPL <li>Two systems connected via MPLS Label Switched Paths (LSPs) as
S Label Switched Paths (LSPs) as described in <xref target="RFC5884">"Bidirectional
described in <xref target="RFC5884" format="default" sectionFormat="of" de
rivedContent="RFC5884">"Bidirectional
Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)"</xref>.</ li> Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)"</xref>.</ li>
<li pn="section-1-2.4" derivedCounter="4.">Two systems connected via a L <li>Two systems connected via a Link Aggregation Group (LAG) interface
ink Aggregation Group (LAG) interface as described in <xref target="RFC7130">"Bidirectional
as described in <xref target="RFC7130" format="default" sectionFormat="of"
derivedContent="RFC7130">"Bidirectional
Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces"</xr ef>.</li> Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces"</xr ef>.</li>
<li pn="section-1-2.5" derivedCounter="5.">Two systems connected via pse <li>Two systems connected via pseudowires (PWs). This is known as
udowires (PWs). This is known as Virtual Circuit Connectivity Verification (VCCV) as described in <xref tar
Virtual Circuit Connectivity Verification (VCCV), as described in <xref ta get="RFC5885">"Bidirectional
rget="RFC5885" format="default" sectionFormat="of" derivedContent="RFC5885">"Bid
irectional
Forwarding Detection (BFD) for the Pseudowire Virtual Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)"</xref>. This scenario is not Circuit Connectivity Verification (VCCV)"</xref>. This scenario is not
addressed in this document.</li> addressed in this document.</li>
</ol> </ol>
<t indent="0" pn="section-1-3">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" format="default" sec tionFormat="of" derivedContent="RFC5882">"Generic Application of Bidirectional F orwarding own operation, as described in <xref target="RFC5882">"Generic Application of Bidirectional Forwarding
Detection (BFD)"</xref>. The obvious Detection (BFD)"</xref>. The obvious
candidates that use BFD are those that do not have "hellos" to detect candidates that use BFD are those that do not have "hellos" to detect
failures, e.g., static routes, and routing protocols whose "hellos" do failures, e.g., static routes, and routing protocols whose "hellos" do
not support sub-second failure detection, e.g., OSPF and IS-IS.</t> not support sub-second failure detection, e.g., OSPF and IS-IS.</t>
<t indent="0" pn="section-1-4">The YANG modules in this document conform t o the <xref target="RFC8342" format="default" sectionFormat="of" derivedContent= "RFC8342">Network Management Datastore <t>The YANG modules in this document conform to the <xref target="RFC8342" >Network Management Datastore
Architecture (NMDA)</xref>. 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 data and separate top-level or sibling containers for configuration data and
operational state data.</t> operational state data.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.1 <section>
"> <name>Tree Diagrams</name>
<name slugifiedName="name-tree-diagrams">Tree Diagrams</name> <t>This document uses the graphical representation of data models, as de
<t indent="0" pn="section-1.1-1">This document uses the graphical repres fined in
entation of data models, as defined in <xref target="RFC8340"/>.</t>
<xref target="RFC8340" format="default" sectionFormat="of" derivedCo
ntent="RFC8340"/>.</t>
</section>
<section numbered="true" toc="include" removeInRFC="true" pn="section-1.2"
>
<name slugifiedName="name-note-to-rfc-editor">Note to RFC
Editor</name>
<t indent="0" pn="section-1.2-2">This document uses several
placeholder values throughout the document. Please replace
them as follows and remove this note before publication.</t>
<t>RFC XXXX, where XXXX is the number assigned to this
document at the time of publication.</t>
<t>2022-04-06 with the actual date of the publication of this
document.</t>
</section> </section>
</section> </section>
<section anchor="DESIGN-DATA" numbered="true" toc="include" removeInRFC="fal <section anchor="DESIGN-DATA">
se" pn="section-2"> <name>Design of the Data Model</name>
<name slugifiedName="name-design-of-the-data-model">Design of the Data Mod <t>Since BFD is used for liveness detection of various forwarding
el</name> paths, there is no uniform key to identify a BFD session. Therefore, the
<t indent="0" pn="section-2-1">Since BFD is used for liveness detection of BFD
various forwarding
paths, there is no uniform key to identify a BFD session, and so the BFD
data model is split into 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 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 that are used by all definitions, we have common types and groupings that are used by all
the modules.</t> the modules.</t>
<t indent="0" pn="section-2-2">A new control-plane protocol, "bfdv1", is d <t>A new control plane protocol, "bfdv1", is defined, and a "bfd" containe
efined, and a "bfd" container r
is created under "control-plane-protocol" as specified in <xref target="RF is created under "control-plane-protocol" as specified in <xref target="RF
C8349" format="default" sectionFormat="of" derivedContent="RFC8349">"A YANG Data C8349">"A YANG Data Model for Routing
Model for Routing
Management (NMDA Version)"</xref>. This new "bfd" container is augmented Management (NMDA Version)"</xref>. This new "bfd" container is augmented
by the following YANG modules for their respective specific information: by the following YANG modules for their respective specific information:
</t> </t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-3" <ol spacing="normal">
> <li>The "ietf-bfd-ip-sh" module (<xref target="bfd-ip-single-hop-module"
<li pn="section-2-3.1" derivedCounter="1.">The "ietf-bfd-ip-sh" module ( />) augments
<xref target="bfd-ip-single-hop-module" format="default" sectionFormat="of" deri
vedContent="Section 2.14"/>) augments
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with "/routing/control-plane-protocols/control-plane-protocol/bfd/" with
the "ip-sh" container for BFD sessions over IP single-hop.</li> the "ip-sh" container for BFD sessions over IP single-hop.</li>
<li pn="section-2-3.2" derivedCounter="2.">The "ietf-bfd-ip-mh" module ( <xref target="bfd-ip-multihop-module" format="default" sectionFormat="of" derive dContent="Section 2.15"/>) augments <li>The "ietf-bfd-ip-mh" module (<xref target="bfd-ip-multihop-module"/> ) 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 multihop.</li> the "ip-mh" container for BFD sessions over IP multihop.</li>
<li pn="section-2-3.3" derivedCounter="3.">The "ietf-bfd-lag" module (<x ref target="bfd-over-lag-module" format="default" sectionFormat="of" derivedCont ent="Section 2.16"/>) augments <li>The "ietf-bfd-lag" module (<xref target="bfd-over-lag-module"/>) aug ments
"/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 a LAG.</li> the "lag" container for BFD sessions over a LAG.</li>
<li pn="section-2-3.4" derivedCounter="4.">The "ietf-bfd-mpls" module (< xref target="bfd-over-mpls-module" format="default" sectionFormat="of" derivedCo ntent="Section 2.17"/>) augments <li>The "ietf-bfd-mpls" module (<xref target="bfd-over-mpls-module"/>) a ugments
"/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.</li> the "mpls" container for BFD-over-MPLS LSPs.</li>
</ol> </ol>
<t indent="0" pn="section-2-4">BFD can operate in the following contexts:< <t>BFD can operate in the following contexts:</t>
/t> <ol spacing="normal">
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-5" <li>At the network-device level.</li>
> <li>In logical network elements (LNEs) as described in <xref target="RFC
<li pn="section-2-5.1" derivedCounter="1.">At the network device level.< 8530">"YANG Model for Logical Network Elements"</xref>.</li>
/li> <li>In network instances as described in <xref target="RFC8529">"YANG Da
<li pn="section-2-5.2" derivedCounter="2.">In logical network elements ( ta Model for Network Instances"</xref>.</li>
LNEs) as described in <xref target="RFC8530" format="default" sectionFormat="of"
derivedContent="RFC8530">"YANG Model for Logical Network Elements"</xref>.</li>
<li pn="section-2-5.3" derivedCounter="3.">In network instances as descr
ibed in <xref target="RFC8529" format="default" sectionFormat="of" derivedConten
t="RFC8529">"YANG Data Model for Network Instances"</xref>.</li>
</ol> </ol>
<t indent="0" pn="section-2-6"> When used at the network device level, the BFD YANG data model is <t> When used at the network device level, the BFD YANG data model is
used "as is". When the BFD YANG data model is used in an LNE or network instance, the BFD YANG data model augments used "as is". When the BFD YANG data model is used in an LNE or network instance, the BFD YANG data model augments
the mounted routing model for the LNE or network instance.</t> the mounted routing model for the LNE or network instance.</t>
<section anchor="CFG-MODEL" numbered="true" toc="include" removeInRFC="fal <section anchor="CFG-MODEL">
se" pn="section-2.1"> <name>Design of the Configuration Model</name>
<name slugifiedName="name-design-of-the-configuration">Design of the Con <t>The configuration model consists mainly of the parameters specified
figuration Model</name> in <xref target="RFC5880">BFD</xref> -- for example, desired
<t indent="0" pn="section-2.1-1">The configuration model consists mainly
of the parameters specified
in <xref target="RFC5880" format="default" sectionFormat="of" derivedCon
tent="RFC5880">BFD</xref> -- for example, desired
minimum transmit interval, required minimum receive interval, and minimum transmit interval, required minimum receive interval, and
detection multiplier.</t> detection multiplier.</t>
<t indent="0" pn="section-2.1-2">BFD clients are applications that use B FD 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, or BGP. 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 indent="0" pn="section-2.1-3">The main BFD parameters of interest to a BFD client are those <t>The main BFD parameters of interest to a BFD client are those
related to 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. Configuration of BFD for all requirements of the BFD client. Configuration of BFD for all
clients should be centralized. However, this is a problem for BFD client s clients should be centralized. However, this is a problem for BFD client s
that auto-discover their peers. For example, IGPs do not have the that auto-discover their peers. For example, IGPs do not have the
peer address configured; instead, the IGP is enabled on an interface, peer address configured; instead, the IGP is enabled on an interface,
and the IGP peers are auto-discovered. So, for an operator to configure 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 the grouping would need to be added. To avoid this issue, we define the grouping
"client-cfg-parms" in <xref target="BFD-TYPES" format="default" sectionF ormat="of" derivedContent="Section 2.12"/> for BFD clients to "client-cfg-parms" in <xref target="BFD-TYPES"/> for BFD clients to
configure BFD: this allows BFD clients, such as the IGPs, to have 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; 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 for 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 the BFD clients is outside the scope of this document, but
this would typically be done by using an API implemented by the BFD modu le on this would typically be done by using an API implemented by the BFD modu le on
the system. In the case of BFD clients that create BFD sessions via thei r own 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="include" removeInR <section anchor="BFD-COMMON-CFG">
FC="false" pn="section-2.1.1"> <name>Common BFD Configuration Parameters</name>
<name slugifiedName="name-common-bfd-configuration-pa">Common BFD Conf <t>The basic BFD configuration parameters are as follows:</t>
iguration Parameters</name> <dl newline="true" spacing="normal">
<t indent="0" pn="section-2.1.1-1">The basic BFD configuration paramet <dt>local-multiplier</dt>
ers are as follows:</t> <dd>This is the detection time multiplier as defined in <xref target
<dl newline="true" spacing="normal" indent="3" pn="section-2.1.1-2"> ="RFC5880">BFD</xref>.</dd>
<dt pn="section-2.1.1-2.1">local-multiplier</dt> <dt>desired-min-tx-interval</dt>
<dd pn="section-2.1.1-2.2">This is the detection time multiplier as <dd>This is the Desired Min TX Interval as defined in <xref target="
defined in <xref target="RFC5880" format="default" sectionFormat="of" derivedCon RFC5880">BFD</xref>.</dd>
tent="RFC5880">BFD</xref>.</dd> <dt>required-min-rx-interval</dt>
<dt pn="section-2.1.1-2.3">desired-min-tx-interval</dt> <dd>This is the Required Min RX Interval as defined in <xref target=
<dd pn="section-2.1.1-2.4">This is the Desired Min TX Interval as de "RFC5880">BFD</xref>.</dd>
fined in <xref target="RFC5880" format="default" sectionFormat="of" derivedConte
nt="RFC5880">BFD</xref>.</dd>
<dt pn="section-2.1.1-2.5">required-min-rx-interval</dt>
<dd pn="section-2.1.1-2.6">This is the Required Min RX Interval as d
efined in <xref target="RFC5880" format="default" sectionFormat="of" derivedCont
ent="RFC5880">BFD</xref>.</dd>
</dl> </dl>
<t indent="0" pn="section-2.1.1-3">Although <xref target="RFC5880" for mat="default" sectionFormat="of" derivedContent="RFC5880">BFD</xref> <t>Although <xref target="RFC5880">BFD</xref>
allows for different values for transmit and receive intervals, some allows for different values for transmit and receive intervals, some
implementations allow users to specify just one interval that is implementations allow users to specify just one interval that is
used for both transmit and receive intervals, or separate values for used for both transmit and receive intervals, or separate values for
transmit and receive intervals. The BFD YANG data model supports this: transmit and receive intervals. The BFD YANG data 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 the "required-min-rx-interval". This is supported via the
"base-cfg-parms" grouping (<xref target="BFD-TYPES" format="default" s ectionFormat="of" derivedContent="Section 2.12"/>), which "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 indent="0" pn="section-2.1.1-4">For BFD authentication, we have the <t>For BFD authentication, we have the following:</t>
following:</t> <dl newline="true" spacing="normal">
<dl newline="true" spacing="normal" indent="3" pn="section-2.1.1-5"> <dt>key-chain</dt>
<dt pn="section-2.1.1-5.1">key-chain</dt> <dd>This is a reference to "key-chain" as defined in <xref target="R
<dd pn="section-2.1.1-5.2">This is a reference to "key-chain" as def FC8177">"YANG Data Model for Key
ined in <xref target="RFC8177" format="default" sectionFormat="of" derivedConten
t="RFC8177">"YANG Data Model for Key
Chains"</xref>. The keys, cryptographic algorithms, key lifetime, Chains"</xref>. The keys, cryptographic algorithms, key lifetime,
etc. are all defined in the "key-chain" model.</dd> etc. are all defined in the "key-chain" model.</dd>
<dt pn="section-2.1.1-5.3">meticulous</dt> <dt>meticulous</dt>
<dd pn="section-2.1.1-5.4">This enables a meticulous mode as per <xr <dd>This enables a meticulous mode as per <xref target="RFC5880">BFD
ef target="RFC5880" format="default" sectionFormat="of" derivedContent="RFC5880" </xref>.</dd>
>BFD </xref>.</dd>
</dl> </dl>
</section> </section>
<section anchor="IP-SH-CFG" numbered="true" toc="include" removeInRFC="f <section anchor="IP-SH-CFG">
alse" pn="section-2.1.2"> <name>Single-Hop IP</name>
<name slugifiedName="name-single-hop-ip">Single-Hop IP</name> <t>For single-hop IP, there is an augment of the "bfd" data node, as
<t indent="0" pn="section-2.1.2-1">For single-hop IP, there is an augm
ent of the "bfd" data node, as
described in described in
<xref target="DESIGN-DATA" format="default" sectionFormat="of" derived Content="Section 2"/>. The "ip-sh" node <xref target="DESIGN-DATA"/>. The "ip-sh" node
contains a list of IP single-hop sessions where each session is contains a list of IP single-hop sessions where each session is
uniquely identified by the interface and destination address uniquely identified by the interface and destination address
pair. We use the configuration parameters defined in pair. We use the configuration parameters defined in
<xref target="BFD-COMMON-CFG" format="default" sectionFormat="of" deri vedContent="Section 2.1.1"/>. The "ip-sh" node <xref target="BFD-COMMON-CFG"/>. The "ip-sh" node
also contains a list of interfaces and is used to specify also contains a list of interfaces and is used to specify
authentication parameters for BFD sessions that are created by BFD authentication parameters for BFD sessions that are created by BFD
clients. See <xref target="CFG-MODEL" format="default" sectionFormat=" clients. See <xref target="CFG-MODEL"/>.</t>
of" derivedContent="Section 2.1"/>.</t> <t><xref target="RFC5880"/> and <xref target="RFC5881"/> do not specif
<t indent="0" pn="section-2.1.2-2"><xref target="RFC5880" format="defa y whether
ult" sectionFormat="of" derivedContent="RFC5880"/> and <xref target="RFC5881" fo
rmat="default" sectionFormat="of" derivedContent="RFC5881"/> do not specify whet
her
the Echo function operates continuously or on demand. Therefore, the m echanism used to the Echo function operates continuously or on demand. Therefore, the m echanism used to
start and stop the Echo function is implementation specific and should start and stop the Echo function is implementation specific and should
be done by augmentation:</t> be done by augmentation:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section- <ol spacing="normal">
2.1.2-3"> <li>Configuration. This is suitable for an Echo function that
<li pn="section-2.1.2-3.1" derivedCounter="1.">Configuration. This i operates continuously. An example is provided in <xref target="ECHO-
s suitable for an Echo function that CONFIG"/>.</li>
operates continuously. An example is provided in <xref target="ECHO- <li>RPC. This is suitable for an Echo function that operates
CONFIG" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</li>
<li pn="section-2.1.2-3.2" derivedCounter="2.">RPC. This is suitable
for an Echo function that operates
on demand.</li> on demand.</li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2 <section>
.1.3"> <name>Multihop IP</name>
<name slugifiedName="name-multihop-ip">Multihop IP</name> <t>For multihop IP, there is an augment of the "bfd" data node, as des
<t indent="0" pn="section-2.1.3-1">For multihop IP, there is an augmen cribed in
t of the "bfd" data node, as described in <xref target="DESIGN-DATA"/>.</t>
<xref target="DESIGN-DATA" format="default" sectionFormat="of" derived <t>Because of multiple paths, there could be multiple multihop IP
Content="Section 2"/>.</t>
<t indent="0" pn="section-2.1.3-2">Because of multiple paths, there co
uld 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 set of sessions as a "session-group". The key for each "session-g roup" consists this set of sessions as a "session-group". The key for each "session-g roup" consists
of the following:</t> of the following:</t>
<dl newline="true" spacing="normal" indent="3" pn="section-2.1.3-3"> <dl newline="true" spacing="normal">
<dt pn="section-2.1.3-3.1">Source address</dt> <dt>Source address</dt>
<dd pn="section-2.1.3-3.2">Address belonging to the local system as <dd>Address belonging to the local system as per <xref target="RFC58
per <xref target="RFC5883" format="default" sectionFormat="of" derivedContent="R 83">"Bidirectional Forwarding
FC5883">"Bidirectional Forwarding
Detection (BFD) for Multihop Paths"</xref>.</dd> Detection (BFD) for Multihop Paths"</xref>.</dd>
<dt pn="section-2.1.3-3.3">Destination address</dt> <dt>Destination address</dt>
<dd pn="section-2.1.3-3.4">Address belonging to the remote system as <dd>Address belonging to the remote system as per <xref target="RFC5
per <xref target="RFC5883" format="default" sectionFormat="of" derivedContent=" 883"/>.</dd>
RFC5883"/>.</dd>
</dl> </dl>
<t indent="0" pn="section-2.1.3-4">We use the configuration parameters <t>We use the configuration parameters defined in <xref target="BFD-CO
defined in <xref target="BFD-COMMON-CFG" format="default" sectionFormat="of" de MMON-CFG"/>.</t>
rivedContent="Section 2.1.1"/>.</t> <t>This document also provides the following parameters:</t>
<t indent="0" pn="section-2.1.3-5">This document also provides the fol <dl newline="true" spacing="normal">
lowing parameters:</t> <dt>tx-ttl</dt>
<dl newline="true" spacing="normal" indent="3" pn="section-2.1.3-6"> <dd>TTL of outgoing BFD control packets.</dd>
<dt pn="section-2.1.3-6.1">tx-ttl</dt> <dt>rx-ttl</dt>
<dd pn="section-2.1.3-6.2">TTL of outgoing BFD control packets.</dd> <dd>Minimum TTL of incoming BFD control packets.</dd>
<dt pn="section-2.1.3-6.3">rx-ttl</dt>
<dd pn="section-2.1.3-6.4">Minimum TTL of incoming BFD control packe
ts.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2 <section>
.1.4"> <name>MPLS Label Switched Paths</name>
<name slugifiedName="name-mpls-label-switched-paths">MPLS Label Switch <t>Here, we address MPLS LSPs whose
ed Paths</name> Forwarding Equivalence Class (FEC) <xref target="RFC3031"/> is an IP
<t indent="0" pn="section-2.1.4-1">Here, we address MPLS LSPs whose
Forwarding Equivalence Class (FEC) <xref target="RFC3031" format="defa
ult" sectionFormat="of" derivedContent="RFC3031"/> is an IP
address. The "bfd" address. The "bfd"
node (<xref target="DESIGN-DATA" format="default" sectionFormat="of" d erivedContent="Section 2"/>) is augmented node (<xref target="DESIGN-DATA"/>) is augmented
with "mpls", which contains a list of sessions uniquely identified by with "mpls", which contains a list of sessions uniquely identified by
an IP prefix. Because of multiple paths, there could be multiple an IP prefix. Because of multiple paths, there could be multiple
MPLS sessions to an MPLS FEC. We identify this set of sessions as a MPLS sessions to an MPLS FEC. We identify this set of sessions as a
"session-group".</t> "session-group".</t>
<t indent="0" pn="section-2.1.4-2">Since these LSPs are unidirectional , there is no LSP <t>Since these LSPs are unidirectional, there is no LSP
configuration on the egress node.</t> configuration on the egress node.</t>
<t indent="0" pn="section-2.1.4-3">The BFD parameters for the egress n ode are added under <t>The BFD parameters for the egress node are added under
"mpls".</t> "mpls".</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2 <section>
.1.5"> <name>Link Aggregation Groups</name>
<name slugifiedName="name-link-aggregation-groups">Link Aggregation Gr <t>Per <xref target="RFC7130">"Bidirectional
oups</name>
<t indent="0" pn="section-2.1.5-1">Per <xref target="RFC7130" format="
default" sectionFormat="of" derivedContent="RFC7130">"Bidirectional
Forwarding Detection (BFD) on Link Aggregation Group (LAG) Forwarding Detection (BFD) on Link Aggregation Group (LAG)
Interfaces"</xref>, configuring BFD on a LAG consists of having micro- BFD Interfaces"</xref>, configuring BFD on a LAG consists of having micro- BFD
sessions on each LAG member link. Since the BFD parameters are an sessions on each LAG member link. Since the BFD parameters are an
attribute of the LAG, they should be under the LAG. However, there is attribute of the LAG, they should be under the LAG. However, there is
no LAG YANG data model that we can augment. So, a "lag" data node is no LAG YANG data model that we can augment. So, a "lag" data node is
added to the "bfd" node; see <xref target="DESIGN-DATA" format="defaul t" sectionFormat="of" derivedContent="Section 2"/>. The configuration is per LAG : we have a list of added to the "bfd" node; see <xref target="DESIGN-DATA"/>. The configu ration is per LAG: we have a list of
LAGs. The destination IP address of the micro-BFD sessions is LAGs. The destination IP address of the micro-BFD sessions is
configured per LAG and per address family (IPv4 and IPv6).</t> configured per LAG and per address family (IPv4 and IPv6).</t>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.2 <section>
"> <name>Design of the Operational State Model</name>
<name slugifiedName="name-design-of-the-operational-s">Design of the Ope <t>The operational state model contains both the overall statistics for
rational State Model</name>
<t indent="0" pn="section-2.2-1">The operational state model contains bo
th the overall statistics for
the 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 indent="0" pn="section-2.2-2">The overall statistics for the BFD sess ions consist of the number of BFD <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 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 globally (i.e., for all BFD sessions) under the "bfd" node
(<xref target="DESIGN-DATA" format="default" sectionFormat="of" derivedC ontent="Section 2"/>) and also per type of (<xref target="DESIGN-DATA"/>) and also per type of
forwarding path.</t> forwarding path.</t>
<t indent="0" pn="section-2.2-3">For each BFD session, three main catego ries of operational state <t>For each BFD session, three main categories of operational state
data are shown.</t> data are shown.</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2. <ol spacing="normal">
2-4"> <li>The first category includes fundamental information regarding a BFD s
<li pn="section-2.2-4.1" derivedCounter="1.">The first category includes ession, such as
fundamental information regarding a BFD session, such as
the local discriminator, the remote discriminator, and the ability to the local discriminator, the remote discriminator, and the ability to
support Demand mode.</li> support Demand mode.</li>
<li pn="section-2.2-4.2" derivedCounter="2.">The <li>The
second category includes BFD "session-running" information, e.g., the second category includes 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 configured desired minimum transmit different from the configured desired minimum transmit
interval. Similar examples include the actual receive 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.</li> the Echo packets.</li>
<li pn="section-2.2-4.3" derivedCounter="3."> The third category conta ins the detailed statistics <li> The third category contains the detailed statistics
for the session, e.g., when the session transitioned up/down and how for the session, e.g., when the session transitioned up/down and how
long it has been in that state.</li> long it has been in that state.</li>
</ol> </ol>
<t indent="0" pn="section-2.2-5">For some path types, there may be more than one 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="include" removeInRFC="false" pn="section-2.3 <section>
"> <name>Notifications</name>
<name slugifiedName="name-notifications">Notifications</name> <t>This YANG data model defines notifications to inform end users of
<t indent="0" pn="section-2.3-1">This YANG data model defines notificati
ons to inform end users of
important events detected during the protocol operation. The important events detected during the protocol operation. The
local discriminator identifies the corresponding BFD session on the local discriminator identifies the corresponding BFD session on the
local system, and the remote discriminator identifies the BFD session local system, and the remote discriminator identifies the BFD session
on the remote system. on the remote system.
Notifications also give more important details about BFD sessions, Notifications also give more important details about BFD sessions,
e.g., new state, time in previous state, network instance, and the 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="include" removeInRFC="false" pn="section-2.4 <section>
"> <name>RPC Operations</name>
<name slugifiedName="name-rpc-operations">RPC Operations</name> <t>None.</t>
<t indent="0" pn="section-2.4-1">None.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.5 <section>
"> <name>BFD Top-Level Hierarchy</name>
<name slugifiedName="name-bfd-top-level-hierarchy">BFD Top-Level Hierarc <t>At the "bfd" node under "control-plane-protocol", there is no
hy</name>
<t indent="0" pn="section-2.5-1">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 consists 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" markers="false" pn="section-2.5-2"> <sourcecode type="yangtree">
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
</sourcecode> </sourcecode>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.6 <section>
"> <name>BFD IP Single-Hop Hierarchy</name>
<name slugifiedName="name-bfd-ip-single-hop-hierarchy">BFD IP Single-Hop <t>An "ip-sh" node is added under the "bfd" node in
Hierarchy</name>
<t indent="0" pn="section-2.6-1">An "ip-sh" node is added under the "bfd
" node in
"control-plane-protocol". The configuration data and operational state d ata "control-plane-protocol". The configuration data and operational state d ata
for each BFD IP single-hop session are under this "ip-sh" node.</t> for each BFD IP single-hop session are under this "ip-sh" node.</t>
<sourcecode type="yangtree" markers="false" pn="section-2.6-2"> <sourcecode type="yangtree">
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 655 skipping to change at line 463
+--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> </sourcecode>
</section> </section>
<section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.7 <name>BFD IP Multihop Hierarchy</name>
"> <t>An "ip-mh" node is added under the "bfd" node in
<name slugifiedName="name-bfd-ip-multihop-hierarchy">BFD IP Multihop Hie
rarchy</name>
<t indent="0" pn="section-2.7-1">An "ip-mh" node is added under the "bfd
" node in
"control-plane-protocol". The configuration data and operational state d ata "control-plane-protocol". The configuration data and operational state d ata
for each BFD IP multihop session are under this "ip-mh" node. In the for each BFD IP multihop session are under this "ip-mh" node. In the
operational state model, we support multiple BFD multihop sessions per operational state model, we support multiple BFD multihop sessions per
remote address (ECMP); the local discriminator is used as the key.</t> remote address (ECMP); the local discriminator is used as the key.</t>
<sourcecode type="yangtree" markers="false" pn="section-2.7-2"> <sourcecode type="yangtree">
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 751 skipping to change at line 558
+--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
</sourcecode> </sourcecode>
</section> </section>
<section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.8 <name>BFD-over-LAG Hierarchy</name>
"> <t>A "lag" node is added under the "bfd" node in
<name slugifiedName="name-bfd-over-lag-hierarchy">BFD-over-LAG Hierarchy
</name>
<t indent="0" pn="section-2.8-1">A "lag" node is added under the "bfd" n
ode in
"control-plane-protocol". The configuration data and operational state d ata "control-plane-protocol". The configuration data and operational state d ata
for each BFD LAG session are under this "lag" node.</t> for each BFD LAG session are under this "lag" node.</t>
<sourcecode type="yangtree" markers="false" pn="section-2.8-2"> <sourcecode type="yangtree">
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 908 skipping to change at line 714
+--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
</sourcecode> </sourcecode>
</section> </section>
<section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.9 <name>BFD-over-MPLS-LSPs Hierarchy</name>
"> <t>An "mpls" node is added under the "bfd" node in
<name slugifiedName="name-bfd-over-mpls-lsps-hierarch">BFD-over-MPLS-LSP
s Hierarchy</name>
<t indent="0" pn="section-2.9-1">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 the 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 can be The "mpls" node can be used in a network device (top level) or can be
mounted in an LNE or network instance.</t> mounted in an LNE or network instance.</t>
<sourcecode type="yangtree" markers="false" pn="section-2.9-2"> <sourcecode type="yangtree">
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
skipping to change at line 1016 skipping to change at line 821
+--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
</sourcecode> </sourcecode>
</section> </section>
<section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.1 <name>Interaction with Other YANG Modules</name>
0"> <t><xref target="RFC8532">"Generic YANG Data Model for the Management
<name slugifiedName="name-interaction-with-other-yang">Interaction with
other YANG Modules</name>
<t indent="0" pn="section-2.10-1"><xref target="RFC8532" format="default
" sectionFormat="of" derivedContent="RFC8532">"Generic YANG Data Model for the M
anagement
of Operations, Administration, and Maintenance (OAM) Protocols That of Operations, Administration, and Maintenance (OAM) Protocols That
Use Connectionless Communications"</xref> describes how the Use Connectionless Communications"</xref> describes how the
Layer-Independent OAM Management in the Multi-Layer Environment (LIME) Layer-Independent OAM Management in the Multi-Layer Environment (LIME)
connectionless OAM model could be extended to support BFD.</t> connectionless OAM model could be extended to support BFD.</t>
<t indent="0" pn="section-2.10-2">Also, the operation of the BFD data mo del 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="include" removeInRFC="false" pn="section-2 <section>
.10.1"> <name>"ietf-interfaces" Module</name>
<name slugifiedName="name-ietf-interfaces-module">"ietf-interfaces" Mo <t>The following boolean configuration is defined in <xref target="RFC
dule</name> 8343">"A YANG Data Model for Interface Management"</xref>:</t>
<t indent="0" pn="section-2.10.1-1">The following boolean configuratio <dl newline="true" spacing="normal">
n is defined in <xref target="RFC8343" format="default" sectionFormat="of" deriv <dt>/if:interfaces/if:interface/if:enabled</dt>
edContent="RFC8343">"A YANG Data Model for Interface Management"</xref>:</t> <dd>If this configuration is set to "false", no BFD packets can be
<dl newline="true" spacing="normal" indent="3" pn="section-2.10.1-2">
<dt pn="section-2.10.1-2.1">/if:interfaces/if:interface/if:enabled</
dt>
<dd pn="section-2.10.1-2.2">If this configuration is set to "false",
no BFD packets can be
transmitted or received on that interface.</dd> transmitted or received on that interface.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2 <section>
.10.2"> <name>"ietf-ip" Module</name>
<name slugifiedName="name-ietf-ip-module">"ietf-ip" Module</name> <t>The following boolean configuration is defined in <xref target="RFC
<t indent="0" pn="section-2.10.2-1">The following boolean configuratio 8344">"A YANG Data Model for IP Management"</xref>:</t>
n is defined in <xref target="RFC8344" format="default" sectionFormat="of" deriv <dl newline="true" spacing="normal">
edContent="RFC8344">"A YANG Data Model for IP Management"</xref>:</t> <dt>/if:interfaces/if:interface/ip:ipv4/ip:enabled</dt>
<dl newline="true" spacing="normal" indent="3" pn="section-2.10.2-2"> <dd>If this configuration is set to "false", no BFD IPv4 packets
<dt pn="section-2.10.2-2.1">/if:interfaces/if:interface/ip:ipv4/ip:e
nabled</dt>
<dd pn="section-2.10.2-2.2">If this configuration is set to "false",
no BFD IPv4 packets
can be transmitted or received on that interface.</dd> can be transmitted or received on that interface.</dd>
<dt pn="section-2.10.2-2.3">/if:interfaces/if:interface/ip:ipv4/ip:f <dt>/if:interfaces/if:interface/ip:ipv4/ip:forwarding</dt>
orwarding</dt> <dd>If this configuration is set to "false", no BFD IPv4 packets
<dd pn="section-2.10.2-2.4">If this configuration is set to "false",
no BFD IPv4 packets
can be transmitted or received on that interface.</dd> can be transmitted or received on that interface.</dd>
<dt pn="section-2.10.2-2.5">/if:interfaces/if:interface/ip:ipv6/ip:e <dt>/if:interfaces/if:interface/ip:ipv6/ip:enabled</dt>
nabled</dt> <dd>If this configuration is set to "false", no BFD IPv6 packets
<dd pn="section-2.10.2-2.6">If this configuration is set to "false",
no BFD IPv6 packets
can be transmitted or received on that interface.</dd> can be transmitted or received on that interface.</dd>
<dt pn="section-2.10.2-2.7">/if:interfaces/if:interface/ip:ipv6/ip:f <dt>/if:interfaces/if:interface/ip:ipv6/ip:forwarding</dt>
orwarding</dt> <dd>If this configuration is set to "false", no BFD IPv6 packets
<dd pn="section-2.10.2-2.8">If this configuration is set to "false",
no BFD IPv6 packets
can be transmitted or received on that interface.</dd> can be transmitted or received on that interface.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2 <section>
.10.3"> <name>"ietf-mpls" Module</name>
<name slugifiedName="name-ietf-mpls-module">"ietf-mpls" Module</name> <t>The following boolean configuration is defined in <xref target="RFC
<t indent="0" pn="section-2.10.3-1">The following boolean configuratio 8960">"A YANG Data Model for MPLS Base"</xref>:</t>
n is defined in <xref target="RFC8960" format="default" sectionFormat="of" deriv <dl newline="true" spacing="normal">
edContent="RFC8960">"A YANG Data Model for MPLS Base"</xref>:</t> <dt>/rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/mpls:mpls-e
<dl newline="true" spacing="normal" indent="3" pn="section-2.10.3-2"> nabled</dt>
<dt pn="section-2.10.3-2.1">/rt:routing/mpls:mpls/mpls:interfaces/mp <dd>If this configuration is set to "false", no BFD MPLS packets
ls:interface/mpls:mpls‑enabled</dt>
<dd pn="section-2.10.3-2.2">If this configuration is set to "false",
no BFD MPLS packets
can be transmitted or received on that interface.</dd> can be transmitted or received on that interface.</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="BFD-TYPES">
<section anchor="BFD-TYPES" numbered="true" toc="include" removeInRFC="fal <name>BFD Types YANG Module</name>
se" pn="section-2.11"> <t>This YANG module imports typedefs from <xref target="RFC6991"/> and <
<name slugifiedName="name-bfd-types-yang-module">BFD Types YANG Module</ xref target="RFC8177"/>.
name>
<t indent="0" pn="section-2.11-1">This YANG module imports typedefs from
<xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6
991"/> and <xref target="RFC8177" format="default" sectionFormat="of" derivedCon
tent="RFC8177"/>.
It also imports definitions from It also imports definitions from
<xref target="RFC5880" format="default" sectionFormat="of" derivedConten <xref target="RFC5880"/>, <xref target="RFC5881"/>,
t="RFC5880"/>, <xref target="RFC5881" format="default" sectionFormat="of" derive <xref target="RFC5883"/>, <xref target="RFC5884"/>, and
dContent="RFC5881"/>, <xref target="RFC7130"/>, as well as the
<xref target="RFC5883" format="default" sectionFormat="of" derivedConten
t="RFC5883"/>, <xref target="RFC5884" format="default" sectionFormat="of" derive
dContent="RFC5884"/>, and
<xref target="RFC7130" format="default" sectionFormat="of" derivedConten
t="RFC7130"/>, as well as the
"control-plane-protocol" identity from "control-plane-protocol" identity from
<xref target="RFC8349" format="default" sectionFormat="of" derivedConten <xref target="RFC8349"/>, and references <xref target="RFC9127"/>.
t="RFC8349"/>, and references <xref target="RFC9127" format="default" sectionFor </t>
mat="of" derivedContent="RFC9127"/>. <sourcecode name="ietf-bfd-types@2022-09-22.yang" type="yang" markers=
</t> "true"><![CDATA[
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-types@2022-04-06.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;
import iana-bfd-types { import iana-bfd-types {
prefix iana-bfd-types; prefix iana-bfd-types;
reference reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding "RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
skipping to change at line 1132 skipping to change at line 930
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com> <mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>"; <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 that 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) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject
the license terms contained in, the Simplified BSD License set to the license terms contained in, the Revised BSD License
forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9314; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection (BFD) "RFC 5880: Bidirectional Forwarding Detection (BFD)
RFC XXXX: YANG Data Model for Bidirectional Forwarding RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2022-04-06 { revision 2022-09-22 {
description description
"This revision is not backwards compatible with the "This revision is not backwards compatible with the
previous version of this model. previous version of this model.
This revision adds an 'if-feature' statement called This revision adds an 'if-feature' statement called
'client-base-cfg-parms' for client configuration parameters. 'client-base-cfg-parms' for client configuration parameters.
Clients expecting to use those parameters now need to Clients expecting to use those parameters now need to
verify that the server declares support of the feature verify that the server declares support of the feature
before depending on the presence of the parameters. before depending on the presence of the parameters.
The change was introduced for clients that do not need The change was introduced for clients that do not need
them, and have to deviate to prevent them from being them and have to deviate to prevent them from being
included."; included.";
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)."; Detection (BFD).";
} }
revision 2021-10-21 { revision 2021-10-21 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding "RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
skipping to change at line 1218 skipping to change at line 1016
reference reference
"RFC 5880: Bidirectional Forwarding Detection (BFD), "RFC 5880: Bidirectional Forwarding Detection (BFD),
Section 6.4"; Section 6.4";
} }
feature client-base-cfg-parms { feature client-base-cfg-parms {
description description
"This feature allows protocol models to configure BFD client "This feature allows protocol models to configure BFD client
session parameters."; session parameters.";
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)."; Detection (BFD).";
} }
/* /*
* Identity definitions * Identity definitions
*/ */
identity bfdv1 { identity bfdv1 {
base rt:control-plane-protocol; base rt:control-plane-protocol;
description description
skipping to change at line 1770 skipping to change at line 1568
} }
leaf path-type { leaf path-type {
type identityref { type identityref {
base path-type; base path-type;
} }
description description
"BFD path type."; "BFD path type.";
} }
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
<section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.1 <name>BFD Top-Level YANG Module</name>
2"> <t>This YANG module imports and augments
<name slugifiedName="name-bfd-top-level-yang-module">BFD Top-Level YANG "/routing/control-plane-protocols/control-plane-protocol" from <xref tar
Module</name> get="RFC8349"/>. It also references
<t indent="0" pn="section-2.12-1">This YANG module imports and augments <xref target="RFC5880"/>.</t>
"/routing/control-plane-protocols/control-plane-protocol" from <xref tar <sourcecode name="ietf-bfd@2022-09-22.yang" type="yang" markers="true"
get="RFC8349" format="default" sectionFormat="of" derivedContent="RFC8349"/>. It ><![CDATA[
also references
<xref target="RFC5880" format="default" sectionFormat="of" derivedConten
t="RFC5880"/>.</t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd@2022-04-06.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;
import ietf-bfd-types { import ietf-bfd-types {
prefix bfd-types; prefix bfd-types;
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-routing { import ietf-routing {
prefix rt; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)"; (NMDA Version)";
} }
organization organization
skipping to change at line 1823 skipping to change at line 1612
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com> <mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>"; <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) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject
the license terms contained in, the Revised BSD License set to the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9314; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection (BFD) "RFC 5880: Bidirectional Forwarding Detection (BFD)
RFC XXXX: YANG Data Model for Bidirectional Forwarding RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2022-04-06 { revision 2022-09-22 {
description description
"Updating reference to RFC XXXX."; "Updating reference to RFC 9314.";
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)."; Detection (BFD).";
} }
revision 2021-10-21 { revision 2021-10-21 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding "RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; 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 description
"BFD augmentation."; "BFD augmentation.";
container bfd { container bfd {
description description
"BFD top-level container."; "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">
<section anchor="bfd-ip-single-hop-module" numbered="true" toc="include" r <name>BFD IP Single-Hop YANG Module</name>
emoveInRFC="false" pn="section-2.13"> <t>This YANG module imports "interface-ref" from <xref target="RFC8343"/
<name slugifiedName="name-bfd-ip-single-hop-yang-modu">BFD IP Single-Hop > and typedefs from <xref target="RFC6991"/>. It also imports and augments
YANG Module</name> "/routing/control-plane-protocols/control-plane-protocol" from <xref tar
<t indent="0" pn="section-2.13-1">This YANG module imports "interface-re get="RFC8349"/>, and it references
f" from <xref target="RFC8343" format="default" sectionFormat="of" derivedConten <xref target="RFC5881"/>.</t>
t="RFC8343"/> and typedefs from <xref target="RFC6991" format="default" sectionF <sourcecode name="ietf-bfd-ip-sh@2022-09-22.yang" type="yang" markers=
ormat="of" derivedContent="RFC6991"/>. It also imports and augments "true"><![CDATA[
"/routing/control-plane-protocols/control-plane-protocol" from <xref tar
get="RFC8349" format="default" sectionFormat="of" derivedContent="RFC8349"/>, an
d it references
<xref target="RFC5881" format="default" sectionFormat="of" derivedConten
t="RFC5881"/>.</t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-ip-sh@2022-04-06.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;
import ietf-bfd-types { import ietf-bfd-types {
prefix bfd-types; prefix bfd-types;
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix bfd; prefix bfd;
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; 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 reference
skipping to change at line 1940 skipping to change at line 1720
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com> <mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>"; <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) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject
the license terms contained in, the Revised BSD License set to the license terms contained in, the Revised BSD License
forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9314; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
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)
RFC XXXX: YANG Data Model for Bidirectional Forwarding RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2022-04-06 { revision 2022-09-22 {
description description
"Updating reference to RFC XXXX."; "Updating reference to RFC 9314.";
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)."; Detection (BFD).";
} }
revision 2021-10-21 { revision 2021-10-21 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding "RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
skipping to change at line 2047 skipping to change at line 1827
description description
"Interface to which this BFD session belongs."; "Interface to which this BFD session belongs.";
} }
leaf echo-enabled { leaf echo-enabled {
type boolean; type boolean;
description description
"Indicates whether Echo was enabled for BFD."; "Indicates whether Echo was enabled for BFD.";
} }
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
<section anchor="bfd-ip-multihop-module" numbered="true" toc="include" rem <section anchor="bfd-ip-multihop-module">
oveInRFC="false" pn="section-2.14"> <name>BFD IP Multihop YANG Module</name>
<name slugifiedName="name-bfd-ip-multihop-yang-module">BFD IP Multihop Y <t>This YANG module imports typedefs from
ANG Module</name> <xref target="RFC6991"/>. It also imports and augments
<t indent="0" pn="section-2.14-1">This YANG module imports typedefs from "/routing/control-plane-protocols/control-plane-protocol" from <xref tar
<xref target="RFC6991" format="default" sectionFormat="of" derivedConten get="RFC8349"/>, and it references
t="RFC6991"/>. It also imports and augments <xref target="RFC5883"/>.</t>
"/routing/control-plane-protocols/control-plane-protocol" from <xref tar <sourcecode name="ietf-bfd-ip-mh@2022-09-22.yang" type="yang" markers=
get="RFC8349" format="default" sectionFormat="of" derivedContent="RFC8349"/>, an "true"><![CDATA[
d it references
<xref target="RFC5883" format="default" sectionFormat="of" derivedConten
t="RFC5883"/>.</t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-ip-mh@2022-04-06.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;
import ietf-bfd-types { import ietf-bfd-types {
prefix bfd-types; prefix bfd-types;
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix bfd; prefix bfd;
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-routing { import ietf-routing {
prefix rt; prefix rt;
reference reference
skipping to change at line 2111 skipping to change at line 1883
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com> <mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>"; <mailto:mjethanandani@gmail.com>";
description description
"This module contains the YANG definition for BFD IP multihop "This module contains the YANG definition for BFD IP multihop
as per RFC 5883. as per RFC 5883.
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9314; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
reference reference
"RFC 5883: Bidirectional Forwarding Detection (BFD) for "RFC 5883: Bidirectional Forwarding Detection (BFD) for
Multihop Paths Multihop Paths
RFC XXXX: YANG Data Model for Bidirectional Forwarding RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2022-04-06 { revision 2022-09-22 {
description description
"Updating reference to RFC XXXX."; "Updating reference to RFC 9314.";
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)."; Detection (BFD).";
} }
revision 2021-10-21 { revision 2021-10-21 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding "RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
skipping to change at line 2215 skipping to change at line 1987
*/ */
notification multihop-notification { notification multihop-notification {
description description
"Notification for BFD multihop 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="include" remove <section anchor="bfd-over-lag-module">
InRFC="false" pn="section-2.15"> <name>BFD-over-LAG YANG Module</name>
<name slugifiedName="name-bfd-over-lag-yang-module">BFD-over-LAG YANG Mo <t>This YANG module imports "interface-ref" from <xref target="RFC8343"/
dule</name> > and typedefs from <xref target="RFC6991"/>. It also imports and augments
<t indent="0" pn="section-2.15-1">This YANG module imports "interface-re "/routing/control-plane-protocols/control-plane-protocol" from <xref tar
f" from <xref target="RFC8343" format="default" sectionFormat="of" derivedConten get="RFC8349"/>. Additionally, it references
t="RFC8343"/> and typedefs from <xref target="RFC6991" format="default" sectionF <xref target="RFC7130"/>.</t>
ormat="of" derivedContent="RFC6991"/>. It also imports and augments <sourcecode name="ietf-bfd-lag@2022-09-22.yang" type="yang" markers="t
"/routing/control-plane-protocols/control-plane-protocol" from <xref tar rue"><![CDATA[
get="RFC8349" format="default" sectionFormat="of" derivedContent="RFC8349"/>. Ad
ditionally, it references
<xref target="RFC7130" format="default" sectionFormat="of" derivedConten
t="RFC7130"/>.</t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-lag@2022-04-06.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;
import ietf-bfd-types { import ietf-bfd-types {
prefix bfd-types; prefix bfd-types;
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix bfd; prefix bfd;
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; 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 reference
skipping to change at line 2283 skipping to change at line 2047
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com> <mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>"; <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 RFC 7130. interfaces as per RFC 7130.
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject
the license terms contained in, the Revised BSD License set to the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9314; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
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
RFC XXXX: YANG Data Model for Bidirectional Forwarding RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2022-04-06 { revision 2022-09-22 {
description description
"Updating reference to RFC XXXX."; "Updating reference to RFC 9314.";
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)."; Detection (BFD).";
} }
revision 2021-10-21 { revision 2021-10-21 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding "RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
skipping to change at line 2427 skipping to change at line 2191
description description
"LAG interface name."; "LAG interface name.";
} }
leaf member-link { leaf member-link {
type if:interface-ref; type if:interface-ref;
description description
"Member link on which BFD is running."; "Member link on which BFD is running.";
} }
} }
} }
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
<section anchor="bfd-over-mpls-module" numbered="true" toc="include" remov <section anchor="bfd-over-mpls-module">
eInRFC="false" pn="section-2.16"> <name>BFD-over-MPLS YANG Module</name>
<name slugifiedName="name-bfd-over-mpls-yang-module">BFD-over-MPLS YANG <t>This YANG module imports typedefs from <xref target="RFC6991"/>. It a
Module</name> lso imports and augments
<t indent="0" pn="section-2.16-1">This YANG module imports typedefs from "/routing/control-plane-protocols/control-plane-protocol" from <xref tar
<xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6 get="RFC8349"/>.
991"/>. It also imports and augments Additionally, it references <xref target="RFC5586"/> and
"/routing/control-plane-protocols/control-plane-protocol" from <xref tar <xref target="RFC5884"/>.</t>
get="RFC8349" format="default" sectionFormat="of" derivedContent="RFC8349"/>. <sourcecode name="ietf-bfd-mpls@2022-09-22.yang" type="yang" markers="
Additionally, it references <xref target="RFC5586" format="default" sect true"><![CDATA[
ionFormat="of" derivedContent="RFC5586"/> and
<xref target="RFC5884" format="default" sectionFormat="of" derivedConten
t="RFC5884"/>.</t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
<CODE BEGINS> file "ietf-bfd-mpls@2022-04-06.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;
import ietf-bfd-types { import ietf-bfd-types {
prefix bfd-types; prefix bfd-types;
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix bfd; prefix bfd;
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-routing { import ietf-routing {
prefix rt; prefix rt;
reference reference
skipping to change at line 2491 skipping to change at line 2247
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com> <mailto:veronique_cheng@hotmail.com>
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>"; <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) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject
the license terms contained in, the Revised BSD License set to the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9314; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
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)
RFC XXXX: YANG Data Model for Bidirectional Forwarding RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2022-04-06 { revision 2022-09-22 {
description description
"Updates to use base-cfg-parms instead of client-cfg-parms, "Updates to use base-cfg-parms instead of client-cfg-parms,
and add the enabled flag."; and add the enabled flag.";
reference reference
"RFC XXXX: YANG Data Model for Bidirectional Forwarding "RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)."; Detection (BFD).";
} }
revision 2021-10-21 { revision 2021-10-21 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding "RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; 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 Generic Associated Channel (G-ACh) encapsulation
as per RFC 5586.";
reference reference
"RFC 5586: MPLS Generic Associated Channel"; "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.";
} }
skipping to change at line 2646 skipping to change at line 2403
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>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3"> <section>
<name slugifiedName="name-data-model-examples">Data Model Examples</name> <name>Data Model Examples</name>
<t indent="0" pn="section-3-1">This section presents some simple and illus <t>This section presents some simple and illustrative examples of how to
trative examples of how to
configure BFD.</t> configure BFD.</t>
<t indent="0" pn="section-3-2">The examples are represented in XML <xref t <t>The examples are represented in XML <xref target="W3C.REC-xml-20081126"
arget="W3C.REC-xml-20081126" format="default" sectionFormat="of" derivedContent= />.</t>
"W3C.REC-xml-20081126"/>.</t> <section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.1 <name>IP Single-Hop</name>
"> <t>The following is an example configuration for a BFD IP single-hop
<name slugifiedName="name-ip-single-hop">IP Single-Hop</name>
<t indent="0" pn="section-3.1-1">The following is an example configurati
on 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 10 ms.</t> interval are both set to 10 ms.</t>
<sourcecode type="xml" markers="false" pn="section-3.1-2"> <sourcecode type="xml">
&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt; &lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
&lt;interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"&gt; &lt;interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"&gt;
&lt;interface&gt; &lt;interface&gt;
&lt;name&gt;eth0&lt;/name&gt; &lt;name&gt;eth0&lt;/name&gt;
&lt;type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"&gt; &lt;type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"&gt;
ianaift:ethernetCsmacd ianaift:ethernetCsmacd
&lt;/type&gt; &lt;/type&gt;
&lt;/interface&gt; &lt;/interface&gt;
&lt;/interfaces&gt; &lt;/interfaces&gt;
skipping to change at line 2703 skipping to change at line 2457
&lt;/session&gt; &lt;/session&gt;
&lt;/sessions&gt; &lt;/sessions&gt;
&lt;/ip-sh&gt; &lt;/ip-sh&gt;
&lt;/bfd&gt; &lt;/bfd&gt;
&lt;/control-plane-protocol&gt; &lt;/control-plane-protocol&gt;
&lt;/control-plane-protocols&gt; &lt;/control-plane-protocols&gt;
&lt;/routing&gt; &lt;/routing&gt;
&lt;/config&gt; &lt;/config&gt;
</sourcecode> </sourcecode>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.2 <section>
"> <name>IP Multihop</name>
<name slugifiedName="name-ip-multihop">IP Multihop</name> <t>The following is an example configuration for a BFD IP multihop
<t indent="0" pn="section-3.2-1">The following is an example configurati
on 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 150 ms.</t> interval are both set to 150 ms.</t>
<sourcecode type="xml" markers="false" pn="section-3.2-2"> <sourcecode type="xml">
&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt; &lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
&lt;routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"&gt; &lt;routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"&gt;
&lt;control-plane-protocols&gt; &lt;control-plane-protocols&gt;
&lt;control-plane-protocol&gt; &lt;control-plane-protocol&gt;
&lt;type xmlns:bfd-types= &lt;type xmlns:bfd-types=
"urn:ietf:params:xml:ns:yang:ietf-bfd-types"&gt; "urn:ietf:params:xml:ns:yang:ietf-bfd-types"&gt;
bfd-types:bfdv1 bfd-types:bfdv1
&lt;/type&gt; &lt;/type&gt;
&lt;name&gt;name:BFD&lt;/name&gt; &lt;name&gt;name:BFD&lt;/name&gt;
skipping to change at line 2742 skipping to change at line 2496
&lt;/session-group&gt; &lt;/session-group&gt;
&lt;/session-groups&gt; &lt;/session-groups&gt;
&lt;/ip-mh&gt; &lt;/ip-mh&gt;
&lt;/bfd&gt; &lt;/bfd&gt;
&lt;/control-plane-protocol&gt; &lt;/control-plane-protocol&gt;
&lt;/control-plane-protocols&gt; &lt;/control-plane-protocols&gt;
&lt;/routing&gt; &lt;/routing&gt;
&lt;/config&gt; &lt;/config&gt;
</sourcecode> </sourcecode>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.3 <section>
"> <name>LAG</name>
<name slugifiedName="name-lag">LAG</name> <t>The following is an example of BFD configuration for a LAG session.
<t indent="0" pn="section-3.3-1">The following is an example of BFD conf
iguration 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
"ieee8023adLag" has a desired transmit interval and required receive int erval "ieee8023adLag" has a desired transmit interval and required receive int erval
set to 10 ms.</t> set to 10 ms.</t>
<sourcecode type="xml" markers="false" pn="section-3.3-2"> <sourcecode type="xml">
&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt; &lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
&lt;interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"&gt; &lt;interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"&gt;
&lt;interface&gt; &lt;interface&gt;
&lt;name&gt;Bundle-Ether1&lt;/name&gt; &lt;name&gt;Bundle-Ether1&lt;/name&gt;
&lt;type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"&gt; &lt;type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"&gt;
ianaift:ieee8023adLag ianaift:ieee8023adLag
&lt;/type&gt; &lt;/type&gt;
&lt;/interface&gt; &lt;/interface&gt;
&lt;/interfaces&gt; &lt;/interfaces&gt;
skipping to change at line 2790 skipping to change at line 2544
&lt;/session&gt; &lt;/session&gt;
&lt;/sessions&gt; &lt;/sessions&gt;
&lt;/lag&gt; &lt;/lag&gt;
&lt;/bfd&gt; &lt;/bfd&gt;
&lt;/control-plane-protocol&gt; &lt;/control-plane-protocol&gt;
&lt;/control-plane-protocols&gt; &lt;/control-plane-protocols&gt;
&lt;/routing&gt; &lt;/routing&gt;
&lt;/config&gt; &lt;/config&gt;
</sourcecode> </sourcecode>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.4 <section>
"> <name>MPLS</name>
<name slugifiedName="name-mpls">MPLS</name> <t>The following is an example of BFD configured for an MPLS LSP. In
<t indent="0" pn="section-3.4-1">The following is an example of BFD conf
igured for an MPLS LSP. In
this case, the desired transmit interval and required receive interval this case, the desired transmit interval and required receive interval
are both set to 250 ms.</t> are both set to 250 ms.</t>
<sourcecode type="xml" markers="false" pn="section-3.4-2"> <sourcecode type="xml">
&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt; &lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
&lt;routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"&gt; &lt;routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"&gt;
&lt;control-plane-protocols&gt; &lt;control-plane-protocols&gt;
&lt;control-plane-protocol&gt; &lt;control-plane-protocol&gt;
&lt;type xmlns:bfd-types= &lt;type xmlns:bfd-types=
"urn:ietf:params:xml:ns:yang:ietf-bfd-types"&gt; "urn:ietf:params:xml:ns:yang:ietf-bfd-types"&gt;
bfd-types:bfdv1 bfd-types:bfdv1
&lt;/type&gt; &lt;/type&gt;
&lt;name&gt;name:BFD&lt;/name&gt; &lt;name&gt;name:BFD&lt;/name&gt;
skipping to change at line 2828 skipping to change at line 2582
&lt;/session-groups&gt; &lt;/session-groups&gt;
&lt;/mpls&gt; &lt;/mpls&gt;
&lt;/bfd&gt; &lt;/bfd&gt;
&lt;/control-plane-protocol&gt; &lt;/control-plane-protocol&gt;
&lt;/control-plane-protocols&gt; &lt;/control-plane-protocols&gt;
&lt;/routing&gt; &lt;/routing&gt;
&lt;/config&gt; &lt;/config&gt;
</sourcecode> </sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4"> <section>
<name slugifiedName="name-security-considerations">Security Considerations <name>Security Considerations</name>
</name> <t>The YANG modules specified in this document define a schema for data
<t indent="0" pn="section-4-1">The YANG modules specified in this document
define a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF <xref target="RFC6241" format="default" sectionFormat="of" derivedCon tent="RFC6241"/> or RESTCONF <xref target="RFC8040" format="default" sectionForm at="of" derivedContent="RFC8040"/>. as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
The lowest NETCONF layer is the secure transport layer, and the The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH) mandatory-to-implement secure transport is Secure Shell (SSH)
<xref target="RFC6242" format="default" sectionFormat="of" derivedContent="RFC62 <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the
42"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.</t>
mandatory-to-implement secure transport is TLS <xref target="RFC8446" format="de <t>The Network Configuration Access Control Model (NACM) <xref target="RFC
fault" sectionFormat="of" derivedContent="RFC8446"/>.</t> 8341"/>
<t indent="0" pn="section-4-2">The Network Configuration Access Control Mo
del (NACM) <xref target="RFC8341" format="default" sectionFormat="of" derivedCon
tent="RFC8341"/>
provides the means to restrict access for particular NETCONF or RESTCONF users provides the means to restrict access for particular NETCONF or RESTCONF users
to 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>
<t indent="0" pn="section-4-3">There are a number of data nodes defined in these YANG modules that are <t>There are a number of data nodes defined in these YANG modules that are
writable/creatable/deletable (i.e., config true, which is the default). These writable/creatable/deletable (i.e., config true, which is the default). These
data nodes may be considered sensitive or vulnerable in some network data nodes may be considered sensitive or vulnerable in some network
environments. Write operations (e.g., edit-config) to these data nodes without environments. Write operations (e.g., edit-config) to these data nodes without
proper protection can have a negative effect on network operations. These are proper protection can have a negative effect on network operations. These are
the subtrees and data nodes and their sensitivity/vulnerability from a write acc the subtrees and data nodes and their sensitivity/vulnerability from a wri
ess perspective:</t> te access perspective:</t>
<dl newline="true" spacing="normal" indent="3" pn="section-4-4"> <dl newline="true" spacing="normal">
<dt pn="section-4-4.1">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessions:<
otocol/bfd/ip-sh/sessions:</dt> /dt>
<dd pn="section-4-4.2"> <dd>
<t indent="0" pn="section-4-4.2.1">This list specifies the IP single-h <t>This list specifies the IP single-hop BFD sessions.</t>
op BFD sessions.</t> <t>Data nodes "local-multiplier", "desired-min-tx-interval",
<t indent="0" pn="section-4-4.2.2">Data nodes "local-multiplier", "des
ired-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 n be used to BFD IP single-hop session. The "source-addr" and "dest-addr" data nodes ca n be used to
send BFD packets to unwitting recipients. <xref target="RFC5880" format="d efault" sectionFormat="of" derivedContent="RFC5880"/> describes how BFD mitigate s such send BFD packets to unwitting recipients. <xref target="RFC5880"/> describ es how BFD mitigates such
threats. Authentication data nodes "key-chain" and "meticulous" impact the threats. Authentication data nodes "key-chain" and "meticulous" impact the
security of the BFD IP single-hop session.</t> security of the BFD IP single-hop session.</t>
</dd> </dd>
<dt pn="section-4-4.3">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/se
otocol/bfd/ip-mh/session-group:</dt> ssion-group:</dt>
<dd pn="section-4-4.4"> <dd>
<t indent="0" pn="section-4-4.4.1">This list specifies the IP multihop <t>This list specifies the IP multihop BFD session groups.</t>
BFD session groups.</t> <t>Data nodes "local-multiplier", "desired-min-tx-interval",
<t indent="0" pn="section-4-4.4.2">Data nodes "local-multiplier", "des
ired-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 multihop session. The "source-addr" and "dest-addr" data nodes can be used to BFD IP multihop session. The "source-addr" and "dest-addr" data nodes can be used to
send BFD packets to unwitting recipients. <xref target="RFC5880" format="d efault" sectionFormat="of" derivedContent="RFC5880"/> describes how BFD mitigate s such send BFD packets to unwitting recipients. <xref target="RFC5880"/> describ es how BFD mitigates such
threats. Authentication data nodes "key-chain" and "meticulous" impact the threats. Authentication data nodes "key-chain" and "meticulous" impact the
security of the BFD IP multihop session.</t> security of the BFD IP multihop session.</t>
</dd> </dd>
<dt pn="section-4-4.5">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sess
otocol/bfd/lag/sessions:</dt> ions:</dt>
<dd pn="section-4-4.6"> <dd>
<t indent="0" pn="section-4-4.6.1">This list specifies the BFD session <t>This list specifies the BFD sessions over a LAG.</t>
s over a LAG.</t> <t>Data nodes "local-multiplier", "desired-min-tx-interval",
<t indent="0" pn="section-4-4.6.2">Data nodes "local-multiplier", "des
ired-min-tx-interval",
"required-min-rx-interval", and "min-interval" all impact the BFD-over-LAG "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 be used to session. The "ipv4-dest-addr" and "ipv6-dest-addr" data nodes can be used to
send BFD packets to unwitting recipients. <xref target="RFC5880" format="d efault" sectionFormat="of" derivedContent="RFC5880"/> describes how BFD mitigate s such send BFD packets to unwitting recipients. <xref target="RFC5880"/> describ es how BFD mitigates such
threats. Authentication data nodes "key-chain" and "meticulous" impact the threats. Authentication data nodes "key-chain" and "meticulous" impact the
security of the BFD-over-LAG session.</t> security of the BFD-over-LAG session.</t>
</dd> </dd>
<dt pn="section-4-4.7">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ses
otocol/bfd/mpls/session-group:</dt> sion-group:</dt>
<dd pn="section-4-4.8"> <dd>
<t indent="0" pn="section-4-4.8.1">This list specifies the session gro <t>This list specifies the session groups for BFD over MPLS.</t>
ups for BFD over MPLS.</t> <t>Data nodes "local-multiplier", "desired-min-tx-interval",
<t indent="0" pn="section-4-4.8.2">Data nodes "local-multiplier", "des
ired-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-MPLS-LSPs session. Authentication data nodes "key-chain" and "met iculous" impact BFD-over-MPLS-LSPs session. Authentication data nodes "key-chain" and "met iculous" impact
the security of the BFD-over-MPLS-LSPs session.</t> the security of the BFD-over-MPLS-LSPs session.</t>
</dd> </dd>
<dt pn="section-4-4.9">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/egr
otocol/bfd/mpls/egress:</dt> ess:</dt>
<dd pn="section-4-4.10">Data nodes "local-multiplier", "desired-min-tx-i <dd>Data nodes "local-multiplier", "desired-min-tx-interval",
nterval",
"required-min-rx-interval", and "min-interval" all impact the "required-min-rx-interval", and "min-interval" all impact the
BFD-over-MPLS-LSPs sessions for which this device is an MPLS LSP egress BFD-over-MPLS-LSPs sessions for which this device is an MPLS LSP egress
node. Authentication data nodes "key-chain" and "meticulous" impact the node. Authentication data nodes "key-chain" and "meticulous" impact the
security of the BFD-over-MPLS-LSPs sessions for which this device is an security of the BFD-over-MPLS-LSPs sessions for which this device is an
MPLS LSP egress node.</dd> MPLS LSP egress node.</dd>
</dl> </dl>
<t indent="0" pn="section-4-5">The YANG modules have writable data nodes t hat can be used for the <t>The YANG modules have writable data nodes that can be used for the
creation of BFD sessions and the modification of BFD session parameters. T he creation of BFD sessions and the modification of BFD session parameters. T he
system should "police" the creation of BFD sessions to prevent new session s system should "police" the creation of BFD sessions to prevent new session s
from causing existing BFD sessions to fail. In the case of BFD session from causing existing BFD sessions to fail. In the case of BFD session
modification, the BFD protocol has mechanisms in place that allow for modification, the BFD protocol has mechanisms in place that allow for
in-service modification.</t> in-service modification.</t>
<t indent="0" pn="section-4-6">When BFD clients are used to modify BFD con <t>When BFD clients are used to modify BFD configuration (as described
figuration (as described in <xref target="CFG-MODEL"/>), the BFD clients need to
in <xref target="CFG-MODEL" format="default" sectionFormat="of" derivedCon
tent="Section 2.1"/>), the BFD clients need to
be included in an analysis of the security properties of the system that be included in an analysis of the security properties of the system that
uses BFD (e.g., when considering the authentication and authorization of uses BFD (e.g., when considering the authentication and authorization of
control actions). In many cases, BFD is not the most vulnerable portion control actions). In many cases, BFD is not the most vulnerable portion
of such a composite system, since BFD is limited to generating of such a composite system, since BFD is limited to generating
well-defined traffic at a fixed rate on a given path; in the case of an well-defined traffic at a fixed rate on a given path; in the case of an
IGP acting as a BFD client, attacking the IGP could cause more broad-scale IGP acting as a BFD client, attacking the IGP could cause more broad-scale
disruption than would (de)configuring a BFD session.</t> disruption than would (de)configuring a BFD session.</t>
<t indent="0" pn="section-4-7">Some of the readable data nodes in these YA NG modules 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 from a read access perspective:</t> and their sensitivity/vulnerability from a read access perspective:</t>
<dl newline="true" spacing="normal" indent="3" pn="section-4-8"> <dl newline="true" spacing="normal">
<dt pn="section-4-8.1">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/su
otocol/bfd/ip-sh/summary:</dt> mmary:</dt>
<dd pn="section-4-8.2">Access to this information discloses the number o <dd>Access to this information discloses the number of BFD IP single-hop
f BFD IP single-hop
sessions that are in the "up", "down", or "admin-down" state. The counters include BFD sessions that are in the "up", "down", or "admin-down" state. 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.</dd>
<dt pn="section-4-8.3">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/se
otocol/bfd/ip-sh/sessions/session/:</dt> ssions/session/:</dt>
<dd pn="section-4-8.4">Access to data nodes "local-discriminator" and "r <dd>Access to data nodes "local-discriminator" and "remote-discriminator
emote-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.</dd> ability to spoof BFD IP single-hop packets.</dd>
<dt pn="section-4-8.5">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/su
otocol/bfd/ip-mh/summary:</dt> mmary:</dt>
<dd pn="section-4-8.6">Access to this information discloses the number o <dd>Access to this information discloses the number of BFD IP multihop
f BFD IP multihop
sessions that are in the "up", "down", or "admin-down" state. The counters include BFD sessions that are in the "up", "down", or "admin-down" state. 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.</dd>
<dt pn="section-4-8.7">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/se
otocol/bfd/ip-mh/session-groups/session-group/sessions:</dt> ssion-groups/session-group/sessions:</dt>
<dd pn="section-4-8.8">Access to data nodes "local-discriminator" and "r <dd>Access to data nodes "local-discriminator" and "remote-discriminator
emote-discriminator" "
(combined with the data nodes in the session group's authentication contai ner) provides the (combined with the data nodes in the session group's authentication contai ner) provides the
ability to spoof BFD IP multihop packets.</dd> ability to spoof BFD IP multihop packets.</dd>
<dt pn="section-4-8.9">/routing/control-plane-protocols/control-plane-pr <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micr
otocol/bfd/lag/micro-bfd-ipv4-session-statistics/summary:</dt> o-bfd-ipv4-session-statistics/summary:</dt>
<dd pn="section-4-8.10">Access to this information discloses the number <dd>Access to this information discloses the number of micro-BFD IPv4 LA
of micro-BFD IPv4 LAG G
sessions that are in the "up", "down", or "admin-down" state. The counters include BFD sessions that are in the "up", "down", or "admin-down" state. 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.</dd>
<dt pn="section-4-8.11">/routing/control-plane-protocols/control-plane-p <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sess
rotocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd-ipv4:</dt> ions/session/member-links/member-link/micro-bfd-ipv4:</dt>
<dd pn="section-4-8.12">Access to data nodes "local-discriminator" and " <dd>Access to data nodes "local-discriminator" and "remote-discriminator
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.</dd> ability to spoof BFD IPv4 LAG packets.</dd>
<dt pn="section-4-8.13">/routing/control-plane-protocols/control-plane-p <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micr
rotocol/bfd/lag/micro-bfd-ipv6-session-statistics/summary:</dt> o-bfd-ipv6-session-statistics/summary:</dt>
<dd pn="section-4-8.14">Access to this information discloses the number <dd>Access to this information discloses the number of micro-BFD IPv6 LA
of micro-BFD IPv6 LAG G
sessions that are in the "up", "down", or "admin-down" state. The counters include BFD sessions that are in the "up", "down", or "admin-down" state. 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.</dd>
<dt pn="section-4-8.15">/routing/control-plane-protocols/control-plane-p <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sess
rotocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd-ipv6:</dt> ions/session/member-links/member-link/micro-bfd-ipv6:</dt>
<dd pn="section-4-8.16">Access to data nodes "local-discriminator" and " <dd>Access to data nodes "local-discriminator" and "remote-discriminator
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.</dd> ability to spoof BFD IPv6 LAG packets.</dd>
<dt pn="section-4-8.17">/routing/control-plane-protocols/control-plane-p <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/sum
rotocol/bfd/mpls/summary:</dt> mary:</dt>
<dd pn="section-4-8.18">Access to this information discloses the number <dd>Access to this information discloses the number of BFD sessions over
of BFD sessions over
MPLS LSPs that are in the "up", "down", or "admin-down" state. The counter s include BFD MPLS LSPs that are in the "up", "down", or "admin-down" state. The counter s include BFD
sessions for which the user does not have read access.</dd> sessions for which the user does not have read access.</dd>
<dt pn="section-4-8.19">/routing/control-plane-protocols/control-plane-p <dt>/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ses
rotocol/bfd/mpls/session-groups/session-group/sessions:</dt> sion-groups/session-group/sessions:</dt>
<dd pn="section-4-8.20">Access to data nodes "local-discriminator" and " <dd>Access to data nodes "local-discriminator" and "remote-discriminator
remote-discriminator" "
(combined with the data nodes in the session group's authentication contai ner) provides the (combined with the data nodes in the session group's authentication contai ner) provides the
ability to spoof BFD-over-MPLS-LSPs packets.</dd> ability to spoof BFD-over-MPLS-LSPs packets.</dd>
</dl> </dl>
<t indent="0" pn="section-4-9">This document does not define any RPC opera tions.</t> <t>This document does not define any RPC operations.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5"> <section>
<name slugifiedName="name-iana-considerations">IANA Considerations</name> <name>IANA Considerations</name>
<t indent="0" pn="section-5-1">This document registers the following names <t>This document registers the following namespace URIs in the "IETF XML R
pace URIs in the IETF XML in the "IETF XML Registry" <xref target="RFC3688" form egistry" <xref target="RFC3688"/>:</t>
at="default" sectionFormat="of" derivedContent="RFC3688"/>:</t> <dl spacing="compact">
<dl newline="false" spacing="compact" indent="3" pn="section-5-2"> <dt>URI:</dt>
<dt pn="section-5-2.1">URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-types</dd>
<dd pn="section-5-2.2">urn:ietf:params:xml:ns:yang:ietf-bfd-types</dd> <dt>Registrant Contact:</dt>
<dt pn="section-5-2.3">Registrant Contact:</dt> <dd>The IESG.</dd>
<dd pn="section-5-2.4">The IESG.</dd> <dt>XML:</dt>
<dt pn="section-5-2.5">XML:</dt> <dd>N/A; the requested URI is an XML namespace.</dd>
<dd pn="section-5-2.6">N/A; the requested URI is an XML namespace.</dd>
</dl> </dl>
<dl newline="false" spacing="compact" indent="3" pn="section-5-3"> <dl spacing="compact">
<dt pn="section-5-3.1">URI:</dt> <dt>URI:</dt>
<dd pn="section-5-3.2">urn:ietf:params:xml:ns:yang:ietf-bfd</dd> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd</dd>
<dt pn="section-5-3.3">Registrant Contact:</dt> <dt>Registrant Contact:</dt>
<dd pn="section-5-3.4">The IESG.</dd> <dd>The IESG.</dd>
<dt pn="section-5-3.5">XML:</dt> <dt>XML:</dt>
<dd pn="section-5-3.6">N/A; the requested URI is an XML namespace.</dd> <dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact" indent="3" pn="section-5-4">
<dt pn="section-5-4.1">URI:</dt>
<dd pn="section-5-4.2">urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh</dd>
<dt pn="section-5-4.3">Registrant Contact:</dt>
<dd pn="section-5-4.4">The IESG.</dd>
<dt pn="section-5-4.5">XML:</dt>
<dd pn="section-5-4.6">N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact" indent="3" pn="section-5-5">
<dt pn="section-5-5.1">URI:</dt>
<dd pn="section-5-5.2">urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh</dd>
<dt pn="section-5-5.3">Registrant Contact:</dt>
<dd pn="section-5-5.4">The IESG.</dd>
<dt pn="section-5-5.5">XML:</dt>
<dd pn="section-5-5.6">N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact" indent="3" pn="section-5-6">
<dt pn="section-5-6.1">URI:</dt>
<dd pn="section-5-6.2">urn:ietf:params:xml:ns:yang:ietf-bfd-lag</dd>
<dt pn="section-5-6.3">Registrant Contact:</dt>
<dd pn="section-5-6.4">The IESG.</dd>
<dt pn="section-5-6.5">XML:</dt>
<dd pn="section-5-6.6">N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact" indent="3" pn="section-5-7">
<dt pn="section-5-7.1">URI:</dt>
<dd pn="section-5-7.2">urn:ietf:params:xml:ns:yang:ietf-bfd-mpls</dd>
<dt pn="section-5-7.3">Registrant Contact:</dt>
<dd pn="section-5-7.4">The IESG.</dd>
<dt pn="section-5-7.5">XML:</dt>
<dd pn="section-5-7.6">N/A; the requested URI is an XML namespace.</dd>
</dl>
<t indent="0" pn="section-5-8">This document registers the following YANG
modules in the "YANG Module Names"
registry <xref target="RFC6020" format="default" sectionFormat="of" derive
dContent="RFC6020"/>:</t>
<dl newline="false" spacing="compact" indent="3" pn="section-5-9">
<dt pn="section-5-9.1">Name:</dt>
<dd pn="section-5-9.2">ietf-bfd-types</dd>
<dt pn="section-5-9.3">Namespace:</dt>
<dd pn="section-5-9.4">urn:ietf:params:xml:ns:yang:ietf-bfd-types</dd>
<dt pn="section-5-9.5">Prefix:</dt>
<dd pn="section-5-9.6">bfd-types</dd>
<dt pn="section-5-9.7">Reference:</dt>
<dd pn="section-5-9.8">RFC XXXX</dd>
</dl> </dl>
<dl newline="false" spacing="compact" indent="3" pn="section-5-10"> <dl spacing="compact">
<dt pn="section-5-10.1">Name:</dt> <dt>URI:</dt>
<dd pn="section-5-10.2">ietf-bfd</dd> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh</dd>
<dt pn="section-5-10.3">Namespace:</dt> <dt>Registrant Contact:</dt>
<dd pn="section-5-10.4">urn:ietf:params:xml:ns:yang:ietf-bfd</dd> <dd>The IESG.</dd>
<dt pn="section-5-10.5">Prefix:</dt> <dt>XML:</dt>
<dd pn="section-5-10.6">bfd</dd> <dd>N/A; the requested URI is an XML namespace.</dd>
<dt pn="section-5-10.7">Reference:</dt> </dl>
<dd pn="section-5-10.8">RFC XXXX</dd> <dl spacing="compact">
</dl> <dt>URI:</dt>
<dl newline="false" spacing="compact" indent="3" pn="section-5-11"> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh</dd>
<dt pn="section-5-11.1">Name:</dt> <dt>Registrant Contact:</dt>
<dd pn="section-5-11.2">ietf-bfd-ip-sh</dd> <dd>The IESG.</dd>
<dt pn="section-5-11.3">Namespace:</dt> <dt>XML:</dt>
<dd pn="section-5-11.4">urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh</dd> <dd>N/A; the requested URI is an XML namespace.</dd>
<dt pn="section-5-11.5">Prefix:</dt> </dl>
<dd pn="section-5-11.6">bfd-ip-sh</dd> <dl spacing="compact">
<dt pn="section-5-11.7">Reference:</dt> <dt>URI:</dt>
<dd pn="section-5-11.8">RFC XXXX</dd> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-lag</dd>
</dl> <dt>Registrant Contact:</dt>
<dl newline="false" spacing="compact" indent="3" pn="section-5-12"> <dd>The IESG.</dd>
<dt pn="section-5-12.1">Name:</dt> <dt>XML:</dt>
<dd pn="section-5-12.2">ietf-bfd-ip-mh</dd> <dd>N/A; the requested URI is an XML namespace.</dd>
<dt pn="section-5-12.3">Namespace:</dt> </dl>
<dd pn="section-5-12.4">urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh</dd> <dl spacing="compact">
<dt pn="section-5-12.5">Prefix:</dt> <dt>URI:</dt>
<dd pn="section-5-12.6">bfd-ip-mh</dd> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-mpls</dd>
<dt pn="section-5-12.7">Reference:</dt> <dt>Registrant Contact:</dt>
<dd pn="section-5-12.8">RFC XXXX</dd> <dd>The IESG.</dd>
</dl> <dt>XML:</dt>
<dl newline="false" spacing="compact" indent="3" pn="section-5-13"> <dd>N/A; the requested URI is an XML namespace.</dd>
<dt pn="section-5-13.1">Name:</dt> </dl>
<dd pn="section-5-13.2">ietf-bfd-lag</dd>
<dt pn="section-5-13.3">Namespace:</dt> <t>This document registers the following YANG modules in the "YANG Module
<dd pn="section-5-13.4">urn:ietf:params:xml:ns:yang:ietf-bfd-lag</dd> Names"
<dt pn="section-5-13.5">Prefix:</dt> registry <xref target="RFC6020"/>:</t>
<dd pn="section-5-13.6">bfd-lag</dd> <dl spacing="compact">
<dt pn="section-5-13.7">Reference:</dt> <dt>Name:</dt>
<dd pn="section-5-13.8">RFC XXXX</dd> <dd>ietf-bfd-types</dd>
</dl> <dt>Namespace:</dt>
<dl newline="false" spacing="compact" indent="3" pn="section-5-14"> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd-types</dd>
<dt pn="section-5-14.1">Name:</dt> <dt>Prefix:</dt>
<dd pn="section-5-14.2">ietf-bfd-mpls</dd> <dd>bfd-types</dd>
<dt pn="section-5-14.3">Namespace:</dt> <dt>Reference:</dt>
<dd pn="section-5-14.4">urn:ietf:params:xml:ns:yang:ietf-bfd-mpls</dd> <dd>RFC 9314</dd>
<dt pn="section-5-14.5">Prefix:</dt> </dl>
<dd pn="section-5-14.6">bfd-mpls</dd> <dl spacing="compact">
<dt pn="section-5-14.7">Reference:</dt> <dt>Name:</dt>
<dd pn="section-5-14.8">RFC XXXX</dd> <dd>ietf-bfd</dd>
</dl> <dt>Namespace:</dt>
</section> <dd>urn:ietf:params:xml:ns:yang:ietf-bfd</dd>
<dt>Prefix:</dt>
<dd>bfd</dd>
<dt>Reference:</dt>
<dd>RFC 9314</dd>
</dl>
<dl spacing="compact">
<dt>Name:</dt>
<dd>ietf-bfd-ip-sh</dd>
<dt>Namespace:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh</dd>
<dt>Prefix:</dt>
<dd>bfd-ip-sh</dd>
<dt>Reference:</dt>
<dd>RFC 9314</dd>
</dl>
<dl spacing="compact">
<dt>Name:</dt>
<dd>ietf-bfd-ip-mh</dd>
<dt>Namespace:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh</dd>
<dt>Prefix:</dt>
<dd>bfd-ip-mh</dd>
<dt>Reference:</dt>
<dd>RFC 9314</dd>
</dl>
<dl spacing="compact">
<dt>Name:</dt>
<dd>ietf-bfd-lag</dd>
<dt>Namespace:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-bfd-lag</dd>
<dt>Prefix:</dt>
<dd>bfd-lag</dd>
<dt>Reference:</dt>
<dd>RFC 9314</dd>
</dl>
<dl spacing="compact">
<dt>Name:</dt>
<dd>ietf-bfd-mpls</dd>
<dt>Namespace:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-bfd-mpls</dd>
<dt>Prefix:</dt>
<dd>bfd-mpls</dd>
<dt>Reference:</dt>
<dd>RFC 9314</dd>
</dl>
</section>
</middle> </middle>
<back> <back>
<references pn="section-6"> <references>
<name slugifiedName="name-references">References</name> <name>References</name>
<references pn="section-6.1"> <references>
<name slugifiedName="name-normative-references">Normative References</na <name>Normative References</name>
me>
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc36 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.
88" quoteTitle="true" derivedAnchor="RFC3688"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5586.
<title>The IETF XML Registry</title> xml"/>
<author initials="M." surname="Mealling" fullname="M. Mealling"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.
<organization showOnFrontPage="true"/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5881.
<date year="2004" month="January"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5882.
<t indent="0">This document describes an IANA maintained registry xml"/>
for IETF standards which use Extensible Markup Language (XML) related items such <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5883.
as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Descrip xml"/>
tion Framework (RDF) Schemas.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5884.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5885.
<seriesInfo name="BCP" value="81"/> xml"/>
<seriesInfo name="RFC" value="3688"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.
<seriesInfo name="DOI" value="10.17487/RFC3688"/> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.
<reference anchor="RFC5586" target="https://www.rfc-editor.org/info/rfc5 xml"/>
586" quoteTitle="true" derivedAnchor="RFC5586"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.
<front> xml"/>
<title>MPLS Generic Associated Channel</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.
<author initials="M." surname="Bocci" fullname="M. Bocci" role="edit xml"/>
or"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7130.
<organization showOnFrontPage="true"/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.
<author initials="M." surname="Vigoureux" fullname="M. Vigoureux" ro xml"/>
le="editor"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8177.
<organization showOnFrontPage="true"/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.
<author initials="S." surname="Bryant" fullname="S. Bryant" role="ed xml"/>
itor"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.
<organization showOnFrontPage="true"/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8343.
<date year="2009" month="June"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8344.
<t indent="0">This document generalizes the applicability of the p xml"/>
seudowire (PW) Associated Channel Header (ACH), enabling the realization of a co <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8349.
ntrol channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections i xml"/>
n addition to MPLS pseudowires. In order to identify the presence of this Assoc <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
iated Channel Header in the label stack, this document also assigns one of the r xml"/>
eserved MPLS label values to the Generic Associated Channel Label (GAL), to be u <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8960.
sed as a label based exception mechanism.</t> xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9127.
</front> xml"/>
<seriesInfo name="RFC" value="5586"/>
<seriesInfo name="DOI" value="10.17487/RFC5586"/>
</reference>
<reference anchor="RFC5880" target="https://www.rfc-editor.org/info/rfc5
880" quoteTitle="true" derivedAnchor="RFC5880">
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<author initials="D." surname="Katz" fullname="D. Katz">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Ward" fullname="D. Ward">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="June"/>
<abstract>
<t indent="0">This document describes a protocol intended to detec
t faults in the bidirectional path between two forwarding engines, including int
erfaces, data link(s), and to the extent possible the forwarding engines themsel
ves, with potentially very low latency. It operates independently of media, dat
a protocols, and routing protocols. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5880"/>
<seriesInfo name="DOI" value="10.17487/RFC5880"/>
</reference>
<reference anchor="RFC5881" target="https://www.rfc-editor.org/info/rfc5
881" quoteTitle="true" derivedAnchor="RFC5881">
<front>
<title>Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (S
ingle Hop)</title>
<author initials="D." surname="Katz" fullname="D. Katz">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Ward" fullname="D. Ward">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="June"/>
<abstract>
<t indent="0">This document describes the use of the Bidirectional
Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STA
NDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5881"/>
<seriesInfo name="DOI" value="10.17487/RFC5881"/>
</reference>
<reference anchor="RFC5882" target="https://www.rfc-editor.org/info/rfc5
882" quoteTitle="true" derivedAnchor="RFC5882">
<front>
<title>Generic Application of Bidirectional Forwarding Detection (BF
D)</title>
<author initials="D." surname="Katz" fullname="D. Katz">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Ward" fullname="D. Ward">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="June"/>
<abstract>
<t indent="0">This document describes the generic application of t
he Bidirectional Forwarding Detection (BFD) protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5882"/>
<seriesInfo name="DOI" value="10.17487/RFC5882"/>
</reference>
<reference anchor="RFC5883" target="https://www.rfc-editor.org/info/rfc5
883" quoteTitle="true" derivedAnchor="RFC5883">
<front>
<title>Bidirectional Forwarding Detection (BFD) for Multihop Paths</
title>
<author initials="D." surname="Katz" fullname="D. Katz">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Ward" fullname="D. Ward">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="June"/>
<abstract>
<t indent="0">This document describes the use of the Bidirectional
Forwarding Detection (BFD) protocol over multihop paths, including unidirection
al links. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5883"/>
<seriesInfo name="DOI" value="10.17487/RFC5883"/>
</reference>
<reference anchor="RFC5884" target="https://www.rfc-editor.org/info/rfc5
884" quoteTitle="true" derivedAnchor="RFC5884">
<front>
<title>Bidirectional Forwarding Detection (BFD) for MPLS Label Switc
hed Paths (LSPs)</title>
<author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Kompella" fullname="K. Kompella">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Nadeau" fullname="T. Nadeau">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="June"/>
<abstract>
<t indent="0">One desirable application of Bidirectional Forwardin
g Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Swit
ched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detec
ting MPLS data plane failures and for verifying the MPLS LSP data plane against
the control plane. BFD can be used for the former, but not for the latter. How
ever, the control plane processing required for BFD Control packets is relativel
y smaller than the processing required for LSP Ping messages. A combination of
LSP Ping and BFD can be used to provide faster data plane failure detection and/
or make it possible to provide such detection on a greater number of LSPs. This
document describes the applicability of BFD in relation to LSP Ping for this ap
plication. It also describes procedures for using BFD in this environment. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5884"/>
<seriesInfo name="DOI" value="10.17487/RFC5884"/>
</reference>
<reference anchor="RFC5885" target="https://www.rfc-editor.org/info/rfc5
885" quoteTitle="true" derivedAnchor="RFC5885">
<front>
<title>Bidirectional Forwarding Detection (BFD) for the Pseudowire V
irtual Circuit Connectivity Verification (VCCV)</title>
<author initials="T." surname="Nadeau" fullname="T. Nadeau" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="June"/>
<abstract>
<t indent="0">This document describes Connectivity Verification (C
V) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Con
nectivity Verification (VCCV). VCCV provides a control channel that is associat
ed with a pseudowire (PW), as well as the corresponding operations and managemen
t functions such as connectivity verification to be used over that control chann
el. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5885"/>
<seriesInfo name="DOI" value="10.17487/RFC5885"/>
</reference>
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6
020" quoteTitle="true" derivedAnchor="RFC6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="October"/>
<abstract>
<t indent="0">YANG is a data modeling language used to model confi
guration and state data manipulated by the Network Configuration Protocol (NETCO
NF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
241" quoteTitle="true" derivedAnchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="June"/>
<abstract>
<t indent="0">The Network Configuration Protocol (NETCONF) defined
in this document provides mechanisms to install, manipulate, and delete the con
figuration of network devices. It uses an Extensible Markup Language (XML)-base
d data encoding for the configuration data as well as the protocol messages. Th
e NETCONF protocol operations are realized as remote procedure calls (RPCs). Th
is document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6
242" quoteTitle="true" derivedAnchor="RFC6242">
<front>
<title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
<author initials="M." surname="Wasserman" fullname="M. Wasserman">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="June"/>
<abstract>
<t indent="0">This document describes a method for invoking and ru
nning the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) s
ession as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6242"/>
<seriesInfo name="DOI" value="10.17487/RFC6242"/>
</reference>
<reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6
991" quoteTitle="true" derivedAnchor="RFC6991">
<front>
<title>Common YANG Data Types</title>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="July"/>
<abstract>
<t indent="0">This document introduces a collection of common data
types to be used with the YANG data modeling language. This document obsoletes
RFC 6021.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6991"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference>
<reference anchor="RFC7130" target="https://www.rfc-editor.org/info/rfc7
130" quoteTitle="true" derivedAnchor="RFC7130">
<front>
<title>Bidirectional Forwarding Detection (BFD) on Link Aggregation
Group (LAG) Interfaces</title>
<author initials="M." surname="Bhatia" fullname="M. Bhatia" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Chen" fullname="M. Chen" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Boutros" fullname="S. Boutros" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Binderberger" fullname="M. Binderberg
er" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Haas" fullname="J. Haas" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="February"/>
<abstract>
<t indent="0">This document defines a mechanism to run Bidirection
al Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. It do
es so by running an independent Asynchronous mode BFD session on every LAG membe
r link.</t>
<t indent="0">This mechanism allows the verification of member lin
k continuity, either in combination with, or in absence of, Link Aggregation Con
trol Protocol (LACP). It provides a shorter detection time than what LACP offer
s. The continuity check can also cover elements of Layer 3 (L3) bidirectional f
orwarding.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7130"/>
<seriesInfo name="DOI" value="10.17487/RFC7130"/>
</reference>
<reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
040" quoteTitle="true" derivedAnchor="RFC8040">
<front>
<title>RESTCONF Protocol</title>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="January"/>
<abstract>
<t indent="0">This document describes an HTTP-based protocol that
provides a programmatic interface for accessing data defined in YANG, using the
datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8040"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>
<reference anchor="RFC8177" target="https://www.rfc-editor.org/info/rfc8
177" quoteTitle="true" derivedAnchor="RFC8177">
<front>
<title>YANG Data Model for Key Chains</title>
<author initials="A." surname="Lindem" fullname="A. Lindem" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Qu" fullname="Y. Qu">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Yeung" fullname="D. Yeung">
<organization showOnFrontPage="true"/>
</author>
<author initials="I." surname="Chen" fullname="I. Chen">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Zhang" fullname="J. Zhang">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="June"/>
<abstract>
<t indent="0">This document describes the key chain YANG data mode
l. Key chains are commonly used for routing protocol authentication and other a
pplications requiring symmetric keys. A key chain is a list containing one or m
ore elements containing a Key ID, key string, send/accept lifetimes, and the ass
ociated authentication or encryption algorithm. By properly overlapping the sen
d and accept lifetimes of multiple key chain elements, key strings and algorithm
s may be gracefully updated. By representing them in a YANG data model, key dis
tribution can be automated.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8177"/>
<seriesInfo name="DOI" value="10.17487/RFC8177"/>
</reference>
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8
340" quoteTitle="true" derivedAnchor="RFC8340">
<front>
<title>YANG Tree Diagrams</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Berger" fullname="L. Berger" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">This document captures the current syntax used in YA
NG module tree diagrams. The purpose of this document is to provide a single lo
cation for this definition. This syntax may be updated from time to time based
on the evolution of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
<reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8
341" quoteTitle="true" derivedAnchor="RFC8341">
<front>
<title>Network Configuration Access Control Model</title>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">The standardization of network configuration interfa
ces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF pr
otocol requires a structured and secure operating environment that promotes huma
n usability and multi-vendor interoperability. There is a need for standard mec
hanisms to restrict NETCONF or RESTCONF protocol access for particular users to
a preconfigured subset of all available NETCONF or RESTCONF protocol operations
and content. This document defines such an access control model.</t>
<t indent="0">This document obsoletes RFC 6536.</t>
</abstract>
</front>
<seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>
<reference anchor="RFC8343" target="https://www.rfc-editor.org/info/rfc8
343" quoteTitle="true" derivedAnchor="RFC8343">
<front>
<title>A YANG Data Model for Interface Management</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">This document defines a YANG data model for the mana
gement of network interfaces. It is expected that interface-type-specific data
models augment the generic interfaces data model defined in this document. The d
ata model includes definitions for configuration and system state (status inform
ation and counters for the collection of statistics).</t>
<t indent="0">The YANG data model in this document conforms to the
Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t>
<t indent="0">This document obsoletes RFC 7223.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8343"/>
<seriesInfo name="DOI" value="10.17487/RFC8343"/>
</reference>
<reference anchor="RFC8344" target="https://www.rfc-editor.org/info/rfc8
344" quoteTitle="true" derivedAnchor="RFC8344">
<front>
<title>A YANG Data Model for IP Management</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">This document defines a YANG data model for manageme
nt of IP implementations. The data model includes configuration and system stat
e.</t>
<t indent="0">The YANG data model in this document conforms to the
Network Management Datastore Architecture defined in RFC 8342.</t>
<t indent="0">This document obsoletes RFC 7277.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8344"/>
<seriesInfo name="DOI" value="10.17487/RFC8344"/>
</reference>
<reference anchor="RFC8349" target="https://www.rfc-editor.org/info/rfc8
349" quoteTitle="true" derivedAnchor="RFC8349">
<front>
<title>A YANG Data Model for Routing Management (NMDA Version)</titl
e>
<author initials="L." surname="Lhotka" fullname="L. Lhotka">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Qu" fullname="Y. Qu">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">This document specifies three YANG modules and one s
ubmodule. Together, they form the core routing data model that serves as a frame
work for configuring and managing a routing subsystem. It is expected that thes
e modules will be augmented by additional YANG modules defining data models for
control-plane protocols, route filters, and other functions. The core routing d
ata model provides common building blocks for such extensions -- routes, Routing
Information Bases (RIBs), and control-plane protocols.</t>
<t indent="0">The YANG modules in this document conform to the Net
work Management Datastore Architecture (NMDA). This document obsoletes RFC 8022
.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8349"/>
<seriesInfo name="DOI" value="10.17487/RFC8349"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport
Layer Security (TLS) protocol. TLS allows client/server applications to commun
icate over the Internet in a way that is designed to prevent eavesdropping, tamp
ering, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
r TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8960" target="https://www.rfc-editor.org/info/rfc8
960" quoteTitle="true" derivedAnchor="RFC8960">
<front>
<title>A YANG Data Model for MPLS Base</title>
<author initials="T." surname="Saad" fullname="T. Saad">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Raza" fullname="K. Raza">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Gandhi" fullname="R. Gandhi">
<organization showOnFrontPage="true"/>
</author>
<author initials="X." surname="Liu" fullname="X. Liu">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Beeram" fullname="V. Beeram">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="December"/>
<abstract>
<t indent="0">This document contains a specification of the MPLS b
ase YANG data model. The MPLS base YANG data model serves as a base framework fo
r configuring and managing an MPLS switching subsystem on an MPLS-enabled router
. It is expected that other MPLS YANG data models (e.g., MPLS Label Switched Pa
th (LSP) static, LDP, or RSVP-TE YANG data models) will augment the MPLS base YA
NG data model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8960"/>
<seriesInfo name="DOI" value="10.17487/RFC8960"/>
</reference>
<reference anchor="RFC9127" target="https://www.rfc-editor.org/info/rfc9
127" quoteTitle="true" derivedAnchor="RFC9127">
<front>
<title>YANG Data Model for Bidirectional Forwarding Detection (BFD)<
/title>
<author initials="R." surname="Rahman" fullname="R. Rahman">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Zheng" fullname="L. Zheng">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Jethanandani" fullname="M Jethanandan
i">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Pallagatti" fullname="S. Pallagatti">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Mirsky" fullname="G. Mirsky">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="October"/>
<abstract>
<t indent="0">This document defines a YANG data model
that can be used to configure and manage Bidirectional
Forwarding Detection (BFD).</t>
<t>The YANG modules in this document conform to the
Network Management Datastore Architecture (NMDA) (RFC
8342).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9127"/>
<seriesInfo name="DOI" value="10.17487/RFC9127"/>
</reference>
</references> </references>
<references pn="section-6.2"> <references>
<name slugifiedName="name-informative-references">Informative References <name>Informative References</name>
</name>
<reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3031.
031" quoteTitle="true" derivedAnchor="RFC3031"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.
<title>Multiprotocol Label Switching Architecture</title> xml"/>
<author initials="E." surname="Rosen" fullname="E. Rosen"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8529.
<organization showOnFrontPage="true"/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8530.
<author initials="A." surname="Viswanathan" fullname="A. Viswanathan xml"/>
"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8532.
<organization showOnFrontPage="true"/> xml"/>
</author>
<author initials="R." surname="Callon" fullname="R. Callon"> <reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2
<organization showOnFrontPage="true"/> 008/REC-xml-20081126">
</author>
<date year="2001" month="January"/>
<abstract>
<t indent="0">This document specifies the architecture for Multipr
otocol Label Switching (MPLS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031"/>
<seriesInfo name="DOI" value="10.17487/RFC3031"/>
</reference>
<reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8
342" quoteTitle="true" derivedAnchor="RFC8342">
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Shafer" fullname="P. Shafer">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Wilton" fullname="R. Wilton">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">Datastores are a fundamental concept binding the dat
a models written in the YANG data modeling language to network management protoc
ols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This docu
ment defines an architectural framework for datastores based on the experience g
ained with the initial simpler model, addressing requirements that were not well
supported in the initial model. This document updates RFC 7950.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>
<reference anchor="RFC8529" target="https://www.rfc-editor.org/info/rfc8
529" quoteTitle="true" derivedAnchor="RFC8529">
<front>
<title>YANG Data Model for Network Instances</title>
<author initials="L." surname="Berger" fullname="L. Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Hopps" fullname="C. Hopps">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Bogdanovic" fullname="D. Bogdanovic">
<organization showOnFrontPage="true"/>
</author>
<author initials="X." surname="Liu" fullname="X. Liu">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="March"/>
<abstract>
<t indent="0">This document defines a network instance module. Th
is module can be used to manage the virtual resource partitioning that may be pr
esent on a network device. Examples of common industry terms for virtual resour
ce partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switc
h Instances (VSIs).</t>
<t indent="0">The YANG data model in this document conforms to the
Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8529"/>
<seriesInfo name="DOI" value="10.17487/RFC8529"/>
</reference>
<reference anchor="RFC8530" target="https://www.rfc-editor.org/info/rfc8
530" quoteTitle="true" derivedAnchor="RFC8530">
<front>
<title>YANG Model for Logical Network Elements</title>
<author initials="L." surname="Berger" fullname="L. Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Hopps" fullname="C. Hopps">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Bogdanovic" fullname="D. Bogdanovic">
<organization showOnFrontPage="true"/>
</author>
<author initials="X." surname="Liu" fullname="X. Liu">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="March"/>
<abstract>
<t indent="0">This document defines a logical network element (LNE
) YANG module that is compliant with the Network Management Datastore Architectu
re (NMDA). This module can be used to manage the logical resource partitioning
that may be present on a network device. Examples of common industry terms for
logical resource partitioning are logical systems or logical routers. The YANG
model in this document conforms with NMDA as defined in RFC 8342.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8530"/>
<seriesInfo name="DOI" value="10.17487/RFC8530"/>
</reference>
<reference anchor="RFC8532" target="https://www.rfc-editor.org/info/rfc8
532" quoteTitle="true" derivedAnchor="RFC8532">
<front>
<title>Generic YANG Data Model for the Management of Operations, Adm
inistration, and Maintenance (OAM) Protocols That Use Connectionless Communicati
ons</title>
<author initials="D." surname="Kumar" fullname="D. Kumar">
<organization showOnFrontPage="true"/>
</author>
<author initials="Z." surname="Wang" fullname="Z. Wang">
<organization showOnFrontPage="true"/>
</author>
<author initials="Q." surname="Wu" fullname="Q. Wu" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Rahman" fullname="R. Rahman">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Raghavan" fullname="S. Raghavan">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="April"/>
<abstract>
<t indent="0">This document presents a base YANG Data model for th
e management of Operations, Administration, and Maintenance (OAM) protocols that
use connectionless communications. The data model is defined using the YANG da
ta modeling language, as specified in RFC 7950. It provides a technology-indepe
ndent abstraction of key OAM constructs for OAM protocols that use connectionles
s communication. The base model presented here can be extended to include techn
ology-specific details.</t>
<t indent="0">There are two key benefits of this approach: First,
it leads to uniformity between OAM protocols. Second, it supports both nested O
AM workflows (i.e., performing OAM functions at the same level or different leve
ls through a unified interface) as well as interactive OAM workflows (i.e., perf
orming OAM functions at the same level through a unified interface).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8532"/>
<seriesInfo name="DOI" value="10.17487/RFC8532"/>
</reference>
<reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2
008/REC-xml-20081126" quoteTitle="true" derivedAnchor="W3C.REC-xml-20081126">
<front> <front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title> <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray"> <author initials="T." surname="Bray" fullname="Tim Bray">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="J." surname="Paoli" fullname="Jean Paoli"> <author initials="J." surname="Paoli" fullname="Jean Paoli">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="M." surname="Sperberg-McQueen" fullname="Michael S perberg-McQueen"> <author initials="M." surname="Sperberg-McQueen" fullname="Michael S perberg-McQueen">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="E." surname="Maler" fullname="Eve Maler"> <author initials="E." surname="Maler" fullname="Eve Maler">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="F." surname="Yergeau" fullname="Francois Yergeau"> <author initials="F." surname="Yergeau" fullname="François Yergeau">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<date month="November" year="2008"/> <date month="November" year="2008"/>
</front> </front>
<refcontent>World Wide Web Consortium Recommendation REC-xml-20081126< /refcontent> <refcontent>World Wide Web Consortium Recommendation REC-xml-20081126< /refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="ECHO-CONFIG" numbered="true" toc="include" removeInRFC="fal <section anchor="ECHO-CONFIG">
se" pn="section-appendix.a"> <name>Echo Function Configuration Example</name>
<name slugifiedName="name-echo-function-configuration">Echo Function Confi <t>As mentioned in <xref target="IP-SH-CFG"/>, the mechanism to start
guration Example</name> and stop the Echo function, as defined in <xref target="RFC5880"/> and dis
<t indent="0" pn="section-appendix.a-1">As mentioned in <xref target="IP-S cussed in
H-CFG" format="default" sectionFormat="of" derivedContent="Section 2.1.2"/>, the <xref target="RFC5881"/>, is implementation specific. In this appendix, we
mechanism to start
and stop the Echo function, as defined in <xref target="RFC5880" format="d
efault" sectionFormat="of" derivedContent="RFC5880"/> and discussed in
<xref target="RFC5881" format="default" sectionFormat="of" derivedContent=
"RFC5881"/>, is implementation specific. In this appendix, we
provide an example of how the Echo function can be implemented via provide an example of how the Echo function can be implemented via
configuration.</t> configuration.</t>
<sourcecode type="yangtree" markers="false" pn="section-appendix.a-2"> <sourcecode type="yangtree">
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
</sourcecode> </sourcecode>
<section numbered="true" toc="include" removeInRFC="false" pn="section-app <section>
endix.a.1"> <name>Example YANG Module for BFD Echo Function Configuration</name>
<name slugifiedName="name-example-yang-module-for-bfd">Example YANG Modu <t>This appendix provides an example YANG module for
le for BFD Echo Function Configuration</name>
<t indent="0" pn="section-appendix.a.1-1">This appendix provides an exam
ple YANG module for
configuration of the BFD Echo function. It imports and augments configuration of the BFD Echo function. It imports and augments
"/routing/control-plane-protocols/control-plane-protocol" from "/routing/control-plane-protocols/control-plane-protocol" from
<xref target="RFC8349" format="default" sectionFormat="of" derivedConten t="RFC8349"/>, and it references <xref target="RFC5880" format="default" section Format="of" derivedContent="RFC5880"/>. <xref target="RFC8349"/>, and it references <xref target="RFC5880"/>.
</t> </t>
<sourcecode type="yang" markers="false" pn="section-appendix.a.1-2">
<sourcecode type="yang"><![CDATA[
module example-bfd-echo { module example-bfd-echo {
namespace "tag:example.com,2021: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 organization
"IETF BFD Working Group"; "IETF BFD Working Group";
contact contact
"WG Web: &lt;https://datatracker.ietf.org/wg/bfd/&gt; "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: &lt;mailto:rtg-bfd@ietf.org&gt; WG List: <mailto:rtg-bfd@ietf.org>
Editor: Reshad Rahman Editor: Reshad Rahman
<mailto:reshad@yahoo.com&gt; <mailto:reshad@yahoo.com&gt;
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:veronique_cheng@hotmail.com&gt; <mailto:veronique_cheng@hotmail.com&gt;
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com&gt;"; <mailto:mjethanandani@gmail.com&gt;";
description description
"This module contains an example YANG augmentation for "This module contains an example YANG augmentation for
configuration of the BFD Echo function. configuration of the BFD Echo function.
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject
the license terms contained in, the Revised BSD License set to the license terms contained in, the Revised BSD License
forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9127; see the This version of this YANG module is part of RFC 9127; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2021-09-03 { revision 2021-10-21 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding "RFC 9127: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
/* /*
* Groupings * Groupings
*/ */
skipping to change at line 3795 skipping to change at line 3013
description description
"Augmentation for the BFD Echo function."; "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;
} }
} }
} }
</sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe <section anchor="updates-since-rfc-9127" numbered="true">
ndix.b"> <name>Updates since RFC 9127</name>
<name slugifiedName="name-acknowledgments">Acknowledgments</name> <t>This document updates the 'ietf-bfd-types' module
<t indent="0" pn="section-appendix.b-1">We would like to thank <contact fu to define a new feature called 'client-base-cfg-parms and an
llname="Nobo Akiya"/> and 'if-feature' statement that conditionally includes definitions
<contact fullname="Jeff Haas"/> for their encouragement on this work. of parameters, such as 'multiplier' or
We would also like to thank <contact fullname="Tom Petch"/> for his
comments on the document. We would also like to thank
<contact fullname="Acee Lindem"/> for his guidance. Thanks also to
<contact fullname="Jürgen Schönwälder"/>, who was instrumental in improvin
g the YANG
modules.</t>
</section>
<section anchor="updates-since-rfc-9127" numbered="false" removeInRFC="false
" toc="include" pn="section-appendix.c">
<name slugifiedName="updates">Updates since RFC 9127</name>
<t>This version of the draft updates the 'ietf-bfd-types' module
to define a new feature called 'client-base-cfg-parms and a
'if-feature' statement that conditionally includes definition
of parameters such as 'multiplier' or
'desired-min-tx-interval'. The feature statement allows 'desired-min-tx-interval'. The feature statement allows
YANG implementations of protocol such as OSPF, ISIS, PIM YANG implementations of protocols, such as OSPF, IS-IS, PIM,
and BGP, to support both a model where such parameters are and BGP, to support both a model where such parameters are
not needed, such as when multiple BFD sessions are supported not needed, such as when multiple BFD sessions are supported
over a given interface, as well as when they need to be over a given interface, as well as when they need to be
defined per session. As a result, the BFD MPLS module has to defined per session. As a result, the BFD MPLS module has to
use the base-cfg-parms instead of client-cfg-parms to be able use the base-cfg-parms instead of client-cfg-parms to be able
to include all the parameters unconditionally. to include all the parameters unconditionally.
</t> </t>
<t>The <t>The
iana-bfd-types module, created in RFC 9127, was delegated to iana-bfd-types module, created in RFC 9127, was delegated to
IANA for maintenance. No changes are requested from IANA as IANA for maintenance. No changes are requested from IANA as
part of this update. part of this update.
</t> </t>
</section> </section>
</back> <section numbered="false">
<name>Acknowledgments</name>
<t>We would like to thank <contact fullname="Nobo Akiya"/> and
<contact fullname="Jeff Haas"/> for their encouragement on this work.
We would also like to thank <contact fullname="Tom Petch"/> for his
comments on the document. We would also like to thank
<contact fullname="Acee Lindem"/> for his guidance. Thanks also to
<contact fullname="Jürgen Schönwälder"/>, who was instrumental in improvin
g the YANG
modules.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 209 change blocks. 
1925 lines changed or deleted 672 lines changed or added

This html diff was produced by rfcdiff 1.48.