Internet-Draft Digital Map Modelling October 2023
Havel, et al. Expires 22 April 2024 [Page]
Intended Status:
Standards Track
O. Havel
B. Claise
O. Gonzalez. de Dios
A. Elhassany
T. Graf
M. Boucadair

Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives


This document shares experience in modelling digital map based on the IETF RFC 8345 topology YANG modules and some of its augmentations. First, the concept of Digital Map is defined and its connection to the Digital Twin is explained. Next to Digital Map requirements and use cases, the document identifies a set of open issues encountered during the modelling phases, the missing features in RFC 8345, and some perspectives on how to address them.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

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

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 22 April 2024.

1. Introduction

[RFC8345] specifies a topology YANG model with many YANG augmentations for different technologies and service types. The modelling approach based upon [RFC8345] provides a standard IETF based API.

At the time of writing (2023), there are at least 59 YANG modules that are augmenting [RFC8345]; 58 IETF-authored modules and 1 BBF-authored module. 9 of these modules have maturity level of 'ratified', 22 of them have maturity level of 'adopted', 11 modules have maturity level of 'latest-approved', and 17 of these modules have maturity level of 'initial'. The up-to-date information can be found in the YANG Catalog available at [Catalog].

From this set of IETF RFCs and IETF I-Ds (at different level of maturity), we designed a Digital Map Proof of concept (PoC), with the following objectives and functionalities:

  • Can the central RFC 8345 YANG module be a good basis to model a Digital Map?
  • How the different topology related IETF YANG modules fit (or not) together?
  • Modelling of digital map entities, relationships, and rules how to build aggregated entities and relationships. Does the base model support key requirements that emerge for a specific layer?
  • Modelling multiple underlay/overlay layers from Layer 2 to Layer 3 to customer service layer. To what extent it is easy to augment the base model to support new technologies?
  • Can the base model be augmented for any new layer and technologies?

This I-D documents an experience in the modeling aspects of the Digital Map, based on a PoC implementation, basically documenting the effort and the open issues encountered so far. During the PoC, we also identified a set of requirements and verified the PoC approach by demoing it iteratively.

Practically, we developed a PoC with a real lab, based on multi-vendor devices, with [RFC8345] as the base YANG module. The PoC successfully modelled the following technologies:

- Layer 2 Network Topology (used [RFC8944])

- Layer 3 Network Topology (used [RFC8346])

- OSPF routing (aligned with [I-D.ogondio-opsawg-ospf-topology])

- IS-IS routing (aligned with [I-D.ogondio-opsawg-isis-topology])

- BGP routing


- MPLS TE Tunnels

- SRv6 Tunnels

- L3VPN service

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Update capitalized versus not capitalized throughout the document. In other drafts capitalized is used for terminology and definitions, but we may decide to have it unified.

Digital Twin -
Virtual instance of a physical system (twin) that is continually updated with the latter's performance, maintenance and health status data throughout the physical system's life cycle (as defined in Section 2.2 of [I-D.irtf-nmrg-network-digital-twin-arch])
Topology -
Network topology defines how physical or logical nodes, links and interfaces are related and arranges. Service topology defines how service components (e.g., VPN instances, customer interfaces, and customer links) between customer sites are interrelated and arranged. There are at least 8 types of topologies: point to point, bus, ring, star, tree, mesh, hybrid and daisy chain. Topologies may be unidirectional or bidirectional (bus, some rings).
Topology Layer -
Defines a layer in the multilayer topology. A multilayer topology models relationships between different layers of connectivity, where each layer represents a connectivity aspect of the network and service that needs to be configured, controlled and monitored. The layer can also represent what needs to be managed by a specific user, for example IGP layer can be of interest to the user troubleshooting 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, L2 for link topology and L3 for IPv4 and IPv6 Topologies. Some topology layers represent the control aspects of L3, like OSPF, IS-IS and BGP. The top layer represents the service view of the connectivity, that can differ for different types of services and for different providers/solutions.
Digital Map -
Basis for the Digital Twin that provides a virtual instance of the topological information of the network. It provides the core multi-layer topology model and data for the digital twin and connects them to the other digital twin models and data.
Digital Map Modelling -
The set of principles, guidelines, and conventions to model the Digital Map using the IETF [RFC8345] approach. They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties and relationship types between entities.
Digital Map Model -
Defines the core topological entities, their role in the network, core properties and relationships both inside each layer and between the layers. It is the basic topological model that is linked to other functional parts of the digital twin and connects them all: configuration, maintenance, assurance (KPIs, status, health, symptoms), traffic engineering, different behaviors, simulation, emulation, mathematical abstractions, AI algorithms, etc
Digital Map 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 data can be historical, real-time or future data for what-if scenarios.

