Session Date/Time: 21 May 2025 14:00

NMOP

Summary

This NMOP interim meeting focused on an educational overview and practical applications of Knowledge Graphs (KGs) within the networking domain. Discussions included a primer on Semantic Web technologies, business justifications for KGs in network operations, and presentations of three related drafts exploring framework, engineering, and specific implementation aspects of KGs. A significant portion of the meeting was dedicated to brainstorming the path forward for Knowledge Graph work within the IETF, addressing questions about the appropriate venue, deliverables, and collaboration models given the evolving nature of ontologies.

Key Discussion Points

Welcome and Agenda:
- Rashad (new co-chair) welcomed participants and introduced the agenda: Semantic Web education, KG business justification, three draft presentations, and an open discussion on next steps.
- Reminder of IETF Note Well.
Educational Presentation: Introduction to Semantic Web and Knowledge Graphs (Rafael Tri):
- Motivation: Tracing back to DARPA in 1999, the need for computers to "understand" information on the web led to the Semantic Web initiative (seminal 2001 Scientific American article). Google's 2012 "Knowledge Graph" blog post popularized the concept for disambiguating search results.
- Definitions:
  - Semantic Web: An evolution of the WWW where information meaning is explicitly defined for machine processing. Comprises W3C standards like RDF, OWL, SPARQL, SHACL, RML.
  - RDF (Resource Description Framework): A triple-based (subject-predicate-object) graph model for describing resources, identified by URIs. Emphasized as a model, not a format, with various serializations (JSON-LD, XML).
  - Linked Data Principles: Four "commandments" for publishing structured data (use URIs, HTTP URIs, provide RDF descriptions upon dereferencing, include links to other RDF entities). DBpedia and WikiData were highlighted as early large-scale implementations.
- Ontologies (Schemas):
  - Formal, machine-readable specifications of shared domain understanding, serving as vocabularies and schemas.
  - Methodologies like Linked Open Terms (LOT) and tools like Protégé were mentioned.
  - Schema.org was noted as a dominant ontology widely used by search engines for web content. LOV and Europe's standard ICT portals catalog existing ontologies.
  - The NOA ontology was cited as an example following good practices by reusing existing ontologies.
- Querying (SPARQL): The RDF query language, analogous to SQL, allowing selection, construction, filtering, aggregation, and federated queries across distributed data. It also defines a standard access protocol.
- Knowledge Graph Construction: Methods include direct mapping or declarative languages like RML for transforming structured data into RDF.
- LLMs and Knowledge Engineering: Large Language Models are increasingly used to assist in ontology development, competency question generation, SPARQL query generation, and RML rule creation, boosting knowledge engineering efforts.
- Q&A:
  - Recommended free MOOCs for deeper learning and hands-on practice.
  - Knowledge Graphs are a universal concept applicable across diverse industries (networking, vehicles, energy, etc.), serving as a structured data layer for integration and enabling autonomous agents.
  - Protégé was mentioned as a common tool for ontology development, but the optimal UI is still being sought, with conversational interfaces as a potential future.
  - RDF is the most common way to implement ontologies, with ongoing convergence efforts with Label Property Graphs (LPGs). LPGs historically lacked a strong focus on schema and unique identifiers, leading to challenges in data integration, though GQL is an attempt to address this.
  - LLMs and KGs are complementary; KGs provide factual, controlled sources for LLMs (RAG architectures), reducing hallucinations and offering efficient querying for simple answers.
