ospf: RFC 9129 ietf-ospf YANG support (operational state + config-write)

[lamestllama]

Overview

Adds RFC 9129 ietf-ospf YANG support for the implemented FRR-backed
OSPFv2 and OSPFv3 subset through mgmtd.

The implementation is anchored on the IETF model. FRR-specific behaviour stays
on the existing CLI surface unless there is a concrete FRR-native augment with
callbacks.

This PR provides the OSPF YANG model integration, callback wiring, mgmtd
dispatch support needed for the shared OSPFv2/OSPFv3 subtree, RPC callbacks,
notifications, user documentation and developer notes.

Generic gRPC Execute and Subscribe support through mgmtd is handled in
#22158. When #22158 is present, external gRPC clients can use the same mgmtd
frontend/backend machinery for OSPF RPCs and notifications. This PR does not
depend on #22158.

What This PR Provides

Operators get broad RFC 9129 YANG configuration, RPC and operational state
coverage for the implemented FRR-backed OSPF subset.

The supported mgmtd-facing surfaces are:

• vtysh through mgmt set-config, mgmt rpc and mgmt commit apply
• the mgmtd frontend socket binary protocol
• daemon-backed operational state, RPC and notification callbacks registered
  with mgmtd

The OSPFv2 and OSPFv3 implementations share the RFC 9129
control-plane-protocol subtree. Requests are routed to the correct daemon by
matching the predicated protocol entry, for example the OSPFv2 or OSPFv3
type and name keys.

Architecture

RFC 9129 puts OSPFv2 and OSPFv3 under the shared RFC 8349
control-plane-protocol list, distinguished by type and name keys. That is
the standard shape, but it means ospfd and ospf6d share one schema subtree
and must receive only the requests that belong to their daemon and instance.

The series adds reusable infrastructure for that shape:

Area	Purpose
Operational callbacks with suppressed config callbacks	Allows operational callbacks on modules that suppress config callbacks.
Per-node config opt-in	Lets selected writable nodes in a mostly suppressed standard module opt into config callbacks.
Batched daemon config-file loads	Gives daemon-direct startup files the same single-transaction semantics vtysh already gets.
Predicate-aware backend xpath matching	Lets backends register predicated list entries such as control-plane-protocol[type='ietf-ospf:ospfv2'].

For multi-instance OSPFv2, backend client names are made instance-aware:
non-instanced daemons keep their existing names, while instanced daemons append
the decimal instance ID, such as ospfd-1 or ospfd-2. The RFC 9129 protocol
name in instance mode is the decimal instance ID.

Configuration Coverage

Per-instance leaves:

RFC 9129 path	OSPFv2	OSPFv3	Notes
explicit-router-id	yes	yes
preference/{all,intra-area,inter-area,internal,external}	yes	yes	RFC internal maps onto intra/inter-area distances.
spf-control/paths	yes	yes	Capped at MULTIPATH_NUM.
auto-cost/{enabled,reference-bandwidth}	yes	yes	FRR has no off-switch, so enabled=false is rejected at validation.
mpls/ldp/igp-sync	yes	N/A	ospf6d has no LDP/IGP-sync.
mpls/te-rid/ipv4-router-id	yes	N/A	ospf6d has no MPLS-TE.
graceful-restart/{enabled,restart-interval,helper-enabled,helper-strict-lsa-checking}	yes	yes
stub-router/always	yes	N/A	ospf6d has no stub-router.

Per-area:

RFC 9129 path	OSPFv2	OSPFv3
areas/area lifecycle	yes	yes
area/area-type normal, stub and NSSA	yes	yes
area/summary	yes	yes
area/default-cost	yes	N/A
area/ranges/range, advertise and cost	yes	yes

Per-interface:

