



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,
              <https://www.rfc-editor.org/rfc/rfc6241>.

   [RFC9200]  Tschofenig, H., "Guidelines for Using the Transport Layer
              Security (TLS) Protocol in Devices", RFC 9200,
              DOI 10.17487/RFC9200, March 2022,
              <https://www.rfc-editor.org/rfc/rfc9200>.



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,
              <https://datatracker.ietf.org/doc/html/draft-yang-nmrg-
              mcp-nm-00>.

   [I-D.google-agent2agent]
              Google., "Agent-to-Agent (A2A) Protocol", Work in
              Progress, Internet-Draft, draft-google-agent2agent-00, May
              2025, <https://datatracker.ietf.org/doc/html/draft-google-
              agent2agent-00>.

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]
