ONSEN Problem Statement

The IETF has produced several YANG data models that are instrumental for automating the provisioning and delivery of connectivity services, such as such as the AC, L3SM , L3NM , L2SM , L2NM , NSS YANG Model , Service Attachment Points (SAPs) . While these abstractions are widely deployed, operators report persistent challenges in operationalizing them in a consistent, scalable, and automatable manner.As highlighted by the IAB Next Era of Network Management Operations workshop, these challenges are systemic and operational in nature, arising from fragmented tooling, inconsistent abstraction serivice semantics, and limited end-to-end coordination. In addition, despite the availability of numerous YANG data models, operators continue to face significant challenges in operationalizing YANG-based service APIs in a consistent, scalable, and interoperable manner. Operational workflows that rely on these APIs remain fragmented and difficult to automate end-to-end. In practice, APIs generated from similar YANG models often differ in service semantics, complicating integration across systems, vendors, and deployment environments. In this document, service semantics refers to the operational meaning of service abstractions as exposed via YANG-based APIs, such as lifecycle behavior, validity, duration, and feedback, rather than YANG syntax itself. Operationalizing Network and SErvice abstractioNs (ONSEN) Working Group is chartered to address this problem space by focusing on the operational aspects of network and service abstractions. It aims to make it easier to implement and use the IETF's service and network abstractions, with the goal of improving network automation, operational efficiency, and interoperability. This document aims to gather operational needs and motivations for network and service abstractions to inform YANG data model refresh work. It introduces a use case of data transmission service for data-intensive workload, which supports ultra-high speed, deterministic time periods, and consists of multiple segments. For the service provisioning over multi-domain heterogeneous networks, the network orchestrator exposed specialized APIs to BSS or external systems, and based on practice, extensions to the existing service models have been identified. Model refresh work has been manifested by , which provides the findings from the implementations, deriving the functionalities required to update the Service and Network YANG data models. In addition, it consolidates operator-observed challenges and problems related to YANG-based service APIs, explains why existing approaches and tools are insufficient when considered in isolation, and frames the requirements that ONSEN is chartered to examine to improve the operationalization and consumption of YANG-based service APIs. This document does not propose specific solutions, protocols, or data models.

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 when, and only when, they appear in all capitals, as shown here.

The following terms are used in this document: AC: Attachment Circuit. API: Application Programming Interface. Abstraction: refers to the definition of simplified, high-level constructs that represent network and service capabilities, while hiding the details of their underlying realization. Such abstractions enable interaction between management and automation systems without requiring direct exposure of device-specific configurations or protocol behaviors. BSS: Business Support Systems. BR: Border Router. CLI: Command-Line Interface. CRM: Customer Relation Managment. CPE: Customer Premise Edge DTS-I: Data Transmission Service for data-Intensive workload. NEMOPS: Next Era of Network Management Operations. ONSEN: Operationalizing Network and SErvice abstractioNs. OSS: Operation Support Systems. PPPoEo6: PPPoE over IPv6. SGW: Service Gateway. SNMP: Simple Network Management Protocol.

The IETF has produced several YANG data models that are instrumental for automating the provisioning and delivery of connectivity services, they are described in . They can be used in various use cases, such as inter-data-center connectivity and on-orbit networking with dynamic interconnection. In the latter environment, network services must be instantiated, modified, and torn down on short timescales. Constructs such as bearers or attachment circuits may need to be dynamically established to interconnect infrastructure at orbital speeds. YANG-based service APIs are a natural interface for exposing such services to planning and control systems. To further elaborate on the challenges operators face in operationalizing YANG-based APIs, a new use case with the name of "Data Transmission Service for Data-Intensive Workload(in short, DTS-I)" is illustrated by this section.

With the advent of the AI era, customers such as scientific research, education, and biotechnology have an increasing need to transfer burst-like massive data. In this context, massive datasets are routinely transferred to centralized computing and storage infrastructure for analysis and processing. These transfers may involve large volumes of data, require predictable completion times, and demand bandwidth that varies significantly over time. To meet this demand, operators need support service automation configuration, enabling elastic high-bandwidth, mission-oriented, and rapid (within seconds) network creation across heterogeneous networks.

This use case follows the rationale described in . Figure 1 illustrates a network example connecting multiple data centers (DCs) and enterprise CPEs, the network may span multiple domains or even multiple operators.

