



onions                                                            C. Xie
Internet-Draft                                             China Telecom
Intended status: Informational                                     B. Wu
Expires: 8 January 2026                                           Huawei
                                                               N. Cocker
                                                                 Red Hat
                                                               L. Dunbar
                                                               Futurewei
                                                             7 July 2025


   Applicability of IETF-Defined Service and Network Data Models for
                     Telcocloud Network Management
               draft-xwcd-neotec-ns-models-telcocloud-00

Abstract

   This document describes how the various data models that are produced
   in the IETF can be combined in the context of Telco Cloud service
   delivery.

   Specifically, this document describes the communication of a Network
   Orchestrator and Cloud orchestrator for the realization of optimized
   Telco Cloud services to implement inter-dc reachability and
   connectivity services.

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 8 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Xie, et al.              Expires 8 January 2026                 [Page 1]

Internet-Draft        Telcocloud Network Management            July 2025


   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
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  A Reference Architecture of Telco Cloud Network
           Coordination  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Telco Cloud Service Requirements  . . . . . . . . . . . . . .   6
     4.1.  Optimized Scenarios of Telco Cloud Service Placement  . .   6
       4.1.1.  Example of Overlay Network and Cloud Service
               Placement . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.2.  More Examples to Add  . . . . . . . . . . . . . . . .  11
     4.2.  Optimized Scenarios of Telco Cloud Service Assurance  . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The IETF has produced several YANG data models that are instrumental
   for automating the provisioning and delivery of connectivity
   services.  An overview of these data models and a framework that
   describes how these various modules can be used together are
   described in [RFC8969].

   This document adopts the rationale of [RFC8969], but with a focus on
   the network coordination with Telco Cloud services.

   The document also identifies some gaps related to existing models.

   The document outlines an architecture and communication process of
   Network Orchestrators and Cloud orchestrators.






Xie, et al.              Expires 8 January 2026                 [Page 2]

Internet-Draft        Telcocloud Network Management            July 2025


2.  Conventions and Definitions

   This document assumes that the reader is familiar with the contents
   of [RFC6241], [RFC7950], and [RFC8309] as it uses terms from those
   RFCs.

   This document uses the term "network model" as defined in Section 2.1
   of [RFC8969].

3.  A Reference Architecture of Telco Cloud Network Coordination

   In some implementation, Cloud Orchestrator and Network Orchestrator
   are only associated with their own respective services.  That is,
   Cloud Orchestrator is responsible for data center (DC) services, such
   as application, compute, and/or storage services within the DC, while
   network Orchestrator plans and deploys connections based on planed
   inter-DC traffic demands.

   In certain scenarios, such as the [ETSI-GS-NFV-IFA-032] cross-site
   connectivity service interfaces definition, to support cloud-based
   cross-data center (DC) scaling, the NFV cloud platform can leverage
   network-exposed API interfaces to dynamically collect underlay WAN
   network status and establish/update inter-DC connections.  The
   architecture option is shown in the figure below.

        +----------------+                     +--------------------+
        | Cloud          |                     |Network Orchestrator|
        | Orchestrator   |<------------------->|                    |
        |( Telco Cloud   | IETF Service&Network|(Provider Network   |
        | Orchestration) |   Data models/API   |  Orchestration)    |
        +----------------+                     +--------------------+
                       |                          |
                       |                          |
                       |                          |
       +---------------|-+                      +-|---------------+
       | +--+          v |                      | v               |
       | |NF+   +----+ .1|    192.0.2.0/31      |.0+--+           |
       | +--+...+DCGW+-----------------------  ----+PE|           |
       |+---+   +----+   |      VLAN 100        |  +--+           |
       ||APP|            |                      |                 |
       |+---+            |                      |     Provider    |
       |  DC Network     |                      |     Network     |
       +-----------------+                      +-----------------+
                      |----------- AC -------  ----|


      Legend: DCGW: DC Gateway




Xie, et al.              Expires 8 January 2026                 [Page 3]

