SIMAP: Concept, Requirements, and Use Cases

Internet-Draft	SIMAP Concept & Needs	February 2025
Havel, et al.	Expires 18 August 2025	[Page]

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 effort of the various topology modules to meet SIMAP requirements.¶

2. Terminology

The document makes use of the following terms:¶

Topology:: Topology in this document refers to the network and service topology. A network topology defines how physical or logical nodes, links and termination points are related and arranged. A Service topology defines how service components (e.g., VPN instances, customer interfaces, and customer links) between customer sites are interrelated and arranged.¶
: There are several types of topologies: point-to-point, bus, ring, star, tree, mesh, hybrid, and daisy chain.¶
: Topologies may be unidirectional or bidirectional (bus, some rings).¶
Multi-layered topology:: A multi-layered topology models relationships between different topology layers, where each layer represents a connectivity aspect of the network and services that needs to be configured, controlled and monitored. Each topology layer has a separate lifecycle.¶
Topology layer:: Represents topology at a single layer in the multi-layered topology.¶
: The topology layer can also represent what needs to be managed by a specific user or application, for example IGP layer can be of interest to the operator troubleshooting or optimizing the routing, while the optical layer may be of interest to the user managing the optical network.¶
: Some topology layers may relate closely to OSI layers, like L1 topology for physical topology, Layer 2 for link topology and Layer 3 for IPv4 and IPv6 topologies.¶
: Some topology layers represent the control aspects of Layer 3, like OSPF, IS-IS, or BGP.¶
: The service layer represents the service view of the connectivity, that can differ for different types of services and for different providers/solutions.¶
: The top layer represents the application/flow view of service connectivity.¶
Service:: Represents network connectivity service provided over a network that enables devices, systems, or networks to communicate and exchange data with each other. It provides the underlying infrastructure and mechanisms necessary for establishing, maintaining, and managing connections between different endpoints. The example services are: L2VPN, L3VPN, EVPN, VPLS, VPWS,¶
Subservice:: Represents component of the service that can be independently managed but is not provided as a service. The example subservices are: MPLS Tunnels, SRV6 Tunnels, VRFs, VPN Links, IGP Links.¶
Resource:: Defined in [I-D.ietf-nmop-terminology]¶

The document defines the following terms:¶

Service & Infrastructure Maps (SIMAP):: SIMAP is a data model that provides a view of the operator's networks and services, including how it is connected to other models/data (e.g., inventory, observability sources, and operational knowledge). It specifically provides an approach to model multi-layered topology and appropriate mechanism to navigate amongst layers and correlate between them. This includes layers from physical topology to service topology.¶
: This model is applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.).¶
SIMAP modelling:: The set of principles, guidelines, and conventions to model the SIMAP using the IETF modelling approach [RFC8345]. They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point, or link), entity properties, relationship types between entities and relationships to other entities.¶
SIMAP model:: Defines the core topological entities, their role in the network, core topological properties, and relationships both inside each layer and between the layers.¶
: It is the basic topological model with references/pointers to other models and connects them all: configuration, maintenance, assurance (KPIs, status, health, symptoms, etc.), traffic engineering, different behaviors, simulation, emulation, mathematical abstractions, AI algorithms, etc.¶
SIMAP data:: Consists of instances of network and service topologies at different layers. This includes instances of networks, nodes, links and termination points, topological relationships between nodes, links and termination points inside a network, relationships between instances belonging to different networks, links to functional data for the instances, including configuration, health, symptoms.¶
: The SIMAP data can be historical, real-time, or future data for 'what-if' scenarios.¶

3. Sample SIMAP Use Cases

The following are sample use cases that require SIMAP:¶

Inventory queries¶
Service placement feasibility checks¶
Service-> subservice -> resource¶
Resource -> subservice -> service¶
Intent/service assurance¶
Service E2E and per-link KPIs on SIMAP (connectivity status, high-availability, delay, jitter, and loss)¶
Capacity planning¶
Network design¶
Network Simulation and Emulation¶
Traffic Engineering¶
Postmortem Replay¶
Closed-loop¶
Network Digital Twin (NDT)¶

