Summary

  • draft-ietf-nmop-simap-concept-13 defines bidirectional navigation between services and their supporting logical and physical resources, but the answer remains the view one SIMAP server exposed to one authorised client.
  • Completeness, time alignment, cause, decision authority, network actuation and observed outcome require separate evidence; revision 13 is in IETF Last Call and is not an RFC.

Imagine an operator selecting a customer service and asking a map to reveal everything beneath it. The answer descends through service nodes and links, Layer 3 and Layer 2 constructs, termination points and eventually physical devices. A second query starts with a failed resource and climbs upward to identify the services that rely on it. This is the operational promise at the centre of the IETF's Service & Infrastructure Maps concept: turn a stack of disconnected topology models into a graph that can be traversed in both directions.

The temptation is to treat a successful traversal as a discovery of the network itself. It is not. It is a successful statement by one server about the model, sources, time and disclosure policy behind that response. That distinction is not a criticism of SIMAP. It is the condition under which the model becomes useful without quietly acquiring authority it does not possess.

The document at issue is revision 13 of draft-ietf-nmop-simap-concept, dated 4 September 2026. The IETF Datatracker lists it as an active NMOP Working Group Internet-Draft intended for Informational status. It entered IETF Last Call on 12 September, with comments due by 26 September. The history therefore records a live review process, not a completed RFC.

What the graph is designed to do

Revision 13 defines a core topology model around networks, nodes, links and termination points. Relationships can exist inside a layer and between layers. The service-to-resource use case begins with selected services and follows supporting relationships down to the logical and physical resources they use. The resource-to-service use case reverses the direction: a client selects a physical, Layer 2 or Layer 3 resource and follows the graph to services, nodes, links and termination points that depend upon it.

That structure matters. A ticket saying that “router X affects product Y” is less useful than a machine-navigable path showing which service component uses which overlay, which underlay and which physical element. The same path can support impact analysis, capacity planning, fault isolation and billing. RFC 8345, the existing Standards Track YANG model for network topologies, already defines supporting networks, nodes, links and termination points. SIMAP's concept extends the question from generic topology representation toward an operator-facing map that links service and infrastructure views and points to external models.

But the graph is deliberately not a warehouse for every operational fact. Capacity, status, performance, inventory, assurance, configuration and observability may live outside the core topology. SIMAP can link to those models. A link means that a client can navigate to another record; it does not prove that the other system uses the same identity, observes the same epoch or expresses the same confidence.

An authorised view can be accurate and incomplete

The draft states that retrieval is always subject to what the client is authorised to see. A server may hide layers or replace a native layer with an abstraction for security, administrative or commercial reasons. That makes the response valid for the client while preventing it from being read as an exhaustive inventory.

This produces a basic rule for incident work: absence from a response is not evidence of absence from the network. A client may see one abstract node where an authorised operator sees a set of native nodes. A service may appear to depend on one logical edge even though the provider has withheld the physical diversity beneath it. The abstraction may be exactly what the access policy requires. The analytical mistake begins only when a downstream system forgets that the graph was scoped.

Abstraction and layering are also different operations. Revision 13 asks SIMAP to navigate between layers—for example, from a Layer 3 link to the Layer 2 path supporting it—and across abstraction levels, such as from one abstract node to the native nodes it represents. A query receipt therefore needs both dimensions. “Layer 3 returned” says nothing about whether it was native, aggregated or selectively disclosed.

“Live” is a claim with a clock

The draft defines live topology as the latest snapshot of the real network and requires implementations to discover and synchronise network state. Those are design requirements. They do not let a consumer infer that every response was complete and freshly synchronised merely because an endpoint returned HTTP success.

The same model can expose snapshots, potential topology, intended topology and passive topology. Intended topology expresses what is desired and may omit intermediate hops, devices or detailed links. Passive topology can contain plant that cannot be discovered from active network protocols and must be recorded or reached through another source. Status and temporal history may be stored in SIMAP or accessed outside it. Before comparing two records, a client needs to know which kind of topology each one represents, when it was observed or asserted and which system supplied it.

This is especially important when an inventory record, an assurance symptom and a topology edge are combined. A serial number from inventory, a health state from assurance and a supporting relationship from SIMAP may all be individually correct yet describe different times. Joining them on a convenient label can create an apparently precise dependency that never existed at one shared epoch.

A dependency is not a cause

When a resource-to-service query returns five services, it identifies modeled exposure. It does not prove that a failure in the selected resource caused an observed service incident. The resource might be on a backup path, shared for load balancing, represented at the wrong time or hidden behind a stale relationship. The service might have failed for an unrelated reason.

The responsible incident statement is narrower: “Under topology instance A, access policy B and snapshot C, these services were represented as dependent on resource D.” Causation needs additional chronology and observation: the resource state changed, the affected traffic or service state changed in a compatible interval, alternatives were considered, and recovery followed an intervention or state restoration. SIMAP can organise that investigation. It cannot substitute for it.

A map write is not network actuation

Revision 13 is unusually helpful on another boundary. SIMAP APIs may provide read and write operations, but writing the topology is not intended to change the live network as a controller configuration interface would. Writes support simulations and topology that cannot be discovered, including intended and passive views. Live changes travel through normal controller operations.

That makes four separate receipts necessary in automation: the map or proposal that informed the decision; the policy decision and actor authorised to make it; the controller or device operation that attempted the change; and the post-change observation that established the outcome. Collapsing those into “SIMAP updated successfully” turns a model transaction into a fictional operating result.

The same discipline applies to a closed loop. The draft describes monitoring, analysis, corrective action and feedback. A graph can supply the representation used by the loop. It does not prove the selected action was permitted, delivered, accepted or effective. The feedback phase has to observe the network and service again.

The useful artefact is a scoped map receipt

For each consequential query, an operator should be able to retain the topology instance and model version; the server; client role and authorisation scope; abstraction level; source systems; snapshot or observation times; relationship direction; external identifiers; and any known sync condition. If the graph informed action, the decision, authority, actuation and outcome should be recorded separately.

That record does not make SIMAP less automated. It makes the automation legible. The IETF concept offers a valuable common surface for tracing dependencies. The strongest conclusion from a successful query is also the most precise: this is the dependency view the server was prepared to show, under these conditions, at this time.

Sources

Primary status and concept text: SIMAP revision 13 and its Datatracker history. Supporting standards: RFC 8345 for the base topology model, RFC 8341 for YANG access control, RFC 8040 for RESTCONF, RFC 9417 for service assurance and RFC 9408 for service attachment points. The related SIMAP YANG draft is an individual Internet-Draft without formal IETF standing. Frozen source text: revision 13 archive. Traffic-engineering context: RFC 9522.