Model-Driven Network Management & Automation

Network automation controls a distributed system whose management connection can be broken by the very change being made. That makes correctness a state-and-evidence problem, not a command-generation problem. A safe system states the desired outcome, validates a model, applies a bounded transaction, observes what the device actually uses, and verifies forwarding or service behavior before expanding the change.

Model-driven management supplies shared structure for this loop. YANG defines data and operations; NETCONF, RESTCONF, and gNMI carry requests and responses with different transaction semantics; Network Management Datastore Architecture (NMDA) distinguishes configuration intent from operational state. The pieces complement one another rather than forming a version ladder.

Keep schema, protocol, encoding, and model separate #

“Uses YANG” does not say which modules, revisions, deviations, or features a device supports. “Uses JSON” says nothing about transaction behavior. “Uses gRPC” says nothing about the data tree. Interoperability requires agreement across all five concerns.

The state chain #

NMDA exists because one object can have several simultaneously relevant values:

• desired state is the controller's product-level objective, such as “edge links use this policy and remain reachable”;
• running configuration is conventional device configuration accepted into the running datastore;
• intended configuration is the configuration after device-side transformations that the system attempts to apply;
• applied configuration is the configuration actually in use;
• system state is non-configuration state such as counters, learned routes, adjacency status, and resource availability;
• operational state combines applied configuration and system state.

The values can differ without a protocol error. Templates may expand; defaults may appear; hardware may be missing; a control protocol may learn a different next hop; a deletion may leave a temporary remnant while resources are released. Therefore, “RPC succeeded” proves only that the request was accepted under that protocol's semantics. It does not prove the desired forwarding behavior exists.

NETCONF's configuration transaction #

NETCONF exchanges XML-encoded RPCs and lets a server advertise capabilities. The base operations include reading state and editing a target datastore. Optional capabilities materially change the safe workflow:

• :candidate provides a candidate configuration that can be edited before commit;
• :validate checks a candidate or other configuration source;
• :confirmed-commit applies a commit that automatically reverts unless it is confirmed within a timeout;
• :rollback-on-error changes how a failed edit affects earlier changes in the same operation;
• locking can prevent concurrent writers from changing a shared datastore during a transaction.

A confirmed commit is especially useful for changes that may break management reachability. It is not a universal rollback engine: the device must advertise the capability, the relevant state must be covered by the transaction, and concurrent changes need coordination. RFC 6241 warns that confirmed commit on a shared datastore can undo other changes unless locking is used.

Safe single-device sequence #

1. Discover protocol capabilities, YANG modules, revisions, features, and deviations.
2. Read the relevant current and operational state, including a version or hash used for optimistic concurrency where available.
3. Render a minimal desired change; validate it locally against the exact schema set.
4. Lock or otherwise guard the target against concurrent writers.
5. Edit the candidate datastore and ask the device to validate it.
6. Commit with a confirmation timeout when loss of reachability is plausible.
7. Read operational state and run external behavioral checks.
8. Confirm only when the acceptance criteria pass; otherwise allow or request the defined revert.
9. Unlock and record the before state, requested diff, responses, observed state, and verification result.

If a required capability is absent, do not silently substitute a less safe command path. Change the plan explicitly or fail closed.

RESTCONF and gNMI are not NETCONF spellings #

RESTCONF exposes YANG-defined data and operations through HTTP resources, commonly using JSON or XML. It offers familiar HTTP methods and conditional requests, but hides some distinctions among NETCONF's conventional datastores. A client must use the semantics actually exposed by the server rather than assuming candidate, locking, or confirmed-commit behavior.

gNMI uses gRPC and protobuf messages with schema paths. Get retrieves data, Set changes it, Subscribe streams it, and Capabilities describes supported models and encodings. Within one SetRequest, delete, replace, and update operations have a defined order and constitute the transaction scope. That does not make several SetRequest messages—or requests to several devices—one atomic transaction.

Desired state and ownership #

Automation needs one declared owner for each field or subtree. Without ownership, two controllers can both be correct locally while continuously overwriting one another. Define:

• the source of truth and its version;
• the selector that maps intent to devices and paths;
• which controller owns each modeled field;
• whether unspecified fields are preserved, defaulted, or removed;
• how manual changes are detected and reconciled;
• how emergency changes enter the source of truth.

An idempotent reconciliation computes the same requested state when repeated against the same desired state. Idempotence does not mean “send replace every minute.” It means repeated evaluation converges without destroying unowned data, retriggering disruptive operations, or hiding an unresolved mismatch.

Multi-device changes are distributed rollouts #

There is generally no atomic transaction across independent routers. A change to routing policy, link aggregation, access control, or an overlay can create an invalid intermediate state even when every final device configuration is correct. Model the rollout as ordered states:

1. Prepare: deploy backward-compatible prerequisites and verify them.
2. Canary: change one low-blast-radius target or failure domain.
3. Observe: compare control-plane, forwarding-plane, and service acceptance criteria over a stated window.
4. Expand: proceed by bounded batches with stop conditions.
5. Remove compatibility state: only after every dependent target has crossed the boundary.

The ordering must follow dependencies. For example, permit a new route or encapsulation at receivers before senders begin using it; remove the old behavior only after the new path is observed.

The control loop and its stability #

Automation is a sampled feedback controller. It measures state, computes an error, acts, and measures again. Several control failures have direct software analogues:

• delay: the device has not converged before the next reconciliation, so the controller overreacts;
• noise: transient telemetry produces repeated configuration changes;
• competing controllers: independent loops drive the same field in opposite directions;
• integral windup analogue: a backlog of desired changes continues to apply after the original condition is gone;
• oscillation: thresholds, retries, or autoscaling repeatedly cross one another;
• unobservable state: the controller cannot distinguish “not applied” from “not measured.”

Use convergence windows, hysteresis, rate limits, explicit ownership, cancellation of obsolete work, and independent outcome checks. Feed-forward information—planned maintenance, a known failed link, a scheduled traffic event—can justify an earlier action, but it does not remove the need to verify the result.

Worked change: routing policy with reachability risk #

Objective: prefer a new upstream for one prefix while preserving management reachability.

1. Resolve the service and management paths that depend on the current policy.
2. Read supported models, current policy, BGP session state, selected route, and FIB entry.
3. Validate the new policy against the exact schema and check that it cannot match the management prefix unintentionally.
4. Apply to a candidate configuration and use a confirmed commit.
5. Verify the BGP session, RIB choice, FIB programming, active probe through the new path, reverse path, and service SLI.
6. Confirm only if every required check passes. A healthy BGP session alone is insufficient because policy can select the wrong route while the session remains established.

The rollback trigger and consequence must be specified before the write. “Try another interface if the probe fails” is an alternate behavior, not a harmless recovery detail.

Failure checklist #

• Did capability and schema discovery run against the target being changed?
• Is the diff minimal, and are unowned fields protected?
• Which request or datastore is the real transaction boundary?
• What prevents concurrent writers from invalidating the precondition?
• Can the change break its own management path, and is an explicit revert mechanism available?
• Which operational-state facts prove application?
• Which external tests prove forwarding and service behavior?
• What is the batch boundary, stop condition, and blast radius?
• Are requested, accepted, applied, and verified states recorded separately?