Overall, the SIMAP is needed to provide the mechanism to connect data islands from the core multi-layered topology. It is a solution feasible and useful in the short-term for the existing operations use cases, but it is also a requirement for the SIMAP.¶

The following subsections include some initial use case descriptions to initiate the discussion about what type of info is needed to describe the use cases in the context of SIMAP. The next version of the draft will include more info on these use cases and more input from the operators, from the perspective of what the value of the SIMAP for each use case is and how the SIMAP API can be used. This will also clarify if only read and if/when write interface is needed per use case.¶

3.1. Inventory Queries

Network inventory refers to a comprehensive record or database that tracks and documents all the network components and devices within an organization's IT infrastructure.¶

Key elements typically found in a network inventory include:¶

Hardware Details:

Descriptions of physical devices such as routers (including its internal components such as cards, power supply units, pluggables), switches, servers, network cables, including model numbers, serial numbers, and manufacturer information. These information will facilitate locating additional details of the hadware in the manufacturer systems and the correlation with the purchase catalog of the company.¶
Software and Firmware:

Versions of operating systems, network management tools, and firmware running on network devices. Note that a network device can have components with their own software and firmware.¶
Licensing Information:

For any licensed software or devices, the network inventory will track license numbers, expiry dates, and compliance.¶

Network inventory lifecycle refers to the stages a network device or component goes through from its introduction to the network until its removal or replacement. It encompasses everything from acquisition and deployment to maintenance, upgrade, and eventually decommissioning. Managing the network inventory lifecycle efficiently is crucial for maintaining a secure, functional, and cost-effective network.¶

A well-maintained network inventory helps organizations with network management, troubleshooting, asset tracking, security, and ensuring compliance with regulations. It also helps in scaling the network, planning upgrades, and responding to issues quickly. In order to facilitate the planning and troubleshooting processes it is necessary to be able to navigate from network inventory to network topology and services.¶

The application will be able to retrieve physical topology from the controller via the SIMAP API and from the response it will be able to retrieve physical inventory of individual devices and cables.¶

The application may request either one or multiple topology layers via the SIMAP API and from the response it will be able to retrieve both physical and logical inventory.¶

For Access network providers the ability to have linkage in the SIMAP of the complete network (active + passive) is essential as it provides many advantages for optimized customer service, reduced Mean Time To Repair (MTTR), and lower operational costs through truck roll reduction. For example, operators may use custom-tags that are readily available for a customer-facing device and then query the inventory based on that tag to correlate it with the inventory and then map it to the network/service topology. The mapping and correlation can be then used for triggering apprpriate service checks.¶

3.2. Service Placement Feasibility Checks

Service placement feasibility checks refers to the process of evaluating whether a specific service can be deployed and operated effectively in a given network. This includes accessing the various factors to ensure that the service will function as indended (e.g., based on traffic performance requirements), without causing network disruptions or innefficiencies and effecting other services already provisioned on the network.¶

Some of the factors that need assesing are network capabilities, status, limitations, resource usage and availability. The service could be simulated during the feasibility checks to identify if there are any potential issues. The load testing could be done to evaluate performance under stress.¶

The Service Feasibility Check application will be able to retrieve the topology at any layer from the controller via the SIMAP API and from the response it will be able to navigate to any other YANG modules outside of the core SIMAP topology to retrive any other information needed: resource usage, availability, status, etc.¶

3.3. Service-> Subservice -> Resource

The application will be able to retrieve all services using the SIMAP API for selected network types. The application will be able to retrieve the topology for selected services via SIMAP API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers. That way, it will be able to determine what logical resources are used by the service. The supporting relations to the lowest layer will help application to determine what physical resources are used by the service.¶

3.4. Resource -> Subservice -> Service

The application will be able to navigate from the Physical, L2 or L3 topology to the services that use specific resources. For example, the application will be able to select the resource and by navigating the supporting relationship bottom-up come to the service and its nodes, tps and links.¶

3.5. Intent/Service Assurance

Network intent and service assurance work together to ensure that the network aligns with business goals and that the services provided meet the agreed-upon Service Level Agreements (SLAs).¶

