Network Working Group G. Zeng Internet-Draft J. Mao Intended status: Standards Track B. Liu Expires: 6 May 2026 N. Geng X. Shang Q. Gao Z. Li Huawei 2 November 2025 When NETCONF Is Not Enough: Applicability of MCP and A2A for Advanced Network Management Scenarios draft-zeng-opsawg-applicability-mcp-a2a-00 Abstract NETCONF provides robust configuration transactions and YANG-based data models, but falls short in scenarios requiring AI-driven semantic translation, long-lived cross-domain orchestration, multi- agent consensus, rapid DevOps iteration, or delivery of large non- configuration artifacts. This document systematically analyzes the functional gaps and presents Model Context Protocol (MCP) and Agent- to-Agent (A2A) as complementary solutions. Implementation guidance and coexistence models are also provided. 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 6 May 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Zeng, et al. Expires 6 May 2026 [Page 1] Internet-Draft MCP-A2A-Gap November 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Gap Analysis Summary . . . . . . . . . . . . . . . . . . . . 3 3. When MCP Must Be Used . . . . . . . . . . . . . . . . . . . . 3 3.1. AI Natural-Language Intent . . . . . . . . . . . . . . . 4 3.2. Rapid Model Iteration (DevOps Week-Release) . . . . . . . 5 4. When A2A Must Be Used . . . . . . . . . . . . . . . . . . . . 6 4.1. Cross-Controller Long-Flow Orchestration . . . . . . . . 6 4.2. Multi-Agent Consensus (Agent-to-Agent) . . . . . . . . . 8 5. Coexistence Model . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Design Choices at a Glance . . . . . . . . . . . . . . . 10 5.2. Common Layering . . . . . . . . . . . . . . . . . . . . . 10 5.3. Controller-Gateway Model . . . . . . . . . . . . . . . . 10 5.4. Device-Embedded Model . . . . . . . . . . . . . . . . . . 10 5.5. Migration Roadmap . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . 10 8. Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction NETCONF [RFC6241] 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 Zeng, et al. Expires 6 May 2026 [Page 2] Internet-Draft MCP-A2A-Gap November 2025 This document identifies objective gaps and specifies when and how MCP [I-D.yang-nmrg-mcp-nm] and A2A [I-D.google-agent2agent] should be engaged. 2. Gap Analysis Summary 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 | MCP /tools/list | | | function registry | + JSON-Schema | +-------------------+-----------------------+------------------+ | Long-Flow | No Task life-cycle or | A2A Task state | | Orchestration | human-in-the-loop | machine | +-------------------+-----------------------+------------------+ | Multi-Agent | Client-server only; | A2A AgentCard + | | Consensus | no peer negotiation | Message | +-------------------+-----------------------+------------------+ | Weekly DevOps | YANG revision 6-9 | MCP Tool hot- | | Iteration | months; firmware lock | register | +-------------------+-----------------------+------------------+ | Large Artifact | 64 kB chunk; no | MCP/A2A Artifact | | Delivery | MIME/hash/URL | (cloud URL) | +-------------------+-----------------------+------------------+ Table 1 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. 3. When MCP Must Be Used Zeng, et al. Expires 6 May 2026 [Page 3] Internet-Draft MCP-A2A-Gap November 2025 3.1. AI Natural-Language Intent 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): { "name": "batch_set_mtu", "description": "Set interface MTU on multiple devices", "inputSchema": { "type": "object", "properties": { "device_group": {"type": "string"}, "mtu": {"type": "integer", "minimum": 576, "maximum": 9216} }, "required": ["device_group", "mtu"] } } Figure 1 The LLM now produces: Zeng, et al. Expires 6 May 2026 [Page 4] Internet-Draft MCP-A2A-Gap November 2025 { "jsonrpc": "2.0", "method": "batch_set_mtu", "params": {"device_group": "beijing-core", "mtu": 9000}, "id": 1 } Figure 2 3.2. Rapid Model Iteration (DevOps Week-Release) 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 Private YANG (120 lines) +--rw start-cleanse | +--rw target-ip inet:ipv4-address | +--rw bandwidth-Mbps uint32 | +--rw duration-min uint16 Figure 3 Compiled JSON-Schema and registered in 30 s: Zeng, et al. Expires 6 May 2026 [Page 5] Internet-Draft MCP-A2A-Gap November 2025 { "name": "start_cleanse", "version": "1.0.0", "description": "Start DDoS cleanse for target IP", "inputSchema": { "type": "object", "properties": { "target_ip": {"type": "string", "format": "ipv4"}, "bandwidth_Mbps": {"type": "integer", "minimum": 100, "maximum": 100000}, "duration_min": {"type": "integer", "minimum": 5, "maximum": 1440} }, "required": ["target_ip", "bandwidth_Mbps"] } } Figure 4 Thus MCP is mandatory for any management surface that must support weekly or daily release cycles without waiting for firmware or standards body timelines. 4. When A2A Must Be Used 4.1. Cross-Controller Long-Flow Orchestration 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). Zeng, et al. Expires 6 May 2026 [Page 6] Internet-Draft MCP-A2A-Gap November 2025 +=========================+================+===================+ | State | Meaning | NETCONF | | | | Equivalent | +=========================+================+===================+ | pending | Waiting for | None (RPC is | | | resources or | fire-and-forget) | | | approval | | +-------------------------+----------------+-------------------+ | awaiting-human-approval | Human must | None | | | click approve/ | | | | cancel | | +-------------------------+----------------+-------------------+ | working | Agents | edit-config | | | executing sub- | (local only) | | | tasks | | +-------------------------+----------------+-------------------+ | completed | All agents | commit | | | report success | | +-------------------------+----------------+-------------------+ | failed | Any agent | rollback-on-error | | | reports | | | | failure | | +-------------------------+----------------+-------------------+ | cancelled | Operator or | discard-changes | | | policy | | | | cancelled | | +-------------------------+----------------+-------------------+ Table 2: A2A Task States vs. NETCONF Operations Real-World Example: Five-City Core MTU Migration Controllers: Huawei NCE (3 cities) + Cisco NSO (2 cities) Devices: 312 PE routers Window: 120 min (02:00-04:00) Artifact: 2 GB firmware image + 40 MB diff-report Figure 5 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). Zeng, et al. Expires 6 May 2026 [Page 7] Internet-Draft MCP-A2A-Gap November 2025 * 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. 4.2. Multi-Agent Consensus (Agent-to-Agent) 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. Zeng, et al. Expires 6 May 2026 [Page 8] Internet-Draft MCP-A2A-Gap November 2025 +================+==================+==========================+ | Field | Description | Example Value | +================+==================+==========================+ | id | globally unique | monitor-sh-01 | | | agent identifier | | +----------------+------------------+--------------------------+ | skills | array of skill | {name: "threat_analyze", | | | objects (name, | desc: "Return 0-10 | | | description) | threat score"} | +----------------+------------------+--------------------------+ | endpoint | HTTPS URL for | https://mon- | | | A2A messages | sh.example:9443/a2a | +----------------+------------------+--------------------------+ | authentication | mTLS + OIDC | {"type": "mTLS", | | | | "sha256": "8f66..."} | +----------------+------------------+--------------------------+ Table 3: AgentCard Mandatory Fields Consensus Flow Example: DDoS Port Shutdown Agents: Monitor, Security, Controller, Human Decision: shutdown port 10/1 ? Scoring: threat_level×0.6 + impact×0.4 Threshold: ≥ 5.0 → shutdown Figure 6 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. Zeng, et al. Expires 6 May 2026 [Page 9] Internet-Draft MCP-A2A-Gap November 2025 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. 5. Coexistence Model 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. 5.1. Design Choices at a Glance TBD 5.2. Common Layering TBD 5.3. Controller-Gateway Model TBD 5.4. Device-Embedded Model TBD 5.5. Migration Roadmap TBD 6. Security Considerations MCP and A2A introduce OAuth2/JWT and long-lived Tasks. 7. Normative References [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC9200] Tschofenig, H., "Guidelines for Using the Transport Layer Security (TLS) Protocol in Devices", RFC 9200, DOI 10.17487/RFC9200, March 2022, . Zeng, et al. Expires 6 May 2026 [Page 10] Internet-Draft MCP-A2A-Gap November 2025 8. Informative References [I-D.yang-nmrg-mcp-nm] Yang, Y., "Applicability of MCP for the Network Management", Work in Progress, Internet-Draft, draft-yang- nmrg-mcp-nm-00, July 2025, . [I-D.google-agent2agent] Google., "Agent-to-Agent (A2A) Protocol", Work in Progress, Internet-Draft, draft-google-agent2agent-00, May 2025, . Authors' Addresses Guanming Zeng Huawei Email: zengguanming@huawei.com Jianwei Mao Huawei Email: maojianwei@huawei.com Bing Liu Huawei Email: leo.liubing@huawei.com Nan Geng Huawei Email: gengnan@huawei.com Xiaotong Shang Huawei Email: shangxiaotong@huawei.com Qiangzhou Gao Huawei Email: gaoqiangzhou@huawei.com Zeng, et al. Expires 6 May 2026 [Page 11] Internet-Draft MCP-A2A-Gap November 2025 Zhenbin Li Huawei Email: robinli314@163.com Zeng, et al. Expires 6 May 2026 [Page 12]