]> INSA-Lyon

vivekananda.boudia@insa-lyon.fr

INSA-Lyon

pierre.francois@insa-lyon.fr

Huawei

sherif.mostafa@huawei.com

NMOP NMOP Working Group simap This document defines a SIMAP feature that enables modeling of external relationships between SIMAP entities and resources outside their core data models. It provides a templating approach to describe queries for external information, and an approach to link them to network elements. Status information for this document may be found at . Discussion of this document takes place on the NMOP Working Group Working Group mailing list (), which is archived at . Subscribe at .

Introduction defines a base model for representing network topologies. This model can be augmented to include additional information, depending on the layer, service, or use case. However, continuously augmenting the base model can lead to excessive complexity and the inclusion of data that is irrelevant to many applications. In some application contexts, it is impractical to maintain the whole network element information within the simap itself. To preserve an exploitable map of the network, it is thus sometimes preferable to keep the base topology model minimal and maintain context-specific information separately. Yet, a formal description of the method to be used to retrieve this information from the production network or any other external source should be maintained. The goal of this document is to provide a common approach to describe such information retrieval methods, in a yang model. The goal of this effort is to fulfill two key requirements: REQ-SCALES and REQ-SYNCH, defined in . For example, when simulating a what-if scenario involving IGP convergence time after an IS-IS link failure, one might require timer-related attributes for each router. While this information is essential in that context, it is unnecessary for many other use cases. In addition, some data elements may change frequently, making it challenging to keep the model synchronized. In the general case, the method to retrieve a given type of information among many network elements is the same, except for some parameters. We thus propose an approach to describe these methods using templates. These templates are then associated with network element instances via a separate datastore referred to as the relation datastore. We introduce filtering mechanisms based on either the template type or the request type, allowing us to retrieve only the relevant data depending on the use case. This document first introduces the terminology used throughout the draft. It then describes the concepts of Template and Relation, followed by the filtering mechanisms available and how it solves REQ-SCALES and REQ-SYNC. Next, it explains how the model can be extended. The workflow is then presented, and the document concludes with the YANG module.

Terminology Network Element: A Network, Node, Link, or Termination Point (TP), as defined in . Template: A reusable model that describes how to retrieve a set of data. Label: A set of keywords that describe the nature or category of information that can be retrieved using the Template. Relation: An association between a Template and a Network Element, indicating that the Template should be applied to the element to retrieve a given set of information.

Template A Template describes how to access data from a Network Element. It is uniquely identified by an id in the form of a uri. The management of the id space is out of the scope of this document. Each Template includes a textual description that explains its purpose and usage, along with additional key attributes, such as the Template's type, parameters, and request definitions, as described in the following sub section. A separation between the template definition and their parameters is used in order to ensure reusability.

Type Each Template includes a type attribute: base-type: Indicates the general category of the data the Template is intended to retrieve. Possible values include: config – for configuration data, state – for operational state data, metric – for performance metrics. is-historical: A boolean flag indicating whether the Template is used to retrieve historical data (true) or only current data (false). label: A set of keywords that describe the nature or category of information that can be retrieved using the Template. These labels serve as metadata, enabling filtering, classification, and discovery of Templates based on their purpose or content (e.g., timers, interface-metrics, isis-state).

Parameter Consider two routers: one with the identifier R1 and another with R2. If we wish to retrieve specific data for each router, the access paths might be /specific/data/id/R1 and /specific/data/id/R2, respectively. Without a parameterization mechanism, we would need to define a separate Template for each router, which does not scale. To address this, Template supports parameters. Instead of hardcoding the identifier, the Template encodes the path using a placeholder: /specific/data/id/{router-id}. The actual value of {router-id} is not stored within the Template itself, but is instead provided via the Relation datastore (described in the next section). This design enables a single Template definition to be reused across multiple Network Elements, with per-instance values injected dynamically through Relations.

