Back from a successful IETF 117 in San Francisco, where the (hallway) discussions were as interesting and intense as the pre-COVID meetings.
Let me share some news regarding the Digital Map Modelling, a new emerging topic.
The IETF started some YANG modeling work around the network topology some time ago, with the publication of a couple of fundamental IETF RFCs:
[RFC8345] specifies a topology YANG model with many YANG augmentations for different technologies and service types: [RFC8346] and [RFC8944] are augmentations for layer 3 and layer 2 network topologies, respectively. The modelling approach based upon [RFC8345] provides a standard IETF based API. Looking at the full series of produced RFCs, we might be considering that the YANG topology-related work is well under way, if not already complete.
However, there are still many augmentations to the basic YANG modules … for the different technologies, layers, and services. So certainly this work is “in progress”.
Back to the Digital Map topic, let’s first differentiate the different terms: Topology, Digital Map, and Digital Twin.
From a high level point of view: the Digital Twin is the full replica of the network for what-if scenarios. To realise this vision, we need a Digital Map, which is based on the network topology. The Digital Map is needed to correlate all models and data in the Digital Twin. Without the Digital Map, all the models and data for topology, assurance, Key Performance Indicator (KPI), alarms, incidents, configuration, planning, traffic engineering are disconnected: it is the barrier for the closed loop.
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.
Digital Map provides the core multi-layer topology model of the digital twin that defines:
- the core topological entities
- their role in the network
- core properties and relationships both inside each layer and between the layers.
- relationships between the entities, both inside each layer and between the layers.
The Digital Map 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.
For those definitions (and the potential evolution of those), keep an eye on the following two drafts: Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives and Digital Twin Network: Concepts and Reference Architecture.
This IETF 117 meeting hold a Digital Map Modelling side meeting, where two operators expressed the use cases.
First Thomas Graf from Swisscom explained the “Swisscom Network Analytics: why Network Modelling with the Digital Map is the next step”. After mentioning that “network engineers are unable to understand all the end-to-end dependencies on all the layers in highly virtualized networks”, he mentioned some of the current Digital Map & analytics limitations and provided an example of Swisscom analytics system. Thomas concluded his talk with this quote:
As a second speaker, Oscar Gonzalez de Dios from Telefonica shared his “Experiences in Modelling Transport Network at Telefonica”. Similarly to Thomas (who targets the anomaly detection and simulation network configuration changes use cases,) Oscar focuses his digital map work on the failure analysis and what-if analysis. However, On top of those, Oscar’s use cases also cover network design and capacity planning. Finally, Oscar explained the digital map layered view.
In his talk, Oscar stressed that:
- It’s all about linking information, in this case, a service to a digital map. As an example, the network element (ne-id) in the L3NM YANG model was a string and not a leaf-ref (it should have really be leaf-ref btw).
- In order to build this digital map, we have to make some assumptions, for example in terms of layer 2 and layer 3. As an example, in his draft, Oscar and his co-authors specify how to model the IS-IS layer.
Without counting, I believe we were about 50 or 60 in the rooms, plus some online. We finished the last 30 seconds of the meeting with two questions:
- Do you recognise the need for the Digital Map?
Answer: More than half of the people in the room - Amongst those, how many are operators?
Answer: I would say one third of the people in the room
Clearly the Digital Map and its related modelling considerations are important to operators. As a consequence, Rob Wilton (as OPS AD) created the digitalmap-yang IETF mailing list (subscription here).
Thomas, Oscar and a couple of us started to document our findings in three different drafts:
1. Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives
2. A YANG Data Model for Intermediate System to intermediate System (IS-IS) Topology
3. Some Refinements to RFC8345 (Network Topologies)
And we came up with the Digital Map Modelling concept, where the important keyword is Modelling.
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.
Indeed, if the industry wants to use the digital map to solve its use cases (closed loop and the link to the Service Assurance for Intent-based Networking, along with the simulation, are close to my heart), the industry will have to address the RFC 8345 limitations (ex: no bidirectional, no point-to-multipoint, etc.) and provide some guidelines on how to augment the map for new layer and technologies, in a consistent way!
Related to Digital Map Modelling effort, the Network Inventory (IVY) WG met for the first time at this IETF. Its goal is to focus 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 case for the Digital Map. Therefore, it is important to have a consistent view of what a network node is. Indeed, a node-Id is node-Id is a node-Id, whether it comes from the topology, the digital map, the inventory, the service definition, or you-name-it. This IVY effort is complimentary to the Digital Map Modelling one, as mentioned here (https://datatracker.ietf.org/doc/html/draft-havel-opsawg-digital-map-00#name-network-inventory-ivy-propo). Once we have the node-id concept properly specified and used all over, following the node-id pointer to the inventory system (as specified by IVY) is an easy process.
Note: to be complete, I must stress that the Traffic Engineering Architecture and Signaling (TEAS) Working Group and the Common Control and Measurement Plane (CCAMP) Working Group have been also been looking at the network topology.