YANG Data Model for Bidirectional Forwarding Detection (BFD)
updates
- rfc-9127 — YANG Data Model for Bidirectional Forwarding Detection (BFD)
Extracted elements (21)
Because BFD has no uniform session key across path types, the data model is split into multiple YANG modules — one per forwarding path type (IP single-hop, IP multihop, MPLS LSPs, LAG) — each with its own session key. A shared 'ietf-bfd-types' module provides common typedefs and groupings to avoid duplication.
Because there is no existing LAG YANG data model that can be augmented, BFD-over-LAG configuration is placed as a 'lag' data node under the 'bfd' node rather than under the LAG interface hierarchy. BFD parameters are per-LAG attributes, and the destination IP address for micro-BFD sessions is configured per-LAG per address family.
RFC 5880 and RFC 5881 do not specify whether the Echo function operates continuously or on-demand, so the mechanism to start and stop the Echo function is declared implementation-specific and expected to be done by augmentation — either via configuration (for continuous operation) or via RPC (for on-demand). An example augmentation is shown in Appendix A.
The 'client-cfg-parms' grouping is defined to let BFD clients such as IGPs configure BFD session parameters (multiplier and intervals) without knowing peer addresses in advance. When an IGP auto-discovers a peer, it can create or remove the BFD session; authentication parameters are still specified centrally under BFD.
The revision from RFC 9127 to RFC 9314 introduces a backwards-incompatible change: an 'if-feature' called 'client-base-cfg-parms' was added to the 'client-cfg-parms' grouping so that BFD clients that do not need those parameters can deviate without being forced to include them. Clients using these parameters must now verify server feature support first.
The YANG modules conform to NMDA (RFC 8342), meaning configuration data and operational state data are not kept in separate top-level or sibling containers. This reflects the architecture where a single datastore hierarchy covers both config and state.
BFD operation depends on interface and IP configuration from other YANG modules: if 'ietf-interfaces' 'if:enabled' is false, no BFD packets can be sent or received. If 'ietf-ip' 'ip:enabled' or 'ip:forwarding' is false for IPv4 or IPv6, no BFD packets of that address family can be sent or received.
If the 'ietf-mpls' module 'mpls:mpls-enabled' is set to false on an interface, no BFD MPLS packets can be transmitted or received on that interface, affecting BFD-over-MPLS sessions.
For BFD IP multihop sessions, the 'rx-ttl' leaf is declared mandatory (no default). Incoming BFD control packets whose hop count is lower than 'rx-ttl' are dropped. This enforces the minimum TTL constraint for multihop BFD as per RFC 5883.
A new 'bfdv1' control-plane-protocol identity is defined, and a 'bfd' container is created under 'control-plane-protocol' as per RFC 8349. Path-specific modules augment this 'bfd' container with their respective 'ip-sh', 'ip-mh', 'lag', or 'mpls' containers.
BFD IP multihop sessions are modeled in 'ietf-bfd-ip-mh' as 'session-group' lists keyed by {source-addr, dest-addr}; each group may contain multiple operational 'sessions' for ECMP paths. The grouping adds 'tx-ttl' (outgoing hop count, default 255) and 'rx-ttl' (mandatory minimum allowed incoming hop count) leaves.
BFD IP single-hop sessions are modeled in 'ietf-bfd-ip-sh' as a list keyed by {interface, dest-addr}. A separate 'interfaces' list under 'ip-sh' allows per-interface authentication configuration for sessions created by BFD clients. The 'singlehop-notification' carries interface and echo-enabled fields in addition to common notification parameters.
BFD-over-LAG is modeled in 'ietf-bfd-lag' with a 'session' list keyed by lag-name. Per-session configuration includes 'ipv4-dest-addr', 'ipv6-dest-addr', 'use-ipv4', and 'use-ipv6' leaves. Operational state is per member-link, with separate 'micro-bfd-ipv4' and 'micro-bfd-ipv6' containers for each LAG member link.
BFD-over-MPLS is modeled in 'ietf-bfd-mpls' with session groups keyed by 'mpls-fec' (inet:ip-prefix) for ingress and a separate 'egress' container for egress BFD configuration (enabled, multiplier, intervals, authentication). MPLS encapsulation identities 'encap-gach' and 'encap-ip-gach' are defined in addition to the base 'encap-ip'.
Notifications are defined for each path type: 'singlehop-notification', 'multihop-notification', 'lag-notification', and 'mpls-notification'. All use the common 'notification-parms' grouping carrying local-discr, remote-discr, new-state, state-change-reason, time-of-last-state-change, dest-addr, source-addr, session-index, and path-type. Implementations may rate-limit notifications during rapid state cycling.
The 'all-session' grouping provides common operational state for every session type: local/remote discriminator, remote multiplier, demand capability, source/dest UDP ports (when IP encapsulation is used), a 'session-running' container (local-state, remote-state, diagnostics, detection mode, negotiated intervals, detection time), and a 'session-statistics' container (counters for up/down transitions, packet send/receive, and invalid/failed packets).
The 'auth-parms' grouping provides BFD authentication configuration (feature-gated by 'authentication'): a 'key-chain' leaf referencing an ietf-key-chain key-chain, and a 'meticulous' boolean leaf enabling meticulous authentication mode per RFC 5880 Section 6.7.
The 'base-cfg-parms' grouping defines the core BFD configuration parameters: 'local-multiplier' (uint8, default 3), and either 'desired-min-tx-interval' + 'required-min-rx-interval' (both uint32 in microseconds, default 1000000) or a single 'min-interval' leaf (feature 'single-minimum-interval'). This grouping is reused by all path-specific modules.
Section 5 registers six YANG modules in the 'IANA XML Registry' and 'IANA YANG Parameters' registry: ietf-bfd-types@2022-09-22, ietf-bfd@2022-09-22, ietf-bfd-ip-sh@2022-09-22, ietf-bfd-ip-mh@2022-09-22, ietf-bfd-lag@2022-09-22, and ietf-bfd-mpls@2022-09-22, each with namespace URN under 'urn:ietf:params:xml:ns:yang:'.
The BFD YANG modules define writable configuration nodes — including session parameters, authentication settings, and admin-down flags — that can directly affect network forwarding liveness detection. Unauthorized modification could disable BFD sessions or alter detection timers, leading to false failure indications or missed failures. Access to these nodes must be controlled using NETCONF access control (NACM, RFC 8341), and sessions must use an authenticated transport protocol.
The 'state' typedef enumerates four BFD session states as defined in RFC 5880: adminDown (0), down (1), init (2), and up (3). Both local-state and remote-state are exposed in 'session-running' operational state. Transitions trigger notifications carrying the new state, diagnostic code, and timestamp.