



CCAMP Working Group                                               Y. Tan
Internet-Draft                                              China Unicom
Intended status: Informational                                   X. Zhao
Expires: 20 October 2026                                           CAICT
                                                                   C. Yu
                                                     Huawei Technologies
                                                            D. King, Ed.
                                                          A. Farrel, Ed.
                                                      Old Dog Consulting
                                                           18 April 2026


 Integrating YANG Configuration and Management into an Abstraction and
       Control of TE Networks (ACTN) System for Optical Networks
            draft-ietf-ccamp-actn-optical-transport-mgmt-05

Abstract

   Many network technologies are operated as Traffic Engineering (TE)
   networks.  Optical networks are a particular case, and have complex
   technology-specific details.

   Abstraction and Control of TE Networks (ACTN) is a management
   architecture that abstracts TE network resources to provide a limited
   network view for customers to request and self-manage connectivity
   services.  It also provides functional components to orchestrate and
   operate the network.

   Management of legacy optical networks is often provided via Fault,
   Configuration, Accounting, Performance, and Security (known as FCAPS)
   using mechanisms such as the Multi-Technology Operations System
   Interface (MTOSI) and the Common Object Request Broker Architecture
   (CORBA).  FCAPS can form a critical part of configuration management
   and service assurance for network operations.  However, the ACTN
   architecture as described in RFC 8453 does not include consideration
   of FCAPS.

   This document enhances the ACTN architecture as applied to optical
   networks by introducing support for detailed YANG Configuration and
   Management, effectively adding support for FCAPS.  It considers which
   elements of existing IETF YANG work can be used to solve existing
   scenarios and emerging technologies, and what new work may be needed.
   In doing so, this document adds rich-detail network management (RDNM)
   to the ACTN architecture.  This enhanced architecture may then be
   used to evolve networks from CORBA and MTOSI FCAPS interfaces to
   IETF-based YANG and RESTful APIs.





Tan, et al.              Expires 20 October 2026                [Page 1]

Internet-Draft           RDNM with Optical ACTN               April 2026


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 20 October 2026.

Copyright Notice

   Copyright (c) 2026 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.  Transport Network Management Approaches . . . . . . . . .   5
     1.2.  Configuration Management  . . . . . . . . . . . . . . . .   5
     1.3.  Service Assurance . . . . . . . . . . . . . . . . . . . .   6
     1.4.  Additional IETF Terminology . . . . . . . . . . . . . . .   7
     1.5.  Motivation and Scope  . . . . . . . . . . . . . . . . . .   7
   2.  Extending the ACTN Architecture to Include RDNM . . . . . . .   8
   3.  Functionality at the MPI  . . . . . . . . . . . . . . . . . .  10
     3.1.  Data Models at the MPI  . . . . . . . . . . . . . . . . .  10
     3.2.  Abstraction and Control at the MPI  . . . . . . . . . . .  11
   4.  Introduction to FCAPS . . . . . . . . . . . . . . . . . . . .  12
   5.  Abstract Control and Rich-Detail Network Management for
           ACTN  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.1.  Abstract Control and Rich-Detail Network Management
           Functions for the MPI . . . . . . . . . . . . . . . . . .  13



Tan, et al.              Expires 20 October 2026                [Page 2]

Internet-Draft           RDNM with Optical ACTN               April 2026


     5.2.  Rich-Detail Network Management Interfaces . . . . . . . .  14
     5.3.  Rich-Detail Network Management Data Models  . . . . . . .  15
     5.4.  Rich-Detail Network Management Example  . . . . . . . . .  17
   6.  Manageability Considerations  . . . . . . . . . . . . . . . .  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   10. Informative References  . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   Abstraction and Control of Traffic Engineering Networks (ACTN)
   [RFC8453] is an architecture that simplifies and optimises the
   management and control of network resources to deliver connectivity
   services in Traffic Engineering (TE) networks [RFC9522], including
   optical networks.  ACTN abstracts and controls TE resources to enable
   end-to-end service provisioning and management across multiple
   network domains.  It provides a way to orchestrate and automate the
   management of network resources, including connectivity and
   bandwidth, to meet the requirements of specific services or
   applications.

   ACTN in an optical network leverages Software Defined Networking
   (SDN) concepts to achieve its objectives.  By applying SDN
   principles, such as centralised control, path computation (such as a
   Path Computation Element - PCE [RFC4655]), and programmability, to
   the transport (i.e., sub-IP) layer, ACTN enables efficient
   orchestration and service provisioning in a multi-domain environment.
   ACTN adds a higher-level framework and management capabilities
   specifically tailored for TE transport networks, including the
   abstraction of network resources, service provisioning, and resource
   optimisation.

   The term FCAPS [M-3060] is used in network management and stands for
   Fault, Configuration, Accounting, Performance, and Security.  FCAPS
   is a widely accepted framework that categorises different aspects of
   network management and provides a structured approach to managing and
   maintaining networks, addressing various operational and maintenance
   areas.

   Although FCAPS provides a structured framework for key functions
   required for managing networks, the level of granularity depends on
   how it is implemented; therefore, it does not inherently guarantee
   rich-detail control and observation.






Tan, et al.              Expires 20 October 2026                [Page 3]

