NMOP

Summary

The NMOP session focused on reviewing the status of several working group and individual drafts, presenting hackathon results, and discussing new proposals. Key updates included refinements to the Yang Push to Message Broker integration, the Telemetry Message draft, and the Yang Data Model for Network Incident Management. The C-MAP concept document was declared ready for Working Group Last Call. Discussions also covered new drafts on AI-based network management agents, distributed authorization policy sharing, generalized capability principles, and a graph-based meta-schema, with an emphasis on gathering feedback and coordinating AI-related efforts across the IETF.

Key Discussion Points

Administrivia and Logistics
- Chairs (Rashad and Benoit) welcomed participants and covered the Note Well.
- Thomas volunteered as notetaker. Collective effort encouraged for meeting minutes.
- Attendees were reminded to sign into Datatracker and use the mic queue.
- Hackathon results for Yang Push to Message Broker Integration were integrated into Session 1 due to their relation to presented drafts.
- The importance of working group members reviewing documents was highlighted, especially for documents nearing Working Group Last Call.
NMOP Working Group Status
- Milestones: The C-MAP concept is targeted for WG Last Call after this IETF. The Message Broker Integration to IESG is aimed for September 2025.
- Document Updates: Authors of the Anomaly Detection draft confirmed updates are coming mid-November.
- Interim Meetings: No interim meetings were held; members were encouraged to request them if needed for document finalization.
- Knowledge Graph Design Team: An update on IETF's role in knowledge graphs is expected on Wednesday.
- Document Reviews: A strong call was made for broader working group review of documents, especially those approaching Working Group Last Call, to ensure quality and timely progress.
Yang Push to Message Broker Integration (Draft-ietf-nmop-yang-push-to-message-broker-integration)
- Updates: Addressed Paul Edkin's review comments.
  - Added references to research papers for Yang and Data Mesh industry adoption claims.
  - Added description of "stream catalog" to terminology and overview diagram.
  - Updated hostname type-def information to inherit changes from RFC 6991bis.
  - Proposed referencing Apache Pulsar instead of RabbitMQ due to Pulsar's support for partitioning, topics, message keying, and topic compaction, aligning better with Apache Kafka.
- Next Steps for Draft:
  - Suggest an early Ops Directorate review.
  - The document is considered stable; intent is for WG Last Call after the notification-version document completes its WG Last Call in NetConf (requested today).
Telemetry Message (Draft-ietf-nmop-telemetry-message)
- Updates:
  - Incorporated changes from Yang Semantic Versioning (e.g., revision-label to version, model-name to name).
  - Addressed Martin's review comments: changed jp-push to yang-push, added a leaf for identity-ref to distinguish message origin (network vs. cached/data collection).
  - Decision (tentative): Confirmed the choice of using a Yang data structure for the message container, consistent with the Yang Push envelope, over a notification. This was based on the definition of a data structure representing data not from a Yang datastore or notification.
- Implementations: NetGoS, PMACCT (Paolo), and Siena Blue Planet UAA (consumer side) are developing implementations.
- Discussion: Question raised about whether this document should be Informational or Standard Track. Initial quick feedback favored Standard Track.
Hackathon Results: Yang Push to Message Broker Integration (Yanick)
- Validation: Conducted a hackathon to validate the telemetry message and Yang Push integration against two Yang Push receivers (PMACCT and NetGoS).
- Tooling: Utilized YangLint from CESNET, which was updated to support Yang structures following a request from a previous hackathon.
- Findings/Issues Discovered:
  - Incorrect anydata encoding in network operator metadata (PMACCT).
  - Timestamp format issues (PMACCT), now updated to RFC 6991bis.
  - Missing namespace (PMACCT).
  - Challenges with nested anydata structures in validation libraries (NetGoS).
- Hackathon Outcomes:
  - Closed Items: YangLint Structure Support, PMACCT support for network telemetry message.
  - Spilled Over Items: Yang schema registry supporting Yang features, NetGoS device-facing automation.
  - New Action Items (for next hackathon): YangLint support for anydata and validation of nested anydata structures.
Yang Data Model for Network Incident Management (Qin Wu)
- Updates (since IETF 123):
  - Replaced "root cause" with "proper root cause" and refined its definition, simplifying it from complex inductive process or ITU-T references.
  - Replaced "machine learning" with "algorithm technique" in the service impact analysis definition to broaden applicability.
  - Polished use cases in the appendix:
    - Correlating troubleshooting tickets with incidents (extending RPC with ticket number).
    - Multi-domain fault demarcation (OSS invoking incident diagnosis RPC, providing extension example parameters).
    - Supporting intent-based networking with asynchronous RPC for diagnosis task creation and lookup.