2. Digital Map and Digital Twin Relationship

2.1. Digital Twin

The network digital twin (referred to simply as digital twin) concepts and a reference architecture are proposed in the "Digital Twin Network: Concepts and Reference Architecture" NMRG I-D [I-D.irtf-nmrg-network-digital-twin-arch].

This document defines the core elements of digital twin - Data, Models, Interfaces, and Mapping. The digital twin constructed based on the four core technology elements is intended to analyze, diagnose, emulate, and control the physical network in its whole lifecycle with the help of optimization algorithms, management methods, and expert knowledge.

Also, this document states that a digital twin can be seen as an indispensable part of the overall network system and provides a general architecture involving the whole lifecycle of physical networks in the future, serving the application of innovative network technologies (e.g., network planning, construction, maintenance and optimization, improving the automation and intelligence level of the network).

2.2. Digital Map

Digital Map provides the core multi-layer topology model and data for the digital twin and connects them to the other digital twin models and data.

The Digital Map Modelling defines the core topological entities (network, node, link and interface), their role in the network, core properties, and relationships both inside each layer and between the layers.

The Digital Map Model is a basic topological model that is linked to other functional parts of the digital twin and connects them all: configuration, maintenance, assurance (KPIs, status, health, symptoms), Traffic Engineering (TE), different behaviors and actions, simulation, emulation, mathematical abstractions, AI algorithms, etc.

The Digital Map Data consists of virtual instances of network and service topologies at different layers. The Digital Map provides the access to this data via standard APIs for both read and write operations (write operations for offline simulations), with query capabilities and links to other YANG modules (e.g., SAIN [RFC9417], SAP [RFC9408], Inventory [I-D.wzwb-opsawg-network-inventory-management], and Assets [I-D.palmero-opsawg-dmlmo]) and non-YANG models.

2.3. Digital Map as a Prerequisite for Digital Twin

One of the important requirements for the digitalization and Digital Twin is to ease correlating all models and data to topological entities at different layers in the layered twin network. The Digital Map aims to provide a virtual instance of the topological information of the network, based on this Digital Map Model. Building a Digital Map is prerequisite towards the Digital Twin.

The Digital Map Model/Data will provide this missing correlation between the topology models/data and all other models/data: KPIs, alarms, incidents, inventory (with UUIDs), configuration, traffic engineering, planning, simulation ("what if"), emulations, actions, and behaviors.

Some of these models/data provide a device view, some provide a network or subnetwork view, while others focus more on the customer service perspective. All these views are needed for both inner and outer closed-loops. It is debatable what is part of the Digital Map itself versus what are pointers from the Digital Map to some other sources of information. As an example, the Digital Map should not specifically include all information about the device inventory (product name, vendor, product series, embedded software, and hardware/software versions, as specified in Network Inventory (IVY) WG, ): a pointer from the Digital Map to another inventory system might be sufficient. Similarly, the Digital Map should not specifically contain incidents, configuration, data plane monitoring, or even assurance information, simply to name a few.

The following are some Digital Twin use cases that require Digital Map:

  • Generic Inventory Queries
  • Service placement feasibility checks
  • Service-> subservice -> resource
  • Resource -> subservice -> service
  • Intent/Service Assurance
  • Service E2E and Per-Link KPIs on the Digital Map (delay, jitter, and loss)
  • Capacity planning
  • Network Design
  • Simulation
  • Closed Loop