Internet-Draft           RDNM with Optical ACTN               April 2026


   While ACTN primarily deals with the abstraction and control of TE
   networks for service provisioning, FCAPS covers broader aspects of
   network management.  In practice, while ACTN provides a suitable
   architecture for requesting and monitoring connectivity services in
   optical networks, operators would also like to leverage the FCAPS
   framework for specific operational tasks and management activities.

   ACTN and FCAPS are not mutually exclusive, and this document explains
   how the ACTN architecture can be extended to support detailed YANG
   Configuration and Management, effectively adding support for FCAPS as
   applied to optical networks.  It considers which elements of IETF
   work can be used, and what new work is needed.

   This enhanced ACTN architecture is known as ACTN Rich-Detail Network
   Management (ACTN RDNM).  It provides an evolution path for FCAPS
   Operational Support System (OSS) functions from Common Object Request
   Broker Architecture (CORBA) [CORBA] interfaces and the Multi-
   Technology Operations System Interface (MTOSI) architecture [MTOSI],
   to IETF YANG-based models and RESTful APIs.

   It should be noted that optical networks have a lot of details that
   are specific to the transmission medium (i.e., the physical and
   optical components and mechanisms used to send data on optical
   fibers).  Different networks contain different physical transmission
   components that need to be managed in very specific ways.  This can
   make generalisation of configuration and management hard, and means
   that the nature of ACTN RDNM is different in an optical network than
   it might be in a more general (and specifically, packet-based) TE
   network.

   In the realm of modern optical networks, both FCAPS and Network
   Management Systems (NMS) are relevant, but in distinct ways.  FCAPS
   is a framework or model that defines the key functional areas of
   network management.  It provides a structured approach for managing
   telecommunication networks.  While often considered a legacy model,
   its principles are still crucial for understanding and addressing the
   various aspects of network management in optical networks.  An NMS,
   on the other hand, is the actual system or application that enables
   network operators to monitor, configure, and maintain communication
   networks.  NMS software tools implement the principles defined by
   frameworks like FCAPS to perform these functions.










Tan, et al.              Expires 20 October 2026                [Page 4]

Internet-Draft           RDNM with Optical ACTN               April 2026


   An NMS is more directly relevant for day-to-day operations: NMS tools
   provide the actual functionality for tasks such as provisioning
   services, monitoring network health, identifying and resolving
   faults, optimising performance, and ensuring security.  FCAPS still
   provides a useful framework: understanding the FCAPS functional areas
   helps evaluate the capabilities and functions of different NMS tools.
   It provides a standardised way to categorise and address various
   management tasks within the NMS.

   Note that the term "fault" is defined in this context in [RFC9940] as
   an undesired event or change, which may or may not directly imply the
   root cause.

1.1.  Transport Network Management Approaches

   ITU-T G.805 [G-805] specifies the architecture and framework for the
   management of transport networks.  G.805 provides guidelines and
   principles for managing network resources and services in a
   coordinated and efficient manner.

   TM Forum has developed its own set of standards and frameworks for
   managing telecommunications networks and services.  Specifically, TM
   Forum developed the Telecommunications Management Network (TMN) model
   and informed ITU-T M.3060 [M-3060] to align with G.805.  TMN is a
   framework that defines a comprehensive set of management functions
   and interfaces for network operations and service management.

   More recently, ITU-T M.3041 [M-3041] introduced a framework for smart
   operation, management, and maintenance (SOMM).  M.3041 provides the
   characteristics, scenarios, and the functional architecture of SOMM
   to support service operation, network management, and infrastructure
   maintenance for both traditional physical networks and for software-
   defined networking.  It is applicable to network function
   virtualisation (non-SDN/NFV) and to SDN/NFV aware networks.

   This document shows how the ACTN architecture can accommodate the
   principles of G.805 and M.3041.  It outlines existing IETF
   mechanisms, protocols and data models, and indicates requirements
   where gaps exist.

1.2.  Configuration Management

   MTOSI [MTOSI] is a standard in the telecommunications industry
   arising from TM Forum that provides a common framework for operations
   support systems (OSSes) to interact with various network elements and
   technologies.  It defines a set of standardised interfaces and
   protocols to enable the integration of different OSS components.




Tan, et al.              Expires 20 October 2026                [Page 5]

Internet-Draft           RDNM with Optical ACTN               April 2026


   It contains several capabilities and key features:

   *  Service Management: MTOSI focuses on service management, allowing
      operators to efficiently provision, activate, and manage services
      on the network.

   *  Interoperability: MTOSI promotes interoperability between
      different vendors' OSS components, reducing the complexity of
      integrating heterogeneous network elements.

   *  Common Data Model: MTOSI defines a common data model for
      information exchanged between OSS components, ensuring consistency
      and accuracy in operations.

   To enable automation of operations, which is crucial for managing
   large, multi-technology, complex, telecommunications networks, these
   features must be introduced into ACTN as ACTN RDNM.

   Increasingly, network OSSes require atomic-level views of network
   devices and interfaces, instead of only abstracted views and
   interactions.  This will allow ACTN-based systems to leverage
   inventory management, device-level and interface-level views, and
   network configuration operations, via RESTful APIs instead of legacy
   CORBA-based APIs.

1.3.  Service Assurance

   Service Assurance refers to the activities and processes that ensure
   the quality, availability, and performance of services delivered by a
   network.  Those processes monitor and manage the end-to-end service
   experience, and ensure that Service Level Agreements (SLAs) and
   customer expectations are met.

   By applying RESTful RDNM functions through the ACTN framework,
   network operators and service providers can address different aspects
   of network management to support Service Assurance.  This helps them
   detect and resolve faults, manage configurations, track resource
   usage, optimise performance, and enhance security, all of which
   contribute to delivering reliable and high-quality services to
   customers.











Tan, et al.              Expires 20 October 2026                [Page 6]

Internet-Draft           RDNM with Optical ACTN               April 2026


   Not all Service Assurance requirements can be provided via existing
   ACTN YANG models.  Rich-detail management may also be required,
   supplementing abstract resource models with inventory-based models
   such as [I-D.ietf-ivy-network-inventory-yang].  This would provide an
   atomic-level view of network devices and components, instead of only
   abstracted views.  Note that not all FCAPS functions require rich-
   detail views and control: a mix of abstracted and detailed views will
   sometimes be needed.

