Neotec (Network Operations in Telecom Cloud)
bofreq-xie-neotec-network-operations-in-telecom-cloud-13

Document Type Declined BOF request
Title Neotec (Network Operations in Telecom Cloud)
Last updated 2025-02-11
State Declined
Editors Jie Dong , Linda Dunbar , Chongfeng Xie
Responsible leadership Mahesh Jethanandani
Send notices to (None)
bofreq-xie-neotec-network-operations-in-telecom-cloud-13

Name

Neotec (Network Operations in Telecom Cloud)
Note: NetOps4Clouds (Network Operations for telecom Clouds) might be chosen for naming the potential WG after the BoF.

Description

The Neotec (NetOps4Clouds) initiative addresses two key challenges in Telecom Cloud operations:

1) Lack of real-time awareness in network controllers when Telecom Cloud services scale up or down.
2) Lack of standardized APIs (or YANG models) for network controllers to consume cloud telemetry from various cloud providers, such as AWS CloudWatch, Google Cloud Monitoring, and Azure Monitor.

Unlike public clouds, which rely on third-party networks, Telecom Clouds operate within a single administrative domain, where both the cloud infrastructure and network are owned and managed by the same entity. This unique integration allows for tighter coordination between cloud service scaling and network resource adjustments, yet existing network management systems lack real-time mechanisms to adapt dynamically to these changes.

Currently, network controllers operate with limited visibility into Telecom Cloud resource changes, leading to suboptimal routing, inefficient load balancing and UCMP policies, and degraded SLA performance for latency-sensitive services such as AI/ML workloads and video streaming. While existing solutions in IETF (e.g., TEAS, OPSAWG, CATS) address traffic engineering and service-aware routing, they do not integrate real-time cloud telemetry into network decision-making.

Neotec (NetOps4Clouds) seeks to bridge this gap by defining standardized interfaces that allow network controllers to consume cloud telemetry in a unified, vendor-neutral manner. By introducing a shim layer that translates cloud monitoring data into IETF-compliant formats (e.g., YANG, gRPC, NetConf APIs), Neotec (NetOps4Clouds) will enable real-time, automated network policy adjustments based on Telecom cloud service scaling events, without exposing internal cloud structures.

[Problem Statement]
Telecom Clouds integrate compute, storage, and networking to support latency-sensitive and bandwidth-intensive applications, such as 5G services, AI/ML workloads, and real-time media processing. Unlike public clouds that rely on third-party networks, Telecom Clouds are owned and managed by the same entity that operates the network, enabling end-to-end coordination between cloud infrastructure and network operations.

However, current network management systems lack real-time awareness of Telecom Cloud resource changes, leading to suboptimal performance, inefficient resource utilization, and difficulty meeting SLAs. Key challenges include:

-Lack of real-time network awareness of Telecom Cloud service scaling – When cloud services scale up or down, network controllers do not receive timely updates, preventing them from dynamically adjusting network load balancing policies and UCMP policies.
-No standardized APIs for cloud-to-network telemetry exchange – Cloud monitoring platforms such as AWS CloudWatch, Google Cloud Monitoring, and Azure Monitor expose resource metrics, but there are no standardized APIs for network controllers to consume and act on this data dynamically.
-Traffic optimization inefficiencies – AI/ML workloads, network slicing for 5G, and inter-cloud traffic generate dynamic traffic patterns that require real-time coordination between the network and cloud. Without timely visibility into traffic characteristics and cloud resource availability, networks cannot adapt dynamically, leading to congestion, inefficient traffic distribution, and degraded service performance.

Existing IETF efforts (e.g., TEAS, OPSAWG, CATS) focus on traffic engineering and service-aware routing, but they do not enable real-time cloud-network coordination tailored for Telecom Clouds.

Neotec (NetOps4Clouds) aims to bridge this gap by defining standardized interfaces and YANG models that allow network controllers to consume real-time Telecom Cloud telemetry and make automated, policy-driven network adjustments based on service scaling events. These capabilities will ensure that Telecom Cloud services maintain SLA guarantees and optimal network resource utilization.

