Using the Model Context Protocol (MCP) for Intent-Based Network Troubleshooting Automation

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.¶

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

Network operators today face two converging demands: (1) reduce Mean Time to Repair (MTTR) while managing ever larger infrastructures, and (2) adopt intent-based interfaces that allow engineers to express high-level goals such as "verify reachability between Site-A and Site-B" instead of typing low-level CLI commands.¶

Simultaneously, Large Language Models (LLMs) have demonstrated utility in reasoning about semi-structured data such as device logs, configurations, and command outputs. However, safely exposing device-level actions and data to an LLM in real time remains an open problem. The Model Context Protocol (MCP), developed by Anthropic and published at https://modelcontextprotocol.io, provides a lightweight, capability-oriented RPC layer that already addresses this problem for general LLM applications.¶

This document specifies a deterministic mapping of MCP roles, primitives, and security workflows onto the network management plane so that:¶

• A network element (router, switch, firewall, etc.) becomes an "MCP server" that exposes management data and actions as MCP Resources, Prompts and Tools.¶
• A controller, orchestrator or chat-based assistant becomes an "MCP client" that consumes these primitives.¶
• Human operators interact with the controller using natural language; the controller translates the intent into a sequence of MCP calls, optionally consulting an LLM for reasoning.¶
• All interactions are subject to explicit user consent, audit, and capability-based access control, as mandated by MCP.¶

While the star-shaped Controller-to-Device model covers most brown-field deployments, some faults are visible only when two or more devices compare live data in real time. To address this we extend MCP to support Device-to-Device (D2D) troubleshooting collaboration. In this mode network elements autonomously form a transient "collaboration domain", exchange YANG/JSON-RPC calls, correlate results with an on-box LLM, and produce a signed report that can be retrieved by the controller once connectivity is restored. Security is maintained through mutual TLS, short-lived device certificates, and a white-list of neighbour-callable capabilities.¶

The result is an intent-based, conversational and secure automation framework that re-uses existing agents (NETCONF/RESTCONF/YANG, SNMP, CLI, gNMI, etc.) already present on devices instead of requiring new firmware.¶

3. Mapping of MCP Primitives to Network Management

{
  "name": "ping",
  "description": "Execute ICMP echo probe",
  "inputSchema": {
    "type": "object",
    "properties": {
      "destination": { "type": "string" },
      "count":       { "type": "integer", "default": 5 },
      "source":      { "type": "string" }
    },
    "required": ["destination"]
  }
}

4. Controller-to-Device Troubleshooting

   +----------------------------------+
   |  Human Operator (Chat UI, Web)   |
   +-----------------+----------------+
                     | Intent (natural lang.)
                     v
   +----------------------------------+
   |  Controller / Orchestrator       |
   |  (MCP Client + LLM Host)         |
   +-----------------+----------------+
                     | JSON-RPC 2.0 over TLS
                     v
   +----------------------------------+
   |  Network Device                  |
   |  (MCP Server)                    |
   +----------------------------------+

5. Device-to-Device Troubleshooting Collaboration

Some root causes are scattered across several nodes (e.g., unidirectional fiber, one-way ACL, single-sided BFD Down, localized SRv6 SID failure). Although the controller can collect data centrally, the north-bound link may be impaired, time-synchronisation is costly, and uploading bulk data is expensive. Allowing nearby devices to form a transient "trusted collaboration domain" and exchange data, correlate and infer root causes locally can significantly shorten MTTR.¶

      +-------------+       +-------------+       +-------------+
      |   Device A  |       |   Device B  |       |   Device C  |
      | MCP Client  |       | MCP Client  |       | MCP Client  |
      |  + Server   |<----->|  + Server   |<----->|  + Server   |
      +-------------+       +-------------+       +-------------+
            |                       |                       |
            |  MCP/JSON-RPC 2.0     |  MCP/JSON-RPC 2.0     |
            |  over mutual-TLS      |  over mutual-TLS      |
            |                       |                       |