- Discussion:
  - Request for feedback on the simplified definition of "proper root cause."
  - Question from Rashad regarding the incident client's ability to resolve incidents when the server is still detecting alarms; clarification needed in the document.
  - Question from Chongfong on handling multi-domain-caused incidents (cross-domain OSS/orchestrator using AI to correlate info).
- Action Item: Chairs to help secure more reviews and comments on the draft to meet the milestone.
C-MAP Concept (Evgeny)
- Updates (since IETF 123):
  - Two new versions submitted based on feedback.
  - Editorial changes and improved definitions for C-MAP modeling to be more generic.
  - Addressed all detailed review comments, especially from Rashad. All open issues closed.
- Decision: The document is considered ready for Working Group Last Call, which will commence after this IETF.
- Next Steps for C-MAP:
  - Starting Yang modeling for identified gaps (side meeting tomorrow).
  - Working on drafts for SPF and ISIS topologies, C-MAP/Pisana relationships.
  - Hackathons on C-MAP as a Knowledge Graph (presented Wednesday), and future hackathons on C-MAP with Anomaly Detection.
RFC 3535 20 Years Later (Luis)
- Goal: Update operator requirements for network management solutions, as per the working group charter.
- Updates:
  - Removed "20 years later" from the title.
  - Reduced the number of authors listed on the first page to five.
  - Moved content from sections 2 and 3 to an appendix.
  - Refined the naming of requirements (removed "new" suffix).
- Requirements Identified: 24 requirements categorized into: data modeling, protocol, interoperability, integration, SDO process, collaboration/cooperation, and skills. Most received strong operator interest.
- Next Steps:
  - Prioritize these requirements. Discussions were triggered on the mailing list but received limited responses.
  - Authors are exploring gathering broader feedback from other fora (e.g., LACNIC, NANOG, RIPE) and other IETF working groups.
  - Complete section 3.4 of the document, focusing on identified priorities (faster implementation, run code, vendor/operator involvement, correlating diverse data).
  - Request for working group help in providing feedback to refine prioritized requirements.
- Discussion:
  - Clarification on the type of feedback expected from the working group, given it's "operator requirements." Emphasis on prioritizing existing requirements.
  - Suggestion to gather feedback from vendors on the implementability of requirements, not just operator needs.
Message Key for Message Broker Integration (Thomas)
- Motivation: Enable network engineers to query network state directly from message broker topics (e.g., SQL commands on topics) instead of individual device show commands, facilitating digital twin capabilities.
- Terminology: Clarified message broker concepts: subject (schema), topic, partition, segment, message key, topic compaction.
- Current vs. Proposed Yang Push Integration:
  - Current: One giant topic for all Yang Push data, with different schema IDs mapped to subjects within that topic.
  - Proposed: Multiple topics, with one topic per schema ID, allowing for a single subject per topic.
- Yang Index: Introduced as a new term, a subset of Yang item identifiers, referring only to Yang nodes of the schema.
- Benefits of Proposed Approach:
  - Topic Compaction: Achieved by having one subject per topic and a well-defined message key, allowing the topic to reduce messages to the latest state.
  - Optimized Consumption: Consumers can subscribe only to topics relevant to their schema ID and, with deterministic keying, consume only from relevant partitions, significantly reducing data overhead.
- Proposed Topic Naming Convention: project.environment.type.schema-id (e.g., statistics.yang.schema-ID).
- Use Cases: Network engineer SQL queries for change verification, anomaly detection, network inventory.
- Discussion:
  - Confirmed that topic compaction and ordering are handled by the message broker.
  - Concern about "statistics" as a type label; suggested a more general term.
  - Discussion on partition dynamics in Kafka and their implications.
  - Highlighted the advantage of streaming for real-time automation and analytics over traditional databases.
  - Reaffirmed that the document describes the integration context, not message broker-specific APIs for topic creation.
  - Comparison to Yang Push Light and GMI, noting this solution builds an end-to-end data pipeline.
