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

[Italo Busi <[e-mail]>]

Hi Olga,

Thanks for the great work in compiling github issues to track my comments and for having started addressing them

I can confirm that you have corrected captured them all

I am starting to review your proposed resolutions and follow-up on each of them

Thanks, Italo

> -----Original Message-----
> From: Olga Havel <[e-mail]>
> Sent: mercoledì 10 dicembre 2025 18:26
> To: Italo Busi <Italo.Busi=[e-mail]>; Reshad Rahman
> <[e-mail]>; [e-mail]; nmop-
> [e-mail]; [e-mail]
> Subject: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends
> 2025-12-01)
> 
> Dear Italo,
> 
> Thanks for your comments. Reshad suggested to open the issues via github. I
> opened 34 Github issues from your email, please verify that I captured all. I
> am currently compiling the issues from all reviewers and merging the similar
> issues, after I finish all we can start addressing them one by one:
> 
> Best Regards,
> Olga
> 
> https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/issues
> 
> Issue Number	Issue
> 83	What is SIMAP?
> 84	What is core topology?
> 85	SIMAP data definition
> 86	Write API operations
> 87	Topology definition
> 88	Topology Layer Definition
> 89	Application versus SIMAP API
> 90	Traffic Engineering Use Case
> 91	Network Design Use Case
> 92	Postmortem Replay
> 93	Design and architecture requirements
> 94	REQ-BASIC-MODEL-SUPPORT
> 95	REQ-VIEWPOINTS
> 96	REQ-PASSIVE-TOPO
> 97	REQ-STD-API-BASED
> 98	REQ-COMMON-API
> 99	REQ-GRAPH-TRAVERSAL
> 100	REQ-SNAPSHOT
> 101	REQ-POTENTIAL and REQ-INTENDED
> 102	REQ-BIDIR
> 103	REQ-MULTI-POINT
> 104	REQ-SHARED
> 105	REQ-SUPPORTING
> 106	REQ-TEMPO-HISTO
> 107	REQ-USABILITY
> 108	Is SIMAP singular or plural?
> 109	"Topology Layer Definition: OSPF, ISIS or BGP as layer"
> 110	Observability sources and operational knowledge
> 111	Core topological entities and properties
> 112	Link to functional data for the instances
> 113	Service->Resource
> 114	REQ-LIVE
> 115	REQ-LAYER-NAVIGATE
> 116	REQ-EXTENSIBLE
> 
> -----Original Message-----
> From: Italo Busi <Italo.Busi=[e-mail]>
> Sent: Friday, November 21, 2025 11:45 AM
> To: Reshad Rahman <[e-mail]>; draft-ietf-nmop-simap-
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [NMOP] WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends
> 2025-12-01)
> 
> 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/
> >
> >