1.4.  Additional IETF Terminology

   Many IETF documents use terminology related to network management
   that is applicable to ACTN RDNM as discussed in this document.
   Consistent and coherent use of terminology is an aid to understanding
   so, where possible, this document defers to definitions present in
   other IETF work.  A useful set of references is as follows:

   *  "Guidelines for the Use of the 'OAM' Acronym in the IETF"
      [RFC6291].

   *  "Guidelines for Characterizing 'OAM'"
      [I-D.ietf-opsawg-oam-characterization] for extended OAM
      terminology.

   *  "Some Key Terms for Network Fault and Problem Management"
      [I-D.ietf-nmop-terminology].

   *  "A Base YANG Data Model for Network Inventory"
      [I-D.ietf-ivy-network-inventory-yang] for terms relating to
      hardware and software components.

   *  "Framework for Abstraction and Control of TE Networks (ACTN)"
      [RFC8453].

   *  "Service Models Explained" [RFC8309] for the context of using YANG
      models to request and monitor services.

   *  "Software-Defined Networking (SDN): Layers and Architecture
      Terminology" [RFC7426].

1.5.  Motivation and Scope

   Operators who manage optical transport networks can leverage ACTN for
   resource abstraction and service provisioning.  At the same time,
   they can utilise the G.805 architecture and the TMN model to
   establish effective network management practices, which will
   facilitate service assurance.  Combining the two management
   approaches aligns with best-practice industry standards and allows



Tan, et al.              Expires 20 October 2026                [Page 7]

Internet-Draft           RDNM with Optical ACTN               April 2026


   adoption of emerging ACTN-based abstraction and control techniques.

   This document studies the RDNM requirements in the context of ACTN
   functional components.  It analyses the ACTN interfaces from a
   management operations perspective.  It identifies suitable IETF data
   models that meet RDNM requirements that can be utilised in the ACTN
   architecture to support optical transport networks.  Gaps and
   requirements are identified where necessary so additional models may
   be developed.

2.  Extending the ACTN Architecture to Include RDNM

   Figure 1 shows the ACTN architecture from [RFC8453] enhanced to
   provide RDNM support.  The Customer Network Controller (CNC), Multi-
   Domain Service Coordinator (MDSC), and Provisioning Network
   Controller (PNC) are functional components of ACTN, as described in
   RFC 8453.  There are two ACTN interfaces between the components: the
   CNC-MDSC Interface (CMI) and the MDSC-PNC Interface (MPI).  In ACTN,
   the CMI and MPI are realised using a combination of IETF YANG data
   models.


                 +--------------------------------------+
                 | OSS                                  |
                 |                                      |
                 |   +------+    +------+     +------+  |
                 |   | FM   |    | PM   |     |   RM |  |
                 |   |   ...|....|......|.....|..    |  |
                 |   |   :  |    |      |     | :    |  |
                 |   |   :  |    |      | CNC | :    |  |
                 |   |   :..|....|......|.....|.:    |  |
                 |   |      |    |      |  |  |      |  |
                 |   +------+    +------+  |  +------+  |
                 |    |   |          |     |       |    |
                 +----|---|----------|-----|-------|----+
                      |   |          |     |       |
    Boundary          |   |          |     | CMI   |
    between           |   |          |     |       |
    Customer &  ======|===|==========|=====|=======|======
    Network           |   |          |     |       |
    Operator          |   |          |     |       |
                      | +------------------------+ |
                      | |         MSDC           | |
                      | +------------------------+ |
                      |                    |       |
                      |            MPI     |       |
                      |        (ACTN/RDNM) |       |
                      |                    |       |



Tan, et al.              Expires 20 October 2026                [Page 8]

Internet-Draft           RDNM with Optical ACTN               April 2026


                  +-----------------------------------+
                  |  Domain                           |
                  |  Controller                       |
                  |                                   |
                  |       +------------+              |
                  |       | NMS/EMS    |              |
                  |       |        .............      |
                  |       |        :   |       :      |
                  |       |        :   |  PNC  :      |
                  |       |        :...|.......:      |
                  |       |            |              |
                  |       +------------+              |
                  |                                   |
                  +-----------------------------------+
                               /            |
                              /             |
                          ---------         |
                         (         )        |
                        ( Physical  )       |
                         ( Network )    ---------
                          ---------    (         )
                                      ( Physical  )
                                       ( Network )
                                        ---------


             Figure 1: The ACTN Architecture Enhanced for RDNM

   Figure 1 shows the ACTN functional components as described in
   [RFC8453], but also introduces some common management system
   components.  The OSS is the overarching management component that the
   operator uses to coordinate customers, services, and the network, and
   to apply policies across the network.  It contains a Fault Management
   (FM) component, a Policy Management (PM) component, and a Resource
   Management (RM) component.  The NMS allows an operator to manage a
   network or set of network elements as a single unit.  At the same
   time, the Element Management System (EMS) applies configuration and
   management to individual network elements.

   As described in [RFC8453], the function of the PNC may be provided by
   an NMS or an EMS.  Thus, Figure 1 shows the PNC overlapping with the
   NMS/EMS.  To avoid confusion between the three possible components
   (NMS, EMS, PNC) that might all be used to operate the devices in the
   network, this document groups all of their function together and uses
   the term Domain Controller (a term used in [RFC7426] and [RFC8309]).






Tan, et al.              Expires 20 October 2026                [Page 9]