Request While parameterization helps avoid duplication when all routers support the same protocol, challenges arise when devices support different access protocols. For instance, consider two routers: R1, which supports only RESTCONF, and R2, which supports only NETCONF. In such cases, although the data being retrieved is semantically the same, using a single protocol-specific Template per device would reintroduce redundancy. To address this, a Template may define multiple protocol-specific access methods for retrieving the same data. Each method corresponds to a different protocol (e.g., RESTCONF, NETCONF) and includes a distinct request format or path. For example: The RESTCONF request path might be: /restconf/specific/data/id/{router-id} The NETCONF XML filter might be: <specific><data><id>{router-id}</id></data></specific> The selection of which request to use for a given Network Element is determined by information stored in the Relation datastore (discussed in the next section). This allows a single Template to cover multiple access methods, while preserving reusability and minimizing duplication.

Relation A Relation defines the association between a Template and a Network Element. It provides the contextual parameters required to apply the Template to the targeted element. Each Relation is uniquely identified by an id. To establish the linkage, the Relation contains: A reference to the template-id of the associated Template. A reference to the network-element-id of the target Network Element. A Relation contains additional contextual information that will be described in the following sections, including: the supported request types, the parameter values, and the path identifying the target sub-layer (if applicable).

Request supported As previously described, a Template may include multiple protocol-specific request definitions. Since not all devices support all protocols, the Relation is responsible for specifying which request(s) are valid for the associated Network Element. This ensures that the correct method is used for data retrieval, without duplicating Template definitions.

Parameter value In addition, each Relation stores the parameter values required to instantiate the associated Template. These values are used to replace placeholders (e.g., {router-id}) defined in the Template when constructing the actual request. If a parameter required by the Template is not provided in the Relation, it is assumed that the user or the consuming system must supply this value at runtime. This design provides flexibility while ensuring that Templates remain reusable across different contexts.

Path Depending on the network modeling approach, a Network Element may be encapsulated within multiple hierarchical layers — for example: base → L3 → IS-IS. Since each Network Element is uniquely identified at the base level, additional context may be required to indicate which layer or model a Template applies to. To address this, the Relation includes an optional path value. This field specifies the relative path from the base element to the targeted sub-layer. For instance: If the Template targets IS-IS attributes, the path value might be set to /l3/isis. If the Template applies to the base layer, the path is set to an empty string. This mechanism enables precise scoping of the Template within a layered network model, without introducing ambiguity.

Filtering To support efficient access and scalability, the system provides multiple filtering mechanisms for querying Relations and Templates. These filters allow consumers to only retrieve the relevant associations based on criteria. Supported filtering options include: By Network Element: Retrieve all Relations associated with a given network element identifier. By Request Type: Filter Relations or Templates based on supported protocol access methods (e.g., restconf, netconf). By Template Type: Select Templates based on their declared base-type (e.g., config, state, metric). By Label : Retrieve Templates based on semantic tags (e.g., timers, isis, interface-metrics) that describe the type of information provided. These filtering capabilities enable flexible integration with automation systems and monitoring platforms, while minimizing unnecessary processing and data retrieval.

SIMAP requirements

REQ-SCALES By grouping all requests within a single template, we avoid defining multiple templates for retrieving the same information. Additionally, by using the supported attribute of the relation, we remove the need to create separate templates for each network element. This approach also prevents overloading the SIMAP itself.

REQ-SYNCH Some types of information remain relatively static over time, while others may change frequently. Using templates to retrieve this information avoids introducing the complexity of storing it directly within SIMAP. It allows the system to delegate data retrieval to external sources and focus solely on maintaining structural and relational data.

Extensions The template can be augmented to support multiple use cases, such as adding a new base type of the template, adding additional labels, or most importantly defining the type of request and the associated request builder.

Base Type A template can be categorized as STATE, CONFIG, or METRIC. However, some use cases may require other base types. These can be introduced through augmentation.

Label A template can describe multiple types of data, and it is not feasible to include every possible label by default. Additional labels can be introduced through augmentation.

