# Proposers - Lluis Gifre (CTTC) # Description This feature proposes adding an optional TeraFlowSDN Agentic Module component to enable natural-language assisted operation of a TeraFlowSDN deployment and peer-to-peer coordination between controller instances. The component runs as a separate microservice and uses the TeraFlowSDN MCP Server as its controller-facing interface, avoiding direct coupling with internal controller APIs. For the initial implementation, the Agentic Module focuses on optical inventory, optical spectrum negotiation, and optical connectivity service lifecycle operations. Each deployed Agentic Module is associated with one TeraFlowSDN controller instance and can coordinate with peer Agentic Modules through an A2A interface when a request spans multiple network domains or locations. The module combines LLM-based intent interpretation and answer composition with deterministic workflows for safety-critical controller operations such as endpoint resolution, spectrum candidate selection, reservation, service creation, verification, rollback, and teardown. The LLM provider, model, peer addresses, MCP endpoint, runtime mode, and persistence settings must be configurable through Kubernetes ConfigMaps and Secrets. # Demo or definition of done The feature is completed when TeraFlowSDN can optionally deploy the Agentic Module as part of the standard deployment framework without affecting existing deployments where it is disabled. The deployed component must expose a health endpoint, an operator-facing HTTP API, and an A2A-compatible peer endpoint. It must connect to the local TeraFlowSDN MCP Server, discover or consume its tool catalogue, and execute read-only inventory requests. It must support optical connectivity service creation and removal through the MCP Server using the established TFS service lifecycle: service reservation, service update with endpoints, constraints and config rules, service-state verification, and cleanup. For cross-domain optical requests, the module must discover peer capabilities, negotiate a common contiguous flex-grid slot block, create local and peer service segments, validate that all resulting TFS services reach ACTIVE, and rollback all created resources on failure. The implementation must include unit tests for configuration, tool invocation contracts, deterministic workflow steps, A2A payload validation, and rollback logic, plus integration smoke tests for single-domain and cross-domain optical service lifecycle scenarios. ## Acknowledgements This work is partially supported by the European Union's Horizon Europe Research and Innovation Program under grant 101139134 in the PROTEUS-6G project. # References 1. [Model Context Protocol](https://modelcontextprotocol.io/) 2. [Agent2Agent Protocol](https://a2aprotocol.ai/) 3. [TeraFlowSDN Documentation](https://tfs.etsi.org/documentation/latest/) 4. L. Gifre, et al., "Massively-Decentralized Network Automation Framework," OFC invited paper, 2025. # Feature Design (for New-Features) ## Clarifications to Expected Behavior Changes The Agentic Module is introduced as an optional TeraFlowSDN component and must not change the behavior of existing controller components when it is not deployed. When enabled, it provides an additional automation entry point on top of the controller rather than replacing the NBI, service, context, path computation, or optical controller components. The controller remains the source of truth for topology, inventory, service state, connections, and spectrum reservations. The Agentic Module may keep session memory and operational context, but such memory is non-authoritative and must be refreshed from the controller before executing mutating operations. Mutating workflows must be deterministic after the intent has been classified. The LLM must not generate controller payloads, endpoint UUIDs, service UUIDs, or spectrum assignments without deterministic validation. The LLM can be used for intent interpretation, task delegation, ambiguous-request clarification, and final operator-facing explanations. Safety-critical operations must be performed through bounded Python workflow steps that call MCP tools and validate returned controller state. Cross-domain workflows require the entry Agentic Module to coordinate with peer Agentic Modules. The entry module should not directly manipulate peer controllers. Instead, it sends peer requests through A2A, and each peer module applies its own local policy and controller operations through its local MCP Server. The first supported cross-domain operation is optical connectivity service provisioning with flex-grid spectrum negotiation. ## References - MCP is used as the local controller tool interface. - A2A is used as the peer Agentic Module coordination interface. - The existing TeraFlowSDN MCP Server feature is assumed to expose inventory, optical spectrum reservation, optical path spectrum candidate, and service lifecycle tools. - The optical connectivity workflow assumes the Service and Optical Controller components implement the required service creation, path computation, spectrum allocation, and teardown behavior. ## Assumptions - The TeraFlowSDN MCP Server component is available and deployed in the same controller instance as the Agentic Module. - The Context, Service, NBI, PathComp, and Optical Controller components expose the optical inventory, candidate path, reservation, and service lifecycle operations required through the MCP Server. - A Kubernetes deployment is the primary runtime target. - Docker Compose can be provided for development and debugging but is not required for production deployment. - An external LLM provider may be used, provided credentials are supplied through a Secret. - An on-premises LLM provider may be used if the selected model is compatible with the runtime and the available acceleration hardware. - The first implementation scope is optical service lifecycle and inventory. - Packet services, closed-loop control, gossip discovery, and disaster recovery workflows are out of scope for this feature. ## Impacted Components Agentic Module, MCP Server, Context, Service, NBI, Optical Controller, PathComp, deployment scripts, Kubernetes manifests, CI pipeline, documentation. ## Agentic Module Impact Add a new `src/agentic` component implemented as a TeraFlowSDN microservice. The component should expose: - an HTTP API for operator requests; - a health endpoint for Kubernetes probes; - an A2A endpoint for peer Agentic Module interactions; - optional debug endpoints for execution traces and session inspection. The runtime should be organized into small modules: - configuration loading from environment variables; - LLM provider adapter; - MCP client and tool registry; - A2A client and server handlers; - deterministic inventory workflows; - deterministic optical service workflows; - session persistence; - execution tracing and audit records; - API routes. The default runtime should use a bounded single-agent or router-agent entry point for intent classification, then execute deterministic workflow functions. The implementation should keep enough trace data to explain which agents, MCP tools, A2A calls, and verification steps were used for each request. ## MCP Server Impact No direct behavior change is required by this feature if the MCP Server already exposes the required tools. The Agentic Module depends on the MCP Server tool catalogue and should discover available tools at startup or on demand. If a required tool is missing, the Agentic Module must report the missing capability instead of falling back to hardcoded controller calls. The MCP Server documentation should list the tool groups consumed by the Agentic Module. ## Context Component Impact No direct behavior change is expected. The Agentic Module relies on context-backed source-of-truth state through MCP tools. If future workflows require additional persisted resources, such as long-lived inter-domain reservations or policy decisions, they should be proposed as separate context model features. ## Service Component Impact No direct behavior change is expected for the first implementation. The Agentic Module must use the existing two-step TFS service lifecycle: create/reserve service identity first, then update the service with endpoints, constraints, and config rules. The Agentic Module must verify resulting service state through MCP/TFS after creation and after deletion. ## NBI Component Impact No direct behavior change is expected. The Agentic Module is not an NBI replacement. The NBI remains available for conventional northbound applications and for MCP Server backend calls. Documentation should clarify how operator requests entering the Agentic Module differ from direct TFS API calls. ## Optical Controller Impact No direct behavior change is expected for the first implementation if optical candidate computation, spectrum reservation, effective spectrum allocation, service provisioning, and teardown are already exposed through the controller and MCP Server. The Agentic Module must consume controller-derived spectrum candidates and must not randomly select spectrum. The selected slot block must be continuous and contiguous across the local and peer optical segments. ## PathComp Impact No direct behavior change is expected. Any future requirement for technology-aware cross-domain path computation should be proposed as a separate PathComp or Optical Controller feature. ## Deployment Impact Add optional deployment support for the Agentic Module: - Dockerfile and component build rules; - Kubernetes Deployment, Service, ConfigMap, Secret, and optional Ingress; - optional activation block in `deploy/all.sh` and project-specific deployment settings; - default disabled state so existing deployments are unaffected; - environment variables for MCP endpoint, A2A bind address, peer URLs, LLM provider, model, credentials, persistence path, runtime profile, and startup warm-up. The component should be deployed after the MCP Server and after the controller components whose tools it consumes. ## CI Pipeline Impact Add component build and unit-test jobs. Unit tests should not require a live TeraFlowSDN controller or an external LLM provider. Use mocks for the MCP client, A2A peer client, and LLM adapter. Integration tests requiring live controller instances should be opt-in or placed under existing end-to-end test stages. ## Documentation Impact Document: - component purpose and scope; - deployment configuration; - supported MCP tool families; - supported A2A methods; - supported operator request families; - security considerations for LLM credentials and peer endpoints; - current limitations and out-of-scope workflows. ## Testing Unit tests: - configuration loading from environment variables and secrets; - MCP tool discovery and missing-tool reporting; - intent classification output schema; - deterministic endpoint-resolution helpers; - optical spectrum intersection and slot-block validation; - service payload construction; - service-state verification; - rollback and bounded delete retry behavior; - A2A request and response schema validation; - session persistence. Integration smoke tests: - read-only inventory request through MCP; - single-domain optical connectivity service creation and deletion; - cross-domain endpoint discovery through A2A; - cross-domain spectrum negotiation with initially occupied slots; - cross-domain optical connectivity service creation and deletion; - rollback after peer segment creation and local failure; - startup with missing optional peer configuration; - startup failure when the MCP Server endpoint is unreachable and the component is configured to require it. Acceptance tests: - existing TeraFlowSDN deployments pass unchanged when `agentic` is not enabled; - enabling `agentic` deploys all Kubernetes resources successfully; - health probes become ready only after mandatory runtime dependencies are initialized; - a cross-domain optical service request creates only controller-backed services and verifies all involved TFS service states as ACTIVE; - deletion removes all segment services and releases related reservations; - failure cases produce a structured operator-facing error and leave no orphaned peer resources.