[Scope description]
Neotec(NetOps4Clouds) focuses on defining data models to enable dynamic coordination between a cloud-aware service orchestrator and existing network controllers and cloud managers. The term “cloud-aware service orchestrator” refers to a functional component at network operation domain, it is capable of dynamically managing networks (e.g., fixed, mobile access, metro networks, or backbone networks) for optimizing services deployment across clouds (including edge clouds). Specifically, these models provide the following information to the network operation domain:

1) Cloud Resource Metrics: Develop data models (e.g. YANG models) for cloud manager to expose key metrics of edge clouds, including resource availability (e.g., CPU, GPU, memory, network). This data allows the network controller to dynamically adjust paths, allocate bandwidth and other network resources to accommodate the SLO requirements between clouds. For example, metrics collected from platforms like Kubernetes or OpenStack will be transformed into a standardized format understandable by the network for seamless integration and coordination.
2) Service Status in Clouds: Develop data models, such as YANG models, to provides network controllers with service instance status to adjust network paths accordingly.
3) Dynamic Adjustment of Load-Balancing Policies: Define mechanisms to enable dynamic adjustments to load-balancing policies, ensuring UCMP policy updates across ingress, intermediate, and egress routers based on service demand and network conditions.
4) Inter-Cloud Network Connectivity and Status: Network controllers expose detailed information about inter-cloud network connectivity to enable the cloud-aware service orchestrator to make informed decisions about service placement and traffic steering, including topology, bandwidth availability, latency, and packet loss metrics. Specific examples include sharing the status of connections to ensure optimal performance and SLA compliance.

Some of the data above is exposed from the cloud domain, however, the purpose of Neotec's awareness of cloud is mainly for dynamic traffic scheduling. Solely cloud scheduling and the placement or management of service instances fall outside the scope of responsibility.

Neotec(NetOps4Clouds) will also define a shim layer in cloud-aware service orchestrator, this shim layer functions as a middleware between cloud manager and the cloud-aware service orchestrators. It will specify the standardized API for the cloud-aware service orchestrators to converts cloud information into IETF-compliant formats (e.g., YANG).

Based on the experience of network operations and cloud service provisioning, we believe that exposing key information from Cloud DC into the network operation is an important trend and has practical needs. Nevertheless, Neotec mainly focuses on addressing the network issues, not that of Cloud DC. Neotec does not aim to develop a production system, such as orchestrator or network operation software. It just focuses on specifying standard interfaces for exposing the resources and metric information from Cloud DC into the network operation domain to meet service needs. To achieve the above functions, Neotec will output a general flow scheduling/load balance policy model that can be applied to various connections (VPN, Internet connection, SD-WAN) for service delivery across telecom edge clouds.

As network operators often rely on equipment and controllers from multiple vendors, standardized and interoperable solutions are essential for the network management and operation to be cloud-aware.

[Use cases]
The Neotec’s use cases focus on network-specific challenges that arise from the service delivery and need the network being awareness of the edge clouds. The use cases are intended to guide the development of standards and interfaces, ensuring that the network operation plays an active role in enabling SLA-driven service delivery across telecom edge clouds.

The first use case is Dynamic Micro-Service Deployment, which involves the efficient placement of micro-service instances across distributed edge and core clouds. This requires dynamic coordination between cloud-aware service orchestrator and network controllers to optimize service paths based on resource availability and network conditions.
The second use case is network operation for Cross-Data Center Scheduling, where real-time cloud awareness enables the network operation system to dynamic allocate computing and storage resources across geographically distributed data centers. This facilitates seamless data migration, AI training, and optimal resource utilization.

The third use case is Machine Learning in 5G and beyond, where ML and Federated ML applications depend on dynamic coordination between cloud-aware service orchestrator and network controllers to ensure on-demand, high-bandwidth, low-latency connections, delivering optimized performance and meeting SLA requirements.