RFC 9129 path	OSPFv2	OSPFv3
interfaces/interface area attachment	yes	yes
interface/cost	yes	yes
interface/{hello,dead,retransmit}-interval	yes	yes
interface/priority	yes	yes
interface/mtu-ignore	yes	yes
interface/transmit-delay	yes	yes
interface/interface-type	yes	yes
interface/passive	yes	yes
interface/prefix-suppression	yes	N/A
interface/bfd/{enabled,local-multiplier,desired-min-tx-interval,required-min-rx-interval}	yes	yes
interface/static-neighbors/neighbor, poll-interval and priority	yes	N/A
interface/authentication/ospfv2-key-chain / ospfv3-key-chain	yes	yes

RPCs

RFC 9129 RPC	OSPFv2	OSPFv3	Notes
clear-neighbor	yes	yes	Whole-instance and per-interface variants.
clear-database	yes	yes	Maps onto ospf{,6}_process_reset.

Notifications

RFC 9129 notification	OSPFv2	OSPFv3	Source
nbr-state-change	yes	yes	ospf_nsm_change / ospf6_neighbor_change hooks
if-state-change	yes	yes	ospf_ism_change / ospf6_interface_change hooks
restart-status-change	yes	yes	Direct emit from GR enter and exit
nbr-restart-helper-status-change	yes	yes	Direct emit from GR helper enter and exit
if-rx-bad-packet	yes	yes	Post-header-validation failure path
if-config-error	yes	yes	Hello/dead interval mismatch checks
nssa-translator-status-change	yes	N/A	ABR NSSA translator transition
lsdb-{approaching-,}overflow	N/A	N/A	FRR has no max-LSA threshold matching this model.

Out of Scope

Documented in doc/developer/ospf-yang-northbound-notes.rst.

Deferred because there is no matching FRR surface, the FRR surface has a
different shape, or the RFC 9129 path needs a separate future mapping:

• Redistribution and default-information-originate
• Virtual links
• Per-address OSPFv2 interface overrides
• FRR-specific NSSA knobs
• ospf/nsr
• database-control/max-lsa
• spf-control/ietf-spf-delay
• node-tag-config
• interface/{enabled,multi-areas,ttl-security}
• ospf/enabled
• address-family
• per-interface fast-reroute/lfa
• nested authentication choice branches that pyang/libyang reject through the
  current deviation paths

Related Work

Two earlier OSPF YANG attempts shaped the choices here:

• FRR PR Start of an OSPF YANG northbound/mgmtd conversion #18401 added lite OSPF YANG modules and real operational callbacks.
  It was useful as a state-callback reference, but its paths do not map onto
  the current RFC 9129 surface.
• FRR PR ospfd: start ospf northbound api to converse #19066 added a broad generated callback skeleton against the current
  frr-ospfd.yang. It was useful as a coverage map, but most callbacks were
  stubs.

FRR also has an experimental YANG-module translator for mapping non-native
models onto native FRR models via deviation modules and XPath translation
tables. This PR does not use it because OSPF does not yet have a complete
callback-backed native OSPF YANG model to serve as the source of truth. RFC
9129 is implemented directly as the canonical northbound surface for the OSPF
behaviour it covers.

Documentation

• doc/user/ospfd.rst and doc/user/ospf6d.rst: supported leaves,
  daemon-instance naming and worked mgmt set-config / mgmt commit apply
  examples.
• doc/developer/ospf-yang-northbound-notes.rst: RFC 9129 design choice,
  predicate-aware dispatch, startup batching, validation approach,
  notification wiring and future FRR-native augment boundaries.

IETF Module Sources

ietf-ospf.yang, ietf-routing.yang, ietf-bfd-types.yang,
iana-routing-types.yang and iana-bfd-types.yang are pulled from their
respective RFCs unchanged, with the IETF Trust BSD licence text.

This follows the existing handling of ietf-interfaces.yang,
ietf-key-chain.yang and ietf-routing-types.yang already in yang/ietf/.

Commit Organisation

The series is organised so that reusable infrastructure lands before the OSPF
callbacks that depend on it:

1. Reusable lib and mgmtd infrastructure.
2. RFC 9129 operational state.
3. Per-leaf config-write support and matching legacy CLI conversions.
4. RFC 9129 RPC callbacks.
5. RFC 9129 notification callbacks.
6. User and developer documentation.