Internet-Draft           RDNM with Optical ACTN               April 2026


   In a conventional management system, the OSS uses an interface with
   the Domain Controller to exchange FCAPS information.  This interface
   has previously been based on CORBA, MTOSI, and XML.  Furthermore, in
   an ACTN system, the OSS is likely the point of origin for policy
   instructions that guide the MDSC in orchestrating customer service
   requests and configuring the network.  Thus, the CNC functions form
   part of the OSS, overlapping with the FM, PM, and RM functional
   components.

   In [RFC8453] the MPI is used by the MDSC to instruct the PNCs about
   how the network must be configured to deliver the customers'
   services.  The MPI also reports to the MDSC on the status of
   provisioning commands and the availability of network resources.
   However, up to now, the MDSC has had no visibility into the majority
   of the FCAPS functions and has, therefore, had limited reactive and
   proactive abilities.

   Instead of only using abstracted Tunnel and Topology YANG models, the
   capability to support network inventory and device models is
   required, facilitating more detailed modeling and configuration
   management of network resource information.

   This document examines how the MPI may be enhanced with extensions
   that utilise current YANG models, such as inventory, as well as with
   future YANG-based data models to deliver extensions that provide
   RESTful RDNM support.

   Note that many operators are now moving away from traditional Fault
   Management, which was slow and costly, toward a concept of Network
   Observability.  This approach emphasises comprehensive data
   collection, monitoring, and semantic context, enabling actionable
   insights and automated responses rather than merely flagging faults
   for operator investigation.

3.  Functionality at the MPI

   This section describes the MPI as specified before the addition of
   RDNM capabilities.

3.1.  Data Models at the MPI

   Figure 2 lists the data models that can be used at the MPI for
   abstraction and control of underlying optical networks.








Tan, et al.              Expires 20 October 2026               [Page 10]

Internet-Draft           RDNM with Optical ACTN               April 2026


Category | Data Model                | Document
---------+---------------------------+----------------------------------
Topology | ietf-network              | RFC 8345
         +---------------------------+----------------------------------
         | ietf-network-topology     | RFC 8345
         +---------------------------+----------------------------------
         | ietf-te-topology          | RFC 8795
         +---------------------------+----------------------------------
         | ietf-wson-topology        | RFC 9094
         +---------------------------+----------------------------------
         | ietf-otn-topology         | draft-ietf-ccamp-otn-topo-yang
         +---------------------------+----------------------------------
         | ietf-flex-grid-topology   | draft-ietf-ccamp-flexigrid-yang
         +---------------------------+----------------------------------
         | ietf-optical-impairment- | draft-ietf-ccamp-optical-
         |                  topology |          impairment-topology-yang
---------+---------------------------+----------------------------------
Tunnel   | ietf-te                   | draft-ietf-teas-yang-te
         +---------------------------+----------------------------------
         | ietf-wson-tunnel          | draft-ietf-ccamp-wson-tunnel-
         |                           |                             model
         +---------------------------+----------------------------------
         | ietf-otn-tunnel           | draft-ietf-ccamp-otn-tunnel-model
         +---------------------------+----------------------------------
         | ietf-flexi-grid-media-    | draft-ietf-ccamp-flexigrid-
         |                   channel |                media-channel-yang
---------+---------------------------+----------------------------------


                    Figure 2: ACTN MPI YANG Models

3.2.  Abstraction and Control at the MPI

   The abstraction of TE modeling is described in Section 3 of
   [RFC8795].  The major objects that are modeled include TE topology,
   TE node, TE link, TE Link Termination Point (LTP), TE Tunnel
   Termination Point (TTP).  Also included in the modeling are
   transitional TE links, the TE node connectivity matrix, and the TTP
   Local Link Connectivity List which is used to describe the
   multiplexing relationship of links.  These TE concepts are generic,
   but they are also specifically applicable within an optical network.
   The MPI deals in abstracted TE network concepts and so can be
   realised using the YANG models listed in Section 3.1 to expose the
   modeled TE objects that can be enhanced using YANG model
   augmentations to make them specific to optical technologies.






Tan, et al.              Expires 20 October 2026               [Page 11]

Internet-Draft           RDNM with Optical ACTN               April 2026


   Generic TE topology models are defined in [RFC8345] and [RFC8795].
   Specific extensions to the abstract TE model for optical networks are
   provided in a series of documents ([RFC9094],
   [I-D.ietf-ccamp-otn-topo-yang], [I-D.ietf-ccamp-flexigrid-yang], and
   [I-D.ietf-ccamp-optical-impairment-topology-yang]).  This list of
   documents arises because the different optical network technologies
   demand different models for the varying characteristics of the
   equipment.

   Tunnels are a fundamental component of TE, and a generic TE tunnel
   YANG model is found in [I-D.ietf-teas-yang-te].  Specific extensions
   to the generic TE tunnel model for optical networks are provided in a
   series of documents ([I-D.ietf-ccamp-wson-tunnel-model],
   [I-D.ietf-ccamp-otn-tunnel-model], and
   [I-D.ietf-ccamp-flexigrid-media-channel-yang]).  Again, there are
   multiple documents because of the different optical network
   technologies.

4.  Introduction to FCAPS

   The full set of building blocks of FCAPS are Fault, Configuration,
   Accounting, Performance, and Security, but the important functions
   for integration within an ACTN system are Configuration, Alarm
   Management, and Performance Management.  All three of these functions
   are underpinned by Inventory Management.

   *  Inventory Management describes all objects involved in the
      network, including hardware resources (such as network elements,
      chassis, slots, boards, ports, optical modules, and cables, etc.)
      and logical resource objects used for service provisioning.

   *  The basic Configuration requirement in ACTN is to configure end-
      to- end paths across the transport network based on user
      requirements.

   *  Alarm Management refers to how the system enables and disables
      alarm reporting, collects alarm information, and processes that
      information to relate it to the connections that are managed by
      ACTN.  When a network is running, the Domain Manager collects
      alarm information from devices or processes connection-related
      alarms and reports them to the operator's OSS so that operations
      and management engineers can detect and rectify network faults in
      a timely manner.  The main functionalities include alarm
      retrieval, alarm handling, and alarm control.

   *  Performance Monitoring enables engineers to collect and monitor
      performance data from certain physical devices or logical objects
      to identify the status of the network.  The interfaces of



