Internet DRAFT - draft-havel-opsawg-digital-map
draft-havel-opsawg-digital-map
OPSAWG O. Havel
Internet-Draft B. Claise
Intended status: Standards Track Huawei
Expires: 22 April 2024 O. Gonzalez. de Dios
Telefonica
A. Elhassany
T. Graf
Swisscom
M. Boucadair
Orange
20 October 2023
Modeling the Digital Map based on RFC 8345: Sharing Experience and
Perspectives
draft-havel-opsawg-digital-map-01
Abstract
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
https://github.com/OlgaHuawei.
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 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."
Havel, et al. Expires 22 April 2024 [Page 1]
Internet-Draft Digital Map Modelling October 2023
This Internet-Draft will expire on 22 April 2024.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Digital Map and Digital Twin Relationship . . . . . . . . . . 6
2.1. Digital Twin . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Digital Map . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Digital Map as a Prerequisite for Digital Twin . . . . . 7
3. The IETF Network Topology Approaches . . . . . . . . . . . . 8
3.1. IETF Network Topology . . . . . . . . . . . . . . . . . . 8
3.2. IETF Network Topology TE . . . . . . . . . . . . . . . . 9
4. Digital Map Requirements . . . . . . . . . . . . . . . . . . 9
4.1. Why RFC8345 is a Good Approach for Digital Map
Modelling . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Design Requirements . . . . . . . . . . . . . . . . . . . 11
5. Digital Map Modelling Experience . . . . . . . . . . . . . . 12
5.1. What is not in the basic model . . . . . . . . . . . . . 12
5.1.1. Bidirectional Links . . . . . . . . . . . . . . . . . 12
5.1.2. Multipoint Connectivity . . . . . . . . . . . . . . . 13
5.1.3. Links Between Networks . . . . . . . . . . . . . . . 14
5.1.4. Networks part of other networks . . . . . . . . . . . 15
5.1.5. Nodes, tps and links in multiple networks . . . . . . 15
5.1.6. Missing Supporting Relationships . . . . . . . . . . 16
5.1.7. Missing Topology Semantics . . . . . . . . . . . . . 16
5.2. Open Issues for Further Analysis . . . . . . . . . . . . 16
5.3. How to Augment for Generic Digital Map Extensions . . . . 17
5.4. How to Augment for New Technologies/Layers . . . . . . . 18
5.5. How to connect to the external world . . . . . . . . . . 18
5.6. Digital Map APIs . . . . . . . . . . . . . . . . . . . . 19
5.7. Digital Map Knowledge . . . . . . . . . . . . . . . . . . 19
6. Related IETF Activities . . . . . . . . . . . . . . . . . . . 19
6.1. Network Topology . . . . . . . . . . . . . . . . . . . . 19
Havel, et al. Expires 22 April 2024 [Page 2]
Internet-Draft Digital Map Modelling October 2023
6.2. Core Digital Map Components . . . . . . . . . . . . . . . 20
6.3. Additional Digital Map Components . . . . . . . . . . . . 21
6.4. Network Inventory (IVY) Proposed Working . . . . . . . . 21
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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?
Havel, et al. Expires 22 April 2024 [Page 3]
Internet-Draft Digital Map Modelling October 2023
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
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,
Havel, et al. Expires 22 April 2024 [Page 4]
Internet-Draft Digital Map Modelling October 2023
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
Havel, et al. Expires 22 April 2024 [Page 5]
Internet-Draft Digital Map Modelling October 2023
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.
Havel, et al. Expires 22 April 2024 [Page 6]
Internet-Draft Digital Map Modelling October 2023
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, 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:
* Generic Inventory Queries
* Service placement feasibility checks
* Service-> subservice -> resource
Havel, et al. Expires 22 April 2024 [Page 7]
Internet-Draft Digital Map Modelling October 2023
* 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
Havel, et al. Expires 22 April 2024 [Page 8]
Internet-Draft Digital Map Modelling October 2023
* 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
Havel, et al. Expires 22 April 2024 [Page 9]
Internet-Draft Digital Map Modelling October 2023
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
Havel, et al. Expires 22 April 2024 [Page 10]
Internet-Draft Digital Map Modelling October 2023
* 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
Havel, et al. Expires 22 April 2024 [Page 11]
Internet-Draft Digital Map Modelling October 2023
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.1. Bidirectional Links
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.
Havel, et al. Expires 22 April 2024 [Page 12]
Internet-Draft Digital Map Modelling October 2023
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.
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.
Havel, et al. Expires 22 April 2024 [Page 13]
Internet-Draft Digital Map Modelling October 2023
5.1.3. Links Between Networks
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:
* IS-IS processes would be grouped in an area via the standard IETF
RFC8345 network->node relationship.
* Applications and algorithms will consume topologies based on the
generic entities and relationships, they will not need to
understand the meaning of specific IS-IS attributes.
* The approach would be aligned with the IS-IS topology model and
the IS-IS network view in manuals and documentation.
* Provide capability to link different IGP domains and links between
them.
* Link between multiple networks/sub-networks is the common concept
in network topology.
Havel, et al. Expires 22 April 2024 [Page 14]
Internet-Draft Digital Map Modelling October 2023
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.
5.1.5. Nodes, tps and links in multiple 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.
Havel, et al. Expires 22 April 2024 [Page 15]
Internet-Draft Digital Map Modelling October 2023
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?
Havel, et al. Expires 22 April 2024 [Page 16]
Internet-Draft Digital Map Modelling October 2023
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
Havel, et al. Expires 22 April 2024 [Page 17]
Internet-Draft Digital Map Modelling October 2023
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
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
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
Havel, et al. Expires 22 April 2024 [Page 18]
Internet-Draft Digital Map Modelling October 2023
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
6. Related IETF Activities
6.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:
Havel, et al. Expires 22 April 2024 [Page 19]
Internet-Draft Digital Map Modelling October 2023
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.
6.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]
Havel, et al. Expires 22 April 2024 [Page 20]
Internet-Draft Digital Map Modelling October 2023
* - A YANG Data Model for IS-IS Topology
[I-D.ogondio-opsawg-isis-topology]
6.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 [RFC9417] and [RFC9418]
* 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 [RFC8299], L2NM [RFC9291],
L3NM [RFC9182]
* Incident Management for Network Services
[I-D.feng-opsawg-incident-management]
6.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").
Havel, et al. Expires 22 April 2024 [Page 21]
Internet-Draft Digital Map Modelling October 2023
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.
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
Havel, et al. Expires 22 April 2024 [Page 22]
Internet-Draft Digital Map Modelling October 2023
9. IANA Considerations
This document has no actions for IANA.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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/info/rfc8345>.
[RFC8346] 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,
March 2018, <https://www.rfc-editor.org/info/rfc8346>.
[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/info/rfc8944>.
10.2. Informative References
[Catalog] "", <https://yangcatalog.org/yang-search/impact_analysis/
ietf-network-topology@2018-02-26>.
[I-D.boro-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-boro-
opsawg-ntw-attachment-circuit-03, 5 September 2023,
<https://datatracker.ietf.org/doc/html/draft-boro-opsawg-
ntw-attachment-circuit-03>.
[I-D.boro-opsawg-teas-attachment-circuit]
Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S.,
and B. Wu, "YANG Data Models for 'Attachment Circuits'-as-
Havel, et al. Expires 22 April 2024 [Page 23]
Internet-Draft Digital Map Modelling October 2023
a-Service (ACaaS)", Work in Progress, Internet-Draft,
draft-boro-opsawg-teas-attachment-circuit-07, 10 July
2023, <https://datatracker.ietf.org/doc/html/draft-boro-
opsawg-teas-attachment-circuit-07>.
[I-D.davis-opsawg-some-refinements-to-rfc8345]
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,
10 July 2023, <https://datatracker.ietf.org/doc/html/
draft-davis-opsawg-some-refinements-to-rfc8345-00>.
[I-D.feng-opsawg-incident-management]
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, 21 October 2023,
<https://datatracker.ietf.org/doc/html/draft-feng-opsawg-
incident-management-02>.
[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-teas-rfc3272bis]
Farrel, A., "Overview and Principles of Internet Traffic
Engineering", Work in Progress, Internet-Draft, draft-
ietf-teas-rfc3272bis-27, 12 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
rfc3272bis-27>.
[I-D.irtf-nmrg-network-digital-twin-arch]
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, 23 October 2023,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
irtf-nmrg-network-digital-twin-arch/>.
[I-D.ogondio-opsawg-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
Havel, et al. Expires 22 April 2024 [Page 24]
Internet-Draft Digital Map Modelling October 2023
Progress, Internet-Draft, draft-ogondio-opsawg-isis-
topology-00, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ogondio-
opsawg-isis-topology-00>.
[I-D.ogondio-opsawg-ospf-topology]
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, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ogondio-
opsawg-ospf-topology-00>.
[I-D.palmero-opsawg-dmlmo]
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, 7 July 2023,
<https://datatracker.ietf.org/doc/html/draft-palmero-
opsawg-dmlmo-10>.
[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>.
[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/info/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/info/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/info/rfc8795>.
[RFC9179] Hopps, C., "A YANG Grouping for Geographic Locations",
RFC 9179, DOI 10.17487/RFC9179, February 2022,
<https://www.rfc-editor.org/info/rfc9179>.
Havel, et al. Expires 22 April 2024 [Page 25]
Internet-Draft Digital Map Modelling October 2023
[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/info/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/info/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/info/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/info/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/info/rfc9418>.
Contributors
The following people all contributed to creating this document:
Acknowledgements
Thanks to xx for their reviews and comments.
Authors' Addresses
Olga Havel
Huawei
Townsend Street, George's Court
Dublin
Ireland
Email: olga.havel@huawei.com
Benoit Claise
Huawei
ADD
ADD
Belgium
Havel, et al. Expires 22 April 2024 [Page 26]
Internet-Draft Digital Map Modelling October 2023
Email: benoit.claise@huawei.com
Oscar Gonzalez de Dios
Telefonica
ADD
Madrid
Spain
Email: oscar.gonzalezdedios@telefonica.com
Ahmed.Elhassany
Swisscom
Binzring 17
CH-8045 Zurich
Switzerland
Email: Ahmed.Elhassany@swisscom.com
Thomas Graf
Swisscom
Binzring 17
CH-8045 Zurich
Switzerland
Email: thomas.graf@swisscom.com
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Havel, et al. Expires 22 April 2024 [Page 27]
