Network management - traditional vs model-driven

Requirement / business driver

Configure, monitor, and assure the network with tooling that scales and feeds automation/observability.

Options

Within the gRPC family the duties split: gNMI carries configuration and telemetry against YANG paths, while gNOI carries operational actions as typed RPCs - ping/traceroute, certificate and OS lifecycle, reboot - the verbs that otherwise exist only as CLI exec commands. The split completes the management plane for a machine consumer: an automation or AIOps system (Telemetry-driven and closed-loop automation, AI-assisted operations - AIOps) needs structured data outbound and structured actions inbound, and the same interface inventory serves both directions - so the deciding question is no longer "SNMP or gNMI?" but "can every read and every action the machine performs be schema-validated?". Screen-scraping CLI over SSH fails that test in both directions, and it fails hardest when the consumer is a probabilistic one - unstructured text handed to an LLM invites mis-parsing - so once the consumer of the management plane stops being a human, model-driven interfaces stop being a convenience and become the data-quality prerequisite.

NETCONF's safe-change machinery (and why it exists)

NETCONF is best understood through RFC 3535 - the operators' requirements list that produced it: transactions with easy rollback, a candidate-vs-active configuration distinction, configuring network services as a whole rather than device by device, a clean configuration-vs-operational data split, and vendor-consistent representation (which YANG supplies). The machinery delivers exactly that: three datastores - running (the active configuration, always present), candidate (a workspace whose contents a commit applies to running), and startup (persisted only by an explicit copy from running) - with edit-config semantics of merge, replace, create, and delete, and every session opening with a capabilities exchange so the client knows which datastores and features this device actually supports. That is the design difference from CLI push: a multi-device change can be staged in candidates everywhere, validated, then committed - atomicity and rollback as protocol features rather than operator heroics (CI-CD pipelines for networks (NetDevOps) builds on exactly this). On the visibility side, telemetry subscriptions come in two lifecycles - dynamic (requested in-session, dies with the session) and configured (persistent across reboots, able to feed multiple receivers) - and two cadences: periodic (right for ever-changing counters such as CPU or interface statistics) and on-change (right for events - faults, new neighbours, threshold crossings). Choosing lifecycle and cadence per data class keeps the telemetry plane informative without drowning the collectors.

Flow and packet visibility (beyond device state)

SNMP and streaming telemetry report device and interface state; they do not tell you who is talking to whom. Two further telemetry tiers answer that. Flow telemetry - NetFlow, its template-based successor Flexible NetFlow, and the IETF-standard IPFIX - exports per-flow records (the classic 5-tuple plus byte/packet counts and more) for traffic analysis, capacity planning, and security/anomaly detection (Threat detection and mitigation - DDoS, spoofing, MITM); flows can be sampled to bound overhead. Packet mirroring - SPAN / RSPAN / ERSPAN - copies actual frames to an analyzer or IDS for deep inspection, the heaviest and most granular tier. Choose the granularity from the observability requirement: device metrics for health, flows for traffic and security visibility, mirrored packets for forensic depth.

There is also a fourth, active tier: synthetic measurement (IP SLA). Instead of reporting state, the network generates continuous probes - ICMP echo for reachability, UDP jitter against a responder (which subtracts its own processing time for accurate one-way delay, jitter, and loss), plus application-style operations - so you measure the SLA itself, from chosen vantage points, and catch brownouts that interface counters and flow records never show. Its distinctive design property is actuation: an object-tracking object bound to a probe's result can condition a static route, a PBR next hop, or FHRP priority, so failover keys on measured path health rather than link state - the answer when the primary path can be up but bad, or when an intermediate Layer-2 handoff hides a far-end failure from the local interface (Fast convergence techniques).

Active measurement - probing the paths you actually use

The tiers above are passive - device state and traffic records. The third tier is active: synthetic probes measuring latency, loss, and liveness per path, and three rules decide whether the numbers mean anything. ECMP honesty: a modern core fans every edge pair across many equal-cost paths, so the solution must discover and probe every ECMP path, budget probe rate for all of them, and report per path - a single-path probe certifies one lane of the motorway. Population over average: report latency as a histogram, not min/avg/max - with one bad path out of eight, 12.5% of sessions suffer while the mean barely moves; the histogram exposes the second bump and localises it. Absolute loss where it matters: alternate marking (RFC 9341) colours blocks of live traffic and differences the per-colour counters between two points - exact loss on real packets, no probe-based approximation. What makes the honest version feasible is hardware: probe generation and ingestion in the forwarding ASIC reaches millions of probes per second (500 edges x 16 ECMP paths at 1 ms cadence is ~8M pps), which collector-based probing cannot sustain - so the measurement architecture is a silicon selection criterion, not a bolt-on. The passive complement for volumes is the SRv6 counter-based demand matrix (Segment Routing); together they feed assurance and the closed loop (Telemetry-driven and closed-loop automation, AI-assisted operations - AIOps).

