NMOP Working Group V. Boudia Internet-Draft P. Francois Intended status: Standards Track INSA-Lyon Expires: 7 May 2026 S. Mostafa Huawei 3 November 2025 External Relationship model for SIMAP draft-vivek-nmop-simap-external-relationship-00 Abstract 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. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-vivek-nmop-simap-external- relationship/. Discussion of this document takes place on the NMOP Working Group Working Group mailing list (mailto:nmop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/nmop/. Subscribe at https://www.ietf.org/mailman/listinfo/nmop/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 May 2026. Boudia, et al. Expires 7 May 2026 [Page 1] Internet-Draft vivek-nmop-simap-ext-ref November 2025 Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Template . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Parameter . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Request . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Relation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Request supported . . . . . . . . . . . . . . . . . . . . 6 4.2. Parameter value . . . . . . . . . . . . . . . . . . . . . 6 4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. SIMAP requirements . . . . . . . . . . . . . . . . . . . . . 8 6.1. REQ-SCALES . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. REQ-SYNCH . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Base Type . . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. Label . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.3. Request . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Template . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Relation . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Boudia, et al. Expires 7 May 2026 [Page 2] Internet-Draft vivek-nmop-simap-ext-ref November 2025 1. Introduction [RFC8345] 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 [I-D.draft-ietf-nmop-simap-concept], Section 4. 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. Boudia, et al. Expires 7 May 2026 [Page 3] Internet-Draft vivek-nmop-simap-ext-ref November 2025 2. Terminology Network Element: A Network, Node, Link, or Termination Point (TP), as defined in [RFC8345]. 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. 3. 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. 3.1. 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). Boudia, et al. Expires 7 May 2026 [Page 4] Internet-Draft vivek-nmop-simap-ext-ref November 2025 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). 3.2. 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. 3.3. 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: {router- id} Boudia, et al. Expires 7 May 2026 [Page 5] Internet-Draft vivek-nmop-simap-ext-ref November 2025 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. 4. 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). 4.1. 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. 4.2. 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. Boudia, et al. Expires 7 May 2026 [Page 6] Internet-Draft vivek-nmop-simap-ext-ref November 2025 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. 4.3. 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. 5. 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. Boudia, et al. Expires 7 May 2026 [Page 7] Internet-Draft vivek-nmop-simap-ext-ref November 2025 These filtering capabilities enable flexible integration with automation systems and monitoring platforms, while minimizing unnecessary processing and data retrieval. 6. SIMAP requirements 6.1. 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. 6.2. 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. 7. 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. 7.1. 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. identity AUGMENT-EXAMPLE-TEMPLATE-TYPE { base dr-tmp:template-type; } 7.2. 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. Boudia, et al. Expires 7 May 2026 [Page 8] Internet-Draft vivek-nmop-simap-ext-ref November 2025 identity AUGMENT-EXAMPLE-LABEL { base dr-tmp:label; } 7.3. 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. identity AUGMENT-EXAMPLE-REQUEST-TYPE { base dr-tmp:request-type; } Then, the required elements for the request can be specified. grouping augment-example-request { leaf foo { type string; } } augment "/dr-tmp:template/dr-tmp:template/" + "dr-tmp:request/dr-tmp:request-builder" { when "derived-from-or-self(../dr-tmp:request-type," + " 'AUGMENT-EXAMPLE-REQUEST-TYPE')"; uses augment-example-request; } The example below illustrates how to define a NETCONF request with a subtree filter. identity NETCONF-EXAMPLE-REQUEST-TYPE { base dr-tmp:request-type; } grouping netconf-example-request { leaf subtree { type string; } } augment "/dr-tmp:template/dr-tmp:template/" + "dr-tmp:request/dr-tmp:request-builder" { when "derived-from-or-self(../dr-tmp:request-type," + " 'NETCONF-EXAMPLE-REQUEST-TYPE')"; uses netconf-example-request; } Boudia, et al. Expires 7 May 2026 [Page 9] Internet-Draft vivek-nmop-simap-ext-ref November 2025 8. 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. 9. YANG Modules 9.1. Template module draft-template { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:draft-template"; prefix dr-tmp; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } organization "INSA Lyon"; contact "Editor: Vivekananda Boudia "; description "template yang model"; revision 2025-08-01 { description "Initial revision"; reference ""; } Boudia, et al. Expires 7 May 2026 [Page 10] Internet-Draft vivek-nmop-simap-ext-ref November 2025 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; Boudia, et al. Expires 7 May 2026 [Page 11] Internet-Draft vivek-nmop-simap-ext-ref November 2025 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"; } Boudia, et al. Expires 7 May 2026 [Page 12] Internet-Draft vivek-nmop-simap-ext-ref November 2025 } 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"; } } } } 9.2. Relation module draft-relation { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:draft-relation"; prefix dr-rel; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-network { Boudia, et al. Expires 7 May 2026 [Page 13] Internet-Draft vivek-nmop-simap-ext-ref November 2025 prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import ietf-network-topology { prefix nt; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import draft-template { prefix dr-tmp; } organization "INSA Lyon"; contact "Editor: Vivekananda Boudia "; 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 Boudia, et al. Expires 7 May 2026 [Page 14] Internet-Draft vivek-nmop-simap-ext-ref November 2025 "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 Boudia, et al. Expires 7 May 2026 [Page 15] Internet-Draft vivek-nmop-simap-ext-ref November 2025 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"; } } } } } 10. Normative References [I-D.draft-ietf-nmop-simap-concept] Havel, O., Claise, B., de Dios, O. G., and T. Graf, "SIMAP: Concept, Requirements, and Use Cases", Work in Progress, Internet-Draft, draft-ietf-nmop-simap-concept- 05, 7 July 2025, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . Boudia, et al. Expires 7 May 2026 [Page 16] Internet-Draft vivek-nmop-simap-ext-ref November 2025 Acknowledgments Acknowledgments Authors' Addresses Vivekananda Boudia INSA-Lyon Email: vivekananda.boudia@insa-lyon.fr Pierre Francois INSA-Lyon Email: pierre.francois@insa-lyon.fr Sherif Mostafa Huawei Email: sherif.mostafa@huawei.com Boudia, et al. Expires 7 May 2026 [Page 17]