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, . 7.2. Informative References [ETSI-GR-NFV-SOL-017] "Report on protocol and data model solutions for Multi- site Connectivity Services", May 2021, . [ETSI-GS-NFV-IFA-032] "Interface and Information Model Specification for Multi- Site Connectivity Services", May 2021, . [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, . 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, . [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, . [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, . [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, . [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, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [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, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . 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, . [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm Management", RFC 8632, DOI 10.17487/RFC8632, September 2019, . [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, . [RFC8975] Kuhn, N., Ed. and E. Lochin, Ed., "Network Coding for Satellite Systems", RFC 8975, DOI 10.17487/RFC8975, January 2021, . [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, . [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, . [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, . [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, . 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]