YANG Data Model for Bidirectional Forwarding
Detection (BFD)Cisco SystemsCanadarrahman@cisco.comHuawei TechnologiesChinavero.zheng@huawei.comXoriant Corporation1248 Reamwood AveSunnyvaleCalifornia94089USAmjethanandani@gmail.comIndiasantosh.pallagatti@gmail.comZTE Corporationgregimirsky@gmail.comThis document defines a YANG data model that can be used to configure
and manage Bidirectional Forwarding Detection (BFD).The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA).This document defines a YANG data model that can be used to configure
and manage Bidirectional Forwarding Detection (BFD) . BFD is a network protocol which is used
for liveness detection of arbitrary paths between systems. Some examples
of different types of paths over which we have BFD:1) Two systems directly connected via IP. This is known as BFD over
single-hop IP, a.k.a. BFD for IPv4 and IPv6
2) Two systems connected via multiple hops as described in BFD for Multiple Hops.3) Two systems connected via MPLS Label Switched Paths (LSPs) as
described in BFD for MPLS LSP 4) Two systems connected via a Link Aggregation Group (LAG) interface
as described in BFD on LAG Interfaces 5) Two systems connected via pseudowires (PWs), this is known as
Virtual Circuit Connectivity Verification (VCCV) as described in BFD for PW VCCV . This is not addressed in this
document.BFD typically does not operate on its own. Various control protocols,
also known as BFD clients, use the services provided by BFD for their
own operation as described in Generic Application
of BFD . The obvious candidates which use BFD are those which do
not have "hellos" to detect failures, e.g. static routes, and routing
protocols whose "hellos" do not support sub-second failure detection,
e.g. OSPF and IS-IS.The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA) Network Management Datastore
Architecture . This means that the data models do not have
separate top-level or sibling containers for configuration and
operational state data.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 when, and only when, they
appear in all capitals, as shown here.This document uses the graphical representation of data models defined in
.Since BFD is used for liveliness detection of various forwarding
paths, there is no uniform key to identify a BFD session. So the BFD
data model is split in multiple YANG modules where each module
corresponds to one type of forwarding path. For example, BFD for IP
single-hop is in one YANG module and BFD for MPLS-TE is in another YANG
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
sessions for that forwarding path. To avoid duplication of BFD
definitions, we have common types and groupings which are used by all
the modules.A new control-plane protocol "bfdv1" is defined and a "bfd" container
is created under control-plane-protocol as specified in "A YANG Data Model for Routing
Management (NMDA Version)". This new "bfd" container is augmented
by all the YANG modules for their respective specific information:ietf-bfd-ip-sh.yang augments
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with
the "ip-sh" container for BFD sessions over IP single-hop.ietf-bfd-ip-mh.yang augments
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with
the "ip-mh" container for BFD sessions over IP multi-hop.ietf-bfd-lag.yang augments
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with
the "lag" container for BFD sessions over LAG.ietf-bfd-mpls.yang augments
"/routing/control-plane-protocols/control-plane-protocol/bfd/" with
the "mpls" container for BFD over MPLS LSPs.ietf-bfd-mpls-te.yang 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: At the network device levelIn Logical Network Elements as described in YANG Logical Network
ElementIn Network Instances as described in YANG Logical Network
Element When used at the network device level, the BFD YANG model is
used "as-is". When the BFD YANG model is used in a Logical Network
Element or in a Network Instance, then the BFD YANG model augments
the mounted routing model for the Logical Network Element or the
Network Instance.The configuration model consists mainly of the parameters specified
in BFD. Some examples are desired
minimum transmit interval, required minimum receive interval,
detection multiplier, etcBFD clients are applications that use BFD for fast detection of
failures. Some implementations have BFD session configuration under
the BFD clients. For example, BFD session configuration under routing
applications such as OSPF, IS-IS, BGP etc. Other implementations have
BFD session configuration centralized under BFD, i.e. outside the
multiple BFD clients.The BFD parameters of interest to a BFD client are mainly the
multiplier and interval(s) since those parameters impact the
convergence time of the BFD clients when a failure occurs. Other
parameters such as BFD authentication are not specific to the
requirements of the BFD client. Ideally all configuration should be
centralized under BFD. However, this is a problem for clients of BFD
which auto-discover their peers. For example, IGPs do not have the
peer address configured, instead the IGP is enabled on an interface
and the IGP peers are auto-discovered. So for an operator to configure
BFD to an IGP peer, the operator would first have to determine the
peer addresses. And when a new peer is discovered, BFD configuration
would need to be added. To avoid this issue, we define grouping
client-cfg-parms in for BFD clients to
configure BFD: this allows BFD clients such as the IGPs to have
configuration (multiplier and intervals) for the BFD sessions they
need. For example, when a new IGP peer is discovered, the IGP would
create a BFD session to the newly discovered peer and similarly when
an IGP peer goes away, the IGP would remove the BFD session to that
peer. The mechanism how the BFD sessions are created and removed by
the BFD clients is outside the scope of this document, but typically
this would be done by use of an API implemented by the BFD module on
the system. For BFD clients which create BFD sessions via their own
configuration, authentication parameters (if required) are still
specified in BFD.The basic BFD configuration parameters are: This is the detection
time multiplier as defined in BFD.This is the
Desired Min TX Interval as defined in BFD.This is the
Required Min RX Interval as defined in BFD.Although BFD allows for
different values for transmit and receive intervals, some
implementations allow users to specify just one interval which is
used for both transmit and receive intervals or separate values for
transmit and receive intervals. The BFD YANG model supports this:
there is a choice between "min-interval", used for both transmit and
receive intervals, and "desired-min-tx-interval" and
"required-min-rx-interval". This is supported via a grouping which
is used by the YANG modules for the various forwarding paths.For BFD authentication we have: This is a reference to
key-chain defined in YANG Data Model for
Key Chains . The keys, cryptographic algorithms, key
lifetime etc are all defined in the key-chain model.This enables meticulous mode
as per BFD .For single-hop IP, there is an augment of the "bfd" data node in
. The "ip-sh" node contains a list of IP
single-hop sessions where each session is uniquely identified by the
interface and destination address pair. For the configuration
parameters we use what is defined in . The "ip-sh" node also contains a list of
interfaces, this is used to specify authentication parameters for
BFD sessions which are created by BFD clients, see . and do not
specify whether echo function is continuous or on demand. Therefore
the mechanism used to start and stop echo function is implementation
specific and should be done by augmentation: 1) Configuration. This is suitable for continuous echo
function. An example is provided in .2) RPC. This is suitable for on-demand echo function.For multihop IP, there is an augment of the "bfd" data node in
.Because of multiple paths, there could be multiple multihop IP
sessions between a source and a destination address. We identify
this as a "session-group". The key for each "session-group" consists
of: Address belonging to the
local system as per BFD for Multiple Hops
Address belonging to
the remote system as per BFD for Multiple
Hops For the configuration parameters we use what is defined in Here are some extra parameters: TTL of outgoing BFD control
packets.Minimum TTL of incoming BFD
control packets.For MPLS-TE tunnels, BFD is configured under the MPLS-TE tunnel
since the desired failure detection parameters is a property of the
MPLS-TE tunnel. This is achieved by augmenting the MPLS-TE data
model in YANG Data Model for TE
Topologies . For BFD parameters which are specific to the TE
application, e.g. whether to tear down the tunnel in the event of a
BFD session failure, these parameters will be defined in the YANG
model of the MPLS-TE application.On top of the usual BFD parameters, we have the following per
MPLS-TE tunnel: Encapsulation for the BFD packets:
choice between IP, G-ACh and IP with G-ACh as per MPLS Generic Associated Channel For general MPLS-TE data, "mpls-te" data node is added under the
"bfd" node in . Since some MPLS-TE
tunnels are uni-directional there is no MPLS-TE configuration for
these tunnels on the egress node (note that this does not apply to
bi-directional MPLS-TP tunnels). The BFD parameters for the egress
node are added under "mpls-te".Here we address MPLS LSPs whose FEC is an IP address. The "bfd"
node in is augmented with "mpls" which
contains a list of sessions uniquely identified by an IP prefix.
Because of multiple paths, there could be multiple MPLS sessions to
an MPLS FEC. We identify this as a "session-group".Since these LSPs are uni-directional there is no LSP
configuration on the egress node.The BFD parameters for the egress node are added under
"mpls".Per BFD on LAG Interfaces ,
configuring BFD on LAG consists 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. However there is no LAG YANG
model which we can augment. So a "lag" data node is added to the
"bfd" node in , the configuration is
per-LAG: we have a list of LAGs. The destination IP address of the
micro-BFD sessions is configured per-LAG and per address-family
(IPv4 and IPv6)The operational state model contains both the overall statistics of
BFD sessions running on the device and the per session operational
information.The overall statistics of BFD sessions consist of number of BFD
sessions, number of BFD sessions up etc. This information is available
globally (i.e. for all BFD sessions) under the "bfd" node in and also per type of forwarding path.For each BFD session, mainly three categories of operational state
data are shown. The fundamental information of a BFD session such as
the local discriminator, remote discriminator and the capability of
supporting demand detect mode are shown in the first category. The
second category includes a BFD session running information, e.g. the
remote BFD state and the diagnostic code received. Another example is
the actual transmit interval between the control packets, which may be
different from the desired minimum transmit interval configured, is
shown in this category. Similar examples are actual received interval
between the control packets and the actual transmit interval between
the echo packets. The third category contains the detailed statistics
of the session, e.g. when the session transitioned up/down and how
long it has been in that state.For some path types, there may be more than 1 session on the
virtual path to the destination. For example, with IP multihop and
MPLS LSPs, there could be multiple BFD sessions from the source to the
same destination to test the various paths (ECMP) to the destination.
This is represented by having multiple "sessions" under each
"session-group".This YANG model defines notifications to inform end-users of
important events detected during the protocol operation. Pair of local
and remote discriminator identifies a BFD session on local system.
Notifications also give more important details about BFD sessions;
e.g. new state, time in previous state, network-instance and the
reason that the BFD session state changed. The notifications are
defined for each type of forwarding path but use groupings for common
information.None.At the "bfd" node under control-plane-protocol, there is no
configuration data, only operational state data. The operational state
data consist of overall BFD session statistics, i.e. for BFD on all
types of forwarding paths.An "ip-sh" node is added under "bfd" node in
control-plane-protocol. The configuration and operational state data
for each BFD IP single-hop session is under this "ip-sh" node.An "ip-mh" node is added under the "bfd" node in
cntrol-plane-protocol. The configuration and operational state data
for each BFD IP multihop session is under this "ip-mh" node. In the
operational state model we support multiple BFD multihop sessions per
remote address (ECMP), the local discriminator is used as key.A "lag" node is added under the "bfd" node in
control-plane-protocol. The configuration and operational state data
for each BFD LAG session is under this "lag" node.An "mpls" node is added under the "bfd" node in
control-plane-protocol. The configuration is per MPLS FEC under this
"mpls" node. In the operational state model we support multiple BFD
sessions per MPLS FEC (ECMP), the local discriminator is used as key.
The "mpls" node can be used in a network device (top-level), or
mounted in an LNE or in a network instance.YANG Data Model for TE
Topologies is augmented. BFD is configured per MPLS-TE tunnel,
and BFD session operational state data is provided per MPLS-TE
LSP.Generic YANG
Data Model for Connectionless OAM protocols describes how the
LIME connectionless OAM model could be extended to support BFD.Also, the operation of the BFD data model depends on configuration
parameters that are defined in other YANG modules.The following boolean configuration is defined in A YANG Data Model for Interface
Management : If
this configuration is set to "false", no BFD packets can be
transmitted or received on that interface.The following boolean configuration is defined in A YANG Data Model for IP
Management : If
this configuration is set to "false", no BFD IPv4 packets can be
transmitted or received on that interface.If
this configuration is set to "false", no BFD IPv4 packets can be
transmitted or received on that interface.If
this configuration is set to "false", no BFD IPv6 packets can be
transmitted or received on that interface.If
this configuration is set to "false", no BFD IPv6 packets can be
transmitted or received on that interface.The following boolean configuration is defined in A YANG Data Model for MPLS Base
: If
this configuration is set to "false", no BFD MPLS packets can be
transmitted or received on that interface.The following configuration is defined in the "ietf-te" YANG
module YANG Data Model for TE
Topology : If
this configuration is not set to "state-up", no BFD MPLS packets
can be transmitted or received on that tunnel.This YANG module imports typedefs from , and
the "control-plane-protocol" identity from .This YANG module imports and augments
"/routing/control-plane-protocols/control-plane-protocol" from .This YANG module imports "interface-ref" from , typedefs from and augments
"/routing/control-plane-protocols/control-plane-protocol" from .This YANG module imports typedefs from and augments
"/routing/control-plane-protocols/control-plane-protocol" from .This YANG module imports "interface-ref" from , typedefs from and augments
"/routing/control-plane-protocols/control-plane-protocol" from .This YANG module imports typedefs from and augments
"/routing/control-plane-protocols/control-plane-protocol" from .This YANG module imports and augments "/te/tunnels/tunnel" from
.This section presents some simple and illustrative examples on how to
configure BFD.The following is an example configuration for a BFD IP single-hop
session. The desired transmit interval and the required receive
interval are both set to 10ms.The following is an example configuration for a BFD IP multihop
session group. The desired transmit interval and the required receive
interval are both set to 150ms.The following is an example of BFD configuration for a LAG session.
In this case, an interface named "Bundle-Ether1" of interface type
"ieee802eadLag" has a desired transmit and required receive interval
set to 10ms. The following is an example of BFD configured for an MPLS LSP. In
this case, the desired transmit and required receive interval set to
250ms.The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such as
NETCONF or RESTCONF .
The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS .The NETCONF access control model provides
the means to restrict access for particular NETCONF or RESTCONF users to
a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., edit-config) to these data
nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessions:
the list specifies the IP single-hop BFD sessions./routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessions:
data nodes local-multiplier, desired-min-tx-interval,
required-min-rx-interval, min-interval and authentication all impact the
BFD IP single-hop session./routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/session-group:
the list specifies the IP multi-hop BFD session groups./routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/session-group:
data nodes local-multiplier, desired-min-tx-interval,
required-min-rx-interval, min-interval and authentication all impact the
BFD IP multi-hop session./routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions:
the list specifies the BFD sessions over LAG./routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions:
data nodes local-multiplier, desired-min-tx-interval,
required-min-rx-interval, min-interval and authentication all impact the
BFD over LAG session./routing/control-plane-protocols/control-plane-protocol/bfd/mpls/session-group:
the list specifies the session groups for BFD over MPLS./routing/control-plane-protocols/control-plane-protocol/bfd/mpls/session-group:
data nodes local-multiplier, desired-min-tx-interval,
required-min-rx-interval, min-interval and authentication all impact the
BFD over MPLS LSPs session./routing/control-plane-protocols/control-plane-protocol/bfd/mpls/egress:
data nodes local-multiplier, desired-min-tx-interval,
required-min-rx-interval, min-interval and authentication all impact the
BFD over MPLS LSPs 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, min-interval and
authentication all impact 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, min-interval and authentication all impact the
BFD over MPLS-TE sessions for which this device is an MPLS-TE egress
node.The YANG module has writeable data nodes which can be used for
creation of BFD sessions and modification of BFD session parameters. The
system should "police" creation of BFD sessions to prevent new sessions
from causing existing BFD sessions to fail. For BFD session
modification, the BFD protocol has mechanisms in place which allow for
in service modification.Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data nodes
and their sensitivity/vulnerability:/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/summary:
access to this information discloses the number of BFD IP single-hop
sessions which are up, down and admin-down. The counters include BFD
sessions for which the user does not have read-access./routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/summary:
access to this information discloses the number of BFD IP multi-hop
sessions which are up, down and admin-down. The counters include BFD
sessions for which the user does not have read-access./routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-bfd-ipv4-session-statistics/summary:
access to this information discloses the number of micro BFD IPv4 LAG
sessions which are up, down and admin-down. The counters include BFD
sessions for which the user does not have read-access./routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-bfd-ipv6-session-statistics/summary:
access to this information discloses the number of micro BFD IPv6 LAG
sessions which are up, down and admin-down. The counters include BFD
sessions for which the user does not have read-access./routing/control-plane-protocols/control-plane-protocol/bfd/mpls/summary:
access to this information discloses the number of BFD sessions over
MPLS LSPs which are up, down and admin-down. The counters include BFD
sessions for which the user does not have read-access./routing/control-plane-protocols/control-plane-protocol/bfd/mpls-te/summary:
access to this information discloses the number of BFD sessions over
MPLS-TE which are up, down and admin-down. The counters include BFD
sessions for which the user does not have read-access.This document registers the following namespace URIs in the IETF XML
registry :--------------------------------------------------------------------URI: urn:ietf:params:xml:ns:yang:iana-bfd-typesRegistrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.----------------------------------------------------------------------------------------------------------------------------------------URI: urn:ietf:params:xml:ns:yang:ietf-bfd-typesRegistrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.----------------------------------------------------------------------------------------------------------------------------------------URI: urn:ietf:params:xml:ns:yang:ietf-bfdRegistrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.----------------------------------------------------------------------------------------------------------------------------------------URI: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-shRegistrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.----------------------------------------------------------------------------------------------------------------------------------------URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mhRegistrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.----------------------------------------------------------------------------------------------------------------------------------------URI: urn:ietf:params:xml:ns:yang:ietf-bfd-lagRegistrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.----------------------------------------------------------------------------------------------------------------------------------------URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mplsRegistrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.----------------------------------------------------------------------------------------------------------------------------------------URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-teRegistrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.--------------------------------------------------------------------This document registers the following YANG modules in the YANG Module Names
registry :RFC Editor: Replace RFC XXXX with actual RFC number and remove this note.--------------------------------------------------------------------Name: iana-bfd-typesNamespace: urn:ietf:params:xml:ns:yang:iana-bfd-typesPrefix: iana-bfd-typesReference: RFC XXXX----------------------------------------------------------------------------------------------------------------------------------------Name: ietf-bfd-typesNamespace: urn:ietf:params:xml:ns:yang:ietf-bfd-typesPrefix: bfd-typesReference: RFC XXXX----------------------------------------------------------------------------------------------------------------------------------------Name: ietf-bfdNamespace: urn:ietf:params:xml:ns:yang:ietf-bfdPrefix: bfdReference: RFC XXXX----------------------------------------------------------------------------------------------------------------------------------------Name: ietf-bfd-ip-shNamespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-shPrefix: bfd-ip-shReference: RFC XXXX----------------------------------------------------------------------------------------------------------------------------------------Name: ietf-bfd-ip-mhNamespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mhPrefix: bfd-ip-mhReference: RFC XXXX----------------------------------------------------------------------------------------------------------------------------------------Name: ietf-bfd-lagNamespace: urn:ietf:params:xml:ns:yang:ietf-bfd-lagPrefix: bfd-lagReference: RFC XXXX----------------------------------------------------------------------------------------------------------------------------------------Name: ietf-bfd-mplsNamespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mplsPrefix: bfd-mplsReference: RFC XXXX----------------------------------------------------------------------------------------------------------------------------------------Name: ietf-bfd-mpls-teNamespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-tePrefix: bfd-mpls-teReference: RFC XXXX--------------------------------------------------------------------This document defines the initial version of the IANA-maintained
iana-bfd-types YANG module.The iana-bfd-types YANG module mirrors the "BFD
Diagnostic Codes" registry and "BFD Authentication Types" registry at
https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml.
Whenever that registry changes, IANA must update the iana-bfd-types YANG module.We would also like to thank Nobo Akiya and Jeff Haas for their
encouragement on this work. We would also like to thank Rakesh Gandhi
and Tarek Saad for their help on the MPLS-TE model. We would also like
to thank Acee Lindem for his guidance.As mentioned in , the mechanism to start
and stop the echo function, as defined in and
, is implementation specific. In this section we
provide an example of how the echo function can be implemented via
configuration.RFC Editor: Remove this section upon publication as an RFC.Added list of modules for YANG module registry.Added missing ietf-bfd-types in XML registry.Addressed missing/incorrect references in import statements.Updated references for drafts which became RFCs recently.Addressed comments from YANG Doctor review of rev11.Added 2 examples.Added a container around some lists.Fixed some indentation nits.Addressed comments from YANG Doctor review.Addressed comments from WGLC.Mostly cosmetic changes to abide by
draft-ietf-netmod-rfc6087bis.Specified yang-version 1.1.Added data model examples.Some minor changes.Timer intervals in client-cfg-parms are not mandatory
anymore.Added list of interfaces under "ip-sh" node for authentication
parameters.Renamed replay-protection to meticulous.New ietf-bfd-types module.Grouping for BFD clients to have BFD multiplier and interval
values.Change in ietf-bfd-mpls-te since MPLS-TE model changed.Removed bfd- prefix from many names.Adhere to NMDA-guidelines.Echo function config moved to appendix as example.Added IANA YANG modules.Addressed various comments."bfd" node in augment of control-plane-protocol.Removed augment of network-instance. Replaced by
schema-mount.Added information on interaction with other YANG modules.Updated author information.Fixed YANG compile error in ietf-bfd-lag.yang which was due to
incorrect when statement.Fixed YANG compilation warning due to incorrect revision date
in ietf-bfd-ip-sh module.Replace routing-instance with network-instance from YANG Network InstancesRemove BFD configuration parameters from BFD clients, all BFD
configuration parameters in BFDYANG module split in multiple YANG modules (one per type of
forwarding path)For BFD over MPLS-TE we augment MPLS-TE modelFor BFD authentication we now use YANG
Data Model for Key Chains