Overall, the Digital Map is needed to break down data islands and have a digital twin for emulation and closed loop, which is a catalyst for autonomous networking.

3. The IETF Network Topology Approaches

3.1. IETF Network Topology

[RFC8345] provides a simple generic topological model. It defines the abstract /generic /base model for network and service topologies. It provides the mechanism to model networks and services as layered topologies with common relationships at the same layer and underlay/overlay relationships between the layers.

[RFC8345] consists of two modules: 'ietf-network' and 'ietf-network-topology'. The 'ietf-network' module defines networks and nodes, while 'ietf-network-topology' module adds definitions for links and termination points.

The relationships inside the layer are containment/aggregation (a network contains nodes, a network contains/has links, a node contains termination points), source (a link has one source termination point) and destination (a link has one destination termination point)

The relationships between the layer modelled via supporting relationship

  • network A is supported by network B - this may model overlay/underlay relationship
  • nodes, links and termination points of network A are supported by nodes, links and termination points of network B. Overlay and underlay nodes, links and termination points must match underlay and overlay networks supporting it

3.2. IETF Network Topology TE

[RFC8795] defines a YANG model for representing, retrieving and manipulating TE topologies. This is a more complex model which augments [RFC8345] with traffic engineering topology information as follows:

  • TE topology, node, link and termination point are defined using the core RFC8345 concepts

    • TE topology augments network with topology identifier (provider, client and topology id), as well as other 'te' information
    • TE node augments node with 'te-node-id' and other 'te' information
    • TE link augments link with te information
    • TE termination point augments termination point with 'te-tp-id' and te information
  • Tunnel, tunnel termination point, local link connectivity, node connectivity matrix, and some supporting and underlay relationships are defined outside of the core RFC 8345 entities and relationships

4. Digital Map Requirements

We discussed if requirements should be in a separate document. We will leave them in this document for now, later we can create a separate draft.

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

  1. Basic model with Network, Node, Link, Interface entity types
  2. Layered Digital Map, from physical network (ideally optical, layer 2, layer 3) up to customer service and intent
  3. Open and Programmable Digital Map. This includes "Read" to understand the view of the network. It also includes "Write", not for the ability to directly change the Digital Map Data (ex: changing the network or service parameters), but for offline simulations, also known as what-if scenarios. Doing what-if analysis requires the ability to take snapshots and to switch easily between them. Because we have to distinguish between a change on the digital map for future simulation and a change that reflects the current reality of the network.
  4. Standard based Digital Map Models and APIs, for multi-vendor support. Digital Map must provide the standard APIs that provide for Read / Write and queries. This API must also provide the capability to retrieve the links to external data / models.
  5. Digital Map Models and APIs must be common over different network domains (campus, core, data center, etc.)
  6. Digital Map must provide semantics for layered network topologies and for linking external models/data
  7. Digital Map must provide inter-layer and between layer relationships
  8. Digital Map must be extensible with meta data
  9. Digital Map must be pluggable a) We must connect to other YANG modules for inventory, configuration, assurance, etc b) Not everything can be in YANG, we need to connect Digital Map YANG model with other modelling mechanisms, both southbound, northbound and internally
  10. Digital Map 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

4.1. Why RFC8345 is a Good Approach for Digital Map Modelling

The main reason for selecting RFC8345 for modelling is its simplicity and that is supports majority of the core requirements. The requirements [1-7] are automatically fulfilled with RFC8345 and extensions:

  • basic model with network, node, link and interface entity types
  • layered topology
  • open and programmable
  • standard, multi-vendor
  • multi-domain
  • semantics for layered topology
  • inter-layer and between-layer relationships

The requirements [6-7] for semantics for layered topology and relationships are partially fulfilled, there may be need for some additional semantics. Other core requirements [8-10] are not supported by RFC8345:

  • extensible with meta data
  • pluggable to other YANG modules and non-YANG data
  • optimized for graph traversal

In some cases, for [9] for pluggable to other YANG modules, the links are already done by augmenting 'ietf-network' and 'ietf-network-topology'. For others, we need to add some mechanisms to link the models and data.

4.2. Design Requirements

