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

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])¶

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.¶

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 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.¶

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].¶

The NMRG I-D 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, The NMRG I-D 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, 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, with query capabilities and links to other YANG modules (e.g., SAIN [I-D.ietf-opsawg-service-assurance-architecture], 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 provides a device view, some provides a network or subnetwork view, while others focus more on the customer service perspective. are needed for both inner and outer closed-loops. It is debatablAll these viewse 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): 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¶
• 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.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 RFC9345 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¶

6.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¶
• Supporting relationships between different types of entities¶
• More Network topology related semantic is needed¶

6.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.¶

6.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 ¶

6.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
                                 supporting-tunnel-termination-point
                                 (te draft)
                augment /nw:networks/nw:network/nt:link:
                                .... adding tunnels (te draft)
                augment /nw:networks/nw:network/nw:node/
                                              nt:termination-point:
                                ....

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 ¶

6.5. How to connect to the external world

How to connect to other YANG modules¶

How to connect YANG models with other modelling mechanisms¶

6.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¶

6.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.1. Network Topology

Interestingly, we could not find any Network Topology definition in IETF RFCs (not even in [RFC8345]) or drafts. However, it's mentioned in multiple documents. As an example, in Overview and Principles of Internet Traffic Engineering [I-D.ietf-teas-rfc3272bis], which mentioned:¶

To conduct performance studies and to support planning of existing and future networks, a routing analysis may be performed to determine the paths the routing protocols will choose for various traffic demands, and to ascertain the utilization of network resources as traffic is routed through the network. Routing analysis captures the selection of paths through the network, the assignment of traffic across multiple feasible routes, and the multiplexing of IP traffic over traffic trunks (if such constructs exist) and over the underlying network infrastructure. A model of network topology is necessary to perform routing analysis. A network topology model may be extracted from:¶

• * network architecture documents¶
• * network designs¶
• * information contained in router configuration files¶
• * routing databases such as the link state database of an interior gateway protocol (IGP)¶
• * routing tables¶
• * automated tools that discover and collate network topology information.¶

Topology information may also be derived from servers that monitor network state, and from servers that perform provisioning functions.¶

7.2. Core Digital Map Components

The following standards are core for the Digital Map.¶

• IETF Network Model and Network Topology Model [RFC8345]¶
• A YANG Grouping for Geographic Location [RFC9179]¶
• IETF Modules that augment [RFC8345] for different technologies:¶
• - A YANG Data Model for Traffic Engineering (TE) Topologies [RFC8795]¶
• - A YANG Data Model for Layer 2 Network Topologies [RFC8944]¶
• - A YANG Data Model for OSFP Topology [I-D.ogondio-opsawg-ospf-topology]¶
• - A YANG Data Model for IS-IS Topology [I-D.ogondio-lsr-isis-topology]¶

7.3. Additional Digital Map Components

The Digital Map may need to link to the following models, some are already augmenting [RFC8345], we need further investigation for each of these items:¶

• Service Access Point (SAP) [RFC9408], augments 'ietf-network' data model [RFC8345] by adding the SAP.¶
• SAIN [I-D.ietf-opsawg-service-assurance-architecture] and [I-D.ietf-opsawg-service-assurance-yang]¶
• An Inventory Management Model for Enterprise Networks [I-D.wzwb-opsawg-network-inventory-management] augments 'ietf-network-topology' with inventory information for node, link and termination-point. It also has UUIDs.¶
• A YANG Data Model for Network Hardware Inventory [I-D.ietf-ccamp-network-inventory-yang] augments network-topology' to provide a generic YANG data model for network hardware inventory data information which can be augmented with technology-specific (e.g., optical) inventory data.¶
• Data Model for Lifecycle Management and Operations [I-D.palmero-opsawg-dmlmo]¶
• KPIs: delay, jitter, loss¶
• Attachment Circuits (ACs) [I-D.boro-opsawg-ntw-attachment-circuit] and [I-D.boro-opsawg-teas-attachment-circuit]¶
• Configuration: L2SM [RFC8466], L3SM [RFC8049], L2NM [RFC9291], L3NM [RFC9182]¶
• Incident Management for Network Services [I-D.feng-opsawg-incident-management]¶

7.4. Network Inventory (IVY) Proposed Working

The charter of the Network Inventory (IVY) IETF Working Group (WG) can be found at https://datatracker.ietf.org/doc/charter-ietf-ivy/. Understanding how the two efforts complement each other is important.¶

The IVY effort focuses on the network inventory (as the charter says, "including a variety of information such as product name, vendor, product series, embedded software, and hardware/software versions"). The network inventory is probably the first use cases for the Digital Map. Therefore, it is important to have a consistent view of what a network node is. While a Digital Map must include a pointer to the hardware and software inventory information, we don't consider that all the inventory information is actually part of the Digital Map. It must also be noted that the set of use cases for the Digital Map is wider than just the network inventory.¶

The IVY charter also says that, "The Working Group will consider existing IETF work, including RFC 8348 and RFC 8345.". In this document, RFC 8345 is considered as the base YANG module, therefore, there is clearly common ground with the work of the ivy working group. This document goes beyond RFC 8345 to evaluate whether that RFC, along with all the augmented YANG modules, would be a good fit for all the Digital Map requirements.¶

Additionally, the IVY charter says, "The WG will also identify a set of requirements and guidelines to ensure consistency across models related to inventory." While the IVY requirements and guidelines focus on inventory, this document looks at the full set of requirements, guidelines, and building blocks for all the Digital Map use cases. The inventory use case does not cover that full set, and other building blocks will be required: for example, to support point-to-multipoint connectivity¶

Thus, this Digital Map modelling effort is complementary to the inventory work in IVY. It has a broader outlook covering all Digital Map use case requirements, and will correlate with the existing IETF models, e.g., topology, service attachment points (SAP), etc.¶