- Next Steps: Gather more feedback, widen contributors, test with complex subscriptions, clarify Informational vs. Standard Track, pursue WG adoption, and extend implementation efforts.
AI-based Network Management Agent (Daniela)
- Background & Goal: Define an architecture framework for AI agents (NMA) in network management, clarifying their relationship with existing controllers and specifying functional requirements (especially interfaces). NMAs augment, not replace, existing automation.
- Definition: NMA is an entity using ML/AI to create autonomous closed loops in the network, mapping to the "decision" component of an automation loop.
- Deployment Models:
  - Independent: NMA separate from network controller (introduces A2U, A2C, A2N interfaces). Potential for misalignment between NMA and controller if NMA interacts directly with the network.
  - Integrated: NMA augments controller interfaces; preferred mode to avoid misalignment.
- Open Issues:
  - Extending controller Northbound Interface API (NBIA) to support NMA invocation.
  - Which interface/protocol to use: NetConf/Yang, HTTP/JSON, or existing industry de facto standards like MCP/A2A?
- Discussion:
  - Raised a broader concern about coordinating AI-related work across IETF, suggesting a potential "AITF" focus.
  - Strong preference for building on MCP/A2A for interfaces due to industry traction and dynamic nature, rather than NetConf/Yang which could be too slow.
  - Emphasized that "closed loop" does not necessarily mean fully autonomous, and human oversight should always be possible.
  - Clarification needed on the specific functions an agent provides in this context.
- Next Steps: Improve content, collect comments, consider WG adoption.
Model for Distributed Authorization Policy Sharing (Unai)
- Motivation: Address the fragmentation of authorization policies in distributed, automated, multi-domain environments by providing a common, machine-readable, interpretable model for expression, sharing, and enforcement.
- Proposal: Use Yang as a canonical representation for authorization policies, treating them as code, allowing fine-grained, context-aware adaptation. Aims to cover the entire policy lifecycle.
- Architecture: Policy author (Yang format) -> Policy Administration Point (validate, verify, distribute) -> Policy Decision Point (evaluate, make decisions).
- Yang Module Structure: Includes metadata (ID, version, language), declarative logic (expressed in languages like Rego or OPA), and optional provenance information (e.g., signatures).
- Discussion:
  - Question about the relationship with IVY's work on capabilities and entitlements; acknowledged potential, but the current focus is on a central control point for policy distribution.
  - The approach is likened to extending SDN's central control concept to policies for verifiability and machine readability.
- Next Steps: Gather feedback, refine the model structure, explore provenance mechanisms, and work on a reference implementation for a future hackathon.
Generalized Capability Principle (Nigel)
- Motivation: Need to describe what a network component or function "can do" (its capabilities) before it arrives in the network (for planning, procurement). RFC 3535 also highlights this requirement.
- Goal: Develop a cohesive framework for expressing capabilities, identifying existing (e.g., Yang) and missing language elements, potentially extending Yang.
- Context: Capabilities are influenced by environment, green considerations, regulation, operator policies, and entitlements (e.g., for plugs).
- Approach: Develop the framework in NMOP and specific examples/implementations in parallel in IVY (e.g., for entitlements and plugs). Aims to use patterns from other bodies (ITT, ONF) and meta-models.
- Discussion:
  - Acknowledged overlap with RFC 9164 (system capabilities) and intends to generalize from it.
  - Concern raised about the potential for creating an overly complex system. The approach is to start with simple solutions ("low-hanging fruit") to provide immediate value and then gradually build complexity with a recursive framework that is simple on the surface but allows deep detail when needed.
Graph-based Meta Schema (Mahesh)
- Motivation: Based on practical implementation, this work proposes a generalized framework for defining modeling using graphs and a set of API operations for multi-actor/parallel processing, offloading client capabilities to the server.
- Terminology: Uses "resource" for a node and "relationship" for an edge in a graph. Introduces a unique identifier for resources.
- Meta-schema Concept: Aims to use existing modeling languages (Yang, OpenAPI schema) and connect their data via an independent layer, decoupling "what" a resource is from "how" it relates to others. This allows integration of diverse data sources.
- API Mechanisms: The framework inherently supports querying (e.g., GraphQL), validation, naming, and resource allocation, enabling reasoning with connected data.
- Discussion:
  - Questioned where this work belongs within the IETF, suggesting it might require a new working group.
  - Comparison to ONF's Component System Pattern (which used hypergraphs) and RDF. The author argued this work decouples the connection layer more, and includes operational aspects not covered by RDF's data concepts.
  - Acknowledged a Hackathon on Wednesday would present translation of models into RDFS schemas, which could be relevant.
- Next Steps: Continue sharing knowledge, determine appropriate IETF venue, engage with community feedback.

Decisions and Action Items