Request The structure of a request may differ across use cases. These variations can be handled by augmenting the base request definition. The first step is to define a new request type.

Then, the required elements for the request can be specified.

The example below illustrates how to define a NETCONF request with a subtree filter.

Workflow The following workflow outlines the typical steps involved in defining and using Templates and Relations to retrieve data from network elements of SIMAP : 1) Define a reusable Template that describes how to access a type of data. 2) Create the SIMAP from the network. 3) Establish Relations to bind Templates to Network Elements based on their role. Populate the required parameters, path, and supported request types. 4) Use the filtering concept to retrieve the needed template, resolve parameters, and select the correct request type to fetch the desired data. Note: The order of steps 1 and 2 is not strict; either may be performed first depending on implementation preferences.

YANG Modules

Template

"; description "template yang model"; revision 2025-08-01 { description "Initial revision"; reference ""; } identity template-type { description "base identity for template type"; } identity CONFIG { base template-type; description "template used to retrieve configuration data"; } identity STATE { base template-type; description "template used to retrieve operational state data"; } identity METRIC { base template-type; description "template used to retrieve metrics"; } identity label { description "base identity for label"; } identity request-type { description "base identity for request type"; } identity ALL_REQUESTS { base request-type; description "all requests"; } container template { description "template container"; list template { key "template-id"; description "template list"; leaf template-id { type inet:uri; description "uniquely identifies a template"; } leaf description { type string; description "template description"; } container template-type { description "template type; used for filtering template"; leaf base { type identityref { base template-type; } description "template base type"; } leaf is-historical { type boolean; description "check if template is used to get historical data or not"; } leaf-list label { type identityref { base label; } description "used to defined which data can be retrieve with the template"; } } list parameter { key "param-id"; description "list of parameter used by request"; leaf param-id { type inet:uri; description "uniquely identifies a parameter"; } leaf description { type string; description "parameter description"; } } list request { key "request-type"; description "request list"; leaf request-type { type identityref { base request-type; } description "request type"; } leaf description { type string; description "request description"; } container request-builder { description "request container that contains everything needed to build the request; parameters must be enclosed in brackets."; } } anydata extra { description "use for augmentation"; } } } } ]]>

Relation

"; description "relations external of RFC8345"; revision 2025-08-01 { description "Initial revision"; reference ""; } container relation { description "relation container"; list relation { key "relation-id"; description "relation list"; leaf relation-id { type inet:uri; description "relation id"; } choice network-element-ref { description "reference to network element"; leaf network-ref { type leafref { path "/nw:networks/nw:network/nw:network-id"; } description "reference to network"; } leaf node-ref { type leafref { path "/nw:networks/nw:network/nw:node/nw:node-id"; } description "reference to node"; } leaf link-ref { type leafref { path "/nw:networks/nw:network/nt:link/nt:link-id"; } description "reference to link"; } leaf tp-ref { type leafref { path "/nw:networks/nw:network/nw:node" + "/nt:termination-point/nt:tp-id"; } description "reference to termination point"; } } leaf template-ref { type leafref { path "/dr-tmp:template/dr-tmp:template/dr-tmp:template-id"; } description "reference to template"; } leaf-list request-type-supported { type identityref { base dr-tmp:request-type; } description "template is generic and may include requests that are not supported by the network element here, we specify the types of requests that the network element supports if network element supports all request types ALL-REQUEST may be used"; } leaf path { type string; description "network element can be augmented and may contain containers nested within other containers. path is used for filtering"; } list parameter-value { key "param-ref request-type"; description "parameter value for network element"; leaf param-ref { type leafref { path "/dr-tmp:template/dr-tmp:template" + "/dr-tmp:parameter/dr-tmp:param-id"; } description "reference to template parameter"; } leaf request-type { type identityref { base dr-tmp:request-type; } description "value can be different depending on the request"; } leaf value { type string; description "value of the parameter"; } } } } } ]]>

This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. Huawei Huawei Telefonica Swisscom 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.

Acknowledgments Acknowledgments