Each DC potentially hosts different computation resources. For instance, DC-1 is directly linked to the network, suggesting it host sufficient computing and storage capabilities. Various DC gateways (DC GWs) are deployed to manage traffic flow towards DCs. Two CPE devices (CPE-1 of user A and CPE-2 of User B) are connected to edge of the network respectively, indicating the start points for customer traffic entering the provider's network. There are several SGW devices (SGW-1, SGW-2, and SGW-3, etc.) which serve as entry and exit points for massive data transmission between the customer and the DCs. The Border routers (BRs) facilitate the inter-connection of different parts of the network. They connect the access/aggregation layer to the core network. When deploying DTS-I services by creating overlay connection for scheduled data transmission across this network, generic API calls are needed. A typical usage is to use Restful APIs of Network Orchestrator to provision the DTS-I connection from CPE-1 to DC-1. In this case, the DTS-I connection consists of three segments: the access segment from CPE-1 to SGW-1, the VPN segment from SGW-1 to SGW-2, and the segment between SGW-2 to the DC-1 egress point, i.e., DC GW. Therefore, this is a composite connection. In this case, it is assumed that the Network Orchestrator has access to the DC and network connectivity topology (e.g. TE Topology ), as well as resource(e.g., bandwidth) information for the network. Some standard network inventory interfaces are available. For example, the Service Attachment Points (SAPs) or ACs can obtain the AC/Bearer information of the PE, which suggests that the private line service provisioning resource resources on the network side.

The workflow below gives an example of efficient use of network connections for massive data transmission in this case. Step 1: Service ordering Via the Service Portal on the BSS, the customer input the relevant information into the BSS, such as: specifying the user-side LAN port for CPE interconnection, configuring the IP address for LAN port interconnection. The customer selects the local enterprise site and service requiring interconnection (determining the caller), then selects the remote enterprise site(s) and service(s) it intends to interconnect (determining the callee(s); multiple callees are possible). The customer selects the ordering parameters, for instant ordering, the key parameters include order duration and bandwidth. The BSS then issues a DTS-I connection setup request to the network orchestrator by calling the corresponding API. Step 2: Resource check Upon receiving the DTS-I order request, the Network Orchestrator first checks if both sites are available (whether the CPEs are online) and verifies if the CPEs exceed their own bandwidth limits after the order is initiated. In practical utilizations, the Network Orchestrator may select an appropriate DC based on the availability of computational resources and then establish connections according to the chosen DC. However, this process falls outside the scope of the IETF and will not be discussed here. Step 3: VPN selection The Network Orchestrator checks for available VPNs (the operator pre-configures multiple VPNs on the SGW for exclusive use by services). The Network Orchestrator selects an unused VPN for this service connection and maintains the VPN occupancy status. It then returns the order initiation result to the user (informing the user whether the order can be initiated). Step 4: Customer-side configuration The Network Controller configures the LAN port (specifies the IP address range of the user private network), WAN port (PPPoE over IPv6 tunnel configuration), and routing for the caller and callee site CPEs respectively. Step 5: VPN configuration The Network Controller configures the VPN-related parameters through SGW or the AAA system associated with the SGW. Step 6: User authentication and authorization After the CPE dials up, the SGW completes user account authentication and authorization. The end-to-end network connection is successfully established.

Following the procedure above, a high-speed connection can be setup between CPE-1 and DC GW of DC-1. The whole connection consistes of three segements: the segment between CPE-1 and SGW-1(based on PPPoEo6), the VPN between SGW-1 and SGW-2, and the segement between SGW-2 and DC-GW of DC-1(based on Session-level IPoE).

Network Orchestrator can use the network and service models to set up connections between the Provider Edge devices, and also customer facing ACs between CEs and PEs, DC GWs and PEs. On the premise that these models can be directly utilized, a series of model-based APIs need be defined to meet the requirements for massive data transmission within a predetermined time period. One typical API of them is for connection setup as below, 1) Data Structure of the API Request

2) Data Structure of the Response (with status code: 200)