The Service Assurance for Intent-Based Networking Architecture (SAIN) [RFC9417] approach emphasizes a comprehensive view of components involved in service delivery, including network devices and functions, to effectively monitor and maintain service health.¶

The key objectives of this architecture:¶

Holistic Service Monitoring:

By considering all elements involved in service delivery, the architecture enables a thorough assessment of service health.¶
Correlation of Service Degradation:

It assists in linking service performance issues to specific network components, facilitating precise identification of faults.¶
Impact Assessment:

The architecture identifies which services are affected by the failure or degradation of particular network components, aiding in prioritizing remediation efforts.¶

When a service is degraded, the SAIN architecture will highlight where in the assurance service graph to look, as opposed to going hop by hop to troubleshoot the issue. More precisely, the SAIN architecture will associate to each service instance a list of symptoms originating from specific subservices, corresponding to components of the network. These components are good candidates for explaining the source of a service degradation.¶

3.6. Service E2E and Per-link KPIs

The application will be able to retrieve the topology at any layer from the controller via the SIMAP API and from the response it will be able to navigate any retrieve any KPIs for selected topology entity.¶

3.7. Capacity Planning

Network Capacity Planning refers to the process of analyzing, predicting, and ensuring that the network has sufficient capacity (e.g., [RFC5136]), resources, and infrastructure to meet current and future demands. It involves evaluating the network's ability to handle increasing (including forecast) amounts of data, traffic, and users activity, while maintaining acceptable levels of performance, reliability, and security.¶

The capacity planning primary goal is to ensure that a network can support business operations, applications, and services without interruptions, delays, or degradation in quality. This requires a thorough understanding of the network's current state, as well as future requirements and growth projections.¶

Key aspects of network capacity planning include:¶

Traffic analysis: Monitoring and analyzing network traffic patterns to identify trends, peak usage periods, and areas of congestion. For example, by generating a core traffic matrix with IPFIX flow record [RFC7011] or deducting an approximate traffic matrix from the link utilization data.¶
Resource utilization: Evaluating the link utilization throughout the network for the current demand identifying bottlenecks and potential QoS peformance issues.¶
Growth forecasting: Predicting future network growth based on business expansion, new applications, or changes in users behavior.¶
What-if scenarios: Creating models to assess the network behavior under different scenarios, such as increased traffic, failure conditions (link, router or Shared Risk Resource Group), and new application deployments (such as a new Content Delivery Network source, a new peering point, a new data center...).¶
Upgrade planning: Identifying areas where upgrades or additions are needed to ensure that the network can minimize the effect of node/link failures, mitigate QoS problems, or simply to support growing demands.¶
Cost-benefit analysis: Evaluating the costs and benefits of upgrading or adding new resources to determine the most cost-effective solutions.¶

By implementing a robust capacity planning process, organizations can:¶

Ensure better network reliability: Minimize downtime and ensure that the network is always available when needed.¶
Improve performance: Optimize network resources to support business-critical applications and services.¶
Optimize costs: Avoid unnecessary over-provisioning by making informed decisions based on data-driven insights.¶
Support business growth: Scale the network to meet increasing demands and support business expansion.¶

The application will be able to retrieve topology layer and any network/node/termination point/link instances from the controller via the SIMAP API and from the response it will be able to map the traffic analysis to the entities (typically links and router), evaluate their current utilization, based on the grow forecasting evaluate which elements to add to the network, and finally perform the 'what-if' failure analysis by simulating the removal of link(s) and/or router(s) while evaluating the network performance.¶

3.8. Network design

Network design involves defining both the logical structure-such as access, aggregation, and core layers and the physical layout, including devices and links.¶

It serves as a blueprint, detailing how these elements interconnect to deliver the intended network behavior and functionality. The application will retrieve the proposed network topology as the initial design, which can then undergo critical analyses-such as traffic flow simulations to identify bottlenecks and redundancy checks to ensure resilience-before being transformed into actionable intent and, eventually, deployment configurations. Throughout the network's lifecycle, the design rules embedded within the topology can be continuously validated. For example, a link rule might specify that a connection etween core and aggregation layers must have its source and destination located within the same data center. Another example to declare that specific link type should only exist between Core <> Aggregation layer with certain constrains on port optic speed, type (LR vs SR for instance) etc."¶