Intent: "Verify packet loss on the SRv6 path from PE-1 to PE-3 via P-2"

  + mcp-d2d-port = 9514
  + supported-capabilities = [ietf-srv6-ping, ietf-interface-counters]
  + cert-thumbprint = <SHA-256 of device certificate>

{ "jsonrpc": "2.0",
  "method": "mcp/initialize",
  "params": {
      "protocolVersion": "2025-12",
      "capabilities": [ "ietf-srv6-ping", "ietf-interface-counters" ]
  },
  "id": 1 }

  Tool: "ietf-srv6-ping"
  Params: { Head=PE-1, Tail=PE-3, SID-List=[P-2, PE-3], Count=100 }

  POST https://[P-2]:9514/mcp/tool/call
  Body: { tool: "ietf-srv6-ping",
          arguments: { Local=P-2, Tail=PE-3, Count=100 } }

  POST https://[PE-3]:9514/mcp/resource/read
  Body: { uri: "urn:ietf:params:xml:ns:yang:ietf-interfaces/interfaces/interface=SID-Endpoint/statistics" }

  "Compare loss % from PE-1 vs P-2; if PE-1>0 and P-2=0, root cause is
   in {PE-1→P-2 link, upstream ACL}; output a single sentence."

  "Loss 3.2 % observed only on PE-1→P-2 direction; P-2→PE-1 0 %;
   suggest checking PE-1 egress ACL 2001."

  URI:  urn:ietf:params:xml:ns:yang:ietf-mcp/report/74e8
  Body: { "creator": "PE-1",
          "created": "2025-10-30T14:23:42Z",
          "hypothesis": "PE-1 egress ACL 2001",
          "evidence": [ <base64 encoded PCAP>, ... ],
          "signatures": { "PE-1": <sig1>, "P-2": <sig2>, "PE-3": <sig3> } }

6. Transport & Encoding Considerations

JSON-RPC 2.0 is carried over TLS 1.3 [RFC8446] with TCP/443 or QUIC [RFC9000] as the underlying transport. Servers present X.509 device certificates; clients use mutual TLS with short-lived SPAKE2 [RFC9383] tokens to achieve zero-touch onboarding.¶

YANG data is encoded in JSON [RFC7951] unless the client explicitly requests XML.¶

Large tech-support files MAY be streamed via HTTP/2 chunked transfer and are integrity-protected by SHA-256 hashes delivered in the JSON-RPC result.¶

Servers MAY support the MCP "progress" notification to report percentage completion for long-running Tools such as "tracepath".¶

7. Security Considerations

This section extends the security model defined in MCP with network-specific requirements.¶

8. IANA Considerations

This document requests IANA to register the following well-known URI:¶

• URI suffix: mcp¶
• Description: Model Context Protocol over TLS¶
• Reference: This document¶

Additionally, the YANG module "ietf-mcp" is requested to be added to the IETF YANG module registry with namespace "urn:ietf:params:xml:ns:yang:ietf-mcp".¶

Appendix A. JSON-RPC Examples

--> {
      "jsonrpc": "2.0",
      "id": 1,
      "method": "tools/call",
      "params": {
        "name": "ping",
        "arguments": {
          "destination": "10.2.2.2",
          "count": 5,
          "source": "192.0.2.1"
        }
      }
    }

<-- {
      "jsonrpc": "2.0",
      "id": 1,
      "result": {
        "loss": 0,
        "rtt": { "min": 2.1, "max": 2.3, "avg": 2.2 }
      }
    }

--> {
      "jsonrpc": "2.0",
      "id": 2,
      "method": "resources/subscribe",
      "params": {
        "uri": "mcp://router1/ietf-interfaces:interfaces/interface=eth0",
        "content-id": "etag-1234"
      }
    }

<-- {
      "jsonrpc": "2.0",
      "id": 2,
      "result": {
        "subscription-id": "sub-42",
        "initial": { "admin-status": "up", "oper-status": "up" }
      }
    }

Authors' Addresses