Compare intended and operational network state after automation

An automation job reporting success proves that a transaction completed according to the tool’s view. It does not prove that every intended resource exists, that the device accepted it as expected, or that the resulting operational state matches the service design.

Source fact:

IETF RFC 8342 defines the Network Management Datastore Architecture for YANG-modeled configuration and state. The architecture distinguishes conventional, intended, and operational datastores. Intended configuration represents the configuration the system is meant to use after processing configuration sources, while operational state represents the system’s actual state, including applied configuration and system-generated or learned information.

The RFC accounts for cases in which intended configuration is absent from operational state, operational resources are generated by the system, or values differ because of system behavior. It also defines how the architecture binds to NETCONF and RESTCONF. This separation gives management systems a way to reason about what was requested and what exists; it does not assert that all platforms expose every origin or state detail uniformly.

Boundary

YANG model coverage, datastore support, origin metadata, default handling, validation timing, and controller abstractions vary by implementation. Operational configuration being present does not prove packet forwarding or application health. Conversely, some legitimate dynamic state will never appear in intended configuration. A raw tree comparison without model awareness can generate noise from defaults, ephemeral state, ordering, or values controlled by the system.

Applicability questions

• Which devices and controllers implement the relevant NMDA datastores and origin metadata?
• Which service assertions can be compared semantically rather than as raw serialized text?
• How are defaults, generated identifiers, learned state, and system-controlled resources normalized?
• What delay is expected between a committed change and stable operational state?
• Which mismatches require rollback, investigation, or an approved exception?

DSE recommendation:

For each automated service, define a small set of postconditions tied to the YANG model: required resources, key values, relationships, administrative state, and relevant operational status. Query the intended and operational datastores through supported interfaces after the transaction and after an appropriate stabilization period. Interpret differences using origin and model semantics rather than a textual diff.

Classify mismatches such as rejected configuration, remnant resources, missing dependencies, system-selected values, and delayed convergence. Fail the deployment or open an exception when a required postcondition is not met. Follow datastore verification with route, neighbor, forwarding, reachability, and application checks proportionate to the change. Preserve a rollback path that uses a known state, not merely the automation job’s prior input.

Verification and evidence

Keep device and model revisions, capability discovery, transaction identifiers, intended and operational queries, normalization rules, postcondition results, convergence timestamps, exceptions, and end-to-end probes. Evidence should allow a reviewer to trace one approved intent through device commit to observed state. Requalify comparisons after model, controller, or device upgrades because schema and origin behavior can change.

Official references

• IETF RFC 8342