Each commit is intended to be reviewable in isolation.

[Jafaral]

Please stop closing/opening PRs for the same changes. Update your branch and force push to the same PR.

[greptile-apps]

Greptile Summary

This PR adds RFC 9129 ietf-ospf YANG northbound support for FRR's OSPFv2 and OSPFv3 daemons, wiring operational state, configuration, RPC, and notification callbacks through mgmtd. It also adds reusable infrastructure: predicate-aware backend XPath dispatch (so ospfd and ospf6d can share one RFC 8349 control-plane-protocol list entry), per-node config opt-in for incremental YANG migration, batched startup config loading, and instance-aware mgmtd backend client names.

• New northbound files: ospfd/ospf_nb_config.c, ospfd/ospf_nb_state.c, ospfd/ospf_nb_notifications.c, ospfd/ospf_nb_rpcs.c and their ospf6d mirrors, registering config, state, RPC, and notification callbacks for the RFC 9129 leaf coverage documented in the PR description.
• mgmtd/mgmt_be_adapter.c: Adds mgmt_be_xpath_prefix_predicate_compatible, a new XPath matcher that honours predicate constraints from backend registrations (e.g. [type='ietf-ospf:ospfv2']) while treating missing query predicates as wildcards for parent-level fan-out.
• Infrastructure changes: lib/northbound.c removes the blanket F_NB_NODE_IGNORE_CFG_CBS guard from operational-state callbacks and replaces it with per-function null guards, enabling modules to suppress config callbacks while retaining operational-state callbacks.

Confidence Score: 5/5

Safe to merge; all previously-flagged blocking issues (area-ranges use-after-free, virtual-link VALIDATE bypass, atomic interface-area moves for both v2 and v3, northbound null guards, multi-instance XPath) are resolved in this version.

The core correctness fixes are present and the new infrastructure (predicate-aware XPath dispatch, per-node cfg_opt_in, batch startup config, instance-aware client names) is sound. Remaining findings are defensive inconsistencies in a new helper function and a fragile relative XPath depth — neither causes wrong behaviour with today's schema.

ospfd/ospf_nb_config.c (ospf_apply_interface_type missing IF_OSPF_IF_INFO guard); ospf6d/ospf6_nb_config.c (same pattern inherited for any future interface-type callback).

Important Files Changed

Filename	Overview
ospfd/ospf_nb_config.c	New file: 2796-line RFC 9129 config callback implementation. Previously-flagged issues (area-ranges use-after-free, virtual-link VALIDATE guard, interface-area move validation) are resolved; ospf_apply_interface_type is missing the IF_OSPF_IF_INFO null guard present in sibling helpers.
mgmtd/mgmt_be_adapter.c	Adds ~250 lines of predicate-aware XPath matching; new matcher correctly handles quoted values and missing-predicate wildcard semantics for the ospfv2/ospfv3 shared list dispatch.
lib/northbound.c	Removes F_NB_NODE_IGNORE_CFG_CBS guard from operational-state callbacks and replaces with null checks; adds cfg_opt_in per-node flag handling in nb_load_callbacks. Previously flagged missing null guards are now present.
ospf6d/ospf6_nb_config.c	New file: 2140-line OSPFv3 config callback implementation, structurally mirrors ospfd counterpart; atomic interface-area move and area-ranges drain patterns are correct.
ospfd/ospf_nb_notifications.c	New file: correct NSM/ISM state-to-RFC-enum translation tables, proper memory management via list_delete on early-exit paths, GR exit-reason mapping is correct.
ospfd/ospf_gr.c	ospf_gr_restart_exit signature extended with exit_reason; all four call sites updated; restart-status-change notifications emitted correctly on both enter and exit.
lib/mgmt_be_client.c	Adds instance-aware backend client name (ospfd-N for multi-instance); length check against MGMTD_CLIENT_NAME_MAX_LEN is semantically correct since buffer is MAXPATHLEN.
ospfd/ospf_nb_rpcs.c	New file: clear-neighbor and clear-database RPCs correctly handle per-interface vs whole-instance variants and silently return NB_OK for non-owner backends.
ospfd/ospf_bfd.c	Promotes ospf_interface_enable_bfd and ospf_interface_bfd_apply to extern; adds ospf_interface_bfd_config_get; adds enabled field checks to quick-neighbor paths; changes are backward-compatible.
lib/command.c	Adds batch_config_file flag that sets vty->pending_allowed=true during config_from_file, enabling single-transaction startup config loads; saved/restored correctly around the loop.