The following are design requirements for modelling the Digital Map:

  1. Digital Map should contain only topological information. Digital Map should not contain all data required for all the management and use cases, but should have pointers to other functional Digital Twin data and models.
  2. Digital Map entities should contain only properties used to identify topological entities at different layers, identify their roles and topological relationships between them
  3. Digital Map should contain only topological relationships inside each layer or between the layers (underlay/overlay)
  4. ACLs and Route Policies will be outside of the digital map, they would be linked to digital map
  5. Dynamic paths may either be outside of the digital map, part of traffic engineering data/models
  6. Provide capability for conditional retrieval of parts of digital map
  7. Must support geo-spatial, temporal, and historical data. The temporal and historical can be supported external to the digital map.

The following are the architectural requirements for the Digital Map:

  1. Scale, performance, integration
  2. Initial discovery and dynamic (change only) synch

5. Digital Map Modelling Experience

5.1. What is not in the basic model

The following are the [RFC8345] extensions needed for Digital Map modelling and APIs:

  • Bidirectional links
  • Multi-point connectivity
  • Links between domains/networks
  • A network can be decomposed of sub-networks
  • Nodes, links, and termination points belong to different networks
  • Supporting relationships between different types of entities
  • More network topology related semantic is needed

5.1.2. Multipoint Connectivity

The RFC8345 defines all links as point to point and unidirectional, it does not support multi-point links (hub and spoke, full mesh, complex). It was done intentionally to keep the model as simple as possible. The RFC suggests to model the multi-point networks via pseudo nodes.

Same as with unidirectionality, while simplifying the model itself, we are making data and APIs more complex for multi point topologies and we are increasing the amount of data transferred via API, stored in the database or managed/monitored.

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.

By forcing the implementation of all topology types and all options for cardinality via unidirectional links and pseudo nodes, we are significantly increasing the complexity of APIs and data, but also lacking full topology semantics in the model. The model cannot be fully used to validate if topology instances are valid or not.

Note that, next to layer 2 mentioned above, the point to multipoint network type is also required in some cases at the OSPF layer.

[I-D.davis-opsawg-some-refinements-to-rfc8345] further elaborates on the need for multipoint connectivity in network topologies and in the digital map, in general. It also proposes how RFC8345 can be augmented to support these missing components.

5.1.4. Networks part of other networks

RFC8345 does not model networks being part of other networks, therefore cannot model subnetworks and network partitioning. We encountered this problem with modelling IS-IS and OSPF Domains and Areas. The initial goal was to model AS/Domain with multiple areas so that the digital map model contains information about how the AS is first split into different IGP domains and how each IGP domain is split into different areas. This is a common problem for both IS-IS and OSPF.

The following are some options how to address this problem:

  • Don't model AS and IS-IS/OSPF Domain directly, they would be modelled via the underlying IP network and IS-IS/OSPF enabled routers. This could be achieved via supporting relationship to L3 network and L3 nodes
  • Model AS, IGP domains and Areas as networks. We use supporting relationship to model the network topology design, with only areas having nodes. This does not describe the correct nature of the relationship, semantic is missing.
  • Extend RFC8345 to support additional relationship between networks.

RFC8345 does not allow nodes and TPs to belong to multiple areas without splitting them into separate entities with separate keys. In OSPF case we have nodes that can belong to different areas, but interfaces can only belong to one area. In the case of IS-IS, although all tutorial are stating that nodes can belong to one area only, the ietf, openconfig and vendor yang models and cli allow IS-IS processes with all its interfaces to belong to multiple areas. We can see the two options here:

  • Use the current RFC8345 approach, this is not the problem for read but may be an issue for write for simulation as we would expect that the interface lists in different nodes and networks be the same without being able to validate.
  • Change the approach of RFC8345 to optionally allow nodes to be defined outside of network tree and enable reference as an alternative to the containment in the tree. This may be a bigger change to the network topology approach as it would have bigger impact on the topology tree.

5.1.6. Missing Supporting Relationships

RFC8345 defines supporting relationships only between the same type of entities. Networks can only be supported by networks, nodes can only be supported by nodes, termination points can only be supported by terminations points and links can only be supported by links.

