When NETCONF Is Not Enough: Applicability of MCP and A2A for Advanced Network Management Scenarios

NETCONF remains the gold standard for network configuration transactions. However, five emerging scenarios expose its fundamental limitations:

(1) AI natural-language intent
(2) Long-flow cross-controller orchestration
(3) multi-agent consensus
(4) weekly DevOps release cycles
(5) multi-modal artifact delivery

This document identifies objective gaps and specifies when and how MCP and A2A should be engaged.

This section enumerates the fundamental gaps between NETCONF and the advanced management scenarios introduced in Section 1. For each gap, the table below identifies:

the missing capability,
its root cause in NETCONF design, and
the protocol (MCP or A2A) that natively provides it.

Gap	Root Cause in NETCONF	MCP/A2A Solution
AI Semantic Layer	XML-centric, no function registry	MCP /tools/list + JSON-Schema
Long-Flow Orchestration	No Task life-cycle or human-in-the-loop	A2A Task state machine
Multi-Agent Consensus	Client-server only; no peer negotiation	A2A AgentCard + Message
Weekly DevOps Iteration	YANG revision 6-9 months; firmware lock	MCP Tool hot-register
Large Artifact Delivery	64 kB chunk; no MIME/hash/URL	MCP/A2A Artifact (cloud URL)

The gaps are not implementation defects but architectural invariants of RFC 6241. They become blocking only in the five advanced scenarios identified. Outside these scenarios, NETCONF continues to provide the most robust configuration transactions and should remain the south-bound protocol of choice.

Operators increasingly expect to issue instructions in natural language: “Raise MTU to 9000 for all Beijing core switches” or “Block source 1.2.3.4 for 30 minutes”. NETCONF requires an edit-config XML blob with exact leaf names and namespaces; even experienced engineers make syntax mistakes under time pressure. The root cause is architectural:

XML is attribute-heavy and case-sensitive; forgotten namespaces or mismatched quotes silently fail.
There is no machine-discoverable “function catalogue” — an LLM must rely on static prompt examples which drift as models evolve.
Multi-vendor differences (OpenConfig vs. proprietary YANG) force the LLM to choose branches inside the XML, exploding prompt size.

MCP solves these issues with three primitives:

/tools/list — JSON array of callable functions, each carrying human-readable description and JSON-Schema input.
JSON-Schema — strong-typed, no namespaces, direct mapping to primitive types (string, integer, enum, array).
JSON-RPC 2.0 — single-line request/response, easily parsed by LLM and by controller gateways.

Example MCP Tool Descriptor (simplified):

The LLM now produces:

Cloud-era value-added services must be deployed within days, not months. NETCONF's revision cycle (IETF draft → RFC: 6-9 months) and firmware upgrade windows (≤ 1 per year) are incompatible with weekly release trains. The blocking points are:

YANG module must be burned into firmware before the first config leaf is usable;
Controller regression suite recompiles the entire YANG tree even for a single new leaf;
Backward-compatibility review (must not break old devices) stretches internal QA to weeks.

MCP breaks the deadlock by treating "intent" as a hot-swappable Tool rather than a permanent YANG node:

Private YANG is compiled to JSON-Schema in the controller (milliseconds);
Tool registers via /tools/register and is immediately callable;
Gray-list rollout (10 % → 30 % → 100 %) and instant rollback (re-register previous Tool) are done without touching device flash.

Example: Cloud-Shield DDoS Cleaning Service

Compiled JSON-Schema and registered in 30 s:

Thus MCP is mandatory for any management surface that must support weekly or daily release cycles without waiting for firmware or standards body timelines.

Maintenance windows for core-network upgrades often exceed 30 minutes and span multiple vendor domains. NETCONF provides atomic configuration on a single controller, but lacks:

a cross-vendor task life-cycle,
human-in-the-loop approval gates, and
delivery of large artifacts (firmware, images, diff reports).

A2A fills these gaps with three primitives:

Task — state machine (pending → working → completed/failed/cancelled) persisting across agent restarts;
Artifact — hash-signed object store (≤ 2 GB, resumable upload);
Message — multi-round negotiation (JSON or natural language).

A2A Task States vs. NETCONF Operations

State	Meaning	NETCONF Equivalent
pending	Waiting for resources or approval	None (RPC is fire-and-forget)
awaiting-human-approval	Human must click approve/cancel	None
working	Agents executing sub-tasks	edit-config (local only)
completed	All agents report success	commit
failed	Any agent reports failure	rollback-on-error
cancelled	Operator or policy cancelled	discard-changes

Real-World Example: Five-City Core MTU Migration

Step-wise A2A Flow (time-stamps):

T+0 min: Orchestrator creates Task T100, goal="Raise MTU to 9000 on core links".
T+5 min: Each controller Agent posts Artifact pre-check.csv (link health KPI).
T+10 min: Orchestrator Artifact hash-verified; human approval card sent to WeChat.
T+15 min: Engineer clicks "approve"; Task state → working.
T+20-90 min: Controllers download 2 GB image via Artifact URL; local NETCONF edit-config issued; progress Artifacts streamed every 5 min.
T+95 min: Last Artifact post-upgrade-verification.csv uploaded.
T+100 min: All agents report success; Task → completed. Total human intervention: 1 click.

A2A is mandatory for any multi-vendor, multi-hour workflow that demands task persistence, human gates, and multi-gigabyte artifact delivery—scenarios where NETCONF's single-controller, single-RPC paradigm is insufficient.

Fault recovery, security mitigation and resource optimisation often require multiple autonomous agents (monitoring, security, controller, human) to reach a common decision. NETCONF's strict client-server model provides no peer-to-peer capability advertisement, multi-round negotiation or voting primitives. A2A introduces three building blocks:

AgentCard — JSON-LD advertisement of skills and endpoint;
Message — multi-round negotiation (JSON or natural language);
Consensus Engine — policy-based scoring, voting, human-in-the-loop.

AgentCard Mandatory Fields

Field	Description	Example Value
id	globally unique agent identifier	monitor-sh-01
skills	array of skill objects (name, description)	{name: "threat_analyze", desc: "Return 0-10 threat score"}
endpoint	HTTPS URL for A2A messages	https://mon-sh.example:9443/a2a
authentication	mTLS + OIDC	{"type": "mTLS", "sha256": "8f66..."}

Consensus Flow Example: DDoS Port Shutdown

Message Sequence (time-stamps):

T+0 s: Monitor Agent posts threat_score=9.0 via Message.
T+5 s: Security Agent confirms attack signature; score unchanged.
T+10 s: Controller Agent posts impact=300 VPN down; computed score = 9×0.6 + 3×0.4 = 6.6 (> 5.0).
T+12 s: Task state → awaiting-human-approval; WeChat card sent.
T+135 s: Human clicks "approve".
T+140 s: Controller Agent calls NETCONF shutdown; Artifact post-action.log uploaded.
T+180 s: All agents report success; Task → completed.

Therefore A2A is mandatory whenever multiple autonomous agents must discover, negotiate, vote and reach a binding decision — scenarios that NETCONF's unidirectional client-server paradigm cannot emulate.

This section describes how MCP and A2A can be deployed without forcing a redesign of the existing NETCONF ecosystem. The architecture keeps NETCONF as the configuration authority and allows either controller-hosted or device-hosted MCP servers — the latter avoids a central gateway bottleneck while preserving operator investment in controllers.

TBD

MCP and A2A introduce OAuth2/JWT and long-lived Tasks.