3.9. Network Simulation and Network Emulation

Network simulation is a process used to analyse the behaviour of networks via software. It allows network engineers and researchers to assess how the network protocols work under different conditions, such as diffenet topologies, traffic loads, network failures, or the introduction of new devices. Network emulation, on the other hand, replicates the behavior of a real-world network, allowing for more realistic analysis compared to network simulation. While network simulation focuses on modeling and approximating network behavior, network emulation involves creating a real-time, functional network environment whose protocol behaves exactly like a real network. Ideally, network emulation uses the same software images as in the real network, but it could also be peformed (with less accuracy) using generic software.¶

3.9.1. Types of Network simulation

There are several types of network simulations, each designed to address specific needs and use cases. Below are the main categories of network simulation:¶

Discrete Event Simulation (DES):

This is the most common type of network simulation. It models a series of events that occur at specific points in time. Each event triggers a change in the state of a network component (e.g., a link is down, a card fails, or a packet arrives).¶
Continuous Simulation:

In contrast to discrete event simulation, continuous simulation models systems where variables change continuously over time. Network parameters like bandwidth, congestion, and throughput can be treated as continuous functions.¶

The main use case is to model certain aspects of network performance that evolve continuously, such as link speeds or delay distributions in links that are impacted by envirnnmental conditions (such as microwave or satellite links).¶
Monte Carlo Simulation:

This type of simulation uses statistical methods to model and analyze networks under uncertain or variable conditions. Monte Carlo simulations generate a large number of random samples to predict the performance of a network across multiple scenarios. It is used for probabilistic analysis, risk assessment, and performance evaluation under uncertain conditions.¶

3.9.2. Goals of Network Simulation

The simulations can be also classified depending on the goal of the simulation.¶

3.9.2.1. Network Protocol Analysis

This type of simulation focuses on simulating specific networking protocols (IS-IS, OSPF, BGP, SR) to understand how they perform under different conditions. It models the protocol operations and interactions among devices in the network. For example, simulation can be used to asses the impact of changing a link metric. Morever, specific features of the networking protocol can be tested. For example, how fast-reroute performs in a given network topology.¶

3.9.2.2. Traffic Simulation

This simulation focuses on modelling traffic flow across the network, including packet generation, flow control, routing, and congestion. It aims to evaluate traffic's impact on network performance.¶

The main use is to model the impact of different types of traffic (e.g., voice, video, mobile data, web browsing) and understand how they affect the network's bandwidth and congestion levels. It can be used to identify bottelnecks and assist the capacity planning process.¶

3.9.2.3. Simulation of Different Topologies Under Normal and Failure Scenarios

This type of simulation focuses on the structure and layout of the network itself. It simulates different network topologies, such as mesh, horse-shoe, bus, star, or tree topologies, and their impact on the network's performance. It can be used, together with the traffic simualtion to evaluate the most efficient topology for a network, under normal conditions and considering factors like fault tolerance.¶

3.10. Traffic Engineering

Traffic Engineering (TE) [RFC9522] is a network optimization technique designed to enhance network performance and resource utilization by intelligently controlling the flow of data, for example by enabling dynamic path selection based on constraints such as bandwidth availability, latency, and link costs.¶

Its primary goal is to prevent network congestion, balance traffic loads, and ensure efficient use of bandwidth while meeting performance requirements.¶

The TE use case is a combination of the both the capacity planning and the simulation use case. Therefore there are no specific SIMAP requirements.¶

3.11. Postmortem Replay

The postmortem replay use case consists in using SIMAPs for the purpose of analysis of network service property evolution based on recorded changes. A collection of relevant timestamped network events, such as routing updates, configuration changes, link status modifications, traffic metrics evolution, and service characteristics, is being made accessible from and/or within a SIMAP to support investigation and automated processing. Using a structured format, the stored data can be replayed in sequence, allowing network operators to examine historical network behavior, diagnose issues, and assess the impact of such events on service assurance.¶

The mechanism supports correlation with external data sources to facilitate comprehensive post-mortem analysis. Further than centralizing and correlating such various sources of information, the SIMAP can provide simulation of the network behaviour to assist investigations.¶

