Hi Guanming, Thanks for the reply. The more I think about it, the more I’m convinced that the coexistence of both architectures is not only a tradeoff, but also a reality or even a desirable evolution direction given the current network is composed of heterogeneous devices with different capabilities and numerous network management tools/protocols with distinct advantages are already deployed. The different tools and protocols will complement with each other and fit in a hierarchical and federated architecture where the top-level application oversees and aggregates all the local and remoter servers. So while I believe MCP would be a critical core component in future network management, my suggestion is to avoid the one-size-fits-all, exclusive solution but to embrace the hybrid architecture where MCP servers can be local, in cloud, and embedded in devices, from the very beginning.
Regards, Haoyu From: zengguanming <[email protected]> Sent: Wednesday, November 19, 2025 3:19 AM To: Haoyu Song <[email protected]>; [email protected] Cc: Liubing (Leo) <[email protected]> Subject: Re: MCP/A2A for Network Devices – New Draft Cluster and Call for Feedback / Co-Author Hi Haoyu, It's a good idea to mention the alternative architecture in the drafts of use cases. Also, I will consider citing draft-yang-nmrg-mcp-nm<https://datatracker.ietf.org/doc/html/draft-yang-nmrg-mcp-nm-01>, since this draft has already analyzed the pros and cons for different architecture. Thank you for your advice. Best regards， Guanming Zeng Huawei E-mail: [email protected]<mailto:[email protected]> 发件人: Haoyu Song <[email protected]<mailto:[email protected]>> 发送时间: 2025年11月13日 2:53 收件人: zengguanming <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 抄送: shangxiaotong <[email protected]<mailto:[email protected]>>; Liubing (Leo) <[email protected]<mailto:[email protected]>> 主题: RE: MCP/A2A for Network Devices – New Draft Cluster and Call for Feedback / Co-Author Hi Guanming, I’ve read the drafts and think they are very interesting and exhibit a promising and least resistance path to realize the vision of intent networking. While there are a lot of things to talk about, here I just raise one question for discussion. The document doesn't cover the local server scenario. An alternative architecture is to keep the servers in controller with the network management application (i.e., local to the clients) and some resources/tools in network devices so the resources and tools can be accessed through the existing controller-device interface and protocols (e.g., NETCONF). While this may appear less appealing than the proposed architecture in the drafts, it's good to understand the pros and cons of each architecture in order to make the optimal decision. The alternative architecture at least shows advantages on the aspects of security, scalability, and development effort. What are the compelling reasons to promote the proposed architecture only? Perhaps the mix of the two is better? Look forward to seeing your thoughts. Best regards, Haoyu From: zengguanming <[email protected]<mailto:[email protected]>> Sent: Friday, November 7, 2025 2:18 AM To: [email protected]<mailto:[email protected]> Cc: shangxiaotong <[email protected]<mailto:[email protected]>>; Liubing (Leo) <[email protected]<mailto:[email protected]>> Subject: [rtgwg] MCP/A2A for Network Devices – New Draft Cluster and Call for Feedback / Co-Author Dear Colleagues, We would like to introduce a freshly-published cluster of five Internet-Drafts that explore the use of the MCP/A2A for AI-driven network devices management, and to ask for your advices, comments and collaboration. 1. A LOGIC-CHAIN IN FIVE DRAFTS Regarding the aspect of LLM driven network operations and management, these five drafts comprehensively analyze the logic chain: scenario, use case and requirement analysis -> limitations of traditional protocols -> gaps in new protocols such as MCP/A2A -> protocol extensions: (1) Define new application scenarios and corresponding use cases for network operation and management driven by LLMs, and identify the capabilities that protocols need to provide. (draft-zm-rtgwg-mcp-network-measurement-01<https://datatracker.ietf.org/doc/draft-zm-rtgwg-mcp-network-measurement/>, draft-zm-rtgwg-mcp-troubleshooting-01<https://datatracker.ietf.org/doc/draft-zm-rtgwg-mcp-troubleshooting/>) (2) Analyze the shortcomings of traditional network protocols (e.g., NETCONF) in implementing new application scenarios for network operation and management, and evaluate the feasibility of using AI-related protocols such as MCP and A2A. (draft-zeng-opsawg-applicability-mcp-a2a-00<https://datatracker.ietf.org/doc/draft-zeng-opsawg-applicability-mcp-a2a/>) (3) Currently, MCP and A2A protocols are primarily designed for non-network management scenarios. This draft analyzes the gaps in protocol evolution when applied to network operation and management scenarios. (draft-zeng-opsawg-llm-netconf-gap-00<https://datatracker.ietf.org/doc/draft-zeng-opsawg-llm-netconf-gap/>) (4) Based on the identified gaps in protocol evolution, attempts are made to extend the MCP protocol. (draft-zw-opsawg-mcp-network-mgmt-00<https://datatracker.ietf.org/doc/draft-zw-opsawg-mcp-network-mgmt/>) 2. ADVICES/ COMMENTS / COLLABORATION Since the work is a little complex, we are sincerely need you help: (1) MCP/A2A live in the application/AI space, but our use cases are deeply routing & operations oriented. What IETF areas and WGs do you think are appropriate for these drafts? How to coordinate these work if they are in different areas and WGs. (2) Solicit your comments on the solution for MCP/A2A applied in network management and operation. (3) Solicit your comments on these drafts. These effort is still in early days — we are actively seeking broad input, additional use-cases, and co-authors to help shape the direction. Wish you could help and join the work. Best regards, Guanming Zeng Huawei E-mail: [email protected]<mailto:[email protected]>
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
