draft-ietf-bfd-yang-17.txt   draft-ietf-bfd-yang-18.txt 
skipping to change at line 12 skipping to change at line 12
Internet Engineering Task Force (IETF) R. Rahman, Ed. Internet Engineering Task Force (IETF) R. Rahman, Ed.
Request for Comments: 0000 Request for Comments: 0000
Category: Standards Track L. Zheng, Ed. Category: Standards Track L. Zheng, Ed.
ISSN: 2070-1721 Huawei Technologies ISSN: 2070-1721 Huawei Technologies
M. Jethanandani, Ed. M. Jethanandani, Ed.
Xoriant Corporation Xoriant Corporation
S. Pallagatti S. Pallagatti
RtBrick RtBrick
G. Mirsky G. Mirsky
ZTE Corporation ZTE Corporation
November 2020 August 2021
YANG Data Model for Bidirectional Forwarding Detection (BFD) YANG Data Model for Bidirectional Forwarding Detection (BFD)
Abstract Abstract
This document defines a YANG data model that can be used to configure This document defines a YANG data model that can be used to configure
and manage Bidirectional Forwarding Detection (BFD). and manage Bidirectional Forwarding Detection (BFD).
The YANG modules in this document conform to the Network Management The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA) (RFC 8342). Datastore Architecture (NMDA) (RFC 8342).
skipping to change at line 40 skipping to change at line 40
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc0000. https://www.rfc-editor.org/info/rfc0000.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at line 62 skipping to change at line 62
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Tree Diagrams 1.1. Tree Diagrams
2. Design of the Data Model 2. Design of the Data Model
2.1. Design of the Configuration Model 2.1. Design of the Configuration Model
2.1.1. Common BFD Configuration Parameters 2.1.1. Common BFD Configuration Parameters
2.1.2. Single-Hop IP 2.1.2. Single-Hop IP
2.1.3. Multihop IP 2.1.3. Multihop IP
2.1.4. MPLS Traffic Engineering Tunnels 2.1.4. MPLS Label Switched Paths
2.1.5. MPLS Label Switched Paths 2.1.5. Link Aggregation Groups
2.1.6. Link Aggregation Groups
2.2. Design of the Operational State Model 2.2. Design of the Operational State Model
2.3. Notifications 2.3. Notifications
2.4. RPC Operations 2.4. RPC Operations
2.5. BFD Top-Level Hierarchy 2.5. BFD Top-Level Hierarchy
2.6. BFD IP Single-Hop Hierarchy 2.6. BFD IP Single-Hop Hierarchy
2.7. BFD IP Multihop Hierarchy 2.7. BFD IP Multihop Hierarchy
2.8. BFD-over-LAG Hierarchy 2.8. BFD-over-LAG Hierarchy
2.9. BFD-over-MPLS-LSPs Hierarchy 2.9. BFD-over-MPLS-LSPs Hierarchy
2.10. BFD-over-MPLS-TE Hierarchy 2.10. Interaction with Other YANG Modules
2.11. Interaction with Other YANG Modules 2.10.1. "ietf-interfaces" Module
2.11.1. "ietf-interfaces" Module 2.10.2. "ietf-ip" Module
2.11.2. "ietf-ip" Module 2.10.3. "ietf-mpls" Module
2.11.3. "ietf-mpls" Module 2.11. IANA BFD YANG Module
2.11.4. "ietf-te" Module 2.12. BFD Types YANG Module
2.12. IANA BFD YANG Module 2.13. BFD Top-Level YANG Module
2.13. BFD Types YANG Module 2.14. BFD IP Single-Hop YANG Module
2.14. BFD Top-Level YANG Module 2.15. BFD IP Multihop YANG Module
2.15. BFD IP Single-Hop YANG Module 2.16. BFD-over-LAG YANG Module
2.16. BFD IP Multihop YANG Module 2.17. BFD-over-MPLS YANG Module
2.17. BFD-over-LAG YANG Module
2.18. BFD-over-MPLS YANG Module
2.19. BFD-over-MPLS-TE YANG Module
3. Data Model Examples 3. Data Model Examples
3.1. IP Single-Hop 3.1. IP Single-Hop
3.2. IP Multihop 3.2. IP Multihop
3.3. LAG 3.3. LAG
3.4. MPLS 3.4. MPLS
4. Security Considerations 4. Security Considerations
5. IANA Considerations 5. IANA Considerations
5.1. IANA-Maintained "iana-bfd-types" Module 5.1. IANA-Maintained "iana-bfd-types" Module
6. References 6. References
6.1. Normative References 6.1. Normative References
skipping to change at line 156 skipping to change at line 152
This document uses the graphical representation of data models, as This document uses the graphical representation of data models, as
defined in [RFC8340]. defined in [RFC8340].
2. Design of the Data Model 2. Design of the Data Model
Since BFD is used for liveness detection of various forwarding paths, Since BFD is used for liveness detection of various forwarding paths,
there is no uniform key to identify a BFD session, and so the BFD 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-TE is in another single-hop is in one YANG module, and BFD for MPLS is in another YANG
YANG module. The main difference between these modules is how a BFD module. The main difference between these modules is how a BFD
session is uniquely identified, i.e., the key for the list containing session is uniquely identified, i.e., the key for the list containing
the BFD sessions for that forwarding path. To avoid duplication of the BFD sessions for that forwarding path. To avoid duplication of
BFD definitions, we have common types and groupings that are used by BFD definitions, we have common types and groupings that are used by
all the modules. all the modules.
A new control-plane protocol, "bfdv1", is defined, and a "bfd" A new control-plane protocol, "bfdv1", is defined, and a "bfd"
container is created under "control-plane-protocol" as specified in container is created under "control-plane-protocol" as specified in
"A YANG Data Model for Routing Management (NMDA Version)" [RFC8349]. "A YANG Data Model for Routing Management (NMDA Version)" [RFC8349].
This new "bfd" container is augmented by the following YANG modules This new "bfd" container is augmented by the following YANG modules
for their respective specific information: for their respective specific information:
1. The "ietf-bfd-ip-sh" module (Section 2.15) augments "/routing/ 1. The "ietf-bfd-ip-sh" module (Section 2.14) augments "/routing/
control-plane-protocols/control-plane-protocol/bfd/" with the control-plane-protocols/control-plane-protocol/bfd/" with the
"ip-sh" container for BFD sessions over IP single-hop. "ip-sh" container for BFD sessions over IP single-hop.
2. The "ietf-bfd-ip-mh" module (Section 2.16) augments "/routing/ 2. The "ietf-bfd-ip-mh" module (Section 2.15) augments "/routing/
control-plane-protocols/control-plane-protocol/bfd/" with the control-plane-protocols/control-plane-protocol/bfd/" with the
"ip-mh" container for BFD sessions over IP multihop. "ip-mh" container for BFD sessions over IP multihop.
3. The "ietf-bfd-lag" module (Section 2.17) augments "/routing/ 3. The "ietf-bfd-lag" module (Section 2.16) augments "/routing/
control-plane-protocols/control-plane-protocol/bfd/" with the control-plane-protocols/control-plane-protocol/bfd/" with the
"lag" container for BFD sessions over a LAG. "lag" container for BFD sessions over a LAG.
4. The "ietf-bfd-mpls" module (Section 2.18) augments "/routing/ 4. The "ietf-bfd-mpls" module (Section 2.17) augments "/routing/
control-plane-protocols/control-plane-protocol/bfd/" with the control-plane-protocols/control-plane-protocol/bfd/" with the
"mpls" container for BFD-over-MPLS LSPs. "mpls" container for BFD-over-MPLS LSPs.
5. The "ietf-bfd-mpls-te" module (Section 2.19) augments "/routing/
control-plane-protocols/control-plane-protocol/bfd/" with the
"mpls-te" container for BFD over MPLS-TE.
BFD can operate in the following contexts: BFD can operate in the following contexts:
1. At the network device level. 1. At the network device level.
2. In logical network elements (LNEs) as described in "YANG Model 2. In logical network elements (LNEs) as described in "YANG Model
for Logical Network Elements" [RFC8530]. for Logical Network Elements" [RFC8530].
3. In network instances as described in "YANG Data Model for Network 3. In network instances as described in "YANG Data Model for Network
Instances" [RFC8529]. Instances" [RFC8529].
skipping to change at line 229 skipping to change at line 221
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 clients requirements of the BFD client. Configuration of BFD for all clients
should be centralized. However, this is a problem for BFD clients should be centralized. However, this is a problem for BFD clients
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 and the IGP peers are auto-discovered. So, for an operator to
configure BFD to an IGP peer, the operator would first have to configure BFD to an IGP peer, the operator would first have to
determine the peer addresses. And when a new peer is discovered, BFD determine the peer addresses. And when a new peer is discovered, BFD
configuration would need to be added. To avoid this issue, we define configuration would need to be added. To avoid this issue, we define
the grouping "client-cfg-parms" in Section 2.13 for BFD clients to the grouping "client-cfg-parms" in Section 2.12 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 an 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 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 peer. The mechanism for how the BFD sessions are created and removed
by the BFD clients is outside the scope of this document, but this by the BFD clients is outside the scope of this document, but this
would typically be done by using an API implemented by the BFD module would typically be done by using an API implemented by the BFD module
on the system. In the case of BFD clients that create BFD sessions on the system. In the case of BFD clients that create BFD sessions
via their own configuration, authentication parameters (if required) via their own configuration, authentication parameters (if required)
skipping to change at line 262 skipping to change at line 254
required-min-rx-interval required-min-rx-interval
This is the Required Min RX Interval as defined in BFD [RFC5880]. This is the Required Min RX Interval as defined in BFD [RFC5880].
Although BFD [RFC5880] allows for different values for transmit and Although BFD [RFC5880] allows for different values for transmit and
receive intervals, some implementations allow users to specify just receive intervals, some implementations allow users to specify just
one interval that is used for both transmit and receive intervals, or one interval that is used for both transmit and receive intervals, or
separate values for transmit and receive intervals. The BFD YANG separate values for transmit and receive intervals. The BFD YANG
data model supports this: there is a choice between "min-interval", data model supports this: there is a choice between "min-interval",
used for both transmit and receive intervals, and "desired-min-tx- used for both transmit and receive intervals, and "desired-min-tx-
interval" and "required-min-rx-interval". This is supported via the interval" and "required-min-rx-interval". This is supported via the
"base-cfg-parms" grouping (Section 2.13), which is used by the YANG "base-cfg-parms" grouping (Section 2.12), which is used by the YANG
modules for the various forwarding paths. modules for the various forwarding paths.
For BFD authentication, we have the following: For BFD authentication, we have the following:
key-chain key-chain
This is a reference to "key-chain" as defined in "YANG Data Model This is a reference to "key-chain" as defined in "YANG Data Model
for Key Chains" [RFC8177]. The keys, cryptographic algorithms, for Key Chains" [RFC8177]. The keys, cryptographic algorithms,
key lifetime, etc. are all defined in the "key-chain" model. key lifetime, etc. are all defined in the "key-chain" model.
meticulous meticulous
skipping to change at line 323 skipping to change at line 315
We use the configuration parameters defined in Section 2.1.1. We use the configuration parameters defined in Section 2.1.1.
This document also provides the following parameters: This document also provides the following parameters:
tx-ttl tx-ttl
TTL of outgoing BFD control packets. TTL of outgoing BFD control packets.
rx-ttl rx-ttl
Minimum TTL of incoming BFD control packets. Minimum TTL of incoming BFD control packets.
2.1.4. MPLS Traffic Engineering Tunnels 2.1.4. MPLS Label Switched Paths
For MPLS-TE tunnels, BFD is configured under the MPLS-TE tunnel,
since the desired failure detection parameters are a property of the
MPLS-TE tunnel. This is achieved by augmenting the MPLS-TE data
model in "A YANG Data Model for Traffic Engineering Tunnels, Label
Switched Paths, and Interfaces" [RFCYYY2]. In the case of BFD
parameters that are specific to the TE application, e.g., whether to
tear down the tunnel in the event of a BFD session failure, these
parameters will be defined in the YANG data model for the MPLS-TE
application.
In addition to the usual BFD parameters, we have the following per
MPLS-TE tunnel:
encap
Encapsulation for the BFD packets: a choice between IP, a Generic
Associated Channel (G-ACh), and IP with a G-ACh as per "MPLS
Generic Associated Channel" [RFC5586].
For general MPLS-TE data, an "mpls-te" data node is added under the
"bfd" node, as described in Section 2. Since some MPLS-TE tunnels
are unidirectional, there is no MPLS-TE configuration for these
tunnels on the egress node (note that this does not apply to
bidirectional MPLS-TP tunnels). The BFD parameters for the egress
node are added under "mpls-te".
2.1.5. MPLS Label Switched Paths
Here, we address MPLS LSPs whose Forwarding Equivalence Class (FEC) Here, we address MPLS LSPs whose Forwarding Equivalence Class (FEC)
[RFC3031] is an IP address. The "bfd" node (Section 2) is augmented [RFC3031] is an IP address. The "bfd" node (Section 2) 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". "session-group".
Since these LSPs are unidirectional, there is no LSP configuration on Since these LSPs are unidirectional, there is no LSP configuration on
the egress node. the egress node.
The BFD parameters for the egress node are added under "mpls". The BFD parameters for the egress node are added under "mpls".
2.1.6. Link Aggregation Groups 2.1.5. Link Aggregation Groups
Per "Bidirectional Forwarding Detection (BFD) on Link Aggregation Per "Bidirectional Forwarding Detection (BFD) on Link Aggregation
Group (LAG) Interfaces" [RFC7130], configuring BFD on a LAG consists Group (LAG) Interfaces" [RFC7130], configuring BFD on a LAG consists
of having micro-BFD sessions on each LAG member link. Since the BFD of having micro-BFD sessions on each LAG member link. Since the BFD
parameters are an attribute of the LAG, they should be under the LAG. parameters are an attribute of the LAG, they should be under the LAG.
However, there is no LAG YANG data model that we can augment. So, a However, there is no LAG YANG data model that we can augment. So, a
"lag" data node is added to the "bfd" node; see Section 2. The "lag" data node is added to the "bfd" node; see Section 2. The
configuration is per LAG: we have a list of LAGs. The destination IP configuration is per LAG: we have a list of LAGs. The destination IP
address of the micro-BFD sessions is configured per LAG and per address of the micro-BFD sessions is configured per LAG and per
address family (IPv4 and IPv6). address family (IPv4 and IPv6).
skipping to change at line 477 skipping to change at line 442
| +--rw (interval-config-type)? | +--rw (interval-config-type)?
| | +--:(tx-rx-intervals) | | +--:(tx-rx-intervals)
| | | +--rw desired-min-tx-interval? uint32 | | | +--rw desired-min-tx-interval? uint32
| | | +--rw required-min-rx-interval? uint32 | | | +--rw required-min-rx-interval? uint32
| | +--:(single-interval) {single-minimum-interval}? | | +--:(single-interval) {single-minimum-interval}?
| | +--rw min-interval? uint32 | | +--rw min-interval? uint32
| +--rw demand-enabled? boolean | +--rw demand-enabled? boolean
| | {demand-mode}? | | {demand-mode}?
| +--rw admin-down? boolean | +--rw admin-down? boolean
| +--rw authentication! {authentication}? | +--rw authentication! {authentication}?
| | +--rw key-chain? kc:key-chain-ref | | +--rw key-chain? key-chain:key-chain-ref
| | +--rw meticulous? boolean | | +--rw meticulous? boolean
| +--ro path-type? identityref | +--ro path-type? identityref
| +--ro ip-encapsulation? boolean | +--ro ip-encapsulation? boolean
| +--ro local-discriminator? discriminator | +--ro local-discriminator? discriminator
| +--ro remote-discriminator? discriminator | +--ro remote-discriminator? discriminator
| +--ro remote-multiplier? multiplier | +--ro remote-multiplier? multiplier
| +--ro demand-capability? boolean | +--ro demand-capability? boolean
| | {demand-mode}? | | {demand-mode}?
| +--ro source-port? inet:port-number | +--ro source-port? inet:port-number
| +--ro dest-port? inet:port-number | +--ro dest-port? inet:port-number
skipping to change at line 521 skipping to change at line 486
| | yang:date-and-time | | yang:date-and-time
| +--ro down-count? yang:counter32 | +--ro down-count? yang:counter32
| +--ro admin-down-count? yang:counter32 | +--ro admin-down-count? yang:counter32
| +--ro receive-packet-count? yang:counter64 | +--ro receive-packet-count? yang:counter64
| +--ro send-packet-count? yang:counter64 | +--ro send-packet-count? yang:counter64
| +--ro receive-invalid-packet-count? yang:counter64 | +--ro receive-invalid-packet-count? yang:counter64
| +--ro send-failed-packet-count? yang:counter64 | +--ro send-failed-packet-count? yang:counter64
+--rw interfaces* [interface] +--rw interfaces* [interface]
+--rw interface if:interface-ref +--rw interface if:interface-ref
+--rw authentication! {authentication}? +--rw authentication! {authentication}?
+--rw key-chain? kc:key-chain-ref +--rw key-chain? key-chain:key-chain-ref
+--rw meticulous? boolean +--rw meticulous? boolean
notifications: notifications:
+---n singlehop-notification +---n singlehop-notification
+--ro local-discr? discriminator +--ro local-discr? discriminator
+--ro remote-discr? discriminator +--ro remote-discr? discriminator
+--ro new-state? state +--ro new-state? state
+--ro state-change-reason? iana-bfd-types:diagnostic +--ro state-change-reason? iana-bfd-types:diagnostic
+--ro time-of-last-state-change? yang:date-and-time +--ro time-of-last-state-change? yang:date-and-time
+--ro dest-addr? inet:ip-address +--ro dest-addr? inet:ip-address
skipping to change at line 571 skipping to change at line 536
+--rw (interval-config-type)? +--rw (interval-config-type)?
| +--:(tx-rx-intervals) | +--:(tx-rx-intervals)
| | +--rw desired-min-tx-interval? uint32 | | +--rw desired-min-tx-interval? uint32
| | +--rw required-min-rx-interval? uint32 | | +--rw required-min-rx-interval? uint32
| +--:(single-interval) {single-minimum-interval}? | +--:(single-interval) {single-minimum-interval}?
| +--rw min-interval? uint32 | +--rw min-interval? uint32
+--rw demand-enabled? boolean +--rw demand-enabled? boolean
| {demand-mode}? | {demand-mode}?
+--rw admin-down? boolean +--rw admin-down? boolean
+--rw authentication! {authentication}? +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| +--rw meticulous? boolean | +--rw meticulous? boolean
+--rw tx-ttl? bfd-types:hops +--rw tx-ttl? bfd-types:hops
+--rw rx-ttl bfd-types:hops +--rw rx-ttl bfd-types:hops
+--ro sessions* [] +--ro sessions* []
+--ro path-type? identityref +--ro path-type? identityref
+--ro ip-encapsulation? boolean +--ro ip-encapsulation? boolean
+--ro local-discriminator? discriminator +--ro local-discriminator? discriminator
+--ro remote-discriminator? discriminator +--ro remote-discriminator? discriminator
+--ro remote-multiplier? multiplier +--ro remote-multiplier? multiplier
+--ro demand-capability? boolean {demand-mode}? +--ro demand-capability? boolean {demand-mode}?
skipping to change at line 673 skipping to change at line 638
+--rw (interval-config-type)? +--rw (interval-config-type)?
| +--:(tx-rx-intervals) | +--:(tx-rx-intervals)
| | +--rw desired-min-tx-interval? uint32 | | +--rw desired-min-tx-interval? uint32
| | +--rw required-min-rx-interval? uint32 | | +--rw required-min-rx-interval? uint32
| +--:(single-interval) {single-minimum-interval}? | +--:(single-interval) {single-minimum-interval}?
| +--rw min-interval? uint32 | +--rw min-interval? uint32
+--rw demand-enabled? boolean +--rw demand-enabled? boolean
| {demand-mode}? | {demand-mode}?
+--rw admin-down? boolean +--rw admin-down? boolean
+--rw authentication! {authentication}? +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| +--rw meticulous? boolean | +--rw meticulous? boolean
+--rw use-ipv4? boolean +--rw use-ipv4? boolean
+--rw use-ipv6? boolean +--rw use-ipv6? boolean
+--ro member-links* [member-link] +--ro member-links* [member-link]
+--ro member-link if:interface-ref +--ro member-link if:interface-ref
+--ro micro-bfd-ipv4 +--ro micro-bfd-ipv4
| +--ro path-type? identityref | +--ro path-type? identityref
| +--ro ip-encapsulation? boolean | +--ro ip-encapsulation? boolean
| +--ro local-discriminator? discriminator | +--ro local-discriminator? discriminator
| +--ro remote-discriminator? discriminator | +--ro remote-discriminator? discriminator
skipping to change at line 816 skipping to change at line 781
+--rw egress +--rw egress
| +--rw enabled? boolean | +--rw enabled? boolean
| +--rw local-multiplier? multiplier | +--rw local-multiplier? multiplier
| +--rw (interval-config-type)? | +--rw (interval-config-type)?
| | +--:(tx-rx-intervals) | | +--:(tx-rx-intervals)
| | | +--rw desired-min-tx-interval? uint32 | | | +--rw desired-min-tx-interval? uint32
| | | +--rw required-min-rx-interval? uint32 | | | +--rw required-min-rx-interval? uint32
| | +--:(single-interval) {single-minimum-interval}? | | +--:(single-interval) {single-minimum-interval}?
| | +--rw min-interval? uint32 | | +--rw min-interval? uint32
| +--rw authentication! {authentication}? | +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| +--rw meticulous? boolean | +--rw meticulous? boolean
+--rw session-groups +--rw session-groups
+--rw session-group* [mpls-fec] +--rw session-group* [mpls-fec]
+--rw mpls-fec inet:ip-prefix +--rw mpls-fec inet:ip-prefix
+--rw local-multiplier? multiplier +--rw local-multiplier? multiplier
+--rw (interval-config-type)? +--rw (interval-config-type)?
| +--:(tx-rx-intervals) | +--:(tx-rx-intervals)
| | +--rw desired-min-tx-interval? uint32 | | +--rw desired-min-tx-interval? uint32
| | +--rw required-min-rx-interval? uint32 | | +--rw required-min-rx-interval? uint32
| +--:(single-interval) {single-minimum-interval}? | +--:(single-interval) {single-minimum-interval}?
| +--rw min-interval? uint32 | +--rw min-interval? uint32
+--rw demand-enabled? boolean +--rw demand-enabled? boolean
| {demand-mode}? | {demand-mode}?
+--rw admin-down? boolean +--rw admin-down? boolean
+--rw authentication! {authentication}? +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| +--rw meticulous? boolean | +--rw meticulous? boolean
+--ro sessions* [] +--ro sessions* []
+--ro path-type? identityref +--ro path-type? identityref
+--ro ip-encapsulation? boolean +--ro ip-encapsulation? boolean
+--ro local-discriminator? discriminator +--ro local-discriminator? discriminator
+--ro remote-discriminator? discriminator +--ro remote-discriminator? discriminator
+--ro remote-multiplier? multiplier +--ro remote-multiplier? multiplier
+--ro demand-capability? boolean {demand-mode}? +--ro demand-capability? boolean {demand-mode}?
+--ro source-port? inet:port-number +--ro source-port? inet:port-number
+--ro dest-port? inet:port-number +--ro dest-port? inet:port-number
skipping to change at line 894 skipping to change at line 859
+--ro remote-discr? discriminator +--ro remote-discr? discriminator
+--ro new-state? state +--ro new-state? state
+--ro state-change-reason? iana-bfd-types:diagnostic +--ro state-change-reason? iana-bfd-types:diagnostic
+--ro time-of-last-state-change? yang:date-and-time +--ro time-of-last-state-change? yang:date-and-time
+--ro dest-addr? inet:ip-address +--ro dest-addr? inet:ip-address
+--ro source-addr? inet:ip-address +--ro source-addr? inet:ip-address
+--ro session-index? uint32 +--ro session-index? uint32
+--ro path-type? identityref +--ro path-type? identityref
+--ro mpls-dest-address? inet:ip-address +--ro mpls-dest-address? inet:ip-address
2.10. BFD-over-MPLS-TE Hierarchy 2.10. Interaction with Other YANG Modules
The "/te/tunnels/tunnel" node as defined in "A YANG Data Model for
Traffic Engineering Tunnels, Label Switched Paths, and Interfaces"
[RFCYYY2] is augmented. BFD is configured per MPLS-TE tunnel, and
BFD session operational state data is provided per MPLS-TE LSP.
module: ietf-bfd-mpls-te
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd:
+--rw mpls-te
+--rw egress
| +--rw enabled? boolean
| +--rw local-multiplier? multiplier
| +--rw (interval-config-type)?
| | +--:(tx-rx-intervals)
| | | +--rw desired-min-tx-interval? uint32
| | | +--rw required-min-rx-interval? uint32
| | +--:(single-interval) {single-minimum-interval}?
| | +--rw min-interval? uint32
| +--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref
| +--rw meticulous? boolean
+--ro summary
+--ro number-of-sessions? yang:gauge32
+--ro number-of-sessions-up? yang:gauge32
+--ro number-of-sessions-down? yang:gauge32
+--ro number-of-sessions-admin-down? yang:gauge32
augment /te:te/te:tunnels/te:tunnel:
+--rw local-multiplier? multiplier
+--rw (interval-config-type)?
| +--:(tx-rx-intervals)
| | +--rw desired-min-tx-interval? uint32
| | +--rw required-min-rx-interval? uint32
| +--:(single-interval) {single-minimum-interval}?
| +--rw min-interval? uint32
+--rw demand-enabled? boolean {demand-mode}?
+--rw admin-down? boolean
+--rw authentication! {authentication}?
| +--rw key-chain? kc:key-chain-ref
| +--rw meticulous? boolean
+--rw encap? identityref
augment /te:te/te:lsps/te:lsp:
+--ro path-type? identityref
+--ro ip-encapsulation? boolean
+--ro local-discriminator? discriminator
+--ro remote-discriminator? discriminator
+--ro remote-multiplier? multiplier
+--ro demand-capability? boolean {demand-mode}?
+--ro source-port? inet:port-number
+--ro dest-port? inet:port-number
+--ro session-running
| +--ro session-index? uint32
| +--ro local-state? state
| +--ro remote-state? state
| +--ro local-diagnostic? iana-bfd-types:diagnostic
| +--ro remote-diagnostic? iana-bfd-types:diagnostic
| +--ro remote-authenticated? boolean
| +--ro remote-authentication-type? iana-bfd-types:auth-type
| | {authentication}?
| +--ro detection-mode? enumeration
| +--ro negotiated-tx-interval? uint32
| +--ro negotiated-rx-interval? uint32
| +--ro detection-time? uint32
| +--ro echo-tx-interval-in-use? uint32 {echo-mode}?
+--ro session-statistics
| +--ro create-time? yang:date-and-time
| +--ro last-down-time? yang:date-and-time
| +--ro last-up-time? yang:date-and-time
| +--ro down-count? yang:counter32
| +--ro admin-down-count? yang:counter32
| +--ro receive-packet-count? yang:counter64
| +--ro send-packet-count? yang:counter64
| +--ro receive-invalid-packet-count? yang:counter64
| +--ro send-failed-packet-count? yang:counter64
+--ro mpls-dest-address? inet:ip-address
notifications:
+---n mpls-te-notification
+--ro local-discr? discriminator
+--ro remote-discr? discriminator
+--ro new-state? state
+--ro state-change-reason? iana-bfd-types:diagnostic
+--ro time-of-last-state-change? yang:date-and-time
+--ro dest-addr? inet:ip-address
+--ro source-addr? inet:ip-address
+--ro session-index? uint32
+--ro path-type? identityref
+--ro mpls-dest-address? inet:ip-address
+--ro tunnel-name? string
2.11. Interaction with Other YANG Modules
"Generic YANG Data Model for the Management of Operations, "Generic YANG Data Model for the Management of Operations,
Administration, and Maintenance (OAM) Protocols That Use Administration, and Maintenance (OAM) Protocols That Use
Connectionless Communications" [RFC8532] describes how the Layer- Connectionless Communications" [RFC8532] describes how the Layer-
Independent OAM Management in the Multi-Layer Environment (LIME) Independent OAM Management in the Multi-Layer Environment (LIME)
connectionless OAM model could be extended to support BFD. connectionless OAM model could be extended to support BFD.
Also, the operation of the BFD data model depends on configuration Also, the operation of the BFD data model depends on configuration
parameters that are defined in other YANG modules. parameters that are defined in other YANG modules.
2.11.1. "ietf-interfaces" Module 2.10.1. "ietf-interfaces" Module
The following boolean configuration is defined in "A YANG Data Model The following boolean configuration is defined in "A YANG Data Model
for Interface Management" [RFC8343]: for Interface Management" [RFC8343]:
/if:interfaces/if:interface/if:enabled /if:interfaces/if:interface/if:enabled
If this configuration is set to "false", no BFD packets can be If this configuration is set to "false", no BFD packets can be
transmitted or received on that interface. transmitted or received on that interface.
2.11.2. "ietf-ip" Module 2.10.2. "ietf-ip" Module
The following boolean configuration is defined in "A YANG Data Model The following boolean configuration is defined in "A YANG Data Model
for IP Management" [RFC8344]: for IP Management" [RFC8344]:
/if:interfaces/if:interface/ip:ipv4/ip:enabled /if:interfaces/if:interface/ip:ipv4/ip:enabled
If this configuration is set to "false", no BFD IPv4 packets can If this configuration is set to "false", no BFD IPv4 packets can
be transmitted or received on that interface. be transmitted or received on that interface.
/if:interfaces/if:interface/ip:ipv4/ip:forwarding /if:interfaces/if:interface/ip:ipv4/ip:forwarding
If this configuration is set to "false", no BFD IPv4 packets can If this configuration is set to "false", no BFD IPv4 packets can
be transmitted or received on that interface. be transmitted or received on that interface.
/if:interfaces/if:interface/ip:ipv6/ip:enabled /if:interfaces/if:interface/ip:ipv6/ip:enabled
If this configuration is set to "false", no BFD IPv6 packets can If this configuration is set to "false", no BFD IPv6 packets can
be transmitted or received on that interface. be transmitted or received on that interface.
/if:interfaces/if:interface/ip:ipv6/ip:forwarding /if:interfaces/if:interface/ip:ipv6/ip:forwarding
If this configuration is set to "false", no BFD IPv6 packets can If this configuration is set to "false", no BFD IPv6 packets can
be transmitted or received on that interface. be transmitted or received on that interface.
2.11.3. "ietf-mpls" Module 2.10.3. "ietf-mpls" Module
The following boolean configuration is defined in "A YANG Data Model The following boolean configuration is defined in "A YANG Data Model
for MPLS Base" [RFCYYY1]: for MPLS Base" [RFC8960]:
/rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/ /rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/
mpls:mpls-enabled mpls:mpls-enabled
If this configuration is set to "false", no BFD MPLS packets can If this configuration is set to "false", no BFD MPLS packets can
be transmitted or received on that interface. be transmitted or received on that interface.
2.11.4. "ietf-te" Module 2.11. IANA BFD YANG Module
The following configuration is defined in the "ietf-te" YANG module
provided in "A YANG Data Model for Traffic Engineering Tunnels, Label
Switched Paths, and Interfaces" [RFCYYY2]:
/ietf-te:te/ietf-te:tunnels/ietf-te:tunnel/ietf-te:admin-state
If this configuration is not set to "tunnel-admin-state-up", no
BFD MPLS packets can be transmitted or received on that tunnel.
2.12. IANA BFD YANG Module
This YANG module imports typedefs from [RFC5880] and references This YANG module imports typedefs from [RFC5880] and references
[RFC6428]. [RFC6428].
<CODE BEGINS> file "iana-bfd-types@2018-08-01.yang" <CODE BEGINS> file "iana-bfd-types@2021-04-08.yang"
module iana-bfd-types { module iana-bfd-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-bfd-types"; namespace "urn:ietf:params:xml:ns:yang:iana-bfd-types";
prefix "iana-bfd-types"; prefix "iana-bfd-types";
organization "IANA"; organization "IANA";
contact contact
"Internet Assigned Numbers Authority "Internet Assigned Numbers Authority
skipping to change at line 1078 skipping to change at line 942
<mailto:iana@iana.org>"; <mailto:iana@iana.org>";
description description
"This module defines YANG data types for IANA-registered "This module defines YANG data types for IANA-registered
BFD parameters. BFD parameters.
This YANG module is maintained by IANA and reflects the This YANG module is maintained by IANA and reflects the
'BFD Diagnostic Codes' and 'BFD Authentication Types' 'BFD Diagnostic Codes' and 'BFD Authentication Types'
registries. registries.
Copyright (c) 2020 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 to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified 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 0000; see the This version of this YANG module is part of RFC 0000; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
reference reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2018-08-01 { revision 2021-04-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
/* /*
* Type definitions * Type definitions
*/ */
skipping to change at line 1205 skipping to change at line 1069
description description
"Keyed SHA1."; "Keyed SHA1.";
} }
enum meticulous-keyed-sha1 { enum meticulous-keyed-sha1 {
value 5; value 5;
description description
"Meticulous Keyed SHA1."; "Meticulous Keyed SHA1.";
} }
} }
description description
"BFD authentication types as defined in RFC 5880. Values are "BFD authentication type as defined in RFC 5880. Values are
maintained in the 'BFD Authentication Types' IANA registry. maintained in the 'BFD Authentication Types' IANA registry.
Range is 0 to 255."; Range is 0 to 255.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection (BFD)"; "RFC 5880: Bidirectional Forwarding Detection (BFD)";
} }
} }
<CODE ENDS> <CODE ENDS>
2.13. BFD Types YANG Module 2.12. BFD Types YANG Module
This YANG module imports typedefs from [RFC6991] and [RFC8177]. It This YANG module imports typedefs from [RFC6991] and [RFC8177]. It
also imports definitions from [RFC5880], [RFC5881], [RFC5883], also imports definitions from [RFC5880], [RFC5881], [RFC5883],
[RFC5884], and [RFC7130], as well as the "control-plane-protocol" [RFC5884], and [RFC7130], as well as the "control-plane-protocol"
identity from [RFC8349]. identity from [RFC8349].
<CODE BEGINS> file "ietf-bfd-types@2019-11-19.yang" <CODE BEGINS> file "ietf-bfd-types@2021-04-08.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 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
skipping to change at line 1280 skipping to change at line 1144
<mailto:vero.zheng@huawei.com> <mailto:vero.zheng@huawei.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) 2020 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 to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified 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 0000; see the This version of this YANG module is part of RFC 0000; 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 0000: YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2019-11-19 { revision 2021-04-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
/* /*
* Feature definitions * Feature definitions
*/ */
skipping to change at line 1483 skipping to change at line 1347
if-feature authentication; if-feature authentication;
presence presence
"Enables BFD authentication (see Section 6.7 of RFC 5880)."; "Enables BFD authentication (see Section 6.7 of RFC 5880).";
description description
"Parameters for BFD authentication."; "Parameters for BFD authentication.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection (BFD), "RFC 5880: Bidirectional Forwarding Detection (BFD),
Section 6.7"; Section 6.7";
leaf key-chain { leaf key-chain {
type kc:key-chain-ref; type key-chain:key-chain-ref;
description description
"Name of the 'key-chain' as per RFC 8177."; "Name of the 'key-chain' as per RFC 8177.";
} }
leaf meticulous { leaf meticulous {
type boolean; type boolean;
description description
"Enables a meticulous mode as per Section 6.7 of "Enables a meticulous mode as per Section 6.7 of
RFC 5880."; RFC 5880.";
} }
skipping to change at line 1903 skipping to change at line 1767
type identityref { type identityref {
base path-type; base path-type;
} }
description description
"BFD path type."; "BFD path type.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
2.14. BFD Top-Level YANG Module 2.13. BFD Top-Level YANG Module
This YANG module imports and augments "/routing/control-plane- This YANG module imports and augments "/routing/control-plane-
protocols/control-plane-protocol" from [RFC8349]. It also references protocols/control-plane-protocol" from [RFC8349]. It also references
[RFC5880]. [RFC5880].
<CODE BEGINS> file "ietf-bfd@2018-08-01.yang" <CODE BEGINS> file "ietf-bfd@2021-04-08.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 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
skipping to change at line 1949 skipping to change at line 1813
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:vero.zheng@huawei.com> <mailto:vero.zheng@huawei.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) 2020 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 to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified 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 0000; see the This version of this YANG module is part of RFC 0000; 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 0000: YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2018-08-01 { revision 2021-04-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: 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')" {
skipping to change at line 1995 skipping to change at line 1859
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;
} }
} }
} }
<CODE ENDS> <CODE ENDS>
2.15. BFD IP Single-Hop YANG Module 2.14. BFD IP Single-Hop YANG Module
This YANG module imports "interface-ref" from [RFC8343] and typedefs This YANG module imports "interface-ref" from [RFC8343] and typedefs
from [RFC6991]. It also imports and augments "/routing/control- from [RFC6991]. It also imports and augments "/routing/control-
plane-protocols/control-plane-protocol" from [RFC8349], and it plane-protocols/control-plane-protocol" from [RFC8349], and it
references [RFC5881]. references [RFC5881].
<CODE BEGINS> file "ietf-bfd-ip-sh@2018-08-01.yang" <CODE BEGINS> file "ietf-bfd-ip-sh@2021-04-08.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 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
skipping to change at line 2061 skipping to change at line 1925
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:vero.zheng@huawei.com> <mailto:vero.zheng@huawei.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) 2020 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 to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified 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 0000; see the This version of this YANG module is part of RFC 0000; 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 0000: YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2018-08-01 { revision 2021-04-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
/* /*
* Augments * Augments
*/ */
skipping to change at line 2170 skipping to change at line 2034
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.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
2.16. BFD IP Multihop YANG Module 2.15. BFD IP Multihop YANG Module
This YANG module imports typedefs from [RFC6991]. It also imports This YANG module imports typedefs from [RFC6991]. It also imports
and augments "/routing/control-plane-protocols/control-plane- and augments "/routing/control-plane-protocols/control-plane-
protocol" from [RFC8349], and it references [RFC5883]. protocol" from [RFC8349], and it references [RFC5883].
<CODE BEGINS> file "ietf-bfd-ip-mh@2018-08-01.yang" <CODE BEGINS> file "ietf-bfd-ip-mh@2021-04-08.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 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
skipping to change at line 2229 skipping to change at line 2093
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:vero.zheng@huawei.com> <mailto:vero.zheng@huawei.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) 2020 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 to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified 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 0000; see the This version of this YANG module is part of RFC 0000; 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 0000: YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2018-08-01 { revision 2021-04-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
/* /*
* Augments * Augments
*/ */
skipping to change at line 2332 skipping to change at line 2196
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;
} }
} }
<CODE ENDS> <CODE ENDS>
2.17. BFD-over-LAG YANG Module 2.16. BFD-over-LAG YANG Module
This YANG module imports "interface-ref" from [RFC8343] and typedefs This YANG module imports "interface-ref" from [RFC8343] and typedefs
from [RFC6991]. It also imports and augments "/routing/control- from [RFC6991]. It also imports and augments "/routing/control-
plane-protocols/control-plane-protocol" from [RFC8349]. plane-protocols/control-plane-protocol" from [RFC8349].
Additionally, it references [RFC7130]. Additionally, it references [RFC7130].
<CODE BEGINS> file "ietf-bfd-lag@2018-08-01.yang" <CODE BEGINS> file "ietf-bfd-lag@2021-04-08.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 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
skipping to change at line 2398 skipping to change at line 2262
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:vero.zheng@huawei.com> <mailto:vero.zheng@huawei.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) 2020 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 to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified 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 0000; see the This version of this YANG module is part of RFC 0000; 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 0000: YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2018-08-01 { revision 2021-04-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
/* /*
* Augments * Augments
*/ */
skipping to change at line 2544 skipping to change at line 2408
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.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
2.18. BFD-over-MPLS YANG Module 2.17. BFD-over-MPLS YANG Module
This YANG module imports typedefs from [RFC6991]. It also imports This YANG module imports typedefs from [RFC6991]. It also imports
and augments "/routing/control-plane-protocols/control-plane- and augments "/routing/control-plane-protocols/control-plane-
protocol" from [RFC8349]. Additionally, it references [RFC5586] and protocol" from [RFC8349]. Additionally, it references [RFC5586] and
[RFC5884]. [RFC5884].
<CODE BEGINS> file "ietf-bfd-mpls@2018-08-01.yang" <CODE BEGINS> file "ietf-bfd-mpls@2021-04-08.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 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
skipping to change at line 2604 skipping to change at line 2468
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:vero.zheng@huawei.com> <mailto:vero.zheng@huawei.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) 2020 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 to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified 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 0000; see the This version of this YANG module is part of RFC 0000; 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 0000: YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
revision 2018-08-01 { revision 2021-04-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
/* /*
* Identity definitions * Identity definitions
*/ */
skipping to change at line 2756 skipping to change at line 2620
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.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
2.19. BFD-over-MPLS-TE YANG Module
This YANG module imports and augments "/routing/control-plane-
protocols/control-plane-protocol" from [RFC8349]. It also imports
and augments "/te/tunnels/tunnel" from [RFCYYY2], and it references
[RFC5884].
<CODE BEGINS> file "ietf-bfd-mpls-te@2018-08-01.yang"
module ietf-bfd-mpls-te {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te";
prefix "bfd-mpls-te";
import ietf-bfd-types {
prefix "bfd-types";
reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
}
import ietf-bfd {
prefix "bfd";
reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
}
import ietf-bfd-mpls {
prefix "bfd-mpls";
reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
}
import ietf-te {
prefix "te";
reference
"RFC YYY2: A YANG Data Model for Traffic Engineering Tunnels,
Label Switched Paths, and Interfaces";
}
import ietf-routing {
prefix "rt";
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
organization "IETF BFD Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <mailto:rtg-bfd@ietf.org>
Editor: Reshad Rahman
<mailto:reshad@yahoo.com>
Editor: Lianshu Zheng
<mailto:vero.zheng@huawei.com>
Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>";
description
"This module contains the YANG definition for BFD parameters for
MPLS Traffic Engineering as per RFC 5884.
Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 0000; see the
RFC itself for full legal notices.";
reference
"RFC 5884: Bidirectional Forwarding Detection (BFD)
for MPLS Label Switched Paths (LSPs)
RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
revision 2018-08-01 {
description
"Initial revision.";
reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
}
/*
* Augments
*/
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd" {
description
"BFD augmentation for MPLS-TE.";
container mpls-te {
description
"BFD MPLS-TE top-level container.";
container egress {
description
"Egress configuration.";
uses bfd-types:client-cfg-parms;
uses bfd-types:auth-parms;
}
uses bfd-types:session-statistics-summary;
}
}
augment "/te:te/te:tunnels/te:tunnel" {
description
"BFD configuration on the MPLS-TE tunnel.";
uses bfd-types:common-cfg-parms;
uses bfd-mpls:encap-cfg;
}
augment "/te:te/te:lsps/te:lsp" {
when "/te:te/te:lsps/te:lsp/te:origin-type != 'transit'" {
description
"BFD information not needed at transit points.";
}
description
"BFD state information on the MPLS-TE LSP.";
uses bfd-types:all-session;
uses bfd-mpls:mpls-dest-address;
}
/*
* Notifications
*/
notification mpls-te-notification {
description
"Notification for BFD-over-MPLS-TE session state change.
An implementation may rate-limit notifications, e.g., when a
session is continuously changing state.";
uses bfd-types:notification-parms;
uses bfd-mpls:mpls-dest-address;
leaf tunnel-name {
type string;
description
"MPLS-TE tunnel on which BFD was running.";
}
}
}
<CODE ENDS>
3. Data Model Examples 3. Data Model Examples
This section presents some simple and illustrative examples of how to This section presents some simple and illustrative examples of how to
configure BFD. configure BFD.
The examples are represented in XML [W3C.REC-xml-20081126]. The examples are represented in XML [W3C.REC-xml-20081126].
3.1. IP Single-Hop 3.1. IP Single-Hop
The following is an example configuration for a BFD IP single-hop The following is an example configuration for a BFD IP single-hop
skipping to change at line 3170 skipping to change at line 2871
/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/
egress: egress:
Data nodes "local-multiplier", "desired-min-tx-interval", Data nodes "local-multiplier", "desired-min-tx-interval",
"required-min-rx-interval", and "min-interval" all impact the BFD- "required-min-rx-interval", and "min-interval" all impact the BFD-
over-MPLS-LSPs sessions for which this device is an MPLS LSP over-MPLS-LSPs sessions for which this device is an MPLS LSP
egress node. Authentication data nodes "key-chain" and egress node. Authentication data nodes "key-chain" and
"meticulous" impact the security of the BFD-over-MPLS-LSPs "meticulous" impact the security of the BFD-over-MPLS-LSPs
sessions for which this device is an MPLS LSP egress node. sessions for which this device is an MPLS LSP egress node.
/te/tunnels/tunnel:
Data nodes "local-multiplier", "desired-min-tx-interval",
"required-min-rx-interval", and "min-interval" all impact the BFD
session over the MPLS-TE tunnel. Authentication data nodes "key-
chain" and "meticulous" impact the security of the BFD session
over the MPLS-TE tunnel.
/routing/control-plane-protocols/control-plane-protocol/bfd/mpls-
te/egress:
Data nodes "local-multiplier", "desired-min-tx-interval",
"required-min-rx-interval", and "min-interval" all impact the BFD-
over-MPLS-TE sessions for which this device is an MPLS-TE egress
node. Authentication data nodes "key-chain" and "meticulous"
impact the security of the BFD-over-MPLS-TE sessions for which
this device is an MPLS-TE egress node.
The YANG modules have writable data nodes that can be used for the The YANG modules have writable data nodes that can be used for the
creation of BFD sessions and the modification of BFD session creation of BFD sessions and the modification of BFD session
parameters. The system should "police" the creation of BFD sessions parameters. The system should "police" the creation of BFD sessions
to prevent new sessions from causing existing BFD sessions to fail. to prevent new sessions from causing existing BFD sessions to fail.
In the case of BFD session modification, the BFD protocol has In the case of BFD session modification, the BFD protocol has
mechanisms in place that allow for in-service modification. mechanisms in place that allow for in-service modification.
When BFD clients are used to modify BFD configuration (as described When BFD clients are used to modify BFD configuration (as described
in Section 2.1), the BFD clients need to be included in an analysis in Section 2.1), the BFD clients need to be included in an analysis
of the security properties of the system that uses BFD (e.g., when of the security properties of the system that uses BFD (e.g., when
skipping to change at line 3281 skipping to change at line 2966
state. The counters include BFD sessions for which the user does state. The counters include BFD sessions for which the user does
not have read access. not have read access.
/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/
session-groups/session-group/sessions: session-groups/session-group/sessions:
Access to data nodes "local-discriminator" and "remote- Access to data nodes "local-discriminator" and "remote-
discriminator" (combined with the data nodes in the session discriminator" (combined with the data nodes in the session
group's authentication container) provides the ability to spoof group's authentication container) provides the ability to spoof
BFD-over-MPLS-LSPs packets. BFD-over-MPLS-LSPs packets.
/routing/control-plane-protocols/control-plane-protocol/bfd/mpls-
te/summary:
Access to this information discloses the number of BFD sessions
over MPLS-TE that are in the "up", "down", or "admin-down" state.
The counters include BFD sessions for which the user does not have
read access.
/te/lsps/lsp:
Access to data nodes "local-discriminator" and "remote-
discriminator" (combined with the data nodes in the tunnel's
authentication container) provides the ability to spoof BFD-over-
MPLS-TE packets.
5. IANA Considerations 5. IANA Considerations
This document registers the following namespace URIs in the "IETF XML This document registers the following namespace URIs in the "IETF XML
Registry" [RFC3688]: Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:iana-bfd-types URI: urn:ietf:params:xml:ns:yang:iana-bfd-types
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-bfd-types URI: urn:ietf:params:xml:ns:yang:ietf-bfd-types
skipping to change at line 3327 skipping to change at line 2999
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-bfd-lag URI: urn:ietf:params:xml:ns:yang:ietf-bfd-lag
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document registers the following YANG modules in the "YANG This document registers the following YANG modules in the "YANG
Module Names" registry [RFC6020]: Module Names" registry [RFC6020]:
Name: iana-bfd-types Name: iana-bfd-types
Namespace: urn:ietf:params:xml:ns:yang:iana-bfd-types Namespace: urn:ietf:params:xml:ns:yang:iana-bfd-types
Prefix: iana-bfd-types Prefix: iana-bfd-types
Reference: RFC 0000 Reference: RFC 0000
Name: ietf-bfd-types Name: ietf-bfd-types
Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-types Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-types
skipping to change at line 3369 skipping to change at line 3037
Name: ietf-bfd-lag Name: ietf-bfd-lag
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
Reference: RFC 0000 Reference: RFC 0000
Name: ietf-bfd-mpls Name: ietf-bfd-mpls
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
Reference: RFC 0000 Reference: RFC 0000
Name: ietf-bfd-mpls-te
Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te
Prefix: bfd-mpls-te
Reference: RFC 0000
5.1. IANA-Maintained "iana-bfd-types" Module 5.1. IANA-Maintained "iana-bfd-types" Module
This document defines the initial version of the IANA-maintained This document defines the initial version of the IANA-maintained
"iana-bfd-types" YANG module. "iana-bfd-types" YANG module.
The "iana-bfd-types" YANG module mirrors the "BFD Diagnostic Codes" The "iana-bfd-types" YANG module mirrors the "BFD Diagnostic Codes"
and "BFD Authentication Types" registries at and "BFD Authentication Types" registries at
<https://www.iana.org/assignments/bfd-parameters/>. Whenever these <https://www.iana.org/assignments/bfd-parameters/>. Whenever these
registries change, IANA must update the "iana-bfd-types" YANG module. registries change, IANA must update the "iana-bfd-types" YANG module.
skipping to change at line 3485 skipping to change at line 3148
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018, DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>. <https://www.rfc-editor.org/info/rfc8349>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFCYYY1] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A [RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A
YANG Data Model for MPLS Base", RFC YYY1, YANG Data Model for MPLS Base", RFC 8960,
DOI 10.17487/RFCYYY1, November 2020, DOI 10.17487/RFC8960, December 2020,
<https://www.rfc-editor.org/rfc/rfcYYY1>. <https://www.rfc-editor.org/info/rfc8960>.
[RFCYYY2] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"A YANG Data Model for Traffic Engineering Tunnels, Label
Switched Paths, and Interfaces", RFC YYY2,
DOI 10.17487/RFCYYY2, November 2020,
<https://www.rfc-editor.org/rfc/rfcYYY2>.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126>. <https://www.w3.org/TR/2008/REC-xml-20081126>.
6.2. Informative References 6.2. Informative References
skipping to change at line 3561 skipping to change at line 3218
+--rw required-min-echo-rx-interval? uint32 +--rw required-min-echo-rx-interval? uint32
A.1. Example YANG Module for BFD Echo Function Configuration A.1. Example YANG Module for BFD Echo Function Configuration
This appendix provides an example YANG module for configuration of This appendix provides an example YANG module for configuration of
the BFD Echo function. It imports and augments "/routing/control- the BFD Echo function. It imports and augments "/routing/control-
plane-protocols/control-plane-protocol" from [RFC8349], and it plane-protocols/control-plane-protocol" from [RFC8349], and it
references [RFC5880]. references [RFC5880].
module example-bfd-echo { module example-bfd-echo {
namespace "tag:example.com,2018:example-bfd-echo"; namespace "tag:example.com,2021:example-bfd-echo";
prefix "example-bfd-echo"; prefix "example-bfd-echo";
import ietf-bfd-types { import ietf-bfd-types {
prefix "bfd-types"; prefix "bfd-types";
} }
import ietf-bfd { import ietf-bfd {
prefix "bfd"; prefix "bfd";
} }
skipping to change at line 3600 skipping to change at line 3257
Editor: Lianshu Zheng Editor: Lianshu Zheng
<mailto:vero.zheng@huawei.com> <mailto:vero.zheng@huawei.com>
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>"; <mailto:mjethanandani@gmail.com>";
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) 2020 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 to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified 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 0000; see the This version of this YANG module is part of RFC 0000; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2018-08-01 { revision 2021-04-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional Forwarding
Detection (BFD)"; Detection (BFD)";
} }
/* /*
* Groupings * Groupings
*/ */
skipping to change at line 3668 skipping to change at line 3325
"BFD Echo function container."; "BFD Echo function container.";
uses echo-cfg-parms; uses echo-cfg-parms;
} }
} }
} }
Acknowledgments Acknowledgments
We would like to thank Nobo Akiya and Jeff Haas for their We would like to thank Nobo Akiya and Jeff Haas for their
encouragement on this work. We would also like to thank Rakesh encouragement on this work. We would also like to thank Tom Petch
Gandhi and Tarek Saad for their help on the MPLS-TE model. We would for his comments on the document. We would also like to thank Acee
also like to thank Acee Lindem for his guidance. Thanks also to Lindem for his guidance. Thanks also to Juergen Schoenwaelder, who
Juergen Schoenwaelder, who was instrumental in improving the YANG was instrumental in improving the YANG modules.
modules.
Authors' Addresses Authors' Addresses
Reshad Rahman (editor) Reshad Rahman (editor)
Canada Canada
Email: reshad@yahoo.com Email: reshad@yahoo.com
Lianshu Zheng (editor) Lianshu Zheng (editor)
Huawei Technologies Huawei Technologies
 End of changes. 65 change blocks. 
421 lines changed or deleted 77 lines changed or added

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