Summary

  • AI4AN’s main proposal is to use an LLM chiefly to develop network-automation software, test it in a simulation environment and deliver it as an Autonomic Service Agent, rather than relying only on a model to make live network decisions.
  • That separation changes where assurance must land: the draft contemplates router interfaces with extensive privileges, while its -01 Security Considerations section is still marked “TBD.” The document is a proposal, not evidence of a deployed system or an IETF standard.

A different job for the model

The familiar “AI for NetOps” picture places a model outside the network. It studies telemetry, summarizes incidents or recommends a configuration while existing control and management systems continue to run the devices. The AI4AN draft starts from the limits of that arrangement. A central NOC agent can assist an operator, but the network itself remains dependent on established automation and protocols.

Toerless Eckert and Alexander Clemm propose a second pattern. In the draft, an Agentic Network DevOps Center receives programming intent, interprets it and uses an LLM to develop the automation software that would perform network functions. The model is meant primarily to write the program; the program, packaged as an Autonomic Service Agent (ASA), would execute on network equipment. The draft does not say that direct agentic LLM control must disappear. It explicitly leaves direct use available where feasible. Its architectural preference is to put a software layer between model reasoning and device action.

That distinction matters because a generated program can, in principle, be inspected, versioned and tested before it is installed. A network simulation can exercise cases that would be risky to test on a live service. The draft also mentions exhaustive testing and, where possible, model-driven or formal validation. Those are proposed techniques, not published acceptance thresholds: the text does not provide a coverage target, benchmark or evidence that an operator has deployed an AI4AN ASA.

The device becomes the trust boundary

AI4AN is built on ANIMA’s idea of autonomic service agents: software components that cooperate across some or all devices to provide network automation. The draft’s diagram places the agent-development environment above an execution plane on network equipment, alongside legacy control and management processes. It depicts existing infrastructure such as the Autonomic Control Plane (ACP), BRSKI bootstrapping and GRASP coordination. Those RFC-defined components supply context for the proposal; they do not make AI4AN an adopted standard.

The device interface section makes the operating stakes unusually concrete. It describes an agent environment that may need router CLI access up to the highest privilege level, read/modify/write/delete access to the router filesystem, connections to management or protocol sockets, and hardware or software diagnostic interfaces. These are capabilities the draft contemplates, not a claim that every ASA must receive them or that they are already deployed.

The version-01 Security Considerations section is marked “TBD.” That is a conspicuous unfinished part of the proposal, but it is not proof that the design is insecure. It does mean that the draft has not yet established how generated code is authenticated, how privileges are bounded, how tests relate to production state, or how an operator withdraws a faulty agent. Those are questions for subsequent specifications and implementations.

Why Eckert’s contribution matters

Eckert is an author of the AI4AN draft with Alexander Clemm and chairs the ANIMA working group. At IETF 126, the two presented the proposal and the meeting record captures discussion of several competing paths: an LLM inside an autonomic control loop, a model limited to constrained parameter optimization, or a model used as a development and deployment assistant for deterministic ASAs. The minutes record discussion, not consensus, working-group adoption or approval of a recharter.

The contribution is useful because it moves the argument from “is the model smart enough?” to “what software runs, under whose authorization, on which devices?” If the model remains a developer tool, the operator can review a code artifact. If the resulting agent is installed, however, the durable actor is that artifact and its runtime permissions. Trust must cover the path from prompt and source inputs through generated code, tests, signing, rollout and rollback.

What would count as evidence

Note 65’s Running-Code Primacy supplies an editorial test, not a fact about Eckert: a published design is not the same as local validation, implementation, adoption and behavior in running systems. For AI4AN, meaningful next evidence would include a revised security section, reproducible test environments, an explicit artifact and update chain, least-privilege device interfaces, and independent implementations or operator trials. Until then, the draft is a design proposal whose most consequential boundary is visible but not yet fully specified.

Sources