In essence, this use case builds upon a collection of other SIMAP use cases, such as, inventory queries, intent/service assurance, Service KPIs, capacity planning, and simulation to provide a thorough understanding of a network event impacting service assurance.¶

Note that this use case may serve as a component of Service Disruption Detection fine tuning as described in [I-D.ietf-nmop-network-anomaly-architecture].¶

3.12. Closed Loop

A network closed loop refers to an automated and intelligent system where network operations are continuously monitored, analyzed, and optimized in real time through feedback mechanisms. This self-adjusting cycle ensures that the network dynamically adapts to changes, resolves issues proactively, and maintains optimal performance without manual intervention.¶

Key Characteristics of a Network Closed Loop:¶

Real-Time Monitoring: Collects data from network devices, traffic flows, and applications to build a comprehensive view of network health and performance.¶
Automated Analysis: Ideally leverages AI and machine learning to identify anomalies, predict potential failures, or detect security threats.¶
Proactive Action: Automatically triggers corrective measures, such as reconfiguring devices, isolating compromised endpoints, or rerouting traffic.¶
Continuous Optimization: Uses feedback from previous cycles to refine network policies and improve future responses.¶

The application will be able to retrieve topology layer and any network/node/termination point/link instances from the controller via the SIMAP API and from the response it will be able to map the traffic analysis to the entities (typically links and router), for automated analysis. The corrective measures would be applied, either directly to the network by managed the SIMAP entities (network/node/termination point/link instances) or by validating first the corrective measure in an offline simulation (see the simulation and traffic engineering use cases).¶

3.13. Network Digital Twin (NDT)

4. SIMAP Requirements

4.1. Core Requirements

The following are the core requirements for the SIMAP (note that some of them are supported by default by [RFC8345]):¶

REQ-BASIC-MODEL-SUPPORT:

Basic model with network, node, link, and termination point entity types.¶

This means that users of the SIMAP model must be able to understand topology model at any layer via these core concepts only, without having to go to the details of the specific augmentations to understand the topology.¶

REQ-LAYERED-MODEL:

Layered SIMAP, from physical network (ideally optical, layer 2, layer 3) up to service and intent views.¶

REQ-PASSIVE-TOPO:

SIMAP must support topology of the complete network, including active and passive parts.¶

REQ-PROG-OPEN-MODEL:

Open and programmable SIMAP.¶

This includes "read" operations to retrieve the view of the network, typically as application-facing interface of Software Defined Networking (SDN) controllers or orchestrators.¶

It also includes "write" operations, not for the ability to directly change the SIMAP data (e.g., changing the network or service parameters), but for offline simulations, also known as what-if scenarios.¶

Running a "what-if" analysis requires the ability to take snapshots and to switch easily between them.¶

Note that there is a need to distinguish between a change on the SIMAP for future simulation and a change that reflects the current reality of the network.¶

REQ-STD-API-BASED:

Standard based SIMAP Models and APIs, for multi-vendor support.¶

SIMAP must provide the standard YANG APIs that provide for read/write and queries. These APIs must also provide the capability to retrieve the links to external data/models.¶

REQ-COMMON-APP:

SIMAP models and APIs must be common over different network domains (campus, core, data center, etc.).¶

This means that clients of the SIMAP API must be able to understand the topology model of layers of any domain without having to understand the details of any technologies and domains.¶

REQ-SEMANTIC:

SIMAP must provide semantics for layered network topologies and for linking external models/data.¶

REQ-LAYER-NAVIGATE:

SIMAP must provide intra-layer and inter-layer relationships.¶

REQ-EXTENSIBLE:

SIMAP must be extensible with metadata.¶

REQ-PLUGG:

SIMAP must be pluggable. That is,¶

Must connect to other YANG modules for inventory, configuration, assurance, etc.¶
Given that no all involved components can be available using YANG, there is a need to connect SIMAP YANG model with other modelling mechanisms.¶

REQ-GRAPH-TRAVERSAL:

SIMAP must be optimized for graph traversal for paths. This means that only providing link nodes and source and sink relationships to termination-points may not be sufficient, we may need to have the direct relationship between the termination points or nodes.¶