During the PoC, we encountered the need to have TP supported by node and node supported by Network. The RFC8795 also adds additional underlay relationship between node and topology and link and topology, but via a new underlay topology and not via the core supporting relationship.

5.1.7. Missing Topology Semantics

We already mentioned that some semantic is missing from the RFC8345 topology model, like bidirectional and multi-point. The following is also missing from the model:

  • Relationship Properties. The supporting relationship could have additional attributes that give more information about the supporting relationship. That way we could use it for aggregation, underlay with primary/backup, load balancing, hop, sequence, etc.
  • Termination point roles. We are missing semantics for the common topology roles: primary, backup, hub, spoke
  • Layers / Sublayers. We need further analysis to determine in network types are sufficient to support all scenarios for layers/sublayers. The network types are more related to technologies so in the case that the same technology is used at different layers, we may need some additional information in the model. For further study.
  • Tunnels and Paths. We modelled Tunnels ad Paths via [RFC8345] but we lost some semantics that is in RFC8795.
  • Supporting or underlay. We modelled all underlay relationships via supporting, further analysis is needed to determine pros and cons of this approach versus RFC8795 approach of using underlay topology.

5.2. Open Issues for Further Analysis

The following are the open issues that need further analysis:

  • Do we need separation of L2 and L3 topologies?

    During the PoC we encountered different solutions with separate set of requirements. In one solution, the L2 and L3 topology were the same with separate set of attributes, while in another solution we had difference in L2 and L3 topology (e.g. Links Aggregation, Switches and Routers).

    The RFC8944 defines L2 topology and RFC8346 defines the L3 topology. They allow to have either one or two instances of this topology.

    The decision if we need separate network instances for L2 and L3 topologies may be based on specific network topology and provider's preferences.

  • Do we need sublayers as well? Layers versus sublayers versus layered instances? Further analysis is needed.
  • Same technology at service versus underlay? BGP per VPN vs common BGP shared between multiple VPNs. Different layers, same model, relationship define the layer.

5.3. How to Augment for Generic Digital Map Extensions

Generic Digital Map extensions are the RFC8345 extensions required for all technologies and layers in the Digital Map. We have the following options:

  1. make backward compatible updates to RFC8345, either via changing or augmenting the network, node, link and termination point in the RFC8345
  2. augment RFC8345 network, node, link and termination point for any changes needed from a new digital map module

    module: dm-network-topology
            augment /nw:networks/nw:network:
                    .... additions
            augment /nw:networks/nw:network/nw:node:
                    .... additions
            augment /nw:networks/nw:network/nt:link:
                    .... additions
            augment /nw:networks/nw:network/nw:node/nt:termination-point:
                    .... additions

This will be a separate draft with describing pros and cons of different approaches and yang model proposal. Add reference to this draft when submitted

5.4. How to Augment for New Technologies/Layers

There are already drafts that support augmentation for specific technologies. These drafts augment network, node, termination point and link, but also add different topological entities inside augmentations. For example, we have examples like this:

module: new-module
        augment /nw:networks/nw:network/nw:network-types:
      +--rw new-topology!
                augment /nw:networks/nw:network:
                augment /nw:networks/nw:network/nw:node:
                        .... adding list of tps of other type
                                 (e.g. tunnel TPs in te draft)
                        ... adding new supporting relationship
                                 (te draft)
                augment /nw:networks/nw:network/nt:link:
                                .... adding tunnels (te draft)
                augment /nw:networks/nw:network/nw:node/

There is need to agree some guidelines for augmenting IETF network topology, so that additional topological information is not added in the custom way. This may either involve

  • adding concepts from TE and SAP topological augmentations to the core digital map topology in the similar way they were added in the corresponding drafts or
  • using the TP to model SAP and 'link' to model tunnel in the core Digital Map

This can be a separate draft. Guidelines with examples? Add reference to this draft when submitted

5.5. How to connect to the external world

How to connect to other YANG modules

How to connect YANG models with other modelling mechanisms

5.6. Digital Map APIs