Tan, et al.              Expires 20 October 2026               [Page 12]

Internet-Draft           RDNM with Optical ACTN               April 2026


      Performance Management include performance monitoring control,
      performance information retrieval, and threshold crossing alert
      control.

5.  Abstract Control and Rich-Detail Network Management for ACTN

   Abstract Control represents the high-level strategic view and
   objectives, while Rich-Detail Network Management represents the
   detailed operational tasks and activities that support the strategic
   objectives.  Both levels are important for effective management and
   control within the operator network.

   Abstract Control is often mapped to G.805 [G-805] objects.  An
   Abstract Control object can also be mapped to multiple Rich-Detail
   Network Management objects that enable the Abstract Control object.
   Therefore, we should not see these concepts as mutually exclusive,
   but instead as necessary approaches to be combined for holistic
   control and operational management of ACTN-based network
   infrastructures.

   In the context of ACTN, the MPI is both a concept and a set of
   mechanisms within ACTN that enable the interconnection of services
   across multiple domains or administrative boundaries.  The MPI
   addresses the challenge of interconnecting services across multiple
   administrative domains.  It provides a mechanism to coordinate and
   manage the service delivery between domains while ensuring end-to-end
   service continuity and quality.

   Section 2 emphasises the importance of finely configuring RDNM
   capabilities for the efficient operation and troubleshooting of ACTN-
   based services.  It is anticipated that these capabilities will
   necessitate detailed and precise network management functions.

5.1.  Abstract Control and Rich-Detail Network Management Functions for
      the MPI

   The Rich-Detail Network Management functions can be categorised as
   follows.  Several aspects of these functions already exist in the
   MDSC in the ACTN architecture, and are accessed via the MPI.  Other
   functions may be added to the MPI in the future by enhancing or
   augmenting existing optical network YANG models or by creating new
   models.

   *  Service Provisioning: This involves the detailed provisioning and
      activation of services.  This includes path computation,
      configuring service parameters, policy management, allocating
      resources, and ensuring proper service activation and
      deactivation.



Tan, et al.              Expires 20 October 2026               [Page 13]

Internet-Draft           RDNM with Optical ACTN               April 2026


   *  Network Performance Monitoring: This encompasses monitoring and
      analysing network performance.  It involves collecting and
      analysing performance metrics such as latency, jitter, packet
      loss, and throughput to identify and resolve performance issues
      promptly.

   *  Fault Detection and Alarm Management: This includes advanced fault
      detection mechanisms to identify and troubleshoot network issues
      quickly.  It involves monitoring network elements, analysing
      alarms and events, and performing fault localisation and isolation
      to expedite problem resolution.

   *  Security Management: This covers the management of security
      measures within the TE network.  It involves activities such as
      access control, authentication, encryption, intrusion detection,
      and vulnerability management to ensure network security and
      protect against threats.

   *  Service Level Agreement (SLA) Management: This involves tracking
      service performance against SLA targets, generating SLA reports,
      and taking corrective actions to meet or exceed customer
      expectations.

   *  Capacity Planning: This encompasses detailed planning activities
      to ensure optimal resource utilisation and to meet future demands.
      It involves analysing traffic patterns, forecasting capacity
      requirements, and implementing capacity expansion strategies.

5.2.  Rich-Detail Network Management Interfaces

   Several legacy Rich-Detail Network Management interfaces, such as
   CORBA, exist to facilitate the precise control and management of
   network elements and services.  These interfaces enable communication
   and interaction between different systems, devices, and management
   platforms:

   *  Command Line Interface (CLI)

   *  Simple Network Management Protocol (SNMP)

   *  Management system approaches such as CORBA, MTOSI, and XML

   New interfaces and data models have been developed that support Rich-
   Detail Network Management functions.  These models are written in
   YANG, and the interfaces use NETCONF and RESTCONF, the latter also
   providing RESTful API functions.





Tan, et al.              Expires 20 October 2026               [Page 14]

Internet-Draft           RDNM with Optical ACTN               April 2026


5.3.  Rich-Detail Network Management Data Models

   As noted in Section 5.1, new or enhanced data models may be required
   for Rich-Detail Network Management in ACTN-based optical networks.
   Figure 3 shows a functional architecture for YANG control in an ACTN
   system enhanced with RDNM.  The existing ACTN YANG models provide
   access to network devices through topology models that map to
   inventory and thus to configuration of network devices.  The old
   MTOSI approach provides access to inventory and device configuration.

   The RDNM additions to ACTN retrieve information from the inventory,
   including performance information viewed through the lens of
   topology.  They also allow direct manipulation of devices through
   configuration of inventory items in a mirror of the MTOSI function.
   Lastly, fault and alarm information generated from the inventory may
   be delivered directly to the fault management system or may be
   correlated before being reported as incidents.


                             ------------------------------
                            |        ACTN with RDNM        |
                             ------------------------------
                                 :    ^   :            ^
                                 :    :   :            :
                                 :    :   :            :
                       ----------:----:-  :            :
                      |          :    : | :            :
              MTOSI   | Topology :    : | :            :
                  \   |          :    : | :            :
                   \   ----------:----:-  :            :
                    \            :    :   :            :
                     \           v    :   v            :
     -------------    \---------------------     -------------
    |             |   |                     |   |             |
    | Performance |---|      Inventory      |---| Fault/Alarm |
    |             |   |                     |   |             |
     -------------     ---------------------\    -------------
                                |            \
                                |             \----------
                        ---------------       |          |
                       | Configuration |      | Security |
                        ---------------       |          |
                                |              ----------
                                |
                             Devices


                Figure 3: Functional Model of ACTN with RDNM