REQ-BIDIR:

SIMAP must provide a mechanism to model bidirectional links One of the core characteristics of any network topology is the link directionality. While data flows are unidirectional, the bidirectional links are also common in networking. Examples are Ethernet cables, bidirectional SONET rings, socket connection to the server, etc. We also encounter requirements for simplified service layer topology, where we want to model link as bidirectional to be supported by unidirectional links at the lower layer.¶

REQ-MULTI-POINT:

SIMAP must provide a mechanism to model multipoint links One of the core characteristics of any network topology is its type and link cardinality. Any topology model should be able to model any topology type in a simple and explicit way, including point to multipoint, bus, ring, star, tree, mesh, hybrid and daisy chain. Any topology model should also be able to model any link cardinality in a simple and explicit way, including point to point, point to multipoint, multipoint to multipoint or hybrid.¶

REQ-MULTI-DOMAIN:

SIMAP must provide a mechanism to model links between the network/domains One of the core characteristics of any topology is connectivity between different network, subnetworks or domains.¶

REQ-SUBNETWORK:

SIMAP must provide a mechanism to model network decomposition into sub-networks. This would allow modelling hierarchical network domains, Autonomous System with multiple Areas or e2e network with multiple domains.¶

REQ-SHARED:

SIMAP must provide a mechanism to share nodes, links and termination points between different networks.¶

REQ-SUPPORTING:

SIMAP must provide a mechanism to model supporting relationships between different types of topological entities (e.g., tp is supported by the node). This may be required in the cases when tp is not supported by the underlying tp, but by the node (e.g., loopback does not have physical representation, so it is supported by physical device).¶

REQ-STATUS:

Links and nodes that are down must appear in the topology. The status of the nodes and links must be either implemented in the SIMAP model or accessible from the SIMAP model.¶

4.2. Design Requirements

The following are design requirements for modelling the SIMAP. They are derived from the core requirements collected from the operators and although there is some duplication, these are focused on summarizing the requirements for the design of the model and API:¶

REQ-TOPO-ONLY:

SIMAP should contain only topological information.¶

SIMAP is not required to contain all models and data required for all the management and use cases. However, it should be designed to support adequate pointers to other functional data and models to ease navigating in the overall system. For example:¶

ACLs and Route Policies are not required to be supported in the SIMAP, they would be linked to the SIMAP¶
Dynamic paths may either be outside of the SIMAP or part of traffic engineering data/models¶

REQ-PROPERTIES:

SIMAP entities should mainly contain properties used to identify topological entities at different layers, identify their roles, and topological relationships between them.¶

REQ-RELATIONSHIPS:

SIMAP should contain all topological relationships inside each layer or between the layers (underlay/overlay)¶

SIMAP should contain links to other models/data to enable generic navigation to other YANG models in generic way.¶

REQ-CONDITIONAL:

Provide capability for conditional retrieval of parts of SIMAP.¶

REQ-TEMPO-HISTO:

Must support geo-spatial, temporal, and historical data. The temporal and historical can also be supported external to the SIMAP.¶

4.3. Architectural Requirements

The following are the architectural requirements for the controller that provides SIMAP API:¶

REQ-DM-SCALES:: Scale, performance, ease of integration.¶
REQ-DM-DISCOVERY:: Initial discovery and dynamic (change only) synch with the physical network.¶

7. References

7.1. Normative References