This will include hierarchical APIs for cross-domain figure, IETF YANG Based API (read and write, change subscription and notify) and Query API

5.7. Digital Map Knowledge

The following knowledge was needed to build digital map:

  • Abstract IETF Entities and Relationships as in [RFC8345]
  • [RFC8345] Augmentations for a)Layers/sublayers b)Entities (services and subservices), c)Properties
  • Rules for aggregating entities
  • Rules for instantiating relationships (inter-layer and intra-layer)
  • Mapping from devices and controllers

What can be achieved with existing RFC8345 YANG:

  • Entities (base class IETF Network, IETF Node, IETF Link, IETF TP)
  • Properties
  • Relationships

Next steps

  • How to support temporal
  • How to support spacial
  • How to support historical

7. Conclusions

Digital Map Modelling and Data are basis for the Digital Twin. During our PoC we have proven that Digital Map can be modelled using [RFC8345]. Nevertheless, we proposed some extensions/augmentations to [RFC8345] to support Digital Maps. There must be some constraints in regards to how to augment the core Digital Map model for different Layers and Technologies in order to support the approach in our PoC. All entities must augment IETF node, IETF network, IETF link or IETF Termination Point and augmentation can only include new properties.

8. Security Considerations

The digital map exposes a lot of key details about the network that may be confidential and might be valuable to an attacker.

Future revisions will add more details of what information needs to be protected and how it may be protected

9. IANA Considerations

This document has no actions for IANA.

10. References

10.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
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, , <>.
Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, , <>.
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, , <>.

10.2. Informative References

"", <>.
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-boro-opsawg-ntw-attachment-circuit-03, , <>.
Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS)", Work in Progress, Internet-Draft, draft-boro-opsawg-teas-attachment-circuit-07, , <>.
Davis, N., Havel, O., and B. Claise, "Some Refinements to RFC8345 (Network Topologies)", Work in Progress, Internet-Draft, draft-davis-opsawg-some-refinements-to-rfc8345-00, , <>.
Feng, C., Hu, T., Contreras, L. M., Graf, T., Wu, Q., Yu, C., and N. Davis, "Incident Management for Network Services", Work in Progress, Internet-Draft, draft-feng-opsawg-incident-management-02, , <>.
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, , <>.
Farrel, A., "Overview and Principles of Internet Traffic Engineering", Work in Progress, Internet-Draft, draft-ietf-teas-rfc3272bis-27, , <>.
Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu, Q., Boucadair, M., and C. Jacquenet, "Digital Twin Network: Concepts and Reference Architecture", Work in Progress, Internet-Draft, draft-irtf-nmrg-network-digital-twin-arch-04, , <>.
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-opsawg-isis-topology-00, , <>.
de Dios, O. G., Barguil, S., and V. Lopez, "A YANG Data Model for Open Source Path First (OSPF) Topology", Work in Progress, Internet-Draft, draft-ogondio-opsawg-ospf-topology-00, , <>.
Palmero, M., Brockners, F., Kumar, S., Bhandari, S., Cardona, C., and D. Lopez, "Data Model for Lifecycle Management and Operations", Work in Progress, Internet-Draft, draft-palmero-opsawg-dmlmo-10, , <>.
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, , <>.
Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, , <>.
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, , <>.
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, , <>.
Hopps, C., "A YANG Grouping for Geographic Locations", RFC 9179, DOI 10.17487/RFC9179, , <>.
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, , <>.
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, , <>.
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, , <>.
Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Arumugam, "Service Assurance for Intent-Based Networking Architecture", RFC 9417, DOI 10.17487/RFC9417, , <>.
Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T. Arumugam, "A YANG Data Model for Service Assurance", RFC 9418, DOI 10.17487/RFC9418, , <>.


The following people all contributed to creating this document:


Thanks to xx for their reviews and comments.

Authors' Addresses

Olga Havel
Townsend Street, George's Court
Benoit Claise
Oscar Gonzalez de Dios
Binzring 17
CH-8045 Zurich
Thomas Graf
Binzring 17
CH-8045 Zurich
Mohamed Boucadair
35000 Rennes