Internet-Draft Digital Map Concept & Needs October 2024
Havel, et al. Expires 12 April 2025 [Page]
Workgroup:
Network Management Operations
Internet-Draft:
draft-ietf-nmop-digital-map-concept-01
Published:
Intended Status:
Informational
Expires:
Authors:
O. Havel
Huawei
B. Claise
Huawei
O. G. D. Dios
Telefonica
T. Graf
Swisscom

Digital Map: Concept, Requirements, and Use Cases

Abstract

This document defines the concept of Digital Map, and identifies a set of Digital Map requirements and use cases.

The document intends to be used as a reference for the assessment effort of the various topology modules to meet Digital Map requirements.

Discussion Venues

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

Discussion of this document takes place on the Network Management Operations Working Group mailing list (nmop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/nmop/.

Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept.

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

This Internet-Draft will expire on 12 April 2025.

Table of Contents

1. Introduction

Digital Map provides a core multi-layer topology model and data and connects them to the other models and data. This includes layers from physical topology to service topology.

The Digital Map modelling defines the core topological entities (network, node, link, and interface) at each layer, their role in the network topology, core topological properties, and topological relationships both inside each layer and between the layers. It also defines how to access other external models from the topology.

The Digital Map model is a topological model that is linked to the other functional models and connects them all: configuration, maintenance, assurance (KPIs, status, health, and symptoms), Traffic-Engineering (TE), different behaviors and actions, simulation, emulation, mathematical abstractions, AI algorithms, etc. These other models exist outside of the digital map and are not defined during digital map modelling.

The Digital Map data consists of virtual instances of network and service topologies at different layers. The Digital Map provides 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., Service Assurance for Intent-based Networking (SAIN) [RFC9417], Service Attachement Points (SAPs) [RFC9408], Inventory [I-D.ietf-ivy-network-inventory-yang], and non-YANG models.

2. Terminology

The document defines the following terms:

Topology:

Network topology defines how physical or logical nodes, links and interfaces are related and arranged. 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 topology layer can also represent what needs to be managed by a specific user, for example IGP layer can be of interest to the operator troubleshooting or optimizating 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, Layer 2 for link topology and Layer 3 for IPv4 and IPv6 topologies.

Some topology layers represent the control aspects of Layer 3, like OSPF, IS-IS, or BGP.

The service layer represents the service view of the connectivity, that can differ for different types of services and for different providers/solutions.

The top layer represents the application/flow view of connectivity.

Digital Map:

Basis for the Operator Network and Services Models that provides topological information of the network. It provides the core multi-layer topology model/data and how to connect them to the other models/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, relationship types between entities and relationships to other entities o.

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 with the links to other models and connects them all: configuration, maintenance, assurance (KPIs, status, health, symptoms, etc.), 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.

3. Sample Digital Map Use Cases

The following are sample use cases that require Digital Map:

Overall, the Digital Map is needed to provide the mechanism to connect data islands from the core multi-layered topology. It is a solution feasible and useful in the short-term for the existing operations use cases, but it is also a requirement for the Digital Twin.

4. Digital Map Requirements

4.1. Core Requirements

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

REQ-BASIC-MODEL-SUPPORT:

Basic model with network, node, link, and interface entity types. This means that users of the Digital Map model must be able to understand topology model at any layer via these core concepts only, without having to go to the details of the specific augmentations to understand the topology.

REQ-LAYERED-MODEL:

Layered Digital Map, from physical network (ideally optical, layer 2, layer 3) up to service and intent views.

REQ-PROG-OPEN-MODEL:

Open and programmable Digital Map.

This includes "read" operations to retrieve the view of the network, typically as application-facing interface of Software Defined Networking (SDN) controllers or orchestrators.

It also includes "write" operations, not for the ability to directly change the Digital Map data (e.g., changing the network or service parameters), but for offline simulations, also known as what-if scenarios.

Running a "what-if" analysis requires the ability to take snapshots and to switch easily between them.

Note that there is a need to distinguish between a change on the Digital Map for future simulation and a change that reflects the current reality of the network.

REQ-STD-API-BASED:

Standard based Digital Map Models and APIs, for multi-vendor support.

Digital Map must provide the standard YANG APIs that provide for read/write and queries. These APIs must also provide the capability to retrieve the links to external data/models.

REQ-COMMON-APP:

Digital Map models and APIs must be common over different network domains (campus, core, data center, etc.). This means that clients of the Digital Map API must be able to understand the topology model of layers of any domain without having to understand the details of any technologies and domains.

REQ-SEMANTIC:

Digital Map must provide semantics for layered network topologies and for linking external models/data.

REQ-LAYER-NAVIGATE:

Digital Map must provide intra-layer and inter-layer relationships.

REQ-EXTENSIBLE:

Digital Map must be extensible with metadata.

REQ-PLUGG:

Digital Map must be pluggable. That is,

  • Must connect to other YANG modules for inventory, configuration, assurance, etc.

  • Given that no all involved components can be available using YANG, there is a need to connect Digital Map YANG model with other modelling mechanisms.

REQ-GRAPH-TRAVERSAL:

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.2. Design Requirements

The following are design requirements for modelling the Digital Map:

REQ-TOPO-ONLY:

Digital Map should contain only topological information.

Digital Map is not required to contain all models and data required for all the management and use cases. However, it should be designed to support adequate pointers to other functional data and models to ease navigating in the overall system. For example:

  • ACLs and Route Policies are not required to be supported in the Digital Map, they would be linked to Digital Map

  • Dynamic paths may either be outside of the Digital Map or part of traffic engineering data/models

REQ-PROPERTIES:

Digital Map entities should mainly contain properties used to identify topological entities at different layers, identify their roles, and topological relationships between them.

REQ-RELATIONSHIPS:

Digital Map should contain only topological relationships inside each layer or between the layers (underlay/overlay).

REQ-CONDITIONAL:

Provide capability for conditional retrieval of parts of Digital Map.

REQ-TEMPO-HISTO:

Must support geo-spatial, temporal, and historical data. The temporal and historical can be supported external to the Digital Map.

4.3. Architectural Requirements

The following are the architectural requirements for the Digital Map:

REQ-DM-SCALES:

Scale, performance, ease of integration.

REQ-DM-DISCOVERY:

Initial discovery and dynamic (change only) synch with the physical network.

5. Security Considerations

As this document covers the Digital Map concepts, requirements, and use cases, there is no specific security considerations. However, the RFC 8345 Security Considerations aspects will be useful when designing the solution.

6. IANA Considerations

This document has no actions for IANA.

7. References

7.1. Normative References

[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, , <https://www.rfc-editor.org/rfc/rfc8345>.

7.2. Informative References

[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-network-inventory-yang-02>.
[I-D.ietf-ivy-network-inventory-topology]
Wu, B., Zhou, C., Wu, Q., and M. Boucadair, "A Network Inventory Topology Model", Work in Progress, Internet-Draft, draft-ietf-ivy-network-inventory-topology-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-topology-00>.
[I-D.ietf-ivy-network-inventory-yang]
Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A YANG Data Model for Network Inventory", Work in Progress, Internet-Draft, draft-ietf-ivy-network-inventory-yang-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-03>.
[I-D.ietf-nmop-network-incident-yang]
Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network-incident-yang-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-incident-yang-01>.
[I-D.ietf-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-ietf-opsawg-ntw-attachment-circuit-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ntw-attachment-circuit-13>.
[I-D.ietf-opsawg-teas-attachment-circuit]
Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)", Work in Progress, Internet-Draft, draft-ietf-opsawg-teas-attachment-circuit-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-16>.
[I-D.ogondio-nmop-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 Progress, Internet-Draft, draft-ogondio-nmop-isis-topology-00, , <https://datatracker.ietf.org/doc/html/draft-ogondio-nmop-isis-topology-00>.
[I-D.ogondio-opsawg-ospf-topology]
de Dios, O. G., Barguil, S., and V. Lopez, "A YANG Data Model for Open Shortest Path First (OSPF) Topology", Work in Progress, Internet-Draft, draft-ogondio-opsawg-ospf-topology-01, , <https://datatracker.ietf.org/doc/html/draft-ogondio-opsawg-ospf-topology-01>.
[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, , <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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/rfc8795>.
[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, , <https://www.rfc-editor.org/rfc/rfc8944>.
[RFC9179]
Hopps, C., "A YANG Grouping for Geographic Locations", RFC 9179, DOI 10.17487/RFC9179, , <https://www.rfc-editor.org/rfc/rfc9179>.
[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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/rfc9418>.
[RFC9522]
Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, , <https://www.rfc-editor.org/rfc/rfc9522>.

Acknowledgments

Many thanks to Mohamed Boucadair (mohamed.boucadair@orange.com) for his valuable contributions, reviews, and comments.

Many thanks to Nigel Davis ndavis@ciena.com for the valuable discussions and his confirmation of the modelling requirements.

Contributors

Ahmed Elhassany
Swisscom

Authors' Addresses

Olga Havel
Huawei
Benoit Claise
Huawei
Oscar Gonzalez de Dios
Telefonica
Thomas Graf
Swisscom