[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, <https://www.rfc-editor.org/rfc/rfc8345>.

7.2. Informative References

[I-D.ietf-ccamp-network-inventory-yang]: Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A YANG Data Model for Network Hardware Inventory", Work in Progress, Internet-Draft, draft-ietf-ccamp-network-inventory-yang-02, 9 July 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-network-inventory-yang-02>.
[I-D.ietf-ivy-network-inventory-topology]: Wu, B., Boucadair, M., Zhou, C., and Q. Wu, "A Network Data Model for Inventory Topology Mapping", Work in Progress, Internet-Draft, draft-ietf-ivy-network-inventory-topology-01, 4 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-topology-01>.
[I-D.ietf-ivy-network-inventory-yang]: Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A Base YANG Data Model for Network Inventory", Work in Progress, Internet-Draft, draft-ietf-ivy-network-inventory-yang-04, 5 November 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-04>.
[I-D.ietf-nmop-network-anomaly-architecture]: Graf, T., Du, W., and P. Francois, "An Architecture for a Network Anomaly Detection Framework", Work in Progress, Internet-Draft, draft-ietf-nmop-network-anomaly-architecture-01, 20 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-anomaly-architecture-01>.
[I-D.ietf-nmop-network-incident-yang]: Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network-incident-yang-02, 10 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-incident-yang-02>.
[I-D.ietf-nmop-terminology]: Davis, N., Farrel, A., Graf, T., Wu, Q., and C. Yu, "Some Key Terms for Network Fault and Problem Management", Work in Progress, Internet-Draft, draft-ietf-nmop-terminology-10, 21 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-terminology-10>.
[I-D.ietf-opsawg-ntw-attachment-circuit]: Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "A Network YANG Data Model for Attachment Circuits", Work in Progress, Internet-Draft, draft-ietf-opsawg-ntw-attachment-circuit-16, 23 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ntw-attachment-circuit-16>.
[I-D.ietf-opsawg-teas-attachment-circuit]: Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)", Work in Progress, Internet-Draft, draft-ietf-opsawg-teas-attachment-circuit-20, 23 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-20>.
[I-D.ogondio-nmop-isis-topology]: de Dios, O. G., Barguil, S., Lopez, V., Ceccarelli, D., and B. Claise, "A YANG Data Model for Intermediate System to intermediate System (IS-IS) Topology", Work in Progress, Internet-Draft, draft-ogondio-nmop-isis-topology-00, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-ogondio-nmop-isis-topology-00>.
[I-D.ogondio-opsawg-ospf-topology]: de Dios, O. G., Barguil, S., and V. Lopez, "A YANG Data Model for Open Shortest Path First (OSPF) Topology", Work in Progress, Internet-Draft, draft-ogondio-opsawg-ospf-topology-01, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-ogondio-opsawg-ospf-topology-01>.
[I-D.wzwb-opsawg-network-inventory-management]: Wu, B., Zhou, C., Wu, Q., and M. Boucadair, "A YANG Network Data Model of Network Inventory", Work in Progress, Internet-Draft, draft-wzwb-opsawg-network-inventory-management-04, 19 October 2023, <https://datatracker.ietf.org/doc/html/draft-wzwb-opsawg-network-inventory-management-04>.
[RFC5136]: Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, <https://www.rfc-editor.org/rfc/rfc5136>.
[RFC7011]: Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/rfc/rfc7011>.
[RFC8299]: Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/rfc/rfc8299>.
[RFC8466]: Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/rfc/rfc8466>.
[RFC8795]: Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, <https://www.rfc-editor.org/rfc/rfc8795>.
[RFC8944]: Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A YANG Data Model for Layer 2 Network Topologies", RFC 8944, DOI 10.17487/RFC8944, November 2020, <https://www.rfc-editor.org/rfc/rfc8944>.
[RFC9179]: Hopps, C., "A YANG Grouping for Geographic Locations", RFC 9179, DOI 10.17487/RFC9179, February 2022, <https://www.rfc-editor.org/rfc/rfc9179>.
[RFC9182]: Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, February 2022, <https://www.rfc-editor.org/rfc/rfc9182>.
[RFC9291]: Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, "A YANG Network Data Model for Layer 2 VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022, <https://www.rfc-editor.org/rfc/rfc9291>.
[RFC9408]: Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Data Model for Service Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, June 2023, <https://www.rfc-editor.org/rfc/rfc9408>.
[RFC9417]: Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Arumugam, "Service Assurance for Intent-Based Networking Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023, <https://www.rfc-editor.org/rfc/rfc9417>.
[RFC9418]: Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T. Arumugam, "A YANG Data Model for Service Assurance", RFC 9418, DOI 10.17487/RFC9418, July 2023, <https://www.rfc-editor.org/rfc/rfc9418>.
[RFC9522]: Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, January 2024, <https://www.rfc-editor.org/rfc/rfc9522>.