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

[Italo Busi <[e-mail]>]

Hi NMOP WG and chairs,

This document aims to provide the concept, requirements, and use cases for SIMAP. This work is quite useful also as a foundation for further discussion on how to develop the YANG data models to address these scenarios.

After having review the document, I think that some aspects of this document require more work or clarification.

Therefore, I do support moving forward this document if my comments below are addressed.

Major comments:

1) What is SIMAP?

Reading section 1, I am getting a bit confused about what SIMAP is.

In particular, it is not clear whether SIMAP is a data model or an API or an application or something else?

For example, the first paragraph says that this document "does not specify a modeling approach for SIMAP" but the second paragraph says that "SIMAP is a data model that provides a view of the operator's networks" and later that SIMAP "specifically provides an approach to model multi-layered topology" ...

My gut feeling is that the confusion is driven by the fact that some text has been taken from an earlier draft which was combining the SIMAP concepts with data model definition. However, considering the scope of this document, IMHO, some more work has to be done to clean-up the text and clarify the concept throughout the whole document.

The document is also using the term "SIMAP API". At the first glance, API definition looks an implementation specific issue, outside the scope of standardization.

2) What is a core topology?

The third paragraph in section 1 introduces terms like "core topological entities" and "core topological properties".

Minor comments

1) Section 1, paragraph 4

It says: "The SIMAP data consists of virtual instances of network and service topologies at different layers"

Why "virtual" and not "abstract"?

RFC8345 speaks about abstract networks.

Moreover, this text seems requiring to define a single network topology instance for each layer in multi-layer networks, while the definition of multi-layered topology allows also defining a single topology instance encompassing multiple layers.

2) Section 1, last two paragraphs

The last paragraph and the second part of the paragraph above, speaks about API and write operations on network topology.

Firstly, it is not clear why we need a standard YANG model for offline simulations. I am wondering whether you are considering online simulations instead.

Some operational considerations would help understanding this concept.

Secondly, it is also not clear whether the intention is to have real network and offline simulation data be reported within the same topology instance or on different topology instances.

3) Section 2, topology definition

It is not clear to me how a topology can be unidirectional or bidirectional. I can understand this concept for p2p links/paths/connectivity but it is not clear to me how this concept can be applied to topologies (e.g., mesh topologies).

4) Section 2, topology layer definition

The difference between the service layer and the top layer is not fully clear. I thought the service layer was the topmost level in SIMAP.

5) Section 3.1

As stated, the current text seems providing a requirement for an internal API to be used by an application.

IMHO, this section should only say that "SIMAP data should provide enough information to allow an application to retrieve the topology for selected services ..."

6) Section 3.1.3

The last paragraph is not fully clear.

IMHO, TE is not covering capacity planning and simulation but capacity planning and simulation use cases should take into account TE if used in the network. Moreover, IMHO, other SIMAP use cases are also applicable to the so-called "TE networks", such as closed loop operations, ...

IMHO, SIMAP can improve the operations of the so-called "TE networks".

For example, a what-if analysis for a TE network should consider the impact of the event to the TE database.

I would also mention that TE is a multi-layer network optimization technique.

7) Section 3.7: Network Design

The workflow described here is not fully clear.

It says that the "application will retrieve a candidate network topology". Who is providing this? The network controller? Based on which input?

Who is writing the proposed network and what is the expected behavior from the write operation?

8) Section 3.9: Postmortem Replay

From the text in this section, it seems to me that SIMAP not only provides topological information but also logs of different events.

I am wondering whether the intention is to say that we can have SIMAP historical view before and after some events in the log and a reference/navigation to the event(s) in the log which has caused the changes in the SIMAP

9) Section 4: design and architecture requirements

I am not sure we need to capture operators' requirements here.

The users of a system should not care about the API design or system architecture as long as the system provide the required functionality and easy to use GUI, but these requirements should be captured in the operator requirements.

10) REQ-BASIC-MODEL-SUPPORT

Pending resolution of the major comment about the "core topology" definition.

Moreover, what does "understand a topology model" mean?

I am wondering whether in this context, the intention is to say that there is no need to understand the technology-specific information (but I assume at least the layer is needed to be understood to know whether the topology reports a L3, L2 or an optical network).

11) REQ-VIEWPOINTS

This requirement is not fully clear, most likely  because linked to the major comments above.

I can understand that different applications may require different SIMAP views. My doubt is how the network controller can know which view is required by the current and future applications.

Considering the example in the draft, does it mean that a network controller shall provide three topology instances: one for L2-only, one for L3-only and one for L2+L3?

12) REQ-PASSIVE-TOPO