Tan, et al.              Expires 20 October 2026               [Page 15]

Internet-Draft           RDNM with Optical ACTN               April 2026


   [I-D.yu-ccamp-rdnm-yang] sets out a generic RDNM extension model,
   which augments the TE topology model for RDNM-specific purposes.  It
   is expected that layer-specific RDNM extensions will also be required
   in the future.

   Additional work in the IETF exists to provide optical resource
   monitoring, telemetry data, alarm and incident monitoring, inventory,
   life cycle management, service assurance, and asset management.  This
   existing IETF work includes:

   *  A YANG Data Model for Network Incident Management
      [I-D.ietf-nmop-network-incident-yang]

   *  A YANG Data Model for Network Inventory
      [I-D.ietf-ivy-network-inventory-yang]

   *  A Network Inventory Topology Model
      [I-D.ietf-ivy-network-inventory-topology]

   *  Service Assurance for Intent-based Networking Architecture
      [RFC9417]

   *  YANG Modules for Service Assurance [RFC9418]

   *  A Data Manifest for Contextualized Telemetry Data
      [I-D.ietf-opsawg-collected-data-manifest]

   *  Asset Lifecycle Management and Operations Problem Statement
      [I-D.palmero-ivy-ps-almo]

   *  Data Model for Asset Lifecycle Management and Operations
      [I-D.palmero-ivy-dmalmo]

   *  A YANG Data Model for Optical Resource Performance Monitoring
      [I-D.yu-ccamp-optical-resource-pm-yang]

   *  A YANG model to manage the optical interface parameters for an
      external transponder in a WDM network
      [I-D.ietf-ccamp-dwdm-if-param-yang]

   *  A YANG Data Model for Client Signal Performance Monitoring
      [I-D.zheng-ccamp-client-pm-yang]

   Further work on this document will add to this list of IETF YANG data
   models that provide Rich-Detail Network Management functionality, in
   the context of ACTN for optical networks and with particular
   attention to the MPI.




Tan, et al.              Expires 20 October 2026               [Page 16]

Internet-Draft           RDNM with Optical ACTN               April 2026


5.4.  Rich-Detail Network Management Example

   Editor's note: An example of Rich-Detail Network Management of an
   optical network using the ACTN architecture will be provided in a
   future version of this document.

6.  Manageability Considerations

   A conventional approach to management of optical networks using MTOSI
   typically employs inventory and device configuration models.
   However, the current ACTN YANG models offer an innovative pathway to
   interact with network devices.  They achieve this by employing
   topology models that correlate directly with both inventory and
   device configurations.  To fully leverage the management
   infrastructure through RDNM interfaces, it is essential to develop
   additional resource data models.  These enhancements to ACTN,
   specifically for optical RDNM, are anticipated to be crucial for
   extracting comprehensive information from the inventory, including
   performance metrics.  Such integration would enable a comprehensive
   perspective on network performance and facilitate direct device
   manipulations by aligning inventory configurations with the
   foundational principles of MTOSI.

   In addressing network fault issues, the system will leverage alarm
   data produced by the network inventory assets.  This information
   might be directly fed into the RDNM system or undergo correlation
   before being flagged as incidents.  This process ensures efficient
   troubleshooting by pinpointing the exact nature and location of
   network anomalies.

   Moreover, security remains a paramount concern in any network as well
   as in the management of the network.  As such, this document
   dedicates Section 7 to security considerations, outlining several
   critical security requirements.  These guidelines are designed to
   safeguard the network environment, ensuring robust protection against
   potential threats and vulnerabilities.

7.  Security Considerations

   Security measures and protocol security must be applied to ensure the
   confidentiality, integrity, and availability of information and
   resources within the context of an ACTN RDNM-based system.

   Key aspects of ACTN RDNM security will require:







Tan, et al.              Expires 20 October 2026               [Page 17]

Internet-Draft           RDNM with Optical ACTN               April 2026


   *  Authentication: The process of verifying the identity of an ACTN
      user, system, or device.  Includes mechanisms to authenticate
      users and systems before allowing them to access sensitive
      resources or perform certain operations.

   *  Authorisation: Once a user or system is authenticated,
      authorisation determines what actions or resources they are
      allowed to access.  MTOSI security mechanisms define roles,
      permissions, and access controls to ensure that only authorised
      entities can perform specific tasks.

   *  Data Encryption: Encryption techniques may be used to protect
      sensitive data as it is transmitted over the management network.
      This prevents unauthorised access to or interception of
      information.

   *  Secure Communication Protocols: The use of secure communication
      protocols, such as HTTPS (HTTP over SSL/TLS) or other
      cryptographic protocols, ensures that data exchanged between ACTN
      components remains confidential and unmodified.

   *  Secure Data Storage: Security measures are put in place to protect
      data stored within the ACTN environment.  This includes encryption
      of stored inventory, device, and service data, access controls,
      and regular security audits.

   *  Auditing and Logging: This includes the capability to record and
      monitor ACTN-based activities within the management system.  Audit
      logs provide a record of who accessed what resources and when,
      which is crucial for investigating security incidents or
      compliance with regulations.

   *  Intrusion Detection and Prevention: Software systems and hardware
      devices may have mechanisms in place to detect and respond to
      unauthorised access attempts or suspicious activities.  Intrusion
      detection systems (IDS) and intrusion prevention systems (IPS) can
      play a role in ACTN-based security.

   *  Vulnerability Management: Regular security assessments and
      vulnerability scans help identify and address potential weaknesses
      in the ACTN environment.

   *  Security Policies and Procedures: Clear security policies and
      procedures should be established and communicated to all
      stakeholders.  This ensures that everyone understands their
      responsibilities in maintaining the security of the ACTN system.





