gNOI for Network Operations Beyond Configuration Push

gNOI addresses the operational work that configuration and telemetry interfaces leave unfinished. Its value lies in making OS upgrades, certificate rotation, diagnostics, and reachability tests programmatic, permissioned, and auditable.

Why gNOI is not a configuration protocol and why that distinction matters

A network can have automated configuration delivery and streaming telemetry and still need a terminal for day-to-day operational work. An OS upgrade sends an engineer back to the CLI. Certificate rotation needs another device session, and a maintenance window brings reachability checks that someone must run by hand. These recurring network operations remain outside the automation workflow when configuration and telemetry are its only interfaces.

That dependency creates an accountability gap as well as an execution gap. A CLI session lacks the named requests, structured responses, and built-in permission checks that a programmatic operational interface has. Composing its actions with other automation requires fragile screen-scraping. The workflow therefore depends on interpreting terminal output at precisely the point where it needs a reliable record of what happened.

The gNOI repository defines gNOI as a collection of gRPC-based microservices for executing operational commands on network devices. By contrast, gNMI handles state retrieval and configuration manipulation. The boundary is clear and operationally useful. Configuration describes or changes device settings, telemetry exposes state, and gNOI invokes actions that neither of those activities replaces.

Collapsing the OpenConfig stack into “push config, collect telemetry” obscures that boundary. An engineer can use gNMI successfully without gaining a programmatic way to upgrade software or run a diagnostic test. Adding more configuration automation does not close that gap, because the missing capability is a different kind of interaction with the device. gNOI gives that interaction an explicit interface instead of leaving it embedded in operator procedures.

What gNOI actually covers — the operational service catalog

The System service exposes familiar NOC actions through named RPCs, including Reboot, Ping, Traceroute, Time, SetPackage, and SwitchControlProcessor. CancelReboot and RebootStatus support control over reboot operations, while KillProcess provides process control. These are operational commands. Their inclusion makes common device interventions available to an automation workflow without requiring it to interpret a terminal session.

Software and boot management extend that scope. The OS service separates an upgrade into Install, Activate, and Verify, with timeout controls for transferring the image, switching the active version, and confirming the running version. BootConfig manages boot configuration on its own, apart from running configuration. FactoryReset and SoftwareBundle address full device reset and software package management. Together, these services expose actions that determine how a device starts and what it runs.

The BGP service exposes session reset and graceful restart, while Layer2 and MPLS extend operational actions into switching and label-switched path domains. File operations are equally practical. The File service provides Get, Put, Stat, Remove, and TransferToRemote, supporting configuration backups and artifact retrieval without separate out-of-band file transfer sessions.

Containerz brings the container and plugin lifecycle into the same model. Cisco NX-OS 10.6(x) translates Containerz RPCs such as Deploy, ListImage, StartContainer, StopContainer, CreateVolume, and StartPlugin into underlying Docker commands, then returns structured responses to the client. The abstraction maps to concrete device behavior.

Diagnostics complete the survey for IP/Ethernet operations teams. Healthz streams component health and diagnostic artifacts, while Diag exposes BERT, or Bit Error Rate Test, operations for physical layer validation. Debug and PacketCapture provide programmatic debug access and on-device packet capture. Packet Link Qualification adds link quality assessment, and OTDR brings Optical Time Domain Reflectometry under programmatic control.

How gNOI's design philosophy enforces auditability that CLI cannot provide

A defined RPC gives an operational action a form that software can inspect. The request identifies the operation, the response exposes its result, and the permission check allows or blocks the caller’s invocation. This changes the basis of accountability. Rather than reconstructing an intervention from a terminal interaction, an orchestration system can evaluate a named action and its structured outcome.

Authentication connects that action to a known identity. gNOI uses mutual TLS and the same certificate infrastructure as gNMI, so operational requests do not require a separate identity scheme outside the configuration and telemetry interfaces. The authenticated identity is logged. A NOC engineer running Ping or Traceroute can therefore produce a timestamped, machine-readable request and structured response under a permission check.

Authorization must distinguish invoking an operation from changing data. RFC 8341 defines NACM access control points for protocol operations, datastore access, and notifications. RPC execution is gated at the protocol-operation layer. That distinction is important because permission to read state or alter configuration is not, by itself, permission to reboot a device. The shared YANG-based access control model keeps those decisions separate within the same set of rules.

The certificate rotation case also shows why a structured interface does not remove the need to handle disruption. When cert.proto provisions or rotates a certificate, the gNMI/gNOI service may restart to apply the new identity. Automation must handle that interruption explicitly through retry logic. A temporarily unavailable service is not an outcome the workflow can silently discard.