Based on the introduction above, it can be seen that the use case of DTS-I has the following requirements which may differentiate it from others, -Dynamic bandwidth adjustment The bandwidth allocation can be modified within seconds or minutes, rather than through configuration changes that may take hours or days. The bandwidth can be provided in various granularities, especially for ultra-high bandwidth, including up to Gigabit-level bandwidth at present.? -Dynamic network provisioning The connectivity can be established and torn down connectivity on demand, rather than being persistent. Further, the connectivity can be setup between the user-specified start and end points based on uers' requirements. The transfer of large volume of data may be finished within a predictable time frame. - Ubiquitous Access Provisioning The service needs ubiquitous access and wide coverage, allowing users to flexibly connect through various access methods and ensuring computational resources are readily available on demand. -Cross-Domain Coordination For user data transmission, the connection may span across domains or even across different operators, the network must possess cross-domain coordination capabilities, enabling flexible end-to-end scheduling of network resources and services. The operation of such a service faces the following issues, -Extension to the existing service models. Due to the requirements above, extension to the existing service models (e.g., L3SM) are needs to be developed for DTS-I, which can also be exposed to external systems for use through YANG2API. -Challenges related to YANG-based API operation. Service abstractions are commonly exposed to external systems, such as orchestration platforms and OSS/BSS applications through APIs derived from YANG data models. The challenge is how to enable low friction interfacing, when operators purchase OSS/BSS commercial products, these interfaces will potentially be TMF-aligned OpenAPIs. Operators face the challenge of either paying commercial OSS providers to create bespoke interfaces to consume the potentially different network interfaces, or building an adaptation layer themselves that converts multiple different network interfaces to a potentially common single commercial product TMF interface. In addition, the lack of consistent guidance on how abstractions should be modeled, exposed, and consumed results in APIs that vary significantly across vendors and deployments. This variability makes it difficult for external systems to consume YANG-based service APIs in a predictable and interoperable manner, operators continue to face challenges related to lifecycle management, service semantic clarity, observability, and interoperability. -Verification of the capabilities of existing network abstractions. It is necessary to check whether the current network abstractions can support the new service model and meet the feature requirements of DTS-I; if not, the existing network abstractions will need to be updated. In addition, the following generic issues have been identified, Some operators are adopting TMF640/641 as APIs for service ordering from their BSS, but how these interfaces can be exposed to / aligned with the service/network models, or more broadly any YANG model, for configuration and/or state is not specified. The declarative model-driven nature of NETCONF/YANG, and its associated semantics through NMDA, allow for the creation of complete abstractions with an unprecedented simplicity as exemplified by the LxNM and LxSM models. However, the lack of choice in commercial, off-the-shelf systems that implement such declarative methodology is seriously affecting the uptake of the protocol/modeling language, due to the risk of vendor lock-in. There are even fewer credible open-source alternatives. An operator who offers a diverse set of customer services including L3VPN, L2VPN, (business) internet access etc. may use the LxSM models as the interface to offer these services. But the models are not well-suited to offer a combination of these, and other, services through a single service orchestrator. The LxSM models lack administrative state control and operational state information. Additionally, in the vast majority of SP networks, configuration management and the collection of statistics / telemetry data continue to exist as two separate silos in both the organizational chart and technology stacks/APIs. This makes it very hard to bring operational state into such model.

The previous section has demonstrated the operational issues related to this specific use case, but on a broader scale, the operation of network and service abstractions faces more challenges. While these abstractions are widely deployed, operators report persistent challenges in operationalizing them in a consistent, scalable, and automatable manner. As highlighted by the NEMOPS workshop, these challenges are systemic and operational in nature, arising from fragmented tooling, inconsistent abstraction serivice semantics, and limited end-to-end coordination. They are not confined to a specific technology or service type, but recur across abstraction domains and deployment environments.

Operational workflows associated with service abstractions, such as service instantiation, monitoring, troubleshooting, modification, and decommissioning, are often fragmented and inconsistently handled. Even when abstractions coexist within the same network or service offering, they frequently rely on different tools, data models, and interfaces. NEMOPS discussions highlighted that operators commonly depend on a heterogeneous mix of management protocols, vendor-specific APIs, and legacy mechanisms to complete these workflows, significantly increasing operational complexity and cost. In practice, lifecycle actions initiated through YANG-based service APIs often require coordination across orchestration systems, controllers, and device configurations. However, these components are rarely aligned in terms of lifecycle semantics, data models, or operational assumptions. This fragmentation limits end-to-end automation, complicates validation and rollback, and increases the likelihood of configuration drift and operational errors. Existing service and network abstractions generally lack native constructs to express lifecycle attributes such as activation time, duration, expiration, or rollback behavior. As a result, transient service intents must be tracked and enforced outside the abstraction framework, increasing operational complexity and the risk of inconsistency.

Service abstractions are typically realized through a combination of service-level models, network-level models, control-plane behavior, and management interfaces. These layers are often developed independently, with limited coordination across working groups or operational domains. This misalignment can manifest as: -Service abstractions that do not cleanly map to underlying network capabilities. -Network models that expose parameters without clear service-level semantics. -Control-plane behaviors that are difficult to correlate with service-level intent. As a result, it is difficult to combine the different services into a higher level service, operators face challenges ensuring that a service behaves as intended throughout its lifecycle, particularly when changes occur at one layer without corresponding visibility or coordination at others.

Existing abstraction models often focus on configuration or control-plane aspects without fully considering how abstractions are realized operationally across networks. Service and network abstractions frequently rely on metrics, attributes, or parameters whose semantics vary across models, implementations, or consumption contexts. Concepts such as cost, availability, or performance may be represented using different definitions, units, scopes, or update models. Many abstraction models expose parameters or metrics that are syntactically similar but semantically inconsistent across technologies or implementations. Differences in interpretation, update frequency, or scope can lead to unpredictable behavior when abstractions are consumed by automation systems. These inconsistencies complicate integration between systems and undermine the reliability of automation. These gaps are typically addressed through custom logic or manual processes, reducing portability and interoperability. Without consistent operational semantics, it is difficult for management and orchestration systems to reliably interpret abstraction state, compare information across domains, or make automated decisions based on abstraction models alone.