Tan, et al.              Expires 20 October 2026               [Page 18]

Internet-Draft           RDNM with Optical ACTN               April 2026


   *  Incident Response: Security should include plans and procedures
      for responding to security incidents, including steps for
      containment, investigation, mitigation, and recovery.

   Overall, security is crucial for maintaining the integrity and
   reliability of ACTN RDNM operations and support systems, especially
   in an environment where sensitive customer data and critical network
   resources are involved.  It is expected that all IETF YANG documents
   include clear analysis of the security vulnerabilities associated
   with the YANG models they describe.

8.  IANA Considerations

   This document makes no requests for IANA action.

9.  Acknowledgements

   Thank you to Daniele Ceccarelli, Victor Lopez, Brad Peters, and Gyan
   Mishra for their observations and suggestions regarding this
   document.

10.  Informative References

   [CORBA]    Object Management Group, "Common Object Request Broker
              Architecture (CORBA) Component Model.", Standard OMG,
              March 2006, <https://www.omg.org/spec/CCM/>.

   [G-805]    International Telecommunication Union - Telecommunication
              Standardization Sector, "ITU-T G.805, Generic functional
              architecture of transport networks.", Recommendation ITU-T
              Recommendation G.805, 10 March 2001,
              <https://www.itu.int/rec/T-REC-G.805-200003-I/en>.

   [I-D.ietf-ccamp-dwdm-if-param-yang]
              Galimberti, G., Hiremagalur, D., Grammel, G., Manzotti,
              R., and D. Breuer, "A YANG data model to manage
              configurable DWDM optical interfaces", Work in Progress,
              Internet-Draft, draft-ietf-ccamp-dwdm-if-param-yang-15, 2
              March 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-ccamp-dwdm-if-param-yang-15>.











Tan, et al.              Expires 20 October 2026               [Page 19]

Internet-Draft           RDNM with Optical ACTN               April 2026


   [I-D.ietf-ccamp-flexigrid-media-channel-yang]
              de Madrid, U. A., Burrero, D. P., King, D., Lopez, V.,
              Busi, I., de Dios, O. G., Lee, Y., and G. Galimberti, "A
              YANG Data Model for Flexi-Grid Media Channels", Work in
              Progress, Internet-Draft, draft-ietf-ccamp-flexigrid-
              media-channel-yang-04, 12 July 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              flexigrid-media-channel-yang-04>.

   [I-D.ietf-ccamp-flexigrid-yang]
              de Madrid, U. A., Burrero, D. P., King, D., Lee, Y., and
              H. Zheng, "A YANG Data Model for Flexi-Grid Optical
              Networks", Work in Progress, Internet-Draft, draft-ietf-
              ccamp-flexigrid-yang-19, 2 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              flexigrid-yang-19>.

   [I-D.ietf-ccamp-optical-impairment-topology-yang]
              Beller, D., Le Rouzic, E., Belotti, S., Galimberti, G.,
              and I. Busi, "A YANG Data Model for Optical Impairment-
              aware Topology", Work in Progress, Internet-Draft, draft-
              ietf-ccamp-optical-impairment-topology-yang-23, 27
              February 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ccamp-optical-impairment-topology-yang-23>.

   [I-D.ietf-ccamp-otn-topo-yang]
              Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. de
              Dios, "A YANG Data Model for Optical Transport Network
              Topology", Work in Progress, Internet-Draft, draft-ietf-
              ccamp-otn-topo-yang-20, 7 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              otn-topo-yang-20>.

   [I-D.ietf-ccamp-otn-tunnel-model]
              Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, "A
              YANG Data Model for Optical Transport Network (OTN)
              Tunnels and Label Switched Paths", Work in Progress,
              Internet-Draft, draft-ietf-ccamp-otn-tunnel-model-24, 1
              December 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ccamp-otn-tunnel-model-24>.

   [I-D.ietf-ccamp-wson-tunnel-model]
              Lee, Y., Zheng, H., Guo, A., Lopez, V., King, D., Yoon, B.
              Y., and R. Vilalta, "A Yang Data Model for WSON Tunnel",
              Work in Progress, Internet-Draft, draft-ietf-ccamp-wson-
              tunnel-model-09, 9 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              wson-tunnel-model-09>.



Tan, et al.              Expires 20 October 2026               [Page 20]