These properties make governance part of the operational design. They do not mean that issuing an RPC alone creates a complete audit system. The surrounding workflow still has to preserve requests, identities, and results, and respond to failures. What gNOI supplies is the defined contract through which that accountability can be enforced consistently.

Three operational workflows where gNOI replaces manual or fragile automation

OS upgrades across a fleet show the limits of doing the work through a terminal. With manual CLI sessions, each operator has to run the commands and read the results, while vendor-specific tools can sit apart from the rest of the automation stack. The OS service replaces that division with discrete RPCs. Install transfers the image, Activate switches the active version, and Verify confirms the running version, with a timeout and structured success or failure response at each stage.

Verify is the decisive step for subsequent automation. Transferring an image or requesting activation does not establish that the intended version is running. A machine-readable confirmation can gate later provisioning actions, rather than leaving a human to interpret a CLI prompt across the fleet.

Certificate rotation changes in a similar way. The cert.proto rotate RPC replaces the manual crypto pki sequence that would otherwise require a CLI session on each managed device. Combined with revoke and check RPCs, it makes certificate hygiene schedulable and verifiable. The workflow must also detect when the service restarts to apply the certificate and retry later calls when needed.

The Nokia SReXperts 2026 Hackathon described a NOC engineer who starts a shift with a report of packet loss on a core network link that could affect application reachability from the data center edge. The prescribed response was to automate ICMP Ping tests using gNOI and Ansible on SR OS, with gNMIc and gNOIc tooling. The engineer needs to test reachability from the device.

System Ping and Traceroute replace that manual verification step with repeatable, loggable requests. During an incident or maintenance window, those requests can be sequenced with gNMI telemetry collection and OS Verify in one automation workflow.

Why gNOI's RPC surface is the right interface for AI agents acting on network devices

An AI agent acting on a network device needs a bounded set of operations. gNOI provides discrete actions with names, permission checks, and structured responses. That fit follows from the interface design. An agent can request an operation whose authority and outcome are evaluated independently of the agent’s own explanation.

The accountability standard must remain the same for human and AI operators. Rebooting a device, rotating a certificate, or activating an OS image has operational consequences regardless of who initiates it. Both kinds of operator therefore belong on the same APIs, audit trails, and permission structures. A separate automation channel would weaken that standard by moving actions outside the controls used for ordinary operations.

NACM sets the boundary between actions that are allowed and those that are blocked. An agent granted access to Ping and Traceroute does not thereby gain authority to invoke Reboot or FactoryReset. To run those operations, the caller must have explicit permission at the protocol-operation access control point. The restriction is enforceable. It does not depend on the agent remembering a written instruction about which commands to avoid.

An orchestration layer can evaluate an OS Verify response rather than accepting an agent’s assertion that an upgrade completed. This separates choosing an action from establishing its result. The same principle applies to human-initiated workflows.

CLI scripts and out-of-band tooling create the opposite risk when their actions escape the shared permission and logging infrastructure. That is shadow automation, even if its immediate task succeeds. An OSS that governs both human and AI operators should manage gNOI within the same API surface as configuration and telemetry. Its role is to make operational authority explicit and inspectable.

What gNOI adoption requires from an OSS architecture

Device support alone cannot deliver that governance. The OSS above the device must represent, authorize, and log operational actions with the same fidelity as configuration changes. Most legacy OSS architectures cannot do this. If an upgrade or certificate rotation is treated as an external activity, the device may expose a structured interface while the service-level record still lacks the action that changed its operating conditions.

A unified operational data model closes that separation. Certificate rotations, OS upgrades, and reachability tests need to be represented with configuration state and telemetry so that actions can be correlated with service impact. This is a lifecycle requirement. An audit trail disconnected from the service model cannot provide the same account of what was done and which service it affected.

Permission consistency also extends above the device. NACM can enforce the rights presented to it, but it cannot repair fragmented credential and role management across telemetry collectors, provisioning systems, and operational tools. The OSS must manage those assignments consistently. Otherwise, device-level enforcement coexists with gaps in the systems deciding which identities may perform which work.

The same gap appears in service delivery. An OSS may qualify, design, provision, and activate a service while leaving the serving device’s OS upgrades and certificate rotation to manual processes or unmonitored tooling. That lifecycle is incomplete. For fiber, dedicated internet, and Carrier Ethernet operators, activating an ONT or router through gNMI does not preserve zero-touch operation if routine software and certificate work later requires a CLI session.

The architectural requirement is therefore to treat gNOI as a first-class operational interface. The OSS must be able to compose its actions with configuration and telemetry operations, apply consistent permissions, and retain their outcomes in the shared operational model. This is where device programmability becomes service-level accountability.