Operational Requirements for Network State Exchange in Agent-Assisted Network Operations

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 5 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The operational complexity of modern networks has grown substantially. Networks now span multiple autonomous systems (ASes), administrative domains, and technology layers. Network management tasks such as anomaly triage, incident correlation, fault localization, configuration consistency checking, and traffic engineering analysis require timely collection, synthesis, and interpretation of large amounts of network state.¶

Operators increasingly use automation and decision-support systems to reduce the time required to diagnose and respond to operational events. Some deployments may include agent-assisted components, including LLM-based agents, to help correlate alerts, summarize evidence, generate hypotheses, or prepare recommendations for human review. These components do not remove the need for existing management systems, telemetry pipelines, operator policy, or human accountability.¶

Agent-assisted operations introduce a practical state exchange problem. An analysis component may need to compare flow behavior across many routers, estimate the number of affected sources, identify configuration drift, or correlate symptoms across domains. Supplying raw telemetry to each component is often impractical because of data volume, privacy constraints, management-plane limits, and the latency of downstream analysis.¶

This document therefore focuses on requirements for network state artifacts consumed by agent-assisted or automated workflows. These artifacts can be generated downstream of existing telemetry mechanisms, including NETCONF [RFC6241], RESTCONF [RFC8040], YANG data models [RFC7950], IPFIX [RFC7011], gNMI [GNMI], YANG Push/message broker pipelines [I-D.ietf-nmop-yang-message-broker-integration], and telemetry message schemas [I-D.ietf-nmop-message-broker-telemetry-message].¶

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The following terms are used throughout this document:¶

Agent:

A software entity that assists a network management workflow by collecting context, correlating evidence, generating recommendations, or coordinating with other components. An agent may be driven by an LLM, a rule engine, a statistical model, or a combination of methods.¶

State Artifact:

A structured representation of network state exchanged between systems. A state artifact can contain raw state, derived state, or a compact summary, together with metadata describing its scope and provenance.¶

Sketch:

A probabilistic data structure that provides a compact, bounded-error summary of a multiset or set of network observations. Examples include Count-Min Sketch, HyperLogLog, DDSketch, MinHash, and Bloom Filter.¶

Sketch Merge:

The operation of combining two Sketch structures of the same type into a single structure whose estimates reflect the union of the underlying observation sets.¶

3. Conceptual Model and Workflow

The following figure shows a conceptual model for network state exchange in an agent-assisted operational workflow. Existing management and telemetry systems remain the sources of operational data. A generation function produces a state artifact that contains payload, scope, quality, provenance, and policy/audit information. The artifact can then be consumed locally, exchanged with another domain, merged with other artifacts, or referenced as evidence by an assisted workflow.¶

        Existing Management and Telemetry Systems
   +------------------------------------------------+
   | NETCONF | RESTCONF | YANG Push | IPFIX | gNMI |
   +------------------------+-----------------------+
                            |
                            v
                  +-------------------+
                  | State Artifact    |
                  | Generation        |
                  +---------+---------+
                            |
                            v
   +------------------------------------------------+
   | State Artifact                                 |
   |                                                |
   | +------------+  +------------+  +------------+ |
   | | Payload    |  | Scope      |  | Quality    | |
   | | raw,       |  | query,     |  | error,     | |
   | | derived,   |  | source,    |  | freshness, | |
   | | compact    |  | domain,    |  | confidence | |
   | | state      |  | time       |  |            | |
   | +------------+  +------------+  +------------+ |
   |                                                |
   | +------------+  +------------+                 |
   | | Provenance |  | Policy and |                 |
   | | source,    |  | Audit      |                 |
   | | method     |  | controls   |                 |
   | +------------+  +------------+                 |
   +--------------+------------------+--------------+
                  |                  |
                  v                  v
         +----------------+  +----------------+
         | Local Consumer |  | Peer or Domain |
         | agent, NMS,    |  | Artifact       |
         | incident tool  |  | Exchange       |
         +--------+-------+  +--------+-------+
                  |                   |
                  +---------+---------+
                            |
                            v
                  +-------------------+
                  | Merge and Time    |
                  | Alignment         |
                  +---------+---------+
                            |
                            v
                  +-------------------+
                  | Assisted Workflow |
                  | triage,           |
                  | correlation,      |
                  | recommendation    |
                  +---------+---------+
                            |
                            v
                  +-------------------+
                  | Operator Review   |
                  | and Existing      |
                  | Action Path       |
                  +-------------------+

The requirements in this document describe the expected properties of the state artifact and of the workflow steps that generate, exchange, merge, and consume it. The figure is illustrative and does not define a protocol architecture or a required deployment topology.¶

4. Problem Statement

Agent-assisted operational workflows may require broad network context across many devices and time windows. For example, incident triage may need recent interface counters, flow records, routing changes, topology information, device health indicators, and configuration differences. Sending raw telemetry to each analysis component can create excessive storage, transport, and processing overhead.¶

Operational workflows often need answers to specific questions rather than full raw records. Examples include:¶

• Which source prefixes are likely to be heavy hitters during an attack?¶

• How many distinct sources are observed across a domain?¶

• Which links show latency distributions that differ from a baseline?¶

• Which devices have configuration sets that are inconsistent with their peers?¶