Internet-Draft        Telcocloud Network Management            July 2025


     Figure 1: Coordination of Network Resources for the Cloud Service
                                Provisioning

   This NFV cloud architecture option implies that the Cloud
   Orchestrator operates with network-awareness.  The Network
   Orchestrator exposes the interfaces to provide pre-planned bandwidth
   and dynamic connections.  The Cloud Orchestrator can then dynamically
   control and manage the capacity and network connections between WANs
   of inter-DC.  As suggested in [ETSI-GR-NFV-SOL-017], The candidate
   IETF interfaces between Network Orchestrator and Cloud Orchestrator
   are outlined in the table below:

    +======+==============+===========================================+
    |Number| Network      | IETF YANG Models                          |
    |      | Function     |                                           |
    |      | Requirements |                                           |
    +======+==============+===========================================+
    |1     | Multi-site   | - L3SM [RFC8299]                          |
    |      | Connectivity | - L3NM [RFC9182]                          |
    |      |              | - L2SM [RFC8466]                          |
    |      |              | - L2NM [RFC9291]                          |
    |      |              | - RFC9543 NSS YANG Model                  |
    |      |              | - I-D.ietf-teas-ietf-network-slice-nbi    |
    |      |              | (https://datatracker.ietf.org/doc/I-      |
    |      |              | D.ietf-teas-ietf-network-slice-nbi/)      |
    |      |              | - AC Service YANG Model I-D.ietf-opsawg-  |
    |      |              | teas-attachment-circuit                   |
    |      |              | (https://datatracker.ietf.org/doc/I-      |
    |      |              | D.ietf-opsawg-teas-attachment-circuit/)   |
    +------+--------------+-------------------------------------------+
    |2     | Capacity     | - Service Attachment Point [RFC9408]      |
    |      | Management   | - TE Service Mapping                      |
    |      |              | [I-D.ietf-teas-te-service-mapping-yang]   |
    |      |              | - TE Topology [RFC8975]                   |
    |      |              | - TE Tunnel [I-D.ietf-teas-yang-te]       |
    |      |              | - SR Policy                               |
    |      |              | [I-D.ietf-spring-sr-policy-yang]          |
    +------+--------------+-------------------------------------------+
    |3     | Fault        | - Alarm Management [RFC8632]              |
    |      | Management   |                                           |
    +------+--------------+-------------------------------------------+
    |4     | Performance  | - Network and VPN Service PM [RFC9375]    |
    |      | Management   |                                           |
    +------+--------------+-------------------------------------------+

                                  Table 1





Xie, et al.              Expires 8 January 2026                 [Page 4]

Internet-Draft        Telcocloud Network Management            July 2025


   However, this NFVO architecture option cannot meet the emerging needs
   of telecom cloud applications because it is difficult to plan
   bandwidth between large-scale edge DCs and enterprise sites.  For
   example, AI-based video analysis and AI-driven knowledge reasoning
   will be deployed in edge data centers, which are characterized by a
   large number of deployments and significant variations in resource
   capabilities.  Combined with the diversity of enterprise sites, the
   new telecom cloud needs fast, private, and reliable connections
   between site-to-site, site-to-cloud, or cloud-to-cloud endpoints.

   A potential alternative architecture option involves centralized
   scheduling of cloud and network resources to coordinate their
   integration, enabling rapid deployment of network services and
   applications such as SD-WAN, SASE, and other edge cloud services.
   This approach ensures agile allocation of cloud resources and
   optimization of WAN network resources to meet dynamic demand.

                      +----------------------------+
                      | Customer Service Requester |
                      +----------------------------+
                                     |
                             Service | (e.g.Edge Cloud services,
                                API  |        SD-WANs,SASE)
                                     |
                                     |
                 +-----------------------------------------+
                 |    Telco Super Service Orchestrator     |
                 +-------+----------------------+----------+
                         |                      |
                         |Network API           |Cloud API
            +------------+----------+           |
            |  Network Orchestrator |     +-----+-------+
            +------------+----------+     |    Cloud    |
                Network  |                | Orchestrator|
                YANG     |                |             |
                Model    |                +-----+-------+
            +------------+----------+           |
            |  Network Controller   |           |
            | (Overlay & Underlay)  |           |
            +-----------------------+           |
                         |                      |
                 Device  |               +------+------+
                 Models  |               |    DC 1     |
                         |               |    +-------------+
                         |               +----|    DC-N     |
          --------------------------          |             |
                   WAN  Network               +-------------+