Sequence Diagram

sequenceDiagram
    participant CLI as vtysh / mgmt CLI
    participant mgmtd
    participant BE as mgmt_be_adapter
    participant ospfd
    participant ospf6d

    CLI->>mgmtd: set-config / commit apply
    mgmtd->>BE: xpath dispatch
    BE->>BE: "mgmt_be_xpath_prefix()<br/>(predicate-aware if '[' in map_path)"
    alt "type='ietf-ospf:ospfv2'"
        BE->>ospfd: NB_EV_VALIDATE → NB_EV_APPLY callbacks
        ospfd-->>BE: NB_OK
    else "type='ietf-ospf:ospfv3'"
        BE->>ospf6d: NB_EV_VALIDATE → NB_EV_APPLY callbacks
        ospf6d-->>BE: NB_OK
    end
    BE-->>mgmtd: commit result
    mgmtd-->>CLI: success / error

    CLI->>mgmtd: mgmt rpc clear-neighbor
    mgmtd->>ospfd: ospfd_ietf_ospf_clear_neighbor_rpc
    mgmtd->>ospf6d: ospf6d_ietf_ospf_clear_neighbor_rpc
    Note over ospfd,ospf6d: Non-owner returns NB_OK silently

    ospfd->>mgmtd: nb_notification_send(nbr-state-change)
    ospfd->>mgmtd: nb_notification_send(if-state-change)
    ospfd->>mgmtd: nb_notification_send(restart-status-change)

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
ospfd/ospf_nb_config.c:1386-1390
`ospf_apply_interface_type` accesses `IF_DEF_PARAMS(ifp)` and `IF_OIFS(ifp)` without first checking `IF_OSPF_IF_INFO(ifp)` for NULL. Both macros dereference `ifp->info` as a `struct ospf_if_info *`, so if the ospf if-hook hasn't yet allocated the info struct for this interface (e.g. an interface that arrived between VALIDATE and APPLY), the function will crash. The sibling helpers `ospfd_ietf_ospf_priority_update` and `ospfd_ietf_ospf_nbr_timer_update` in the same file both add this guard explicitly.

```suggestion
static void ospf_apply_interface_type(struct interface *ifp, int new_type)
{
	struct ospf_if_params *params;
	struct route_node *rn;
	int old_type;

	if (!IF_OSPF_IF_INFO(ifp) || !IF_OIFS(ifp))
		return;

	params = IF_DEF_PARAMS(ifp);
	old_type = params->type;
```

### Issue 2 of 2
ospfd/ospf_nb_config.c:2612-2625
**Hardcoded 6-level relative XPath is fragile**

The XPath `../../../../../../areas/area/interfaces/interface/static-neighbors/neighbor[identifier='%s']` hard-codes 6 `..` hops up to the `ospf` subtree. If the YANG tree nesting ever changes (e.g. an extra grouping or augment is introduced between `ospf` and `areas`), this silently finds the wrong scope and the uniqueness check either always passes or always fails. Using `yang_dnode_get_parent(neigh, "ospf")` to first anchor to the `ospf` node and then a relative XPath like `areas/area/interfaces/interface/static-neighbors/neighbor[identifier='%s']` would be more robust.

_{Reviews (30): Last reviewed commit: "ospfd,ospf6d: harden OSPF notification m..." | Re-trigger Greptile}

[greptile-apps]

Want your agent to iterate on Greptile's feedback? Try greploops.

[lamestllama]

@greptile[bot] review

[lamestllama]

@greptile[bot] review

[lamestllama]

CI:rerun

[lamestllama]

@greptile[bot] review