Business Justification: Networking Challenges and Knowledge Graphs (Benoît Claise):
- Problem: Current Network Operations Centers (NOCs) struggle with siloed, disconnected data from various sources (CLI, syslog, SNMP, YANG, IPFIX, BGP, RADIUS), each with different formats, models, and naming conventions. An "interface" or "network element ID" can have multiple, inconsistent representations across systems.
- Limits of YANG: While useful, YANG alone cannot integrate all operational data due to the long lifecycle of operations and the impracticality of converting all existing data models (IPFIX, BMP) to YANG. The cost of data model integration is very high.
- Operator Needs: Operators possess vast data lakes (management, control, data planes) but struggle with fault prediction, root cause analysis, and remediation due to lack of linked, contextualized information.
- Audience Heterogeneity: Different teams (AI/ML experts, software engineers, network engineers, configuration, assurance) and their distinct competencies require linked information.
- Linking Requirements: Data must be linked to configuration, service definitions, incidents, assurance graphs, digital maps, customers, and intent for business value and closed-loop automation.
- Autonomous Networking: Requires clean, consistent, interconnected data with clear semantics and context (e.g., router roles: access, PE, P, ASBR).
- NMOP's Role: NMOP's work on YANG push, data mesh principles, anomaly detection, and semantic mapping aligns with these needs. KGs provide the ontology, linking, and mapping capabilities required to address data overload and context loss.
Draft Presentation: draft-michael-nmop-knowledge-graph-framework (Michael Haugh):
- Motivation: Existing NMS/EMS applications are swimming in data and models (TMF, IETF, ETSI) but lack connectivity. The draft aims to highlight how KGs can unlock this information, focusing on connecting existing models rather than creating new ones.
- Key Enablers: IRIs for object naming, SPARQL federation for querying distributed sources, and FAIR data principles (Findable, Accessible, Interoperable, Reusable). KGs handle "open world" assumptions, making them suitable for disparate sources.
- YANG & RDF: YANG models can be represented in RDF and OWL, and YANG data can be converted to RDF.
- Architecture: The knowledge engine is positioned as a layer atop existing systems (following a Monitor-Analyze-Plan-Execute loop) to connect and enable autonomous networks.
- Implementation Challenges:
  - Lack of mature, open-source, full-stack RDF tools comparable to SQL databases.
  - Academic origins of many tools, leading to abandonment or lack of active maintenance.
  - Reasoners, while powerful, can lead to exponentially complicated queries, especially with virtual data.
  - Ongoing convergence but still distinct ecosystems for RDF/OWL and LPGs, with LPGs historically lacking strong schema focus.
- IETF Role: Possible roles include formalizing knowledge sharing methods, standardizing a format (RDFS/OWL), capturing additional information, and exploring use cases like mapping between L3SM and L3NM. Suggests that living documents might be a better fit than RFCs for ontologies.
Draft Presentation: draft-nacho-nmop-knowledge-graph-engineering (Nacho Cordero):
- Aim: Focus on the core elements for practical KG construction: ontology development and knowledge engineering.
- Ontology Development: Emphasizes using proven methodologies like LOT, which is use-case driven and helpful for easing adoption, but involves manual steps. Automation with LLMs is seen as a future improvement.
- Knowledge Engineering: Transforming raw or semi-structured data into RDF. Favors declarative mapping languages (e.g., RML, MTL based on Apache Velocity) over ad-hoc code for scalability, reusability, and traceability. Noted RML's current limitations with functions and nested data.
- Use Case: A "Network Data Catalog" prototype using YANG-based devices. Collects YANG library data from NETCONF servers and integrates it into a KG using a custom YANG Library Ontology.
- Takeaways: LOT is helpful but needs automation. Declarative mappings are useful for data creation but updates and deletions remain challenging. KG lifecycle management (ontology/data source changes) and governance (reusability, interoperability) are critical.
- Next Steps: Prototype demonstration at Madrid hackathon, promote LOT4KG for lifecycle management and governance.
Draft Presentation: draft-tada-nmop-orange-knowledge-graph (Lionel Tada):
- Motivation: Orange's internal "IT Service Management Knowledge Graph" (ITSM KG) for enhanced cross-operator incident management and network design. Aims for linked abstract representations that combine digital map, operational data, OSS data, and YANG configuration.
- Approach: Builds an ITSM KG from heterogeneous sources, aligning with ITIL/ITSM best practices. Uses multiple abstraction layers to integrate configuration data, allowing queries with a shared vocabulary while retaining access to local specifics.
- Pipeline Model: Defines six tasks for KG construction, which can be contributed to.
- Implementation: Two complementary experiments: Noria (downstream pipeline, unified view, behavioral models) and YANG2OWL (upstream pipeline, automates ontology implementation/updates, streamlines digital twin architectures).
- YANG2OWL Process: Gathers YANG models (e.g., ETSI), translates to OWL (simple algebra, leverages YANG catalog), constructs 5G infrastructure data graph from YANG config and other data, merges subgraphs into ITSM KG (Neo4j with Neo Semantics toolkit), applies business rules for enrichment, and enables query for impact analysis.
- Conclusion: The draft demonstrates the relevancy of ITSM KGs built with YANG data for operational concerns, opening avenues for shared knowledge engineering practices and KG lifecycle management within the network industry.
Brainstorming & Next Steps (Chairs & Attendees):
- Question 1: Standard Networking Ontology?: Is there a single, reusable standard ontology for networking, or must we create our own?
  - Rafael noted a tension: some see YANG as a meta-model for one comprehensive ontology, while others see individual YANG models as mini-ontologies.
  - Michael clarified his view: the goal is to connect all existing models (YANG, TMF, ETSI, proprietary), not necessarily create new ones. The focus is on tracing connections and provenance, perhaps using taxonomy for common semantics.
