| Internet-Draft | NTI Problem Statement | July 2026 |
| Wu, et al. | Expires 7 January 2027 | [Page] |
AI-driven Network Management Agents (NMAs) are being deployed to automate operational workflows such as cross-domain fault diagnosis and service remediation. While the IETF has standardized service data models and access protocols through the Controller NBI (RFC 8969), these provide atomic configuration and monitoring capabilities, not the semantics for delegating end-to-end operational tasks to an autonomous agent. As a result, NMA northbound interfaces are vendor-specific overlays. This document defines the problem statement for the Northbound Task Interface (NTI): the interface through which an operator or OSS delegates operational tasks to an NMA.¶
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 7 January 2027.¶
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.¶
The IETF has standardized data models and access protocols for network service management through YANG [RFC7950], NETCONF [RFC6241], RESTCONF [RFC8040], and the Controller NBI architecture [RFC8969]. Within this framework, SDN Controllers expose standardized northbound interfaces for service configuration, operational state retrieval, and event notification. AI-driven Network Management Agents (NMAs) are being deployed within these Controllers to automate operational workflows -- such as fault diagnosis, service remediation, and what-if feasibility analysis -- that currently require human operators to decompose high-level goals into sequences of atomic data model operations.¶
However, while the Controller NBI provides the data models and access mechanisms for individual network operations, it does not provide the semantics for delegating an end-to-end operational task to an autonomous agent. The interface through which an operator or OSS/BSS delegates such tasks to an NMA, and receives structured feedback on execution progress, is implemented today as vendor-specific overlays. This document defines the problem statement for standardizing these interfaces, referred to as the Northbound Task Interface (NTI).¶
The IETF has standardized data models for network configuration, operational state, topology, performance monitoring, and service assurance, accessible through the Controller NBI using NETCONF, RESTCONF, and YANG-Push [RFC8641]. These interfaces provide deterministic operations on well-defined data structures: an OSS can retrieve an interface counter, modify a VPN parameter, or subscribe to an alarm stream. However, accomplishing an operational goal -- such as diagnosing and remedying a VPN service degradation -- requires the OSS to sequence and correlate multiple such atomic operations across independent YANG modules, interpret intermediate results, and decide on subsequent actions. The NBI provides the data and the operations, but not the semantics for delegating the end-to-end goal as a unitary task.¶
NMAs address this by internally decomposing operational goals into NBI operations, executing them, and verifying outcomes. Because the NMA resides within the Controller and uses the standardized NBI as its southbound interface, its internal reasoning is decoupled from the consumer. Yet the northbound interface through which the consumer delegates the goal and monitors progress remains vendor- specific. In multi-vendor environments, operators must therefore maintain distinct integration logic per Controller. The gap is not in the data models or the access protocols, but in the task- abstraction layer above them. Existing standards define how to operate on network resources; what is missing is a standardized interface for expressing an operational intent, tracking its execution lifecycle, negotiating when constraints conflict, and discovering what autonomous capabilities an NMA supports.¶
This document defines the problem statement for the Northbound Task Interface (NTI): the interaction through which an operator or OSS/BSS delegates operational tasks to an NMA and receives structured feedback on execution progress, capability boundaries, and task outcomes.¶
The following are explicitly out of scope:¶
Internal NMA implementation: The data models, algorithms, or reasoning mechanisms used by the NMA to decompose tasks into southbound operations. The NTI standardizes the northbound contract, not the internal implementation.¶
Agent-to-Agent (A2A) protocols: Inter-NMA negotiation, cross-domain task delegation, and multi-agent coordination. These are addressed by other opensource projects, or other SDO, e.g. TMF. The NTI is complementary: it standardizes how a single NMA exposes capabilities and reports progress to its consumer.¶
Southbound data models: The NTI layers task semantics atop existing IETF data models without defining new device-level or service-level configuration structures.¶
Transport protocol definition: The NTI standardizes the semantics and information model for task delegation. Whether these semantics are carried over RESTCONF, NETCONF, or another existing IETF protocol is a matter for subsequent work.¶
The scenarios below do not argue that AI-driven diagnosis is superior to existing automation; they demonstrate that when an NMA is capable of autonomous reasoning, the absence of a standardized task interface forces the OSS to integrate with vendor-specific overlays.¶
Scenario: A gold-tier enterprise L3VPN service (VPN-Corp-A) experiences bursty quality degradation during peak hours. End users report application timeouts and video conference freezes. Network monitoring shows periodic packet loss bursts (2-5 seconds, several times per hour) with rapid recovery. Traditional threshold-based alarms cannot reliably detect this: the loss bursts are too brief to trigger sustained alarm conditions, and average loss over 5-minute intervals remains within normal range.¶
The Controller NBI exposes YANG models for VPN service configuration (ietf-l3vpn-ntw), VPN performance monitoring [RFC9375], alarm notification [RFC8632], topology [RFC8345], service assurance [RFC9418], and interface state [RFC8343]. The OSS can retrieve VPN routing state, query interface counters, subscribe to telemetry streams, and receive threshold-crossing alarms.¶
The operator's goal is not to "retrieve counters" but to "restore VPN-Corp-A to contracted SLA (packet loss < 0.1%, latency < 50ms) and identify the root cause." Achieving this goal requires correlating transient events across multiple data sources over time, which the existing NBI does not support as a delegable task.¶
Specifically, the diagnostic process involves:¶
Detecting the micro-burst pattern (2-5 second loss) that does not trigger sustained alarms, requiring high-frequency telemetry analysis.¶
Localizing the fault to ingress PE, egress PE, or core P-node path by correlating interface drop counters across nodes.¶
Identifying the root cause: congestion, routing instability, MTU mismatch, or link-level errors.¶
Selecting and executing remediation (QoS adjustment, BGP policy tuning, protection switching, etc.).¶
Verifying that the micro-burst pattern disappears and SLA metrics are restored.¶
The gap: The existing NBI provides all the raw data for steps 1-5, but no semantics to delegate the end-to-end goal. The OSS must either implement all correlation and reasoning logic itself, or integrate with a vendor-specific NMA interface. In a multi-vendor network, the latter requires distinct integration logic per Controller vendor.¶
Scenario: A 5G base station (gNB-001) connects to the IPRAN access network via a single fiber pair to PE-agg-01. The operator observes service degradation for cells served by gNB-001. The goal is to determine whether the root cause lies in the IP transport domain or the RAN access domain, and to restore service or prepare a structured human repair action. The IP domain Controller has a co-resident NMA. The RAN domain is managed by a separate Controller with limited northbound data exposure.¶
The IP domain Controller NBI exposes YANG models for interface state (ietf-interfaces), performance monitoring (ietf-network-vpn-pm), and other necessary metrics. The OSS can query these directly.¶
The operator's goal is not to "query interface counters" but to "determine the root cause and restore service, or prepare a structured human repair action if the fault is physical." This goal spans both domains, but the OSS must perform the correlation itself.¶
The NMA in the IP domain can:¶
Query the gNB-001 attachment interface on PE-agg-01: admin-up, oper-down. Optical RX power on PE-agg-01: -28dBm (below receiver sensitivity of -20dBm). Optical TX power on PE-agg-01 is within normal range. Conclusion: PE-agg-01 is transmitting normally but receiving no usable light.¶
Infer fiber plant status from available IP-domain data: the interface on PE-agg-01 shows no administrative disable, no protection switching events, and no interface-level alarms beyond the loss of signal. The optical transceiver on PE-agg-01 reports that a faint optical signal is detected on the receive side, though insufficient for data reception. Conclusion: there is no positive evidence of a fiber break observable from the IP domain; the fault appears to be upstream of PE-agg-01.¶
Query Layer 2/Layer 3 reachability: no ARP response or ICMP echo reply from gNB-001. The faint optical signal detected on PE-agg-01 indicates the remote transmitter is emitting weak light. Conclusion: gNB-001 is powered but data signal is insufficient.¶
Query RAN domain status: gNB-001 reported as "administratively online" by RAN OAM 5 minutes ago, but current status query times out. No "site power loss" alarm. Conclusion: base station likely has power but management/data paths are non-functional.¶
Correlate findings: optical RX below threshold, no positive evidence of fiber break from IP domain data, PE-agg-01 TX normal, gNB-001 emits weak signal but no protocol response, no power alarm. Root cause inference: gNB-001 optical transceiver (TX side) degraded or failed, or there is a partial fiber fault between gNB-001 and PE-agg-01 that severely attenuates the signal. IP domain equipment is not at fault, though the exact boundary of the failure (gNB-001 transceiver vs. fiber plant) cannot be determined from IP-domain data alone.¶
Determine: physical inspection or repair at gNB-001 site is required. Possible actions include optical transceiver replacement at gNB-001, fiber cleaning, or fiber plant testing. No autonomous remediation available. Task cannot be fully closed without human repair action.¶
The gap: At step 6, the NMA has completed diagnosis but cannot complete remediation. The OSS needs:¶
Task status: not "success" or "failure," but "diagnosed, human repair action required"¶
Structured human repair data: location, action, estimated duration, business impact¶
Evidence trace: references to YANG-modeled data supporting the diagnosis¶
The existing NBI provides no semantics for the NMA to report such a structured conclusion. The OSS must either perform this correlation itself or integrate with each vendor's proprietary diagnostic output. In a multi-vendor deployment, diagnostic quality, repair dispatch workflows, and programmatic verifiability remain vendor-specific.¶
The operational scenarios in Section 2 reveal the following gaps, which a standardized NTI would need to address.¶
Current NMA northbound interfaces are implemented as vendor- specific constructs: proprietary REST APIs, gRPC schemas, or conversational prompt templates. In multi-vendor environments, operators must integrate with each of these variations individually.¶
The gap is the absence of a common, machine-readable structure for expressing operational goals, constraints, and execution feedback. Whether such a structure is expressed in YANG, JSON Schema, or another formalism is a matter for subsequent standardization work.¶
The existing Controller NBI enables the OSS to operate on network resources -- modify a VPN parameter, retrieve a metric, subscribe to an alarm stream. However, the operator's goal is often expressed at a higher level: "restore VPN-X to its SLA within 30 minutes."¶
The gap is that current NMA interfaces either expose the same data operations as the NBI (forcing the OSS to decompose the goal itself) or accept goals through proprietary, unstructured formats. There is no standardized mechanism for expressing an operational intent with its associated constraints and success criteria.¶
Current vendor NMA interfaces use divergent models for tracking task execution. One vendor may report "submitted -> in_progress -> done -> failed"; another may use "accepted -> analyzing -> acting -> verifying -> closed"; a third may expose no intermediate states at all, requiring the OSS to poll for completion.¶
The gap is the absence of common semantics for expressing task progress, partial completion, suspension awaiting human input, or handover to another system. Operators cannot build unified dashboards or automated escalation workflows without normalizing these divergent state models.¶
When an NMA reports a diagnostic conclusion or remediation result, the consumer needs to verify it against the network state. Current vendor implementations use proprietary formats for referencing incidents, alarms, performance metrics, and topology resources.¶
The gap is the absence of a standardized mechanism for NMA outputs to reference existing IETF data model instances -- such as an ietf-network-incident record, an ietf-alarms instance, or an ietf-network-vpn-pm metric -- by standard identifier. Without this, the consumer cannot programmatically correlate NMA conclusions with the underlying network data.¶
Operators managing multi-vendor networks lack a standardized mechanism to determine what tasks an NMA supports without vendor- specific integration. Capability information is typically conveyed in human-readable documentation or proprietary API descriptors, not in a machine-consumable structure that an OSS can query and act upon. For example, one vendor's NMA may support autonomous VPN fault remediation; another's may only support advisory diagnosis.¶
Some current NMA implementations expose operations through their northbound interface that are already available through the Controller NBI -- such as VPN service creation, tunnel parameter modification, or QoS policy adjustment. This creates ambiguity for the consumer: should the OSS use the standardized NBI directly, or the NMA's proprietary interface for the same operation?¶
The gap is the absence of a clear boundary between the task layer (what goal to achieve) and the data layer (how to configure a resource).¶
When an NMA performs autonomous remediation, the operator needs to define and enforce boundaries: what actions may be taken without human confirmation, under what time constraints, and with what scope limitations. Current vendor implementations use proprietary authorization models -- some support per-task risk levels, others use static allow-lists, others provide no programmatic control at all.¶
The gap is the absence of a standardized mechanism for the consumer to express authorization constraints to the NMA and for the NMA to report compliance with those constraints.¶
Current NMA interfaces require the OSS to either poll for task status or maintain vendor-specific event subscriptions. In multi- vendor environments, this forces the OSS to implement multiple notification mechanisms -- REST callbacks, gRPC streams, or proprietary message formats.¶
The gap is the absence of common semantics for notifying the consumer of task progress, partial completion, or state transitions that require human attention. Whether these notifications are delivered via YANG-Push, HTTP callbacks, or another mechanism is a matter for subsequent standardization.¶
The NTI is a consumer of existing IETF specifications and complementary to other SDO work; it is not a replacement.¶
RFC 8969 [RFC8969] defines the architecture for a YANG-based controller northbound interface. The NTI assumes this architecture: the NMA resides within or alongside the Controller and consumes the NBI for southbound operations. The NTI operates at the layer above the NBI, where operational tasks are delegated to the NMA and execution progress is reported back.¶
[I-D.ietf-nmop-yang-message-broker-integration] defines an architecture for integrating YANG-Push notifications with message brokers and schema registries. The NTI may reference data distributed through this architecture as part of Task Context. The NTI consumes standardized data; it does not redefine the distribution mechanisms.¶
RFC 9315 [RFC9315] defines Intent-Based Networking (IBN) concepts for expressing network service and resource configuration objectives. The NTI addresses a distinct but related scope: operational task delegation -- such as fault diagnosis, service assurance remediation, and what-if analysis -- rather than network resource configuration. The two may be used together, but neither depends on the other.¶
RFC 9417 [RFC9417] and RFC 9418 [RFC9418] define the SAIN architecture and YANG models for health scores, symptoms, and assurance graphs. The NTI may reference SAIN-modeled data in Task Context or execution results, but does not define assurance data structures; it references them by standard identifier.¶
[I-D.zhao-nmop-network-management-agent] defines the NMA concept, architecture variants, and deployment modes. It identifies the need for a northbound task interface but does not define its semantics. This document provides the problem statement motivating that standardization work.¶
[I-D.ietf-nmop-network-incident-yang] defines a YANG model for network incident lifecycle management. The NTI may reference incident instances in Task Context, but does not define incident structures.¶
[I-D.yu-ccamp-resource-pm-yang] defines a YANG model for resource performance monitoring. The NTI may reference resource PM data in Task Context or execution results, but does not define PM data structures.¶
TMF IG1453 (A2A-T) [A2A-T] defines generic task templates, event structures, and negotiation semantics for cross-domain multi-agent collaboration. The NTI addresses a related but distinct scope: how a single NMA exposes task delegation, capability, and progress reporting to its consumer using IETF management protocol identifiers. Where an operator uses A2A-T for inter-domain coordination, the NTI defines how those same task concepts are expressed within the IETF management stack. The two are complementary and not overlapping.¶
Standardization of the NTI would introduce the following security considerations, which are distinct from those of the underlying management protocols (NETCONF, RESTCONF) due to the higher semantic level of task delegation.¶
Intent Injection: A compromised consumer could submit malicious goals that trigger unintended autonomous actions across the network. This risk is analogous to configuration injection but operates at a higher semantic level where a single task maps to multiple underlying operations. Standardization of the NTI would need to consider how intent authentication, authorization, and scope validation relate to existing mechanisms such as NACM [RFC8341].¶
Information Leakage: NTI responses may contain diagnostic conclusions, evidence traces, or capability descriptions that reveal internal network topology, resource utilization, or operational weaknesses. Standardization would need to consider how response content is authorized and filtered, potentially leveraging access control frameworks such as NACM [RFC8341].¶
Concurrent Operation Conflicts: In deployments where both the NTI and direct NBI access are available, a task delegated through the NTI may overlap with manual NBI operations. This creates potential for race conditions. Standardization would need to make such conflicts visible and auditable.¶
This document makes no requests of IANA.¶
In today's multi-vendor deployments, an OSS managing VPN service assurance must interact with each Controller's NBI directly. For a fault diagnosis task, the OSS typically:¶
Subscribes to alarm streams via YANG-Push¶
Retrieves performance metrics from ietf-network-vpn-pm¶
Queries topology from ietf-network-topology¶
Correlates findings in custom application logic¶
Decides on remediation actions¶
Executes configuration changes via NETCONF/RESTCONF¶
Verifies recovery through repeated metric queries¶
Steps 1-7 must be implemented per vendor, as each Controller may expose different YANG module versions, different notification mechanisms, or different RPC signatures. The orchestration logic -- state machines, error handling, retry policies, correlation rules -- is maintained in the OSS layer.¶
When an NMA exists within the Controller, capable of performing steps 1-7 internally, the OSS currently has no standardized interface to delegate the goal. Instead, the OSS must either continue executing steps 1-7 itself, or integrate with the vendor's proprietary task interface, replicating this integration for each Controller vendor.¶
The NTI would address this gap by providing standardized semantics for the OSS to express the operational goal, receive progress updates, and obtain structured results -- without requiring the OSS to know how the NMA internally decomposes the task into NBI operations.¶
The following diagram illustrates the conceptual relationship between the layers.¶
Traditional approach (YANG APIs) NTI approach
============================== =====================
OSS / Orchestrator OSS / Orchestrator
| |
+--------+--------+ +--------+--------+
| | | |
v v v |
Alarm PM Topology NTI task submission |
Model Model (goal + constraints)
| | | |
+--------+--------+ | |
| | |
OSS local orchestration | |
logic | |
| v |
v NMA internal
Controller NBI (RFC 8969) orchestration & reasoning
| | |
v v |
Network devices Controller NBI
(RFC 8969)
|
v
Network devices