| Internet-Draft | Neotec API | April 2025 |
| Dunbar, et al. | Expires 19 October 2025 | [Page] |
This document explores how existing IETF YANG models, specifically the Attachment Circuit (AC) and Traffic Engineering (TE) topology models, can be applied to support a representative Neotec use case involving dynamic AI model placement at Edge Cloud sites. The use case, derived from China Telecom's Neotec side meeting at IETF 122, involves selecting optimal Edge locations for real-time AI inference based on end-to-end network performance between street-level cameras and Edge Cloud compute nodes. By mapping the use case across multiple network segments and applying relevant YANG models to query bandwidth, latency, and reliability, this document serves as a practical exercise to evaluate model suitability and identify potential gaps. The goal is to inform future work under the proposed Neotec Working Group.¶
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 19 October 2025.¶
Copyright (c) 2025 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.¶
This document explores using the Attachment Circuits YANG model [opsawg-teas-attachment-circuit] and TE topology YANG model, to support a simplified version of the use case described in China telecom's Neotec side meeting during IETF122(Cloud aware Network Operation for AI Services). Also specify the APIs needed to support the simplified use case.¶
Simplifed Use Case:¶
Let's assume there are 10 Edge Cloud sites. An City Surveillance AI model (e.g., detecting traffic congestion or garbage classification) needs to be deployed dynamically to some of these sites in response to real time events.¶
High level steps for selecting Edge sites to instantiate the City Surveillance AI model:¶
- Step 1: The Cloud Manager needs to query the network connectivity characteristics (bandwidth, latency, topology constraints, etc.) between street cameras (or gateways, eNB that connect to those street cameras) and candidate Edge Cloud sites in order to determine the optimal locations for the City Surveillance AI model deployment.¶
- Step 2: Based on the information gathered, the Cloud Manager decides to deploy the City Surveillance AI module in 4 of the 10 Edge Cloud sites.¶
High level steps to support the following desired outcome:¶
- Suppose the City Surveillance AI modules in the 4 Edge Cloud sites need to exchange large volumes of data with strict performance constraints (e.g., XX Gbps bandwidth and YY ms latency). The goal is to have the network controller dynamically adjust UCMP (Unequal Cost Multipath) load-balancing algorithms on all the nodes along the paths interconnecting those 4 sites.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
In this use case, multiple Edge Cloud sites are located in close geographic proximity, allowing any of them to potentially host AI inference model instances for city surveillance tasks such as traffic congestion detection or garbage classification. The Cloud Manager must evaluate the end-to-end data paths between the street-level cameras and each Edge Cloud site to determine which sites offer sufficient compute resources and the required network performance (e.g., low latency and high throughput). This assessment enables dynamic placement of AI inference models in response to real-time events while ensuring reliable data delivery from the field.¶
This path typically spans three segments. The first is the access segment from the cameras local access node, such as a WiFi Access Point or an eNB, to a PE router. The second segment traverses the provider transport network between that Access PE and the PE router serving the candidate Edge Cloud site. The third segment connects that Edge PE to the Edge Cloud Gateway or compute node where the AI workload is deployed.¶
There are two primary types of access connectivity for the cameras: via cellular networks (e.g., through eNBs/gNBs and UPFs) or via WiFi Access Points. In cellular based access, cameras connect to the network through eNBs, which forward user data to User Plane Functions (UPFs) vir GTP-U tunnels. The UPFs serve as termination points for GTP-U tunnels and are often co-located with or adjacent to Edge Cloud sites. When the Cloud Manager selects Edge Cloud sites for hosting AI inference modules, it must ensure that the corresponding nearby UPFs are assigned as the serving UPFs for the associated eNBs. This enables the establishment of GTP-U tunnels from the eNBs directly to the selected Edge Cloud locations, minimizing latency and improving efficiency for real-time AI processing.¶
For cameras connected through WiFi Access Points, no GTP tunneling is involved. These access points typically connect to PE routers through Layer 2 or Layer 3 links. In this case, the Attachment Circuit (AC) YANG model can be directly used to represent the logical connectivity between the WiFi AP and the Access PE. The Cloud Manager or orchestrator can query the AC model to evaluate operational status, available bandwidth, latency, and packet loss, and determine whether the path is capable of supporting the target AI workload.¶
In both access scenarios, after determining viable Edge Cloud sites, the Cloud Manager must also evaluate the transport network (Segment 2) between the access side PE (or the PE adjacent to the UPF) and the Edge side PE. This segment is typically traffic engineered and can be modeled using the IETF TE topology model [RFC8795] and the TE tunnel model [RFC8776]. These models expose metrics such as available bandwidth, TE delay, and administrative attributes, which the orchestrator can use to assess whether the transport paths meet the end to end SLA constraints.¶
Finally, the last segment (Segment 3: from the Edge PE to the Edge Cloud Gateway or compute node) is again modeled using the AC YANG model. By combining insights from the AC and TE models across all three segments, the Cloud Manager and orchestrator can select Edge Cloud sites that not only have available compute capacity but also meet the network performance requirements to support low latency, high bandwidth AI model inference.¶
+---------------------+
| Street Cameras |
+---------------------+
/ \
/ \
(Cellular Access) (WiFi Access)
/ \
+--------+ +-------------+
| eNB | | WiFi AP |
+--------+ +-------------+
| |
| |
+----------------------+ +----------------------+
| UPF | | Access PE Router |
+----------------------+ +----------------------+
| |
| Segment 1 |
|<--------------------------->|
(Access Segment)
\ /
\ /
\ /
+----------------------+
| Provider Transport |
| Network (TE) |
+----------------------+
|
Segment 2 | (PE-to-PE)
v
+---------------------------+
| Edge PE Router (per site)|
+---------------------------+
|
|
Segment 3 v
+--------------------+
| Edge Cloud Gateway|
| + AI Model Module |
+--------------------+
For the first and third segments, the Attachment Circuit (AC) YANG model, defined in [opsawg-teas-attachment-circuit], provides a standardized abstraction of the logical link between a service access point and the provider's routing infrastructure. This model allows the Cloud Manager to retrieve configuration and operational status of these links, including encapsulation type, bandwidth, and link status. By querying this information, the orchestrator can determine whether each access circuit is operational and capable of delivering real-time video streams to or from the AI inference point.¶
The second segment, the PE to PE transport path across the provider network, requires querying a different set of YANG models. The base network and topology models defined in [RFC8345] provide the foundation, while the Traffic Engineering Topology model [RFC8795] adds details such as TE metrics, link delay, bandwidth availability, and administrative constraints. These models are typically maintained by network controllers and made accessible via NETCONF or RESTCONF interfaces. The Cloud Manager can use this information to assess the performance characteristics of available transport paths between PEs. In addition, the orchestrator may use the TE Tunnel model [RFC8776] to discover existing LSPs or establish new traffic engineered paths. In architectures using PCE, path queries can also be issued via PCEP or a REST API to identify optimal transport paths that meet performance policies.¶
By combining the Attachment Circuit and TE topology models, the Cloud Manager can construct an end to end view of network connectivity from each camera access point to every potential Edge Cloud site. It can then select the subset of Edge Cloud locations that not only have sufficient computing resources but also meet the required network performance criteria for serving the selected set of street cameras. This allows dynamic, network aware placement of AI inference models, ensuring efficient use of edge infrastructure while meeting service quality requirements.¶
The Attachment Circuit (AC) YANG model provides a standardized abstraction to describe and manage the logical connections between customer-facing interfaces and the provider's edge infrastructure. In the context of dynamic AI model placement at Edge Cloud sites, this model is particularly useful for querying the health and performance of the two edge segments of the data path: Segment 1, which connects Access Points or eNBs to Access PE routers, and Segment 3, which links Edge PE routers to Edge Cloud Gateways or compute nodes.¶
Each attachment circuit is modeled with attributes such as administrative state, operational status, encapsulation type, and configured bandwidth. When augmented with telemetry or traffic engineering extensions, the model also supports operational performance data such as current utilization, available bandwidth, latency, and even packet loss. This enables the Cloud Manager or orchestrator to assess whether a given access or egress segment can support the performance requirements of the AI inference workload, typically low latency (e.g., less than 10ms) and guaranteed throughput (e.g., larger than 500 Mbps).¶
For example, if the Cloud Manager knows the PE router address at the access or edge side, it can issue a RESTCONF GET query to retrieve the state of attachment circuits connected to that PE. Consider the following RESTCONF request:¶
GET https://<controller>/restconf/data/ietf-ac:attachment-circuits /ac[pe-address='192.0.2.11']
{
"ietf-ac:ac": [
{
"name": "ac-to-eNB-001",
"pe-address": "192.0.2.11",
"ce-interface": "ge-0/0/1",
"oper-status": "up",
"admin-status": "enabled",
"encapsulation-type": "dot1q",
"bandwidth": {
"configured": 1000,
"available": 850,
"unit": "Mbps"
},
"performance-metrics": {
"latency": {
"average": 5,
"max": 10,
"unit": "ms"
},
"packet-loss": {
"percentage": 0.01
}
}
}
]
}
In this example, the attachment circuit is operational (oper-status: up), with 850 Mbps of available bandwidth and average latency of 5 ms, making it a strong candidate for supporting a real time AI application. The Cloud Manager may apply similar queries to all PE addresses associated with candidate Edge Cloud sites and their corresponding access points, filtering the results to identify which circuits meet both latency and throughput thresholds.¶
Segment 2 of the end to end path connects the Access PE, adjacent to the street level access points, to the Edge PE router serving a candidate Edge Cloud site. This segment traverses the provider's core or aggregation transport network and plays a critical role in determining whether the latency and bandwidth requirements of real time AI inference can be satisfied. To evaluate this segment, the Cloud Manager can leverage IETF YANG models that expose both the topological and performance characteristics of traffic-engineered (TE) or IGP routed networks.¶
The foundational models used for this purpose are the IETF Network Topology YANG model [RFC8345] and the Traffic Engineering Topology YANG model [RFC8795]. These models represent network nodes (e.g., PE routers), TE links (interconnecting core routers or PE-PE paths), and associated attributes such as available bandwidth, latency, SRLGs, and link metrics. In addition, TE tunnels modeled via the TE YANG module [RFC8776] can be queried to retrieve the current state of established Label Switched Paths (LSPs) or Segment Routing tunnels between PEs.¶
For example, to query available transport links from an Access PE at PE1 to a set of Edge PEs, the Cloud Manager may retrieve the list of TE links and their attributes using the following RESTCONF-style request:¶
GET https://<controller>/restconf/data/ietf-te-topology:te-topologies /topology=default/te-node=PE1
{
"te-links": [
{
"name": "PE1-to-PE5",
"link-id": "link-001",
"oper-status": "up",
"te-default-metric": 30,
"te-bandwidth": {
"max-link-bandwidth": 10000,
"available-bandwidth": 7000,
"unit": "Mbps"
},
"delay": {
"unidirectional-delay": 8,
"unit": "ms"
},
"adjacent-te-node-id": "PE5"
}
]
}
In this example, the link from PE1 to PE5 offers 7 Gbps of available bandwidth with 8 ms unidirectional delay, which may satisfy a 500 Mbps, sub-10 ms latency requirement for AI data ingestion. The Cloud Manager can evaluate similar TE links or tunnels to other Edge PEs (e.g., PE6, PE7) and compare their performance characteristics.¶
Alternatively, if the network has PCE deployed, the Cloud Manager can issue a path computation request, using PCEP to query the end to end path metrics and validate whether a PE to PE segment can meet specified SLA constraints. If Segment Routing (SR-MPLS or SRv6) is deployed, these models can also include SR label stacks or SID lists needed for forwarding decisions.¶
By querying the TE topology and tunnel models, the orchestrator can build a filtered set of feasible transport segments that support the expected latency and bandwidth for the AI workload. This insight, combined with data from the Attachment Circuit models for Segments 1 and 3, allows the orchestrator to make holistic decisions about AI workload placement and optimal traffic steering across the network.¶
This section outlines a potential Neotec API interface to enable Kubernetes (or its external workload orchestrators) to make network-aware workload placement decisions, such as selecting appropriate Edge Cloud sites for deploying latency-sensitive AI inference modules.¶
Cloud-native platforms such as Kubernetes do not consume YANG-modeled data directly. Instead, they rely on REST-style APIs or gRPC interfaces with JSON or protobuf-encoded payloads. To support Neotec use cases, the network infrastructure can expose an abstracted API that translates YANG-modeled topology and performance data into a form consumable by Kubernetes or its scheduling extensions.¶
A representative Neotec API endpoint could take the form:¶
GET /network-advisor/query-path-performance? source-node=<access-node-id>&target-node=<edge-site-id>
This API allows Kubernetes to query the performance of the network path between a street camera's access node (e.g., a WiFi AP or eNB/UPF) and a candidate Edge Cloud site. The API response includes metrics such as available bandwidth, average path latency, and operational status. A sample response might be:¶
{
"source-node": "AP-235",
"target-node": "EdgeSite-4",
"path-latency-ms": 6.5,
"available-bandwidth-mbps": 920,
"path-status": "healthy"
}
This API provides a read-only, low-latency interface for workload schedulers to assess whether a given path meets predefined service-level thresholds (e.g., latency less than 10 ms, bandwidth larger than 500 Mbps). The source node and target node identifiers correspond to access nodes (e.g., PE routers adjacent to UPFs or WiFi APs) and Edge Cloud PE routers respectively. These identifiers are assumed to be mapped within the operator domain.¶
The semantics of the fields are as follows:¶
- path-latency-ms: Derived from YANG-modeled metrics in ietf-TE-topology, representing end to end unidirectional delay.¶
- available-bandwidth-mbps: Aggregated from TE-bandwidth in the same topology model.¶
- path-status: Reflects operational state derived from oper-status fields in the TE and AC models.¶
The backend implementation of this API is expected to query IETF defined YANG models using RESTCONF or NETCONF. Specifically:¶
- Topology and path delay metrics are sourced from the ietf-te-topology and ietf-network-topology models [RFC8795], [RFC8345].¶
- Access circuit status and available bandwidth can be derived from the AC model [opsawg-teas-attachment-circuit].¶
This API represents a shim layer between the cloud native environment and the YANG driven network management domain, allowing real time path evaluations without requiring Kubernetes to consume YANG directly.¶
The Neotec use cases, such as dynamic placement of AI inference workloads at Edge Cloud sites based on real time network and compute conditions, are built around tight coordination between cloud orchestration systems (e.g., Kubernetes) and network infrastructure. While IETF has standardized many of the foundational models and protocols necessary to monitor and control network state, there remain several functional and architectural gaps that limit seamless integration with modern cloud native systems.¶
By identifying these gaps, the proposed Neotec Working Group can provide a platform for deeper discussion on how to align IETF models with the operational needs of cloud native environments. This may take the form of WG documents that explore solution frameworks and explicitly invite review and collaboration from the Kubernetes ecosystem, open source cloud orchestration communities, and network operator forums. The goal is not to replace existing IETF YANG models or protocols, but to define complementary APIs and interaction patterns that bridge the network cloud interface in a vendor neutral and implementation friendly manner, enabling effective coordination of service placement, telemetry, and policy enforcement across domains.¶
Most IETF models, such as those defined in ietf-TE-topology, ietf-network, and ietf-ac, are accessed using NETCONF or RESTCONF, and expressed in YANG. These protocols and data models are not natively supported by cloud orchestration platforms, which instead rely on REST APIs, JSON payloads, and gRPC interfaces. As a result, there is no standardized mechanism for a cloud native platform to directly consume network aware telemetry modeled by IETF YANG.¶
While the IETF has defined rich YANG models for traffic engineering and service topology, there is no standard IETF-defined query interface to extract high-level performance views such as "What is the latency from access node A to Edge Cloud B?" or "Which Edge sites meet latency less than 10 ms from this access cluster?" These higher-level path-performance queries are essential for use cases such as AI workload placement, but currently require custom, operator-specific logic to extract and interpret low-level link state and tunnel data.¶
Neotec use cases often involve event-driven interactions, such as informing the network when an AI inference pod scales out, or notifying the orchestrator when a transport path degrades. Current IETF YANG models are primarily state-oriented, with limited native support for event notification, pub/sub patterns, or subscription-based workflows between cloud and network domains.¶
Although there is work in areas like YANG-Push and pub/sub over NETCONF, these are not yet integrated into mainstream cloud orchestration models. There is a need for standardized event publication APIs that allow network or cloud domains to push relevant updates across the boundary.¶
IETF models focus on abstract representations of network state, but do not define service aware policy APIs, for example, to express that a newly deployed workload requires specific network SLA guarantees, or that a policy change should apply only to traffic associated with a particular AI inference service. A Neotec-specific gap exists in translating service intents into network policy directives, such as UCMP weight adjustments or slice reconfiguration.¶
While the IETF has defined robust identity and access control mechanisms (e.g., OAuth2, RPKI, TLS), integrating these mechanisms with cloud-native identity systems (such as Kubernetes RBAC, SPIFFE/SPIRE, or cloud IAM services) is still ad hoc. A standard framework for mutual trust establishment and token exchange between cloud and network domains is needed to support secure Neotec APIs under Zero Trust principles.¶
To be added¶
None¶
The authors would like to thank for following for discussions and providing input to this document: xxx.¶