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 | Fernando.camacho1@huawei.com ZSMSupport@etsi.org |
Cc | Mahesh Jethanandani <mjethanandani@gmail.com> Warren Kumari <warren@kumari.net> Network Management Operations Discussion List <nmop@ietf.org> Benoît Claise <benoit.claise@huawei.com> Mohamed Boucadair <mohamed.boucadair@orange.com> |
Response Contact | Mohamed Boucadair <mohamed.boucadair@orange.com> Benoît Claise <benoit.claise@huawei.com> |
Technical Contact | mohamed.boucadair@orange.com |
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)
|
Body |
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 management". 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 References: [1] https://datatracker.ietf.org/liaison/1914/ [2] https://datatracker.ietf.org/group/nmop/about/ [3] https://datatracker.ietf.org/doc/draft-havel-nmop-digital-map/ [4] https://datatracker.ietf.org/doc/draft-irtf-nmrg-network-digital-twin-arch/ [5] https://datatracker.ietf.org/doc/html/rfc8969 [6] https://www.yangcatalog.org/yang-search [7] https://www.ietf.org/mailman/listinfo/nmop [8] nmop-chairs@ietf.org [9] https://www.ietf.org/meeting/upcoming/ Note: RFCs cited in the LS can be retrieved from https://datatracker.ietf.org/ |