Defining the SLA itself - parameters, objectives, and where they live

An SLA is a contract, and its technical core is a set of service level objectives: each is a parameter plus a target value, usually qualified by a validity window (business hours vs off-hours), with penalties and remedies giving the numbers teeth. A parameter earns its place by three tests: significance (it matters for this service - jitter matters to voice, not to email), relevance to how the customer actually uses the service, and measurability (objectively verifiable, or it will be argued rather than measured). The classic mistake is defining the service one layer too low: users experience dropped calls, time-to-ring-tone, and voice quality (MOS), not jitter - so put the service-layer experience in the SLA and keep the lower-layer dependency map as the provider's internal engineering knowledge. Good objectives also carry their context assumptions explicitly (a busy-hour-call-attempts capacity target means nothing without the assumed call-holding time and on-net/off-net distribution), often come paired (an average target plus a never-exceed threshold whose breach defines unavailable), and can cover the management of the service as well as the service (time-to-provision, moves/adds per day). Availability itself must be defined operationally - the percentage of intervals in which the service verb actually works - not left as a bare count of nines. The design check ties back to the measurement tiers above: every objective names its measurement method and its measurement point, because where you measure is part of what the number means - which is exactly what the synthetic-probe tier exists to supply.

Events you can trust - or you are still polling

Event-driven management wins on exchanges and timeliness, but only reliable events actually free the manager from polling. If the event channel can silently drop, the application ends up event-directed but still polling-based - a safety-net sweep to catch what the events missed. Three techniques make events trustworthy: a reliable transport (with the caveat that a broken session or crashed collector still loses the interim - the conference-call gap); sequence numbers with gap detection and replay, so a missed message is at least known and ideally recoverable from the device's retained log; and acknowledged events, effective but pushing retention-and-retransmit bookkeeping onto the agent. This is the timeless reason unacknowledged UDP traps never carried critical state on their own, and precisely what the model-driven stack fixes structurally - subscription-based streaming over a connection-oriented, sequenced channel - so a design that still leans on best-effort notifications should either add the safety-net poll or move that data class onto the reliable subscription path.

Recommendation / justification

For new designs use model-driven management - NETCONF/RESTCONF + YANG for config and gNMI / streaming telemetry for push-based, sub-second visibility - because it scales, is programmable, and underpins CI/CD and AIOps (telemetry analysis, log correlation). Keep SNMP/SYSLOG for legacy devices and coexistence. Justify by scale, automation goals, and assurance needs.

What would change this

• Brownfield with legacy gear -> SNMP/SYSLOG bridge during migration.
• Heavy automation / observability targets -> prioritize telemetry + YANG.

IPv6 / dual-stack note

Run the management plane dual-stack; telemetry/NETCONF work over v6.

Related

• Reference models and migration considerations
• QoS design - models and strategy

Spaced repetition

Sources

• Cisco Live BRKSP-2551 (2026), Introduction to Segment Routing - A foundation for Autonomous Networks (Donzelli, Cisco / Gorovoy, Nebius; incl. the Microsoft AI-fabric and Nebius DCI material)
• Cisco Press, Network Management Fundamentals (Clemm) - SLA parameter/objective construction, reliable-event doctrine.
• Cisco Press, CCNA DevNet Associate DEVASC 200-901 OCG - RFC 3535 requirements, NETCONF datastores and operations, telemetry subscription models.
• Cisco Live DEVNET-3707 - Network Telemetry and AI for Network Incident Response (gNOI, machine-consumer interfaces)
• Cisco Press, Network Management Fundamentals; Cisco model-driven programmability docs.
• Cisco Press, CCNP ENARSI 300-410 OCG (Edgeworth/Lacoste) - IP SLA, object tracking.

domain: Core · blueprint-ref: Core 5.7 Network management techniques · type: design-decision · status: complete · tags: [core, core/virtualization, tradeoff/operability]