Markdown Version | Session Recording

Session Date/Time: 14 Feb 2025 09:30

NMOP

Summary

The NMOP working group held an interim meeting to discuss the status and progression of the C-MAP concept document. Key topics included the status of GitHub issues and use cases, the handling of network element status information (e.g., maintenance vs. failure), approaches for linking C-MAP to external data sources, and the integration of passive inventory. Participants agreed on several actions to advance the draft and address outstanding technical questions.

Key Discussion Points

• C-MAP Document Status and Goals:

  • Version 01 of the C-MAP concept document is on the data tracker, with version 02 ready for submission pending minor fixes.
  • The goal is to achieve a Working Group Last Call (WGLC) by May (or April, optimistically) to meet the June milestone.
  • Discussions included updates on closed, in-progress, and open GitHub issues, use case changes, and new requirements.

• Terminology and Use Cases (Service/Sub-service/Resource):

  • Discussion around defining "service" and "sub-service" within the C-MAP document, as suggested by Adrian.
  • A poll was taken, and the sense of those present was that defining these terms within the C-MAP document is acceptable to avoid lengthy debates, acknowledging the complexity and historical challenges of such definitions.
  • Med suggested simplifying by focusing on "service" and "resource" and avoiding "sub-service" for consistency with existing resource definitions, which was noted for further consideration.
  • For the "service-sub-service-resource" and "resource-sub-service-service" use cases, there was a discussion on whether these are specific business use cases or more general architectural patterns/requirements for other use cases (e.g., intent assurance, consistency checks, capacity planning, post-mortem replay). Oscar suggested moving these under broader use cases like "Intent and Service Assurance" and focusing on the underlying capabilities they provide.
  • Network Digital Twin Use Case: Oscar raised concerns that "Network Digital Twin" is a broad, research-oriented term that might be too ambitious for a standard. It was agreed to refine the wording to clarify that C-MAP can be a consumer or enabler for digital twin initiatives rather than aiming to define the digital twin itself.
  • Traffic Engineering and Closed Loop Use Cases: Oscar and Med suggested that "Traffic Engineering" and "Closed Loop" are more like techniques or enablers rather than standalone business use cases. It was proposed to integrate these into more concrete business use cases (e.g., capacity planning, intent assurance) to avoid duplication and improve clarity.

• Network Element Status Information:

  • Oscar presented on the need to distinguish between different types of "down" states for links and nodes (e.g., "in maintenance" vs. "failure"). This is crucial for capacity planning and simulation to avoid making incorrect assumptions about network availability.
  • The base IETF topology model (RFC 8345) does not include status.
  • Discussion revolved around whether status should be directly augmented into the C-MAP model or accessed via external references.
  • Concerns were raised about the complexity of a unified "status" across different network layers and its maintenance, given that status can be layer-dependent and vary in definition.
  • The need for requirements to differentiate between Live Network, Snapshot, and Potential Network views was discussed, with a proposal to add these as requirements for C-MAP's retrieval/write capabilities.

• Linking C-MAP to External Elements:

  • Pierre and Vic presented approaches for extending C-MAP models to link to external information sources, driven by use cases like "state," "what-if" scenarios (e.g., SRv6 policy analysis), and "replay/post-mortem root cause analysis."
  • Challenges: The immense amount of data and the dynamic nature of network state make it impractical to store everything directly within C-MAP Yang models.
  • Proposed Approaches:
    1. Augmenting ietf-network (RFC 8345): Adding external references directly to Yang nodes.
    2. External Database Mapping: Maintaining a separate database that maps ietf-network elements to external data sources.
  • Both approaches have pros and cons regarding scalability, ease of reference, and lookup performance. The presenters are prototyping both.
  • A Yang model for templating descriptions on how to query external information (e.g., NETCONF, RESTCONF, database queries) was proposed to standardize the interaction mechanism, not the data itself.
  • Standardization Question: There was a query to the working group on whether the method for describing these external links should be standardized. The initial sentiment was to document it as an informational draft or implementation report, prove its value through hackathons and deployments, and then revisit standardization.

• Linking C-MAP to SAIN (Service Assurance for Intent-based Networks):

  • Pierre raised a question about how to formally link C-MAP to SAIN (RFC 9417/9418), expressing difficulty in finding clear guidance. Med suggested engaging with the OPSA working group, which produced the SAIN documents, to clarify integration aspects and gather user feedback.

• Passive Inventory and Relationship to C-MAP:

  • Olga summarized discussions on the mailing list and within the IV WG regarding passive inventory.
  • The IV WG is working on a passive inventory draft that models cable and segment topology.
  • Key Questions:
    • Should passive inventory be modeled directly within C-MAP, or referenced externally?
    • If in C-MAP, should it be a separate layer or integrated?
    • Is bidirectional referencing between topology and inventory required?
    • Should connectivity for cables/segments be modeled via topology links rather than solely within the passive inventory module?
  • Brad (Swisscom) and Thomas strongly supported including passive topology within C-MAP (perhaps as a separate layer) due to its critical importance for planning, capacity management, and root cause analysis in large-scale networks. Oscar suggested keeping C-MAP simple with pointers to external fiber plant systems.
  • Olga suggested a common module for active and passive devices, augmenting specific properties rather than entirely separate modeling.

Decisions and Action Items

• C-MAP Document (v02): The updated C-MAP draft (version 02), incorporating recent changes and contributor additions, will be submitted.
• Terminology (Service/Sub-service): Definitions for "service" and "sub-service" will be kept within the C-MAP draft, not moved to the terminology document.
• Use Case Refinement:
  • The wording for the "Network Digital Twin" use case will be refined to position C-MAP as an enabler/consumer rather than a definer of digital twins.
  • Oscar will assist in refining the text for the "Intent and Service Assurance" use case to include "consistency checks."
  • Oscar will provide more concrete examples or consolidate the "Traffic Engineering" use case, as it's considered a technique rather than a standalone use case.
• New Requirements: Proposed requirements differentiating Live, Snapshot, and Potential Networks will be discussed on the mailing list before being added to the document.
• GitHub Issues: Olga will drive the closure of open GitHub issues, ensuring adequate discussion on the mailing list for resolution.
• External Linking: Pierre and Vic will demonstrate their approaches for linking C-MAP to external elements at the next IETF Hackathon in Bangkok.
• SAIN Integration: Pierre will engage with the OPSA Working Group to discuss the formal linkage between C-MAP and SAIN (RFC 9417/9418).
• Passive Inventory: Olga will cross-post discussions regarding passive inventory (modeling, integration with C-MAP) on both NMOP and IV working group mailing lists to ensure coordinated progress.

Next Steps

• Continue active discussion on the NMOP mailing list, particularly on the newly proposed requirements and the consolidation of use cases.
• Chairs will schedule a dedicated follow-up session to delve deeper into Pierre and Vic's work on external linking and discuss the findings from their hackathon demonstration.
• Participants are encouraged to contribute to the document's progress by providing reviews and feedback on GitHub and the mailing list leading up to IETF 122 in Bangkok.