YANG Data Model for Bidirectional Forwarding Detection (BFD)
updated by
- rfc-9314 — YANG Data Model for Bidirectional Forwarding Detection (BFD)
Extracted elements (27)
BFD-over-LAG parameters are placed under a 'lag' data node within the BFD top-level container rather than augmenting a LAG YANG module, because no standard LAG YANG data model existed at the time that could be augmented.
The BFD YANG data model is split into multiple modules, each corresponding to one type of forwarding path, because there is no uniform key to identify a BFD session across all path types. The main difference between modules is how a BFD session is uniquely identified (i.e., the key for the session list).
The 'client-cfg-parms' grouping is defined to allow BFD clients such as IGPs to configure BFD for auto-discovered peers (multiplier and intervals only), since IGPs do not pre-configure peer addresses and discover them dynamically. Authentication parameters for client-created sessions are still specified in BFD directly.
BFD packet transmission and reception on an interface depends on enabling flags from other YANG modules: /if:interfaces/if:interface/if:enabled (ietf-interfaces), /ip:ipv4/ip:enabled and /ip:ipv4/ip:forwarding (ietf-ip), and /mpls:mpls-enabled (ietf-mpls). Setting any of these to false prevents BFD packets on that interface.
RFC 5880 and RFC 5881 do not specify whether the Echo function operates continuously or on demand; the mechanism to start/stop it is implementation-specific and should be done by augmentation — either via configuration (for continuous operation) or via RPC (for on-demand). An example is provided in Appendix A.
The YANG modules conform to NMDA (RFC 8342), meaning configuration and operational state data are not separated into distinct top-level or sibling containers. The same nodes carry both 'rw' (config) and 'ro' (state) leaves.
Implementations MAY rate-limit BFD state-change notifications, for example when a session is continuously changing state.
A new control-plane protocol identity 'bfdv1' is defined, and a 'bfd' container is created under 'control-plane-protocol' as specified in RFC 8349. Path-specific modules (ietf-bfd-ip-sh, ietf-bfd-ip-mh, ietf-bfd-lag, ietf-bfd-mpls) augment this 'bfd' container with their respective containers.
BFD authentication configuration uses the 'auth-parms' grouping with a 'key-chain' leaf (reference to RFC 8177 key-chain model) and a 'meticulous' boolean leaf. The authentication container is guarded by the 'authentication' feature and uses presence semantics to enable authentication.
BFD IP multihop sessions (ietf-bfd-ip-mh) are grouped into 'session-group' entries keyed by source-addr and dest-addr. Multiple BFD sessions may exist per group to test ECMP paths; in the operational state model the local discriminator is used as a further key.
BFD IP single-hop sessions (ietf-bfd-ip-sh) are uniquely identified by the composite key of interface and destination address. The 'ip-sh' container also holds a list of interfaces used to specify per-interface authentication parameters for sessions created by BFD clients.
BFD-over-LAG sessions (ietf-bfd-lag) consist of micro-BFD sessions on each LAG member link. Configuration is per LAG (keyed by lag-name); destination IP addresses for micro-BFD are configured per address family (IPv4 and IPv6) per LAG. Operational state is per member-link under each LAG session.
BFD-over-MPLS sessions (ietf-bfd-mpls) are organized as 'session-group' entries keyed by mpls-fec (inet:ip-prefix). Multiple BFD sessions per FEC are supported for ECMP. An 'egress' container holds BFD parameters for the egress node; since LSPs are unidirectional, there is no LSP configuration on the egress node beyond this.
Common BFD configuration parameters are: local-multiplier (detection time multiplier, default 3), desired-min-tx-interval (in microseconds, default 1000000), and required-min-rx-interval (in microseconds, default 1000000). An implementation may optionally support a single min-interval used for both tx and rx via the 'single-minimum-interval' feature.
For BFD IP multihop, 'tx-ttl' (hop count of outgoing BFD control packets, default 255, type uint8 range 1–255) and 'rx-ttl' (mandatory minimum allowed hop count of incoming packets; packets below this are dropped) are configurable per session-group.
Four YANG features gate optional BFD capabilities: 'single-minimum-interval' (one interval value for both tx and rx), 'authentication' (BFD authentication per RFC 5880 Section 6.7), 'demand-mode' (BFD Demand mode per RFC 5880 Section 6.6), and 'echo-mode' (BFD Echo mode per RFC 5880 Section 6.4).
Four YANG notifications are defined, one per path type: singlehop-notification, multihop-notification, lag-notification, and mpls-notification. All carry common parameters (local-discr, remote-discr, new-state, state-change-reason, time-of-last-state-change, dest-addr, source-addr, session-index, path-type) from the 'notification-parms' grouping.
Per-session statistics in the 'session-statistics' container include: create-time, last-down-time, last-up-time, down-count (counter32), admin-down-count (counter32), receive-packet-count (counter64), send-packet-count (counter64), receive-invalid-packet-count (counter64), and send-failed-packet-count (counter64).
Session summary statistics (number-of-sessions, number-of-sessions-up, number-of-sessions-down, number-of-sessions-admin-down, all gauge32) are exposed at two levels: globally under the top-level 'bfd' container and per path-type container (ip-sh, ip-mh, mpls, and separately for micro-BFD IPv4/IPv6 in lag).
The 'discriminator' typedef is uint32 representing the BFD discriminator as per RFC 5880. The 'multiplier' typedef is uint8 with range 1–255. The 'hops' typedef is uint8 with range 1–255, representing TTL for IPv4 or hop limit for IPv6.
The 'iana-bfd-types' YANG module defines the 'auth-type' typedef enumerating BFD authentication types (0–255): reserved, simple-password, keyed-md5, meticulous-keyed-md5, keyed-sha1, meticulous-keyed-sha1. Values are maintained in the IANA 'BFD Authentication Types' registry.
The ietf-bfd-mpls module defines two additional encapsulation type identities: 'encap-gach' (BFD with G-ACh encapsulation per RFC 5586) and 'encap-ip-gach' (BFD with IP and G-ACh encapsulation), extending the base 'encap-type' identity from ietf-bfd-types.
The 'session-running' container captures live operational state per session: local-state, remote-state, local-diagnostic, remote-diagnostic, remote-authenticated, remote-authentication-type, detection-mode (async-with-echo, async-without-echo, demand-with-echo, demand-without-echo), negotiated-tx-interval, negotiated-rx-interval, detection-time, and echo-tx-interval-in-use.
The 'iana-bfd-types' YANG module is IANA-maintained and reflects two IANA registries: 'BFD Diagnostic Codes' and 'BFD Authentication Types', both defined in RFC 5880. The module namespace is 'urn:ietf:params:xml:ns:yang:iana-bfd-types'.
The BFD YANG modules define writable nodes that, if accessed by an unauthorized user, could disrupt BFD sessions and consequently affect network convergence for routing protocols and other BFD clients. Access to these nodes should be controlled using NETCONF access control (NACM, RFC 8341).
The 'key-chain' reference in BFD authentication configuration is sensitive; unauthorized read access could expose cryptographic keys used to authenticate BFD control packets. Implementations should restrict read access to authentication configuration nodes.
BFD session states as defined in RFC 5880 and modeled in the 'state' typedef: adminDown (0), down (1), init (2), up (3). State changes trigger notifications carrying the new-state and a diagnostic code explaining the reason.