Xie, et al.              Expires 8 January 2026                 [Page 5]

Internet-Draft        Telcocloud Network Management            July 2025


    Figure 2: Alternative Architecture of the Cloud Service Provisioning

   This proposed telco cloud reference architecture is an open framework
   to allow for multiple vendor Network Orchestrators and multiple
   vendor Cloud Orchestrators.  The goal is to enable standard data
   models or APIs to provide those services.

4.  Telco Cloud Service Requirements

4.1.  Optimized Scenarios of Telco Cloud Service Placement

4.1.1.  Example of Overlay Network and Cloud Service Placement

   The diagram below illustrates a telco cloud network example
   connecting multiple data centers (DCs) and enterprise CEs.  Multiple
   data centers are shown, each potentially hosting different services
   or applications.  For instance, DC-1 is directly linked to gateway
   GW2A and GW2B, suggesting it may host critical applications or
   services that require high availability.  Various DC gateways are
   deployed to manage traffic flow towards Data Centers or Application
   instances.  Two CE1 devices are connected to PE5A and PE5B
   respectively, indicating the start points for customer traffic
   entering the provider's network.  There are several Provider Edge
   devices (PE5A, PE5B, etc.) which serve as entry and exit points for
   traffic moving between the customer and the provider's network.  The
   Border routers (BRs) facilitates the transfer of data across
   different parts of the network.  They connect the access/aggregation
   layer to the core network.























Xie, et al.              Expires 8 January 2026                 [Page 6]

Internet-Draft        Telcocloud Network Management            July 2025


             +-----------------+     +-----------------+
             |                 |     |                 |
+---+       +----+             |     |                 |
|CE1+-------|PE5A|             |     |                 |
+---+       +----+             |     |                 |
             |                 |     |                 |
             |                 |     |                 |  +------DC 1 ---+
             |                 |     |                 |  |              |
+---+       +----+         +----+   +----+         +---++ |+----+        |
|CE2+-------|PE5B|         |BR2A|---|BR1A|         |PE1A|-+|GW2A|        |
+---+       +----+         +----+   +----+         +----+ |+----+        |
             |    Access/Agg   |     |     Core        |  |      +------+|
             |                 |     |                 |  |      |APP A ||
+--------+   |     Network     |     |     Network     |  |      +------+|
|        |  +----+         +----+   +----+         +----+ |+----+        |
| DC-4   |--|PE4A|         |BR2B|---|BR1B|         |PE1B|-+|GW2B|        |
|        |  +----+         +----+   +----+         +----+ |+----+        |
+--------+   |                 |     |                 |  +--------------+
             |                 |     |                 |
+--------+   |                 |     |                 |
|        |  +----+             |     |                 |
| DC-5   |--|PE4B|             |     |                 |
|        |  +----+             |     |                 |
+--------+   |   +----+ +----+ |     | +----+  +----+  |
             +---|PE3A|-|PE3B|-+     +-|PE2A|--|PE2B|--+
                 +-+--+ +-+--+         +-+--+  +--+-+
                   |      |              |        |
            +------+------+------+  +----+--------+------+
            |    +-+--+ +-+--+   |  |  +-+--+  +--+-+    |
            |    |GW1A| |GW1B|   |     |GW3A|  |GW3B|    |
            |    +----+ +----+   |  |  +----+  +----+    |
            |                    |  |                    |
            |                    |  |                    |
            |                    |  |                    |
            |  +------+ +------+ |  |                    |
            |  |vCPE  | |APP A | |  |                    |
            |  +------+ +------+ |  |                    |
            |                    |  |                    |
            +---------DC-3-------+  +-------DC-2---------+
