Hi Stewart, Thanks for your review.
Attached is rfcdiff with the current proposed changes.Alternatively, see https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/pull/190
See inline On 25/07/2026 12:49, Stewart Bryant via Datatracker wrote:
Document: draft-ietf-nmop-simap-concept Title: SIMAP: Concept, Requirements, and Use Cases Reviewer: Stewart Bryant Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-nmop-simap-concept-12 Reviewer: Stewart Bryant Review Date: 2026-07-25 IETF LC End Date: None IESG Telechat date: Not scheduled for a telechat Summary: A well written and informative document that is ready for approval. I have a few comments listed under nits that the authors may wish to consider. Major issues:None Minor issues:None Nits/editorial comments: Early in the document it talks about simulation prior to change and then at later talks about simulation at varying degrees of abstraction. Only much later in the document does it formally talk about the digital twin concept. Now it may be industry convention, but given that unless you simulate at the quantum level all digital twinning is based on abstraction I am surprised the concept is not introduced earlier and in conjunction with the higher levels of abstraction,
We deliberately kept the Network Digital Twin (NDT) discussion in its own use case section rather than in the Introduction, because we want to avoid the impression that SIMAP is an NDT: SIMAP is a topology model that an NDT can be built on, and the NDT is the broader construct. Section 3.10 says this explicitly and defers to [I-D.irtf-nmrg-network-digital-twin-arch] for the definition rather than competing with it. However, we dded at the end of Section 1, after the paragraph ending "...while enabling side by side analysis.": NEW: These simulation capabilities, together with the different levels of abstraction at which a SIMAP can represent a network, are among the building blocks of a Network Digital Twin. The relationship between SIMAP and the Network Digital Twin concept is discussed in Section 3.10.
======= 214 There are several types of topologies: point-to-point, bus, ring, 215 star, tree, mesh, hybrid, and daisy chain. SB> Nit: I think there should be a for example preceding the above list so as not to limit it.
Agreed. OLD: There are several types of topologies: point-to-point, bus, ring, star, tree, mesh, hybrid, and daisy chain. NEW: There are several types of topologies, for example: point-to- point, bus, ring, star, tree, mesh, hybrid, and daisy chain.
======== 217 Topologies may be unidirectional (all links unidirectional) or 218 bidirectional (all links bidirectional), or contain combination of 219 unidirectional and bidirectional links. SB> Do you need to consider co-routing here?
OLD: Topologies may be unidirectional (all links unidirectional) or bidirectional (all links bidirectional), or contain combination of unidirectional and bidirectional links. NEW: Topologies may be unidirectional (all links unidirectional) or bidirectional (all links bidirectional), or contain combination of unidirectional and bidirectional links. Where a link is bidirectional, the two directions may or may not be supported by the same underlay resources. Both cases, co- routed and non-co-routed (also referred to as associated) bidirectionality, need to be distinguishable, since they differ in fate sharing and therefore change the outcome of any impact analysis.
========= 250 Some topology layers may relate closely to OSI layers, like Layer 251 1 topology for physical topology, Layer 2 for link topology and 252 Layer 3 for IPv4 and IPv6 topologies. SB> Does there need to be a comment about the cross layer operation of the Internet which is not as “pure” as the OSI model? For example the IP layer carries transport layer type which some have argued is a layer violation. Normally this is of no significant consequence but needs to be thought about in formal hierarchical models like this/ Maybe that is addressed by "closely"?
OLD: Some topology layers may relate closely to OSI layers, like Layer 1 topology for physical topology, Layer 2 for link topology and Layer 3 for IPv4 and IPv6 topologies. NEW: Some topology layers may relate closely to OSI layers, like Layer 1 topology for physical topology, Layer 2 for link topology and Layer 3 for IPv4 and IPv6 topologies. The correspondence is deliberately loose: as defined above, each topology layer represents a connectivity aspect of the network and services that needs to be configured, controlled and monitored, and such layers are not required to map one to one onto the OSI layers.
======== 278 * tunnel: for transport tunnels and paths, for MPLS and SRv6, SB> I am not sure SRv6 is a tunnel, and the designation of MPLS as a tunnel causes confusion until you understand what is really happening. MPLS can be thought of as a full blown network layer in its own right and SRv6 in some applications is a novel network layer constructed using IPv6 infrastructure. A GRE, IPSec or pseudowire might be a better examples.
OLD: * tunnel: for transport tunnels and paths, for MPLS and SRv6, NEW: * tunnel/transport: for transport tunnels, paths and policies, for example GRE, IPsec, pseudowires, MPLS-TE LSPs, and SR/SRv6 policies,
======== Reading section 3.1.1 SB> I am caused to wonder what happens in cases where you are not allowed to know the physics of the underlay. Presumably you support the abstraction of those concepts into a higher layer? 561 The service placement feasibility check application will be able to 562 retrieve the topology at any layer from the SIMAP server via the SB> Should that be any visible layer? I would have thought that there would still be layer hiding for security and commercial reasons.
Rather than qualify every occurrence of "at any layer" in Section 3, we have added one statement to the Section 3 preamble
NEW: In this section, the ability to retrieve "a topology layer" or "the topology at any layer" is always subject to what the client application is authorized to see: a SIMAP server may hide layers, or expose an abstraction of a layer in place of the layer itself, for security, administrative, or commercial reasons. Where the underlying resources are not disclosed, the client is presented with an abstract topology and navigates that instead (REQ-TOPOLOGY- ABSTRACTION).
We would rather not speculate about it in the document, so no change proposed here.======== 755 3.8.1. Types of Network Simulation SB> Presumably we will eventually have quantum simulation where it explores all network conditions simultaneously.
Several of the methods described in this document could reasonably be called a digital twin, depending on where one places the boundary on the abstraction-to-reality line. That boundary is precisely why we chose not to define NDT ourselves: a second definition competing with the one in [I-D.irtf-nmrg-network-digital-twin-arch] would help neither the reader nor the wider community. Section 3.10 therefore cites the IRTF definition, then states what SIMAP contributes to an NDT and what an NDT adds beyond SIMAP.SB> My thought on section 3.10 in response to the notes on [I-D.irtf-nmrg-network-digital-twin-arch] SB> That is the IRTF view, but I would have thought that some of the methods celled up in this document would have been considered a digital twin. I imagine it depends on where DT needs to sit on the abstraction-reality line, and different points seem appropriate for different levels of congruence between the physics and the analysis.
Thanks again for your review. Regards, Benoit (on behalf of the authors).
========
<<< text/html; charset=UTF-8; name="draft-ietf-nmop-simap-concept-12-13.diff.html": Unrecognized >>>
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
