Skip to main content

Liaison statement
NMOP WG Reply to the ETSI ISG ZSM LS on Network Digital Twin

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2024-04-26
From Group nmop
From Contact Mohamed Boucadair
To Group ETSI
To Contacts
Cc Mahesh Jethanandani <>
Warren Kumari <>
Network Management Operations Discussion List <>
Benoît Claise <>
Mohamed Boucadair <>
Response Contact Mohamed Boucadair <>
Benoît Claise <>
Technical Contact
Purpose In response
Attachments PDF Version of the LS Reply
Liaisons referred by this one Liaison on ongoing work on Network Digital Twin
Liaisons referring to this one Liaison response to LS/r on “IETF_NMOP_WG_Reply_to_the_ETSI_ISG_ZSM_LS_on_Network” (ETSI ISG ZSM- ZSM(24)000101)
We would like to thank the ETSI ISG ZSM for informing us [1] about the
initiation of a new normative specification work on Network Digital Twin "ETSI
GS ZSM018 Network Digital Twin for enhanced zero-touch network and service

For your information, the IETF has chartered a new Working Group (WG) on
Network Management OPerations (NMOP WG) [2]. One of the current NMOP WG topics
is investigating issues related to the deployment and usage of YANG topology
modules in order to model a Digital Map.

Specifically, the WG is discussing "Modeling the Digital Map based on RFC 8345:
Sharing Experience and Perspectives” [3] which defines the concept of Digital
Map and explains its connection to the Network Digital Twin (NDT). Also, the
document identifies a set of candidate issues in RFC 8345 to meet NDT needs.
These issues will be fixed as part of the NMOP WG activities.

The Digital Map effort leverages the NDT architecture defined in the IRTF
“Network Digital Twin: Concepts and Reference Architecture” [4] specification
which also provides an overview of the NDT terms and concepts.

In addition, the ongoing effort leverages existing tools and data models, such
as (but not limited to):

(1) A "Framework for Automating Service and Network Management with YANG" [5]
which describes a framework for service and network management automation that
takes advantage of YANG modeling technologies.

   (1.1) This framework is drawn irrespective of the origin of a data model;
   thus, it can accommodate YANG modules that are developed outside the IETF.
   (1.2) Data models are also instrumental in the automation of network
   management, and they can provide closed-loop control for adaptive and
   deterministic service creation, delivery, and maintenance.

(2) YANG is a data modeling language that is independent of both the encoding
and the transport that is used. Many of the YANG modules are used to exchange
data between NETCONF/RESTCONF clients and servers (RFC 6241, RFC 8040).
However, YANG can be used by encodings other than XML/JSON and protocols other
than NETCONF/RESTCONF. For example, YANG can be used to define abstract data
structures per RFC8791.

(3) The IETF has specified a comprehensive list of models which cover various
layers and components. For example:

    (3.1) Service-level abstractions to represent how a service is exposed by a
    network to a customer or an application:

      - RFC 8309: Service Models Explained
      - RFC 8299: The L3VPN Service Model
      - RFC 8466: The L2VPN Service Model

    (3.2) Network-level abstractions, including devices and their subsystems,
    and relevant protocols operating at the link and network layers across
    multiple devices. Examples of such models are as follows:

      - RFC 8345: The Network Topologies Model defines a base model for network
      topology and inventories. Network  topology data includes link, node, and
      terminate-point resources.

      - RFC 8795: The Traffic Engineering (TE) Topology Model defines a YANG
      data model for representing and manipulating TE topologies.

      - RFC 8346: The Layer 3 Topology Model defines a YANG data model for
      representing and manipulating Layer 3 topologies.

      - RFC 8944: The Layer 2 Topology Model defines a YANG data model for
      representing and manipulating Layer 2 topologies.

      - RFC 8675: The Tunnel Interface Types Model defines a collection of YANG
      identities used as interface types for tunnel interfaces.

      - RFC 9182: The L3VPN Network Model (L3NM) provides a network-centric
      view of L3VPN services within a network.

      - RFC 9291: The L2VPN Network Model (L2NM) provides a network-centric
      view of L2VPN services within a network.

      - RFC 9408: The Service Attachment Point (SAP) Model defines a YANG data
      model for representing an abstract view of the provider network topology
      that contains the points from which its services can be attached (e.g.,
      basic connectivity, VPN, Network Slices) or to retrieve the points where
      the services are being delivered to customers (including peer networks).

    (3.3) Sample device models:

      - RFC 8530: The Logical Network Element Model defines a logical network
      element model that can be used to manage the logical resource
      partitioning that may be present on a network device.

      - RFC 8529: The Network Instance Model defines a network instance module.
      This module can be used to manage the virtual resource partitioning that
      may be present on a network device.

      - RFC 8348: The Hardware Management Model defines a YANG module for the
      management of hardware.

      - RFC 7317: The System Management Model defines the "ietf-system" YANG
      module that provides many features such as the configuration and the
      monitoring of system or system control operations (e.g., shutdown,
      restart, and setting time) identification.

      - RFC 8341: The Network Configuration Access Control Model defines a
      network configuration access control YANG module.

      - RFC 7224: The Interface Type Model defines a YANG module for interface
      type definitions.

      - RFC 8343: The Interface Management Model defines a YANG module for the
      management of network interfaces.

      - RFC 8349: The Routing Management Model defines a YANG module for
      routing management.

      - RFC 8512: The Network Address Translation (NAT) and Network Prefix
      Translation (NPT) Model defines a YANG module for NAT management.

      - RFC 8519: The Network Access Control Lists (ACLs) Model defines a YANG
      module for managing ACLs.

      - …

Available data models can be retrieved from [6].

The NMOP WG believes that existing data models can be leveraged in the context
of NDT beyond the IETF. Concretely, the Digital Map is a key foundation for
building the NDT, independent of the applications that will use this NDT.

The NMOP WG encourages the use of NMOP WG mailing list [7] as the most
effective and expedient way of exchanging information, answering questions, and
progressing any work. The WG will consider presentation requests from the ETSI
ISG ZSM that describe data modeling issues that you may identify, including,
but not limited to, when integrating and consuming existing data models. Such
issues can also be shared during formal WG meetings. Requests for presentations
can be sent to the NMOP Chairs [8].

Following is the schedule of upcoming IETF meetings [9]:

* 04 June 2024, Online interim meeting on Digital Map
* 20 July 2024 - 26 July 2024, Vancouver Canada
* 02 Nov 2024 - 08 Nov 2024, Dublin Ireland

NMOP WG Chairs
Mohamed Boucadair & Benoît Claise


Note: RFCs cited in the LS can be retrieved from