Digital Map: Concept, Requirements, and Use Cases
draft-ietf-nmop-digital-map-concept-00

Network Management Operations                                   O. Havel
Internet-Draft                                                 B. Claise
Intended status: Informational                                    Huawei
Expires: 28 March 2025                                     O. G. D. Dios
                                                              Telefonica
                                                                 T. Graf
                                                                Swisscom
                                                       24 September 2024

           Digital Map: Concept, Requirements, and Use Cases
                 draft-ietf-nmop-digital-map-concept-00

Abstract

   This document defines the concept of Digital Map, explains its
   connection to the Digital Twin, 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."

Havel, et al.             Expires 28 March 2025                 [Page 1]
Internet-Draft         Digital Map Concept & Needs        September 2024

   This Internet-Draft will expire on 28 March 2025.

Copyright Notice

   Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Digital Twin Overview . . . . . . . . . . . . . . . . . .   3
     1.2.  Digital Map . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Digital Map as a Prerequisite for Digital Twin  . . . . .   4
     1.4.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Sample Digital Map Use Cases  . . . . . . . . . . . . . . . .   6
   4.  Digital Map Requirements  . . . . . . . . . . . . . . . . . .   7
     4.1.  Core Requirements . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Design Requirements . . . . . . . . . . . . . . . . . . .   8
     4.3.  Architectural Requirements  . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Related IETF Activities  . . . . . . . . . . . . . .  13
     A.1.  Network Topology  . . . . . . . . . . . . . . . . . . . .  13
     A.2.  Core Digital Map Components . . . . . . . . . . . . . . .  13
     A.3.  Additional Digital Map Components . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

Havel, et al.             Expires 28 March 2025                 [Page 2]
Internet-Draft         Digital Map Concept & Needs        September 2024

1.1.  Digital Twin Overview

   The network digital twin (referred to simply as Digital Twin)
   concepts and a reference architecture are discussed in the "Digital
   Twin Network: Concepts and Reference Architecture"
   [I-D.irtf-nmrg-network-digital-twin-arch].  That reference 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, that document [I-D.irtf-nmrg-network-digital-twin-arch] 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).

1.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.  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, core properties, and relationships both inside each layer
   and between the layers.

   The Digital Map model can be approached as a topological model that
   is linked to other functional parts of the Digital Twin 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.

Havel, et al.             Expires 28 March 2025                 [Page 3]
Internet-Draft         Digital Map Concept & Needs        September 2024

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

1.3.  Digital Map as a Prerequisite for Digital Twin

   One of the important requirements for 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 at
   providing 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 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, a 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 a Network Inventory.  A pointer to another
   inventory system might be sufficient or support of means that ease
   the mapping between inventory and topology.

   Similarly, Digital Map should not specifically contain incidents,
   configuration, data plane monitoring, or even assurance information,
   simply to name a few, but should provide pointers to the different
   data sources.

1.4.  Scope

   This document defines the concept of Digital Map, explains its
   connection to the Digital Twin, and identifies a set of Digital Map
   requirements and use cases.

Havel, et al.             Expires 28 March 2025                 [Page 4]
Internet-Draft         Digital Map Concept & Needs        September 2024

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

2.  Terminology

   The document defines the following terms:

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

Havel, et al.             Expires 28 March 2025                 [Page 5]
Internet-Draft         Digital Map Concept & Needs        September 2024

   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, 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 Digital Twin use cases that require Digital
   Map:

   *  Generic inventory queries

   *  Service placement feasibility checks

   *  Service-> subservice -> resource

   *  Resource -> subservice -> service

   *  Intent/service assurance

Havel, et al.             Expires 28 March 2025                 [Page 6]
Internet-Draft         Digital Map Concept & Needs        September 2024

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

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

Havel, et al.             Expires 28 March 2025                 [Page 7]
Internet-Draft         Digital Map Concept & Needs        September 2024

      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 data required for all

Havel, et al.             Expires 28 March 2025                 [Page 8]
Internet-Draft         Digital Map Concept & Needs        September 2024

      the management and use cases.  However, it should be designed to
      support adequate pointers to other functional Digital Twin 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

Havel, et al.             Expires 28 March 2025                 [Page 9]
Internet-Draft         Digital Map Concept & Needs        September 2024

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