Legend: GW: DC Gateway

  Figure 3: Coordination of Network Resources for the Cloud Service
                             Provisioning








Xie, et al.              Expires 8 January 2026                 [Page 7]

Internet-Draft        Telcocloud Network Management            July 2025


   To create services across DCs like optimized service placement,
   generic API calls are needed.  A typical usage is to use Restful APIs
   of Cloud Orchestrator and Network Orchestrator and used by the Super
   Orchestrator to provision the inter-DC services connections and also
   applications.

   When deploying cross-DC cloud services, it is assumed that the Super
   Orchestrator has access to the DC and network connectivity topology
   (e.g. TE Topology [RFC8975]), as well as centralized resource
   information for both the DCs and the network.  Some standard network
   inventory interfaces are available.  For example, the Service
   Attachment Points (SAPs) [RFC9408] or ACs
   [I-D.ietf-opsawg-teas-attachment-circuit] can obtain the AC/Bearer
   information of the PE, which suggests that the private line service
   provisioning resource resources on the network side, but there is no
   cloud DC service provisioning resource information, such as CPU, GPU,
   storage, and DC network information.  DC aware TE topology model
   [I-D.llc-teas-dc-aware-topo-model-04] defines YANG models about the
   information.  One API example is as below.

        GET /api/cloud/resources?type=compute&network&location=dc-3
        {
          "compute": {
            "vCPU": 100,
            "GPU": 2,
            "memory": "1280GB",
            "storage": "10TB",
            "instance_type": "large"
          },
          "network": {
            "availability": {
              "throughput": "10 Gbps",
              "latency": "<1ms",
              "packet_loss": "0.001%",
              "supported_protocols": ["VxLAN", "GRE"]
            },
            "subnets": [
              {
                "cidr": "10.1.0.0/24",
              }
            ],
          }
        }

                       Figure 4: Cloud Inventory API






Xie, et al.              Expires 8 January 2026                 [Page 8]

Internet-Draft        Telcocloud Network Management            July 2025


   The flowchart below gives an example of hospital applications are
   deployed and ensure efficient use of network connections for
   optimized data flow.

                      +-----------------------------+
                      |1 Super Orchestrator         |
                      |                             |
                      |   Requirement Analysis &    |
                      | Resource Allocation Decision|
                      |                             |
                      | Branch Data Transfer:       |
                      |Bandwidth 100Mbps,Latency<50ms
                      |Secure, AI Analysis          |
                      |                             |
                      |Select Edge DC and compute   |
                      |dedicated Line               |
                      +-----------------------------+
                                     |
                                     |
                                     |
                                     v
                      +-----------------------------+
                      |2   Cloud Orchestrator &     |
                      |    Network Orchestrator     |
                      |                             |
                      |   Application & Network     |
                      |   connections deployment    |
                      |   Center DC:AI training     |
                      |   Edge DC:AI inference      |
                      +-----------------------------+
                                      |
                                      |
                                      v
                      +-----------------------------+
                      |3 Super Orchestrator         |
                      |                             |
                      |   Validation and Monitoring |
                      |(Test Transmission Latency:  |
                      |48ms Check Data Integrity)   |
                      +-----------------------------+

                     Figure 5: Cloud Service Placement

   Here is a step-by-step breakdown of the flowchart with detailed
   explanations for each step:






Xie, et al.              Expires 8 January 2026                 [Page 9]