- Question 2: What is "Success"?: What tangible deliverables or capabilities would define success in 1-2 years?
  - Lionel emphasized sharing capabilities – allowing different entities (e.g., Orange and another company) to share and align semantic models for anomaly detection, network design, and automation, even if their specific business goals differ.
  - Benoît pressed for practical deliverables for an IETF charter, suggesting a "clever experiment" to compare anomaly root cause analysis across different frameworks.
  - Michael stressed agreeing on a format for sharing knowledge (e.g., RDFS/OWL), acknowledging the complexity of the existing ecosystem and advocating starting simple. He suggested focusing on high-value, representative use cases (like L3SM/L3NM mapping) and recognizing that RFCs might not be the best format for living ontologies.
- Question 3: IETF NMOP as the Right Place?:
  - A quick poll indicated high interest in the work, but mixed feelings on IETF NMOP as the appropriate venue.
  - Rob (individual perspective): "Probably not yet or not now." The experiments are not tightly scoped enough for the IETF, feeling more like IRTF work. However, the underlying problem of combining disparate data/schemas is critical.
  - Nacho: Agreed, "not today." The slow RFC process is not suitable for living ontologies, suggesting the IETF process needs to evolve for such work.
  - Rafael: Emphasized that IETF/IRTF provides a crucial legal vehicle for open collaboration, overcoming IP/trade secret concerns that would otherwise prevent companies from collaborating.
- Conclusion by Chairs:
  - Acknowledged the mixed opinions on the venue but high interest in the problem.
  - Proposed that the authors of the three drafts (Lionel, Nacho, Michael) self-organize into a "design team."
  - This team should:
    - Define clear goals for collaboration.
    - Outline what "success" would look like in 1-2 years (e.g., specific deliverables, tools, mappings).
    - Propose the most suitable venue for this work (NMOP, IRTF, or elsewhere), considering IETF process limitations.
  - This plan, regardless of the venue, would provide a clear path forward.
  - The chairs will follow up with more questions to the mailing list to facilitate this self-organization.

Decisions and Action Items

The authors of the three presented drafts (draft-michael-nmop-knowledge-graph-framework, draft-nacho-nmop-knowledge-graph-engineering, draft-tada-nmop-orange-knowledge-graph) are to self-organize as a "design team."
This design team is tasked with developing a concrete plan, including:
- Defining shared goals and objectives for Knowledge Graph work.
- Identifying what tangible "success" would look like in 1-2 years.
- Proposing the most appropriate forum or working group within the IETF (or potentially IRTF/other) for this work, considering the unique nature of ontologies as living documents.

Next Steps

The NMOP chairs will send follow-up questions to the mailing list to guide the self-organization of the design team.
The design team is encouraged to use the Madrid IETF meeting (end of July) as a checkpoint to provide an update on their discussions and proposed plan.