C-MAP Concept: The document is ready for Working Group Last Call. WG Last Call will be initiated after this IETF. (Chairs)
Yang Push to Message Broker Integration: An early Ops Directorate review is recommended, followed by WG Last Call after the NetConf notification document concludes its WG Last Call. (Authors, Chairs)
Yang Data Model for Network Incident Management: Chairs will assist in gathering more reviews and comments to help the draft meet its milestone. (Chairs)
RFC 3535 20 Years Later: Authors will continue to gather broader feedback on requirement prioritization from various fora, including vendors, and update section 3.4. (Authors)
Telemetry Message & Message Key for Message Broker Integration: Authors to continue discussions on mailing list regarding Informational vs. Standard Track status. (Authors)

Next Steps

Ongoing Draft Development: Authors of all presented drafts are encouraged to incorporate feedback, refine content, and continue discussions on the mailing list.
Reviews: Working group members are urged to actively review documents, especially those approaching Working Group Last Call.
Hackathons: Continued development and validation through hackathons are planned for Yang Push, C-MAP (Knowledge Graph, Anomaly Detection), and Distributed Authorization Policy Sharing.
IETF-wide Coordination: A need for clearer guidance and coordination on AI-related work across different IETF working groups was identified.
WG Adoption: Authors of new individual drafts (AI-based Agent, Distributed Authorization Policy Sharing, Generalized Capability Principle, Graph-based Meta Schema) will seek more feedback to determine interest for potential working group adoption.

Session Date/Time: 05 Nov 2025 19:30

NMOP

Summary

The NMOP session featured updates and discussions across three main topics: China Telecom's experience with network incidents and AI-based operations, the results of the CMAP hackathon focusing on SRv6 path computation, and an update on the CMAP YANG modeling efforts and the Knowledge Graph Design Team. Key discussions included the application of AI-Ops to diagnose complex network faults, identified gaps in existing CMAP modeling for SRv6, and a critical debate on the use and standardization of YANG profiles (T-profiles) in the IETF context. The Knowledge Graph Design Team presented a Proof of Concept (PoC) demonstrating the integration of IETF data with external ontologies to create queryable network knowledge.

Key Discussion Points

China Telecom Incident and AI-based Network Operation
- Incident Description: A 5G NG interface alarm occurred due to SRv6 packet source IP addresses being reported as unknown (all zeros) by a CE router during a capacity event. This led to SCTP connection handshake failures between base stations and the AMF.
- Root Causes:
  - A software bug in a CE router, triggered by misconfiguration of an SRv6 address, caused the deletion of the IPv6 source address in the underlying table.
  - A spine router failed to report packet discard information to the network management system, thus obscuring the problem.
- IETF Relevance: Noted that IPF forwarding status (IPFix) and ongoing drafts in OPSAWG on packet discard reporting could be helpful for future incident resolution.
- AI-Ops Architecture: China Telecom presented a four-layered AI-Ops architecture:
  - Corpus: Network-related text (chain of thoughts), images, vocabularies used for training domain-specific models.
  - Model Metrics: Combination of multi-type models (language, time-series, multi-modal, specific optimization models).
  - Toolchain: Platform for streamlined model development and deployment, including training, inference, agent development, and operation tools.
  - Application: Examples include "present assistant" and AI agents (over 330 developed, 23 types of "digital employees").
- Comments on MOPP Architecture: Suggested extending the MOPP architecture to include building blocks for AI agents, as well as mechanisms for exposure, identification, and authorization of these agents.
- Q&A: A participant inquired about the alignment of China Telecom's internal knowledge graph with existing IETF knowledge graph documents, noting it's currently a proprietary solution. Another question clarified the troubleshooting process, emphasizing that packet captures were used after initial ping tests showed normal network connectivity.
CMAP Hackathon Results (SRv6 C-MAP)
- Focus: The hackathon focused on computing the physical path of a packet based on the SRv6 C-MAP model and identifying necessary extensions to RFC 8345.
- Achievements: Implemented micro-CIDs in labs, enabled link-enabled same mechanism, developed algorithms for physical path computation, and began modeling the path using RFC 8345.
- Conclusions/Gaps: Identified missing elements in the CMAP model:
  - Supporting relationships from links to supporting links to understand path computation.
  - Properties for preference and weight for segment lists and segments.