7.2.  Informative References

   [I-D.draft-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, 28 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
              network-incident-yang-01>.

   [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-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, 7
              August 2024, <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, 7 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-
              network-inventory-yang-03>.

   [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, 5 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              ntw-attachment-circuit-13>.

Havel, et al.             Expires 28 March 2025                [Page 10]
Internet-Draft         Digital Map Concept & Needs        September 2024

   [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, 10 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              teas-attachment-circuit-16>.

   [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, "Network Digital
              Twin: Concepts and Reference Architecture", Work in
              Progress, Internet-Draft, draft-irtf-nmrg-network-digital-
              twin-arch-06, 7 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
              network-digital-twin-arch-06>.

   [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, 4 March 2024,
              <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, 23 October 2023,
              <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, 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/rfc/rfc8299>.

Havel, et al.             Expires 28 March 2025                [Page 11]
Internet-Draft         Digital Map Concept & Needs        September 2024

   [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/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, August 2020,
              <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, November 2020,
              <https://www.rfc-editor.org/rfc/rfc8944>.

   [RFC9179]  Hopps, C., "A YANG Grouping for Geographic Locations",
              RFC 9179, DOI 10.17487/RFC9179, February 2022,
              <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,
              February 2022, <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, September 2022,
              <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,
              June 2023, <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, July 2023,
              <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, July 2023,
              <https://www.rfc-editor.org/rfc/rfc9418>.

   [RFC9522]  Farrel, A., Ed., "Overview and Principles of Internet
              Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
              January 2024, <https://www.rfc-editor.org/rfc/rfc9522>.

Havel, et al.             Expires 28 March 2025                [Page 12]
Internet-Draft         Digital Map Concept & Needs        September 2024

Appendix A.  Related IETF Activities

A.1.  Network Topology

   Interestingly, we could not find any network topology definition in
   IETF RFCs (not even in [RFC8345]) or Internet-Drafts.  However, it is
   mentioned in multiple documents.  As an example, in Overview and
   Principles of Internet Traffic Engineering [RFC9522], which mentions:

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

A.2.  Core Digital Map Components

   The following specifications 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:

Havel, et al.             Expires 28 March 2025                [Page 13]
Internet-Draft         Digital Map Concept & Needs        September 2024

      -  A YANG data model for Traffic Engineering (TE) Topologies
         [RFC8795]

      -  A YANG data model for Layer 2 network topologies [RFC8944]

      -  A YANG data model for OSFP topology
         [I-D.ogondio-opsawg-ospf-topology]

      -  A YANG data model for IS-IS topology
         [I-D.ogondio-nmop-isis-topology]

A.3.  Additional Digital Map Components

   The Digital Map may need to link to the following models, some are
   already augmenting [RFC8345]:

   *  Service Attachment Point (SAP) [RFC9408], augments 'ietf-network'
      data model [RFC8345] by adding the SAP.

   *  SAIN [RFC9417] [RFC9418]

   *  Network Inventory Model [I-D.ietf-ivy-network-inventory-yang]
      focuses on physical and virtual inventory.  Logical inventory is
      currently outside of the scope.  It does not augment RFC8345 like
      the two Internet-Drafts that it evolved from
      [I-D.ietf-ccamp-network-inventory-yang] and
      [I-D.wzwb-opsawg-network-inventory-management].
      [I-D.ietf-ivy-network-inventory-topology] correlates the network
      inventory with the general topology via RFC8345 augmentations that
      reference inventory.

   *  KPIs: delay, jitter, loss

   *  Attachment Circuits (ACs) [I-D.ietf-opsawg-ntw-attachment-circuit]
      and [I-D.ietf-opsawg-teas-attachment-circuit]

   *  Configuration: L2SM [RFC8466], L3SM [RFC8299], L2NM [RFC9291], and
      L3NM [RFC9182]

   *  Incident Management for Network Services
      [I-D.draft-ietf-nmop-network-incident-yang]

Acknowledgments

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

Havel, et al.             Expires 28 March 2025                [Page 14]
Internet-Draft         Digital Map Concept & Needs        September 2024

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

Contributors

   Ahmed Elhassany
   Swisscom
   Email: Ahmed.Elhassany@swisscom.com

Authors' Addresses

   Olga Havel
   Huawei
   Email: olga.havel@huawei.com

   Benoit Claise
   Huawei
   Email: benoit.claise@huawei.com

   Oscar Gonzalez de Dios
   Telefonica
   Email: oscar.gonzalezdedios@telefonica.com

   Thomas Graf
   Swisscom
   Email: thomas.graf@swisscom.com

Havel, et al.             Expires 28 March 2025                [Page 15]