Internet-Draft           RDNM with Optical ACTN               April 2026


   [I-D.ietf-ivy-network-inventory-topology]
              Wu, B., Boucadair, M., Zhou, C., and Q. Wu, "A YANG
              Network Data Model for Inventory Topology Mapping", Work
              in Progress, Internet-Draft, draft-ietf-ivy-network-
              inventory-topology-06, 28 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-
              network-inventory-topology-06>.

   [I-D.ietf-ivy-network-inventory-yang]
              Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P.
              Bedard, "A Base YANG Data Model for Network Inventory",
              Work in Progress, Internet-Draft, draft-ietf-ivy-network-
              inventory-yang-14, 5 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-
              network-inventory-yang-14>.

   [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-08, 13 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
              network-incident-yang-08>.

   [I-D.ietf-nmop-terminology]
              Davis, N., Farrel, A., Graf, T., Wu, Q., and C. Yu, "Some
              Key Terms for Network Fault and Problem Management", Work
              in Progress, Internet-Draft, draft-ietf-nmop-terminology-
              23, 18 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
              terminology-23>.

   [I-D.ietf-opsawg-collected-data-manifest]
              Claise, B., Quilbeuf, J., Lopez, D., Martinez-Casanueva,
              I. D., and T. Graf, "A Data Manifest for Contextualized
              Telemetry Data", Work in Progress, Internet-Draft, draft-
              ietf-opsawg-collected-data-manifest-10, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              collected-data-manifest-10>.

   [I-D.ietf-opsawg-oam-characterization]
              Pignataro, C., Farrel, A., and T. Mizrahi, "Guidelines for
              Characterizing the Term "OAM"", Work in Progress,
              Internet-Draft, draft-ietf-opsawg-oam-characterization-17,
              28 January 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-opsawg-oam-characterization-17>.





Tan, et al.              Expires 20 October 2026               [Page 21]

Internet-Draft           RDNM with Optical ACTN               April 2026


   [I-D.ietf-teas-yang-te]
              Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
              Bryskin, "A YANG Data Model for Traffic Engineering
              Tunnels, Label Switched Paths, and Interfaces", Work in
              Progress, Internet-Draft, draft-ietf-teas-yang-te-44, 26
              March 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-teas-yang-te-44>.

   [I-D.palmero-ivy-dmalmo]
              Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D.
              Lopez, "Data Model for Asset Lifecycle Management and
              Operations", Work in Progress, Internet-Draft, draft-
              palmero-ivy-dmalmo-02, 8 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-palmero-ivy-
              dmalmo-02>.

   [I-D.palmero-ivy-ps-almo]
              Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D.
              Lopez, "Asset Lifecycle Management and Operations: A
              Problem Statement", Work in Progress, Internet-Draft,
              draft-palmero-ivy-ps-almo-02, 8 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-palmero-ivy-
              ps-almo-02>.

   [I-D.yu-ccamp-optical-resource-pm-yang]
              Yu, C., Peruzzini, F., Yanlei, Z., Busi, I., Guo, A.,
              Lopez, V., and XingZhao, "A YANG Data Model for Optical
              Resource Performance Monitoring", Work in Progress,
              Internet-Draft, draft-yu-ccamp-optical-resource-pm-yang-
              03, 4 March 2024, <https://datatracker.ietf.org/doc/html/
              draft-yu-ccamp-optical-resource-pm-yang-03>.

   [I-D.yu-ccamp-rdnm-yang]
              Yu, C., XingZhao, Tan, Davis, N., and D. King, "YANG Data
              Models for Transport Network Rich-Detail Network
              Management (RDNM)", Work in Progress, Internet-Draft,
              draft-yu-ccamp-rdnm-yang-01, 10 April 2025,
              <https://datatracker.ietf.org/doc/html/draft-yu-ccamp-
              rdnm-yang-01>.

   [I-D.zheng-ccamp-client-pm-yang]
              Yu, C., Zheng, H., Busi, I., Yanlei, Z., Lopez, V., and O.
              G. de Dios, "A YANG Data Model for Client Signal
              Performance Monitoring", Work in Progress, Internet-Draft,
              draft-zheng-ccamp-client-pm-yang-14, 26 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-zheng-ccamp-
              client-pm-yang-14>.




Tan, et al.              Expires 20 October 2026               [Page 22]

Internet-Draft           RDNM with Optical ACTN               April 2026


   [M-3041]   International Telecommunication Union - Telecommunication
              Standardization Sector, "ITU-T M.3041, Framework of smart
              operation, management and maintenance.",
              Recommendation ITU-T Recommendation M.3041, 13 February
              2020, <https://www.itu.int/rec/T-REC-M.3041-202002-I/en>.

   [M-3060]   International Telecommunication Union - Telecommunication
              Standardization Sector, "ITU-T M.3060, Principles for the
              Management of Next Generation Networks.",
              Recommendation ITU-T Recommendation M.3060/Y.2401, 22
              March 2006,
              <https://www.itu.int/rec/T-REC-M.3060-200603-I/en>.

   [MTOSI]    TeleManagement Forum (TM Forum), "The Multi-Technology
              Operations System Interface.", Web page TM Forum,
              <https://www.tmforum.org/mtosi/>.

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
              Acronym in the IETF", BCP 161, RFC 6291,
              DOI 10.17487/RFC6291, June 2011,
              <https://www.rfc-editor.org/info/rfc6291>.

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
              Defined Networking (SDN): Layers and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/info/rfc7426>.

   [RFC8309]  Wu, Q., Liu, W., and A. Farrel, "Service Models
              Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
              <https://www.rfc-editor.org/info/rfc8309>.

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

   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
              Abstraction and Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/info/rfc8453>.




Tan, et al.              Expires 20 October 2026               [Page 23]

Internet-Draft           RDNM with Optical ACTN               April 2026


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

   [RFC9094]  Zheng, H., Lee, Y., Guo, A., Lopez, V., and D. King, "A
              YANG Data Model for Wavelength Switched Optical Networks
              (WSONs)", RFC 9094, DOI 10.17487/RFC9094, August 2021,
              <https://www.rfc-editor.org/info/rfc9094>.

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

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

   [RFC9940]  Davis, N., Ed., Farrel, A., Ed., Graf, T., Wu, Q., and C.
              Yu, "Some Key Terms for Network Fault and Problem
              Management", RFC 9940, DOI 10.17487/RFC9940, April 2026,
              <https://www.rfc-editor.org/info/rfc9940>.

Authors' Addresses

   Yinxia Tan
   China Unicom
   Email: tanyx11@chinaunicom.cn


   Xing Zhao
   CAICT
   Email: zhaoxing@caict.ac.cn


   Chaode Yu
   Huawei Technologies
   Email: yuchaode@huawei.com






Tan, et al.              Expires 20 October 2026               [Page 24]

Internet-Draft           RDNM with Optical ACTN               April 2026


   Daniel King (editor)
   Old Dog Consulting
   Email: daniel@olddog.co.uk


   Adrian Farrel (editor)
   Old Dog Consulting
   Email: adrian@olddog.co.uk











































Tan, et al.              Expires 20 October 2026               [Page 25]