- Next Hackathon Focus: Modeling the identified gaps, keeping synchronization with the CMAP YANG draft and ISIS topology, and extending path computation algorithms.
CMAP YANG and Side Meeting
- Goal: To initiate discussion on CMAP modeling based on requirements, present proposed approaches for extending RFC 8345, and summarize findings.
- Draft Scope: Focus is on proposing YANG module extensions or augmentations to RFC 8345 to address identified gaps, rather than creating an entirely new module.
- Identified Gaps (from operators' requirements): Grouped into topological (bi-directional links, multi-point, sub-networks), extendability, and lifecycle management, with some requiring further study.
- Discussion on Bi-directional Links: RFC 8345 models bi-directional links as two unidirectional links. A proposal was made for an explicit bi-directional link option using an identity for TP direction and a list of TPs within the model. Discussion included the advantages of a single entity for lifecycle management versus the current two-unidirectional approach.
- Discussion on Multi-point: RFC 8345 proposes modeling multi-point connections via a pseudo-node with links to all endpoints. A proposal for direct multi-point representation was discussed, aiming for simpler lifecycle management, especially for VPNs with many endpoints.
- Cross-cutting Issue: YANG Profiles (T-profiles): A significant part of the discussion revolved around the use of "profiles" (or T-profiles) to manage the complexity and size of YANG models, particularly RFC 8795.
  - Concerns were raised about the lack of programmatic definition, tooling support, versioning, and library capabilities for profiles within the IETF framework.
  - The NetMod chair indicated that while profiles might be useful internally for operators, they are not yet a broadly accepted or programmatically defined generic approach within IETF, leading to reluctance to mandate their use for current modeling efforts.
  - It was acknowledged that many implementations use a subset of a model, but the formal definition and tooling implications of "profiling" remain a challenge.
Knowledge Graph Design Team Update
- Team Composition: Diverse group from Telefonica, Orange, Swisscom, Huawei, academia, Broadband Australia, Cisco.
- PoC Demonstration: The team developed a Proof of Concept (PoC) by integrating an existing external ontology (NOIA from Orange) with an RDFS representation of CMAP data (from a previous hackathon).
  - This demonstrated how IT models and IETF network data could be combined into a queryable graph format.
  - The PoC successfully linked IETF network data with external information like trouble tickets, network parts, and organizational entities, showcasing the potential for augmenting IETF data with new insights.
- Goal: To take existing IETF models and knowledge, convert them into a graph format, enable querying, discover new connections, and provide a way to document these relationships for the community, rather than creating new models.
- IETF Fit (BoF-like Questions):
  - Problem Solved: Yes, addressing fragmentation in extensive YANG models and connecting data with defined relationships. IETF is the right group due to its network expertise.
  - Critical Mass: Yes, a diverse design team with growing interest from operators like China Unicom and China Mobile.
  - Scope: Still "a little bit vague". The current plan is to start with a sample set of use cases, develop requirements, and then propose deliverables before the Shenzhen IETF meeting.
- Discussion on Standardization: Questions arose regarding how to standardize evolving ontologies (e.g., as RFCs, or through other processes like ONIONS, which is still in charter development). It was recognized that while IETF has networking expertise, its processes might be too rigid for constantly evolving knowledge. The fragmentation of models is definitively an IETF problem.

Decisions and Action Items

China Telecom: Provide specific suggestions for MOPP architecture extensions (e.g., regarding AI agent exposure, identification, authorization) to the NMOP mailing list.
CMAP YANG Modeling: The draft will be updated to reflect feedback from the bi-directional link discussion.
YANG Profiles: Italo Buzzi will send an email to the NetMod mailing list to initiate a broader discussion on the generic problem of YANG profiles (e.g., programmatic definition, tooling, versioning).
CMAP YANG Modeling (Immediate): For the ongoing CMAP modeling effort, the working group will continue to focus on using and augmenting RFC 8345, rather than waiting for a generic IETF consensus or programmatic definition of "profiles."
Knowledge Graph Design Team: The team is tasked with defining a sample set of use cases, developing requirements, and proposing specific deliverables before IETF 120 (Shenzhen).

Next Steps

CMAP Hackathon: The next hackathon will focus on modeling the identified gaps related to supporting relationships and properties for segment lists/segments.
CMAP YANG Modeling: Continue the analysis and proposal of solutions for other identified requirements, including multi-point connections, sub-networks, extendability, and lifecycle management. An interim meeting may be considered after IETF 124.
Knowledge Graph Design Team: Proceed with defining use cases, requirements, and deliverables. Continue exploring appropriate IETF processes or mechanisms for standardizing or managing evolving ontologies and knowledge graphs, potentially in coordination with future efforts like ONIONS.