[BOF intro]
The Neotec BoF will discuss several use cases of cloud-aware network operation, which needs the exchange of resource, attributes, status, requirement and policy between cloud-aware service orchestrator and network controllers. Moreover, it will analyze the gaps in existing IETF works of the cloud-awareness capabilities in network management and operation, and hopefully identifies a suit of short deliverables aimed at improving network operation by integrating cloud information, such as YANG model extension and potentially a shim layer which will be used by cloud-aware service orchestrator for the abstraction of the APIs provided by different cloud implementations.

Neotec will also aim to serve as a platform for the community to exchange requirements, challenges, and experiences related to network management and operation for cloud-based services.

Required Details

Information for IAB/IESG

To allow evaluation of your proposal, please include the following items

  • Any protocols or practices that already exist in this space

[Gap analysis]
Currently there are several WGs in IETF which work on topics related to Neotec:
* OPSAWG deals with operational and management topics that are not in scope of an existing OPS area working group and do not justify the formation of a new working group. OPSAWG has already defined connection interfaces such as Attachment Circuits (AC) between cloud gateway and network edge devices (draft-ietf-opsawg-teas-attachment-circuit) and Service Attachment Points (SAPs) (RFC 9408), as well as interfaces for network and VPN services topology and performance status (RFC 9375). None of these documents or RFCs cover the traffic flow scheduling policy interface. In addition, the WG is publishing ACaaS YANG model. This model can be used for the provisioning of ACs before or during computing service deployment to connect a cloud infrastructure to a service provider network. Although it provides bearer and AC services for communication between Cloud manager and network orchestrator or controller, it does not provider a general flow scheduling/load balance policy , which are crucial for making dynamic network path decisions.
* VPN service models (RFC8299 L3SM, RFC8466 L2SM) have been produced by several WGs, they can be used for connection service between DCs. None of them covers the traffic flow scheduling policy interface.
* TEAS WG is responsible for defining traffic engineering architecture and identifying required related routing and path computation element functions. It takes network capability and information into consideration for traffic engineering in network. It also delivers YANG models in support of traffic engineering. TEAS does not cover the traffic flow scheduling policy interface for connections such as VPN, IPSec, and SD-WAN.
* CATS WG focuses on the problem of how the network edge can steer traffic between clients of a compute service and sites offering the service. It works on a general framework for the distribution of compute and network metrics and transport of traffic from network edge to service instance, and identifies some common metrics(draft-ysl-cats-metric-definition), which will be used for traffic steering at the network edge node. CATS WG belong to Routing Area, it does not consider the coordination with cloud at the level of network management and operation.
* Network Management Operations (NMOP) WG focuses on solving network management problems faced by operators. Currently it discusses operational issues faced by the deployment of existing network management technologies, but it does not cover the management and operation problems of telecom clouds faced by TCSPs.

  • Which (if any) modifications to existing protocols or practices are required
    None identified so far.

  • Which (if any) entirely new protocols or practices are required
    None.

Agenda

  • BoF introduction and Administrivia [Chairs] 5 mins
  • A chance for the AD to say what he expects from the meeting 5 mins
  • Use Cases and Problem Statements 36 mins (each with 12 mins)
    Case 1: Cloud-aware Network Scheduling for AI Applications
    Qiong Sun(China Telecom)
    Case 2: DC-aware TE Topology Model for Computing Service Deployment, draft-llc-teas-dc-aware-topo-model,
    Luis M. Contreras (Telefonica)
    Case 3: Network-wide LB dynamic policy to accommodate cloud service placement,
    Gyan Mishra(Verizon)
  • Gap Analysis and potential work in IETF (Bo Wu) 15 mins
  • Charter Discussion and Open Discussion 55 mins
    - Charter Discussion
    - Open Dicussion
  • Speaker shuffling time 4 mins