Internet-Draft        Telcocloud Network Management            July 2025


   1.  Step 1: Requirement Analysis: This is the first step where the
       Super Orchestrator gathers and analyzes requirements for branch
       data transfer.  Key Requirements are bandwidth must be at least
       100 Mbps, data must be transmitted over a private connectionbe,
       and support AI analysis. the Super Orchestrator also determines
       the optimal allocation of resources for data transfer.  Data will
       flow from the branch office to the center data center (DC).  A
       edge DC is selected as an intermediate hop.  A dedicated line of
       100 Mbps of bandwidth with redundant links and to the center and
       edge DC is needed.  Underlay Network Controllers may expose to
       Network Orchestrator s a set of network data models, such as the
       AC, L3SM [RFC8299], L3NM [RFC9182], L2SM [RFC8466], L2NM
       [RFC9291], RFC9543 NSS YANG Model
       [I-D.ietf-teas-ietf-network-slice-nbi-yang], Service Attachment
       Points (SAPs) [RFC9408], TE Service Mapping
       [I-D.ietf-teas-te-service-mapping-yang], TE Tunnel
       [I-D.ietf-teas-yang-te], or SR Policy
       [I-D.ietf-spring-sr-policy-yang].  Network Orchestrator can use
       these models to set up connections between the Provider Edge
       devices, and also customer facing ACs between CEs and PEs, DC-GWs
       and PEs.

   2.  Step 2: Application Instances Deployment and Parallel Network
       Connectivity: This step involves deploying AI at the center DC
       and the edge DC.  With request from Super Orchestrator, Cloud
       Orchestrator allocates resources, including GPU clusters and
       storage.  Also Network Orchestrator can configure PE.

   3.  Step 3: Validation and Monitoring: This step ensures that the
       service meets performance and reliability expectations.  Through
       the open interfaces, Super orchestrator can monitor status of
       cloud resources and WAN connections.  The open interfaces could
       be VPN PM [RFC9375] ,Alarm Management [RFC8632], or new service
       assurance models.

   The steps described above assume that Super Orchestrator can access
   both network and cloud resources to perform resource analysis and
   allocation.

4.1.1.1.  Example of Telco Cloud Service Creation Flow

   An example of service creation flow is as follows:









Xie, et al.              Expires 8 January 2026                [Page 10]

Internet-Draft        Telcocloud Network Management            July 2025


 +------------------+         +---------------+    +----------------+
 |Super Orchestrator|         | Cloud Orchestr|    |Network Orchestr|
 +------------------+         +---------------+    +----------------+
      |                               |                        |
      |                               |                        |
      |1.1 Create a cloud service     |                        |
      |------------------------------>|                        |
      |                               |                        |
      |                   +--------------------------+         |
      |                   |2.Deploy the cloud service|         |
      |                   +--------------------------+         |
      |                               |                        |
      |         1.2 Create a network service                   |
      |------------------------------------------------------->|
      |                               |                        |
      |                               |   +----------------------------+
      |                               |   |2.Deploy the network service|
      |                               | +------------------------------+
      | 3.Create cloud service response                        |
      |-------------------------------|                        |
      |                               |                        |
      |                               |                        |
      |         3. Create Network service response             |
      |--------------------------------------------------------|
      |                               |                        |
      |                               |                        |
      |                               |                        |
      | 4. Subscribe for cloud performance metric              |
      |------------------------------>|                        |
      |                               |                        |
      |             5.Subscribe for network performance metric |
      |------------------------------------------------------->|
      |                               |                        |
 +------------------------+           |                        |
 |                        |           |                        |
 |5.Continuous monitoring |           |                        |
 +------------------------+           |                        |
      |                               |                        |
      |                               |                        |

                   Figure 6: Cloud Service Creation

4.1.2.  More Examples to Add

4.2.  Optimized Scenarios of Telco Cloud Service Assurance

   A scaling example is to add.




Xie, et al.              Expires 8 January 2026                [Page 11]

Internet-Draft        Telcocloud Network Management            July 2025


5.  Security Considerations

   TBC.

6.  IANA Considerations

   None.

7.  References

7.1.  Normative References

   [I-D.ietf-teas-ietf-network-slice-nbi-yang]
              Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
              "A YANG Data Model for the RFC 9543 Network Slice
              Service", Work in Progress, Internet-Draft, draft-ietf-
              teas-ietf-network-slice-nbi-yang-25, 9 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              ietf-network-slice-nbi-yang-25>.