The requirement is valid but the provisioning of the passive resources is an interesting open issue.

If the YANG client knows the passive resources, why it should write this information to the YANG server and read that from the YANG server rather than from its internal database?

I would suggest to leave out of scope the mechanisms used to discover the passive topology and just require that network inventory includes also passive resources and SIMAP provides link to those passive resources

13) REQ-STD-API-BASED

Pending resolution of the major comments above

14) REQ-COMMON-API

It seems a duplication of the REQ-BASIC-MODEL-SUPPORT above, with similar issue

I am wondering whether the intention  here is to simply say that SIMAP applies to different network domains (campus, core, data centers, etc.)

15) REQ-GRAPH-TRAVERSAL

The sentence looks weird: "SIMAP must be optimized for graph traversal for paths and for graph traversal for the specific use case queries"

The term "optimized" needs some qualification about what are the optimization criteria

It is also not clear why "only providing link nodes and source and sink relationships to termination-points may not be sufficient" nore what is the "direct relationship between the termination points or nodes" information

Moreover, is there a definition of graph traversal? Searching from it, I have found references to path computation algorithms.

If this is the case, this description needs to be discussed with TEAS WG.

16) REQ-SNAPSHOT

The requirement looks valid to me but, as currently stated, appears unfeasible so some more details are needed

How can I get now the SIMAP snapshot of one hour ago?

Somehow and sometime before one hour ago, a request for saving this snapshot had to be sent to the network controller.

Alternatively, are we requiring the network controller to save a snapshot of the SIMAP every time there is a change?

17) REQ-POTENTIAL and REQ-INTENDED

I am not sure I can understand the difference (maybe it is a terminology issue)

I can understand the requirement to inform the network controller that I have the intention to install new nodes and links so I can be able to pre-configure them before they are actually installed in the network. Is this intended or potential or a different requirement?

The need to write information about the nodes/links which are not discovered by the network controller is still unclear to me (see previous comment on REQ-PASSIVE-TOPO)

BTW, I agree that there is a need to improve the semantic description of write operation on the topology model. This document seems to me a good starting point to define the actual requirements for writing topology information on a network controller.

18) REQ-BIDIR

The term "simplified service layer topology" needs further qualification on the "simplification".

I do agree on the requirement to show how a bidirectional link in the client layer (or higher abstraction view) can be supported by two unidirectional links in the server layer (or lower abstraction view).

19) REQ-MULTI-POINT

Again the term "simple" requires clarification

Why modelling these entities as "explicit" is an operators' requirement? For me it is a questionable design requirement.

What is an "hybrid" cardinality?

Proposed rephrase:

SIMAP must provide a mechanism to model multipoint links. A topology model should be able to model any topology type, including point to multipoint, bus, ring, star, tree, mesh, hybrid and daisy chain. A topology model should also be able to model any link cardinality, including point-to-point, point-to-multipoint, multipoint-to-multipoint.

20) REQ-SHARED

Since in RFC8345, nodes, links and termination points are defined under the network, it is not possible to share them between different networks.

21) REQ-SUPPORTING

I have a mixed feeling on this requirement.

IMHO, if the TP is defined as just a point binding a node with a link, there is no need to model a supporting relationship with a node. However, if the TP can encompass also functions of a node or a of link, then I understand the need for this requirement.

However, I am not sure about the example. The loopback is an interface on a physical device and can be modelled as a TP which belongs to the node that is associated with the physical device.

22) REQ-TEMPO-HISTO

What is the difference between the temporal and historical part of this requirement and REQ-SNAPSHOT?

What is the difference between temporal data and historical data?

What do you mean with geo-spatial data? Do you mean that SIMAP should provide geolocation information for the topology elements? If so, why this is a design requirement and not an operators' requirement?

23) REQ-USABILITY

I do not see the need for this requirement. The terms "simple" and "easy" requires further qualification.

Moreover a network controller should support multiple applications with different requirements. What is perceived a simple from one set of application developers may be perceived as complex by another set of application developers.

Propose to remove this requirement

Nits:

1) Is SIMAP singular or plural?

I am not sure whether this is a nit or not, but let me flag it:

- the SIMAP acronym spells out as Service & Infrastructure Maps, which is plural

- the document is using the SIMAP acronym as a singular term

2) Section 2, topology layer definition

I am not sure OSPF, IS-IS or BGP can be considered a "layer"

Thanks, Italo

> -----Original Message-----
> From: Reshad Rahman via Datatracker <[e-mail]>
> Sent: lunedì 17 novembre 2025 21:01
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: [NMOP] WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-
> 12-01)
> 
> 
> 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] 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/
> 
>