[NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

[Olga Havel <[e-mail]>]

Thanks Daniele, I closed the issue 129 with the clarification from the email.

Best regards,
Olga

From: Daniele Ceccarelli (dceccare) <[e-mail]>
Sent: Monday, December 15, 2025 1:38 PM
To: Olga Havel <[e-mail]>; Reshad Rahman <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

Thanks a lot Olga.

Yes, the comment on the relationship with the knowledge graph is to get a common understanding in the working group. I’m not expecting to have the question answered in the draft but rather to have it discussed on the list.
I’m ok to close the issue.

Thanks
Daniele

From: Olga Havel <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, December 11, 2025 3:46 PM
To: Daniele Ceccarelli (dceccare) <[e-mail]<mailto:[e-mail]>>; Reshad Rahman <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

Dear Daniele,

Thanks you very much for the review and the feedback.

I opened 2 new github issues (128 and 129) and merged other comments  with 4 Italo’s and Segio’s issues (83, 84, 87, 88). I hope I did not miss anything,

Issue Number    Issue
83          What is SIMAP?
84          What is core topology?
87          Topology definition
88          Topology Layer Definition
128        Unclear separation between live and simulation
129        Difference between SIMAP and knowledge graph

We will discuss these issues on the mailing list when I finish merging all the comments.

In regards to 129 I remember you asked about relation between the SIMAP and knowledge graph. But as knowledge graph activities were just starting in the NMOP and it is not yet clear where/what the scope is and SIMAP was supposed to be used for both the current operations and the future, we decided not to mention knowledge graph in SIMAP draft for now. I think they may mention relation with SIMAP in the knowledge graph draft and hackathon, so that could be done from their direction as they may/will be using SIMAP.
Let me know what you think and if you are OK with me closing 129.

Best Regards,
Olga


From: Daniele Ceccarelli (dceccare) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, December 1, 2025 4:35 PM
To: Reshad Rahman <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

Hi Reshad, working group,

I believe the draft is extremely useful and in a good state to move forward, but I have some suggestions on how I’d like to see it improved. I’ve seen many comments on the list and probably the ones I mostly agree with are the ones from Bo.

The draft captures a useful set of operator needs and use cases (inventory queries, planning, simulation, NDT, etc.), but some conceptual ambiguities still stand.  The three biggest I found are:


  1.  Ambiguity about what SIMAP is (conceptual framework vs concrete data model vs API vs product feature). Clarifying it would improve the draft.


  1.  Core topology vocabulary (what are “core topological entities/properties”) — explicit mapping to the objects used in deployments (nodes, links, termination points, logical resources, service endpoints) would help
  2.  Unclear separation (and usage patterns) between live network state and simulation/“digital twin” instances (write operations, provenance, isolation, reconciliation and expected operational workflows are not well defined). The draft hints at both but it would be beneficial to add some  concrete operational guidance

Major items & recommended fixes

1) What is SIMAP? — make the role explicit
Intro mixes statements like “does not specify a modeling approach for SIMAP” with “SIMAP is a data model...” and later references a “SIMAP API” (section 1). Is  SIMAP  a conceptual framework and requirements document, or a concrete YANG/JSON data model, or  an API/behavioral spec.
You could add an explicit “Scope and Positioning” paragraph in section 1 that states it clearly.
My suggestion is to treat this draft strictly as Concept and requirements. That matches its stated intent (“Concept, Requirements, and Use Cases”) and avoids prematurely prescribing APIs. If you do that, remove the term “SIMAP API” from this document (or define it as “an implementation-specific northbound interface” but do not normatively specify it here).

Suggested text for  for section 1 (intro)
“This document defines the conceptual framework, operator requirements, and representative use cases for Service & Infrastructure Maps (SIMAP). SIMAP in this document is a conceptual construct — a way to describe and exchange views of service and infrastructure topology across multiple layers. This document does not itself standardize a concrete YANG/JSON module or a normative northbound API; such artifacts are in scope for follow-on work. The term ‘SIMAP API’ is used only informally in this document to reference one or more northbound interfaces that an implementation may expose; concrete API behaviour and transactions will be specified in separate normative documents.”

2) Regarding the core topology and core topological entities, the draft refers to “core topological entities” and “core topological properties” (section 1) but never pins down their meaning. Which canonical topology objects to they map to ? network, node, termination point, link, path, service-attachment point, resource attributes, and technology-specific augmentations.
Adding a SIMAP ontology (given it’s a fashionable term in these days 😃 ) subsection (short list) that explicitly maps SIMAP terms to RFC8345 entities (or to the canonical names you choose) would help e.g.: network, node, termination point, link, SAP, resource object…

I’m wondering if it could also make sense to define core properties that every SIMAP network instance should carry (identifiers, timestamps, provenance, administrative state, operational state, capacity attributes, technology type).

3) Topology directionality is another thing that is not very clear to me:  unidirectional/bidirectional usage. The draft currently states that a topology can be “unidirectional or bidirectional” (section 2) but it’s not clear to me what it means at a topology level — directionality generally applies to links or path/connection semantics, not to an entire mesh topology.

4) Last things, I promise, is topology layers. The draft’s language about “service layer” vs “top layer” is confusing; at one point it sounds like the service layer is the topmost layer, elsewhere it implies a separate “top” layer concept.
Would it be possible to define topology layers as a level of abstraction or technology domain represented as a topology instance. Examples: physical layer (L0/L1), L2, L3, optical WSON, transport layers, and service layer (customer-facing logical services — VPNs, slices, overlay services) ?

I also asked a question a while back on the mailing list regarding the different between SIMAP and a knowledge graph in the context of telco network. Given SIMAP is an umbrella under which we put all the relevant models and, if I correctly understand, which provides the relationship between them…I getting confused on what else is needed? But maybe this is not a question that this draft should provide and answer to.

Thanks
Daniele


From: Reshad Rahman <reshad=[e-mail]<mailto:reshad=[e-mail]>>
Sent: Tuesday, November 25, 2025 12:57 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

NMP WG,

This is a reminder to review this document and provide comments by responding to the email below sent last week.

Regards,
Reshad.

On Monday, November 17, 2025 at 03:01:16 PM EST, Reshad Rahman via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:



Subject: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

This message starts a 2-week WG Last Call for this document.

Abstract:
  This document defines the concept of Service & Infrastructure Maps
  (SIMAP) and identifies a set of SIMAP requirements and use cases.
  The SIMAP was previously known as Digital Map.

  The document intends to be used as a reference for the assessment of
  the various topology modules to meet SIMAP requirements.

File can be retrieved from:
https://datatracker.ietf.org/doc/draft-ietf-nmop-simap-concept/

Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping [e-mail]<mailto:[e-mail]>
in copy. Objections should be motivated and suggestions to resolve them are
highly appreciated.

Authors, and WG participants in general, are reminded again of the
Intellectual Property Rights (IPR) disclosure obligations described in BCP 79
[1]. Appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of
any. Sanctions available for application to violators of IETF IPR Policy can
be found at [3].

Thank you.

[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/