7.2.  Informative References

   [ETSI-GR-NFV-SOL-017]
              "Report on protocol and data model solutions for Multi-
              site Connectivity Services", May 2021,
              <https://www.etsi.org/deliver/etsi_gr/NFV-
              SOL/001_099/017/03.03.01_60/gr_NFV-SOL017v030301p.pdf>.

   [ETSI-GS-NFV-IFA-032]
              "Interface and Information Model Specification for Multi-
              Site Connectivity Services", May 2021,
              <https://www.etsi.org/deliver/etsi_gs/nfv-
              ifa/001_099/032/04.02.01_60/gs_nfv-ifa032v040201p.pdf>.

   [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-
              20, 23 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              teas-attachment-circuit-20>.









Xie, et al.              Expires 8 January 2026                [Page 12]

Internet-Draft        Telcocloud Network Management            July 2025


   [I-D.ietf-spring-sr-policy-yang]
              Raza, S. K., Saleh, T., Zhuang, S., Voyer, D., Durrani,
              M., Matsushima, S., and V. P. Beeram, "YANG Data Model for
              Segment Routing Policy", Work in Progress, Internet-Draft,
              draft-ietf-spring-sr-policy-yang-05, 25 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-policy-yang-05>.

   [I-D.ietf-teas-te-service-mapping-yang]
              Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D.,
              and J. Tantsura, "Traffic Engineering (TE) and Service
              Mapping YANG Data Model", Work in Progress, Internet-
              Draft, draft-ietf-teas-te-service-mapping-yang-17, 29
              January 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-teas-te-service-mapping-yang-17>.

   [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-38, 29
              May 2025, <https://datatracker.ietf.org/doc/html/draft-
              ietf-teas-yang-te-38>.

   [I-D.llc-teas-dc-aware-topo-model-04]
              Contreras, L. M. and X. Liu, "DC aware TE topology model",
              Work in Progress, Internet-Draft, draft-llc-teas-dc-aware-
              topo-model-04, 3 March 2025,
              <https://datatracker.ietf.org/doc/html/draft-llc-teas-dc-
              aware-topo-model-04>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/rfc/rfc6241>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7950>.

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

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



Xie, et al.              Expires 8 January 2026                [Page 13]

Internet-Draft        Telcocloud Network Management            July 2025


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

   [RFC8632]  Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm
              Management", RFC 8632, DOI 10.17487/RFC8632, September
              2019, <https://www.rfc-editor.org/rfc/rfc8632>.

   [RFC8969]  Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
              L. Geng, "A Framework for Automating Service and Network
              Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
              January 2021, <https://www.rfc-editor.org/rfc/rfc8969>.

   [RFC8975]  Kuhn, N., Ed. and E. Lochin, Ed., "Network Coding for
              Satellite Systems", RFC 8975, DOI 10.17487/RFC8975,
              January 2021, <https://www.rfc-editor.org/rfc/rfc8975>.

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

   [RFC9375]  Wu, B., Ed., Wu, Q., Ed., Boucadair, M., Ed., Gonzalez de
              Dios, O., and B. Wen, "A YANG Data Model for Network and
              VPN Service Performance Monitoring", RFC 9375,
              DOI 10.17487/RFC9375, April 2023,
              <https://www.rfc-editor.org/rfc/rfc9375>.

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

Acknowledgments

   The authors wish to thank xxx and many others for their helpful
   comments and suggestions.

Contributors

   Jie Dong
   Huawei



Xie, et al.              Expires 8 January 2026                [Page 14]

Internet-Draft        Telcocloud Network Management            July 2025


   Email: jie.dong@huawei.com


Authors' Addresses

   Chongfeng Xie
   China Telecom
   Email: xiechf@chinatelecom.cn


   Bo Wu
   Huawei
   Email: lana.wubo@huawei.com


   Nabeel Cocker
   Red Hat
   Email: ncocker@redhat.com


   Linda Dunbar
   Futurewei
   Email: ldunbar@futurewei.com




























Xie, et al.              Expires 8 January 2026                [Page 15]
