Internet-Draft | Digital Map Modelling | October 2023 |
Havel, et al. | Expires 22 April 2024 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.com/OlgaHuawei.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[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:¶
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 LDP¶
- MPLS TE Tunnels¶
- SRv6 Tunnels¶
- L3VPN service¶
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.¶
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).¶
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.¶
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, https://datatracker.ietf.org/doc/charter-ietf-ivy/ ): 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:¶
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.¶
[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¶
[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¶
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]:¶
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:¶
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:¶
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.¶
The following are design requirements for modelling the Digital Map:¶
The following are the architectural requirements for the Digital Map:¶
The following are the [RFC8345] extensions needed for Digital Map modelling and APIs:¶
The RFC8345 defines all links as unidirectional, it does not support bidirectional links. It was done intentionally to keep the model as simple as possible. The RFC suggests to model the bidirectional connections as pairs of unidirectional links.¶
Nevertheless, while simplifying the model itself, we are making data and APIs more complex for the cases where we have bidirectional links. And we are increasing the amount of instances / data transferred via API, stored in the database, or managed/monitored.¶
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.¶
[I-D.davis-opsawg-some-refinements-to-rfc8345] further elaborates on the need for bidirectional links in the network topologies and in the digital map. It also proposes how RFC8345 can be augmented to support missing components.¶
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.¶
The RFC8345 defines all links as belonging to one network instance and having the source and destination as node and termination point only, not allowing to link to termination point of another network. This does not allow for links between networks in the case of multi-domains or partitioning. The only way would be to model each domain as node and have links between them.¶
We modelled IS-IS Areas as networks during the PoC and we needed to extend the capability to have links between different areas. We added network reference as well to the source / destination of the link. The RFC8795 also augments links with external-domain info for the case of links that connect different domains.¶
The IS-IS topology [I-D.ogondio-opsawg-isis-topology] models Autonomous System (AS) or IS-IS domain as a network, and IS-IS areas as attributes of IS-IS nodes. The RFC8345 extension can be used to model IS-IS areas as networks and IS-IS links between L1-2 nodes as links between two different areas. This is not problem for OSPF, althogh the OSPF nodes can belong to multiple areas, the links can belong to only one area.¶
The following are some benefits of modeling links between different 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:¶
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:¶
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.¶
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:¶
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.¶
Generic Digital Map extensions are the RFC8345 extensions required for all technologies and layers in the Digital Map. We have the following options:¶
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 ¶
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¶
This can be a separate draft. Guidelines with examples? Add reference to this draft when submitted ¶
How to connect to other YANG modules¶
How to connect YANG models with other modelling mechanisms¶
This will include hierarchical APIs for cross-domain figure, IETF YANG Based API (read and write, change subscription and notify) and Query API¶
The following knowledge was needed to build digital map:¶
What can be achieved with existing RFC8345 YANG:¶
Next steps¶
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:¶
Topology information may also be derived from servers that monitor network state, and from servers that perform provisioning functions.¶
The following standards are core for the Digital Map.¶
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:¶
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.¶
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.¶
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¶
This document has no actions for IANA.¶
The following people all contributed to creating this document:¶
Thanks to xx for their reviews and comments.¶