Existing abstractions primarily focus on configuration and offer limited standardized mechanisms for reporting whether requested behaviors have been successfully applied or remain valid over time. This lack of feedback assurance impedes closed-loop automation and increases reliance on manual monitoring and intervention.

The challenges described above directly impact operational efficiency, automation, and interoperability. Operators are required to invest significant effort in integration, validation, and troubleshooting, reducing the benefits that abstractions are intended to provide. Without a more coordinated approach to abstraction modeling and operational usage, these issues are likely to persist as networks continue to evolve.

The operational challenges described in this document are consistent with, and reinforced by, the findings of workshop, which examined the state of network management and automation based on operator experience across diverse deployment environments. The NEMOPS workshop identified that, despite significant progress in protocol development and data modeling, operational workflows remain fragmented and difficult to automate end-to-end. Operators reported continued reliance on a heterogeneous mix of tools, protocols, and interfaces, including YANG-based management protocols, vendor-specific APIs, legacy mechanisms such as CLI and SNMP, and bespoke orchestration logic to deploy and operate services. This fragmentation increases operational complexity and limits the effectiveness of abstraction-driven automation. A key observation from the workshop is that model-driven network management is generally successful, yet insufficient on its own to address higher-level operational needs. In particular, the workshop highlighted gaps between device-level and service-level abstractions, noting that existing models often lack the semantic alignment and contextual information required by orchestration and OSS/BSS systems. As a result, operators must perform extensive model mapping, data transformation, and system-specific integration outside the scope of standardized abstractions. The workshop further emphasized challenges related to observability, verification, and feedback. While configuration mechanisms are relatively mature, operators reported limited ability to validate whether service intent is being met over time or to correlate operational state across abstraction layers. This lack of consistent feedback undermines closed-loop automation and complicates troubleshooting, particularly in multi-vendor and multi-domain environments. Another recurring theme from the NEMOPS discussions is the lack of architectural documentation and operational guidance explaining how existing abstractions, models, protocols, and tools are intended to work together as a system. Operators expressed difficulty understanding which abstractions to use, how they should be combined, and how responsibilities are divided across layers and working groups. This absence of cohesive guidance leads to divergent interpretations and inconsistent deployments. These findings closely align with the limitations identified in the applicability studies discussed earlier and reinforce a broader operational problem: while many of the necessary technical components for service and network abstractions exist, they are not sufficiently coordinated, aligned, or documented to support consistent, interoperable, and automatable operations. Addressing these systemic issues requires a focus on abstraction coherence, lifecycle semantics, and operational consumption concerns that fall squarely within the scope of the ONSEN Working Group.

From an operational perspective, the network operation system needs to dynamically coordinate behavior across multiple network segments, expose the YANG-based network and service capabilities through open APIs, driven by service-level events, workload changes, or short-lived operational needs. Service and network abstractions are defined and evolved across multiple IETF working groups, each focusing on a specific technology, protocol, or layer. Although this separation is appropriate for protocol development, it has resulted in abstraction models and operational assumptions that are not well coordinated across domains. As a result, operators must integrate abstractions that were designed with different scopes, semantics, and lifecycle assumptions. This fragmentation increases integration effort and complicates automation, particularly when a service abstraction spans multiple technologies or administrative domains. YANG data models are commonly used as the basis for APIs that expose service abstractions to external systems. However, existing work provides limited guidance on how these abstractions should be exposed, versioned, or consumed in a predictable and interoperable manner. As a result, APIs derived from similar abstraction models may differ significantly across vendors or deployments, requiring bespoke integration by operators and OSS/BSS systems. Some operators are adopting TMF640/641 as APIs for service ordering from their BSS, but how these interfaces can be exposed to / aligned with the service/network models, or more broadly any YANG model, for configuration and/or state is not specified. This variability undermines the portability and reuse that abstractions are intended to provide. To address the issues above, a new Working Group is needed to perform the following tasks: - Identify these gaps and provide guidance and recommendations on how YANG-based service APIs should express and expose such behaviors to better support dynamic, multi-operator environments. - Maintaining YANG data models for network and service abstractions. - Evaluating whether YANG data model activities above necessitate changing the Automating Service and Network Management Framework defined in - Provide YANG-based API tooling-related guidances and document in WG-maintained repositories such as GitHub or a Wiki.

TBD.

No Action is needed.