• Which flows are likely affected by a reported incident?¶

Raw telemetry can answer these questions, but it may be unnecessarily expensive to exchange. Conversely, a summary that is too lossy, lacks error metadata, or cannot be audited can mislead an automated workflow. The challenge is to represent state at the right granularity for the operational question.¶

Some incidents cross administrative boundaries. Examples include distributed denial-of-service attacks, inter-domain reachability failures, and multi-provider service incidents. In such cases, operators may need to share selected state with peers or with a coordinating system. However, raw flow records, customer identifiers, topology details, and configuration fragments may be sensitive or subject to policy restrictions.¶

Compact or approximate state summaries can reduce data movement, but they introduce uncertainty. If an agent-assisted workflow consumes approximate state without understanding error bounds, time coverage, source scope, or freshness, it may generate incorrect conclusions or overconfident recommendations.¶

Existing telemetry and management mechanisms provide important capabilities, including schema-driven configuration and state access, streaming telemetry, flow export, and message-broker integration. However, deployments that introduce agent-assisted analysis still need guidance on what properties exchanged state artifacts should have so that they are compact, mergeable, bounded in error, privacy-aware, and auditable.¶

5. Requirements

This section defines initial operational requirements for network state exchange in agent-assisted network operations. The list is intended as a starting point for discussion.¶

6. Relationship to NMOP Work

This document is intended to complement existing NMOP work, rather than replace it.¶

The network anomaly architecture [I-D.ietf-nmop-network-anomaly-architecture], anomaly lifecycle [I-D.ietf-nmop-network-anomaly-lifecycle], and anomaly semantics [I-D.ietf-nmop-network-anomaly-semantics] describe how operational evidence can be collected, annotated, validated, and used in anomaly detection workflows. The requirements in this document focus on the properties of state artifacts that may feed such workflows.¶

The network incident YANG model [I-D.ietf-nmop-network-incident-yang] provides a structure for incident management. Compact state artifacts can be referenced as incident evidence or diagnostic inputs.¶

The YANG Push/message broker integration work [I-D.ietf-nmop-yang-message-broker-integration] and telemetry message model [I-D.ietf-nmop-message-broker-telemetry-message] address telemetry transport, schema, and provenance. Compact state artifacts can be generated downstream of such pipelines and should preserve relevant provenance and scope metadata.¶

7. Example Candidate: Sketch-Based State Summaries

Sketch structures are one candidate representation for compact state artifacts exchanged by agent-assisted workflows. Rather than transmitting raw flow records, routing tables, or interface statistics for every query, a deployment can exchange Sketch summaries that answer specific questions about network state with bounded or measurable error.¶

A Sketch is not a detection tool or anomaly detector. It is a candidate summary artifact that may be consumed by operational systems. Its usefulness depends on the operational query, selected parameters, acceptable error bounds, and audit requirements.¶

The appropriate Sketch type depends on the nature of the network state being represented and the queries agents need to answer:¶

If Sketches are used, their artifacts need to carry scope, freshness, provenance, and error metadata as described in the requirements above.¶

8. Initial Use Cases

This section lists initial use cases. More detailed operator use cases are expected in future revisions.¶

DDoS evidence exchange:

A domain can publish a compact heavy-hitter or cardinality summary as evidence for an incident workflow. A peer or coordinating system can use the artifact to assess whether an attack appears distributed without requiring raw flow records. Mitigation, if any, is performed through existing mechanisms such as FlowSpec [RFC8955] or local filtering procedures.¶

Multi-domain fault localization:

Domains can exchange latency or loss distribution summaries for aligned time windows. A coordinating workflow can identify where behavior deviates from baseline and request additional evidence from the relevant domain.¶

Configuration consistency verification:

A collector can publish compact configuration-set similarity artifacts. An audit workflow can identify devices that appear inconsistent and hand them to existing configuration management systems for operator review.¶

Traffic engineering analysis:

A traffic engineering workflow can consume summarized traffic matrix and latency artifacts to prepare recommendations. Any approved routing or policy change is applied through existing operational procedures.¶

9. Security Considerations

State artifacts exchanged over untrusted networks need authentication, integrity protection, and confidentiality appropriate to the sensitivity of the represented state.¶

Credential management should bind a consuming component to an operational role, administrative domain, and permitted state scope.¶

Sketch structures or other compact state artifacts could be tampered with to influence agent-assisted analysis. Transport security can prevent eavesdropping and impersonation, but deployments should also consider artifact-level integrity protection where artifacts are stored, forwarded, or consumed asynchronously.¶

An adversary with write access to a summary generation function could manipulate summaries to cause incorrect analysis or recommendations. Defenses include using keyed hash functions such as SipHash [SIPHASH] for Sketch index computation, cross-validating estimates from multiple independent sources, and monitoring for statistically anomalous summary patterns.¶

State generation and exchange functions can be targets for denial-of-service attacks. Implementations should enforce rate limits, quotas, back pressure, and admission control for artifact generation and retrieval.¶

Approximate state summaries can also leak information through repeated queries, low-cardinality sets, or correlation with external data. Sharing policies need to account for such leakage risks.¶

10. IANA Considerations

This document has no IANA actions.¶

11. References

Acknowledgments

TODO acknowledge.¶

Authors' Addresses