ONSEN Working Group S. Barguil Internet-Draft Nokia Intended status: Informational K. Lambrechts Expires: 2 May 2027 Intwine C. Xie China Telecom 29 October 2026 ONSEN Problem Statement draft-kbf-onsen-problem-statement-01 Abstract The IETF has published a number of YANG data models for automating the provisioning and delivery of network and connectivity services, including the L2SM, L3SM, L2NM, L3NM, Attachment Circuits, and Network Slicing models. These models are intended to provided abstracted representations of common operator services, exposing only the necessary parameters for configuring and managing services. These abstractions help to contain the complexity of service provisioning within the necessary domains, making the implementation of complex, multi-domain services easier to implement and manage. However, operators have reported persistent challenges in operationalizing these abstractions in a consistent, scalable, and automatable manner. This document describes the problem space for the ONSEN Working Group, identifying the operational gaps and deficiencies in existing IETF service and network abstraction models that complicate, or prevent effective end-to-end automation. The problems documented here are initially drawn from operator experience, and from the findings of the IAB NEMOPS Workshop. It is a living draft, not intended for publication as an RFC, and will be updated with new problem descriptions as the ONSEN work proceeds. This document does not propose solutions, protocols, or new data models. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://sbarguil.github.io/ONSEN_Problem_Statement/draft-kbf-onsen- problem-statement.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kbf-onsen-problem- statement/. Barguil, et al. Expires 2 May 2027 [Page 1] Internet-Draft ONSEN Problem Statement October 2026 Discussion of this document takes place on the ONSEN Working Group mailing list (mailto:onsen@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/onsen/. Subscribe at https://www.ietf.org/mailman/listinfo/onsen/. Source for this draft and an issue tracker can be found at https://github.com/sbarguil/ONSEN_Problem_Statement. 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 2 May 2027. Copyright Notice Copyright (c) 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Problem Area Qualification Criteria . . . . . . . . . . . . . 5 4. Missing LxSM and LxNM Functionality . . . . . . . . . . . . . 5 4.1. LxNM Updates . . . . . . . . . . . . . . . . . . . . . . 5 4.2. On-Demand and Scheduled Service Operations . . . . . . . 6 5. Structural LxNM/LxSM Problems . . . . . . . . . . . . . . . . 6 Barguil, et al. Expires 2 May 2027 [Page 2] Internet-Draft ONSEN Problem Statement October 2026 6. Limited Observability and Service Assurance . . . . . . . . . 7 7. OSS/BSS Interface and API Interoperability . . . . . . . . . 7 7.1. Northbound API Semantics . . . . . . . . . . . . . . . . 7 7.2. TMF API-Based Semantics . . . . . . . . . . . . . . . . . 8 8. Insufficient Guidance for Implementing YANG-based Orchestration . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Other Southbound Management Interfaces . . . . . . . . . 9 9. Items for Future Study . . . . . . . . . . . . . . . . . . . 9 9.1. Quantum-Security Requirements in Service Models . . . . . 9 9.2. Secure Handling of Secrets in Orchestration Workflows . . 9 9.3. Generic Abstraction-to-Underlay Mapping . . . . . . . . . 10 9.4. Absence of Reusable Service Configuration Constructs . . 10 9.5. Abstractions for Telco-Cloud Scenarios . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The IETF has published several YANG data models that are intended for automating the provisioning and management of service provider connectivity services. These include models such as L3SM [RFC8299], L3NM [RFC9182], L2SM [RFC8466], L2NM [RFC9291] and Service Attachment Points (SAPs) [RFC9408]. A new YANG model for the Network Slice Service [RFC9543], is currently being authored: [I-D.ietf-teas-ietf-network-slice-nbi-yang]. While some of these abstractions have been deployed, operators report persistent challenges in operationalizing them. As highlighted by the IAB NEMOPS Workshop [NEMOPS], these challenges are systemic and operational in nature. They are not confined to a specific technology or service type, but reoccur across abstraction domains and deployment environments. In addition, despite the availability of numerous YANG data models - covering configuration, assurance, and fault management - and the ongoing effort to make these models coexist within a common framework under the IETF umbrella, operators continue to face significant challenges in operationalizing YANG-based service APIs in a consistent, scalable, and interoperable manner. While models such as the L3SM, L2SM, L3NM, L2NM, AC/SAP abstractions and Network Slice Service each address specific aspects of service delivery, it is not always clear which models should be used together, in which scenarios, or to what extent a given implementation actually supports the full model. The usage of these APIs remains fragmented - often partially implemented - and difficult to automate end-to-end. In practice, APIs generated from similar YANG models often differ in Barguil, et al. Expires 2 May 2027 [Page 3] Internet-Draft ONSEN Problem Statement October 2026 service semantics, and the lack of clear guidance on model composition and interoperability complicates integration across systems, vendors, and deployment environments. The 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 defines the problem space for ONSEN. It does not propose solutions, protocols, or new data models. 2. Conventions and Definitions The following terms are used in this document: AC: Attachment Circuit Abstraction: The process of defining simplified, high-level constructs that represent network and service-level capabilities, while hiding the details of their underlying realization. Abstraction enables interaction between management and automation systems without requiring direct exposure of device-specific configurations or protocol behaviors. BSS: Business Support System LxNM: Layer x Network Model (L2NM or L3NM) LxSM: Layer x Service Model (L2SM or L3SM) NEMOPS: Next Era of Network Management Operations ONSEN: Operationalizing Network and SErvice abstractioNs OSS: Operation Support System SLO: Service Level Objective Service Model Intent: The desired service behavior expressed by an operator through a service model (LxSM), as described in [RFC8309]. This refers to the set of customer requirements — connectivity, performance, availability — submitted to the orchestration layer and expected to be maintained by the network over time. When this document uses the term "service intent", it refers to Service Model Intent in this sense. Barguil, et al. Expires 2 May 2027 [Page 4] Internet-Draft ONSEN Problem Statement October 2026 3. Problem Area Qualification Criteria The ONSEN problem space has been divided into five main areas. These areas were chosen to enable work in each area to advance independently as much as possible. * Missing LxSM and LxNM functionality: Minor omissions or extensions to the existing LxNM and LxSM models that can be resolved with backward-compatible updates. * Structural LxNM/LxSM Problems: More significant structural problems with the LxNM and/or LxSM models that may require deeper changes. * Limited observability and service assurance: Absence of a standardized approach and the relevant model constructs for reporting operational state and service health. * OSS/BSS interface and API interoperability: Problems related to the interworking between YANG-based service models and the northbound APIs exposed by orchestrators toward OSS/BSS systems. * Insufficient guidance for YANG-based orchestration: Problems arising from the lack of concrete guidance or examples on how to deploy and combine the LxNM and LxSM models in practice. Finally, the Items for Future Study section captures problem areas that are recognized by the WG but are not sufficiently developed or prioritized for inclusion in the current work. 4. Missing LxSM and LxNM Functionality Operators who use the LxSM and LxNM models in real-world deployments report that the models do not provide the constructs needed to express the full range of service behaviors and operational requirements. This sections lists a number of YANG backward compatible enhancements to these models. 4.1. LxNM Updates The operator-driven LxNM updates effort [LxNM-Updates] captures concrete update requests and implementation feedback. Barguil, et al. Expires 2 May 2027 [Page 5] Internet-Draft ONSEN Problem Statement October 2026 4.2. On-Demand and Scheduled Service Operations Existing YANG service and network models are primarily designed for static, long-lived services. They do not provide the constructs needed to express service behaviors that vary over time, are triggered on demand, or follow a defined schedule. As operators introduce services such as data-intensive workload transmission or SD-WAN-like dynamic VPN capabilities, this gap becomes a concrete operational blocker. [RFC9922] defines a generic model for scheduling that could be bound to LxSM service instances. ONSEN can leverage this model to define how dynamic scheduling can be applied to the LxSM service models. 5. Structural LxNM/LxSM Problems Both during the NEMOPS workshop and as part of the ONSEN working group forming BoF session, operators have reported various difficulties which they experienced in implementing and using these models. The RFC 8969 framework [RFC8969] proposes a hierarchical three-layer approach: Service, Network, and Device, intended to promote reusability and prevent feature duplication across management layers. Operators who followed this hierarchical approach and elected to deploy both LxSM and LxNM together did so in alignment with that architecture. They report challenges in integrating the two models effectively, due to differences in parameter naming, data types, and the lack of guidance on integration logic. In the absence of standardized integration guidance, operators have resolved these challenges by implementing bespoke adaptation logic outside the abstraction framework. The consequence is that each such deployment produces a custom, closed integration layer that is tightly coupled to a specific vendor stack or orchestrator implementation. These solutions are difficult to share, extend, or migrate, and reproduce the same integration effort across independent deployments. Some operators report difficulties in selecting the relevant service model(s) for a given deployment scenario, and in applying them in real-world deployments. The L2SM [RFC8466], L3SM [RFC8299], ACaaS [RFC9834], and NSS [I-D.ietf-teas-ietf-network-slice-nbi-yang] all define service abstractions at a similar level in adjacent domains. Insufficient guidance exists on how to effectively use and compose these service models in practice. Barguil, et al. Expires 2 May 2027 [Page 6] Internet-Draft ONSEN Problem Statement October 2026 Overall, the working group would benefit from collecting operator's concrete implementation experiences and best practices arround the LxNM and LxSM models, both successful and unsuccessful. Other operators can learn from these experiences, and the working group can assess whether structural (e.g., non-backward compatible) changes to the models are warranted. 6. Limited Observability and Service Assurance Existing service and network models focus on configuration and provide no standardised mechanism for reporting whether a service is being delivered as ordered. This gap applies both to discrete operational state — whether the service is up and fault-free at a given moment — and to historical SLO compliance — whether the service has met its contracted performance targets over a given period. SAIN ([RFC9417], [RFC9418]) addresses observability internally within the provider domain through an assurance graph that enables operators to troubleshoot outages. It is not designed to be exposed to customers or to the service model layer. SAIN can contribute through a feedback loop from the SAIN Controller to the Service Orchestrator, which would then populate relevant state in LxSM/LxNM; however, that interworking is not currently defined. [RFC9375] provides raw performance monitoring data but does not include a model for expressing the outcome of evaluating that data against the SLOs set in the service model. The gap is a customer-facing service delivery reporting layer that does not currently exist in LxSM or LxNM. 7. OSS/BSS Interface and API Interoperability 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. 7.1. Northbound API Semantics Orchestration and controller systems have widely adopted YANG as a schema language, but a lack of equivalent standards for API semantics on orchestrator northbound APIs has resulted in divergent implementations and interoperability challenges. Barguil, et al. Expires 2 May 2027 [Page 7] Internet-Draft ONSEN Problem Statement October 2026 Standardized semantics for service creation, modification, and decommissioning would simplify the implementation of orchestrators and controllers, and enable better interoperability across vendors and deployments. 7.2. TMF API-Based Semantics Some operators use [TMF640]/[TMF641] as the northbound API for service ordering from their BSS. There is no specification of how these interfaces can be aligned with YANG service and network models. Operators must either pay commercial OSS/BSS vendors to build bespoke interfaces or build and maintain their own adaptation layer. The absence of a defined API creates integration complexity, lack of re- useability, vendor lock-in risk, and inconsistent implementations across deployments. 8. Insufficient Guidance for Implementing YANG-based Orchestration With the YANG Data Store [RFC7950] and the NMDA architecture [RFC8342] the IETF has standardized a clear operational model for exposing configuration and operational state from an individual NETCONF/RESTCONF server. YANG has since gained widespread adoption as a schema language for describing the data model at varous abstraction layers, above the network devices themselves. In other words, YANG is increasingly used to define the schemas for OSS systems, orchestrators, and controllers. A prime example are the IETF LxSM and LxNM models. A variety of Informational RFCs, including The YANG Module Classification [RFC8199], Service Models Explained [RFC8309], and A Framework for Automating Service and Network Management with YANG [RFC8969] have advanced the classification of, and relationships between YANG modules as well as the software components that implement them. Operators consistently report they require more precise guidelines, and a much more concrete service stack. This includes a requirement for clear guidelines on how and when to combine IETF standardized models with vendor models and user models at each layer. Further guidance is needed on the interactions between the Service and Network Models. Previous IETF work has attempted to define an exact mapping between these layers, which was determined to be impractical, yet guidance on how to manage these interactions is still needed. Barguil, et al. Expires 2 May 2027 [Page 8] Internet-Draft ONSEN Problem Statement October 2026 8.1. Other Southbound Management Interfaces Operators depend on a heterogeneous mix of network devices, and network controllers, some of which are YANG model-driven, and others that are not. Vendor-specific APIs, and legacy management mechanisms such as CLI and SNMP remain prevalent. A mix of these interfaces is common even within a single deployment. Operators require a standardized approach to integrating non-YANG modeled devices into YANG-model driven orchestration systems. This includes the ability to apply a YANG-modeled intent to non-NETCONF/ RESTCONF devices, and to collect telemetry data from non-YANG modeled devices in a way that can be correlated with YANG modeled service state and performance data. 9. Items for Future Study The following problem areas were raised during the IETF126 ONSEN work group meeting and subsequent mailing list exchanges. They are currently insufficiently developed or prioritised for inclusion in the core problem statement. They are documented here for completeness and to solicit community input on whether and how they should be addressed by ONSEN or other working groups. 9.1. Quantum-Security Requirements in Service Models An increasing number of customers require long-term data confidentiality and protection against future quantum-computing threats. Current service models do not provide a way to express quantum-security requirements or capabilities. It is not yet clear whether this is best addressed through extensions to existing models or through new model constructs. This item is considered lower priority relative to the core problems above and may be revisited in a later revision. 9.2. Secure Handling of Secrets in Orchestration Workflows Device-level configuration often requires credentials, authentication keys, or other sensitive data. There is currently no standardised mechanism for referencing sensitive information securely across the orchestration stack and resolving it only at the point of device configuration. Whether this belongs within the scope of ONSEN, NETMOD, or another WG is an open question that requires further discussion. Barguil, et al. Expires 2 May 2027 [Page 9] Internet-Draft ONSEN Problem Statement October 2026 9.3. Generic Abstraction-to-Underlay Mapping Operators repeatedly encounter the challenge of mapping service-layer abstractions to underlying infrastructure resources in a generic, technology-independent way. Existing work addresses this problem in specific contexts (e.g., TE-based approaches in TEAS) but no broadly applicable mechanism exists. The ONSEN charter defines the device layer as the lowest layer in scope; mapping below the device layer is therefore out of scope. Further information from the community on the exact problem being identified is needed before this item can be evaluated for inclusion. 9.4. Absence of Reusable Service Configuration Constructs The LxSM models do not provide templates or reusable constructs to aid operators in reducing the input parameters required for common site deployment patterns. Operators must manually configure each service instance, which increases the risk of misconfiguration and reduces operational efficiency. YANG Configuration Templates [I-D.tt-netmod-yang-config-templates], being worked on in NETMOD already provide a generic solution that addresses repetitive YANG configuration instances. 9.5. Abstractions for Telco-Cloud Scenarios Cloud-native networking and distributed cloud infrastructure are reshaping how telecommunication services are deployed and operated. Telco-Cloud environments span central data centers, edge sites, and far-edge locations, and combine networking, compute, storage, and application resources. Emerging services require placement decisions that jointly consider network and compute characteristics, but current workflows often depend on multiple cloud managers, network controllers, monitoring systems, and inventory repositories. This complexity can slow admission control and service instantiation. Better abstractions can provide a consistent view of infrastructure capabilities so orchestration systems can make faster decisions without exposing implementation detail. 10. IANA Considerations This memo includes no request to IANA. Barguil, et al. Expires 2 May 2027 [Page 10] Internet-Draft ONSEN Problem Statement October 2026 11. Security Considerations TODO 12. Informative 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-26, 26 May 2026, . [I-D.tt-netmod-yang-config-templates] Watsen, K., Ma, Q., and D. Rajaram, "YANG Configuration Templates", Work in Progress, Internet-Draft, draft-tt- netmod-yang-config-templates-04, 22 September 2026, . [LxNM-Updates] LxNM-Updates Contributors, "LxNM-Updates", n.d., . [NEMOPS] "IAB Workshop Report: Next Era of Network Management Operations (NEMOPS)", n.d., . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, . [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, . Barguil, et al. Expires 2 May 2027 [Page 11] Internet-Draft ONSEN Problem Statement October 2026 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [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, . [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, . [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, . [RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Arumugam, "Service Assurance for Intent-Based Networking Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023, . [RFC9418] Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T. Arumugam, "A YANG Data Model for Service Assurance", RFC 9418, DOI 10.17487/RFC9418, July 2023, . Barguil, et al. Expires 2 May 2027 [Page 12] Internet-Draft ONSEN Problem Statement October 2026 [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . [RFC9834] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios, O., Barguil, S., and B. Wu, "YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS)", RFC 9834, DOI 10.17487/RFC9834, September 2025, . [RFC9922] Ma, Q., Ed., Wu, Q., Boucadair, M., Ed., and D. King, "A Common YANG Data Model for Scheduling", RFC 9922, DOI 10.17487/RFC9922, March 2026, . [TMF640] TM Forum, "TMF640 Service Activation and Configuration API User Guide v4.0.1", n.d., . [TMF641] TM Forum, "TMF641 Service Ordering Management API User Guide v4.1.1", n.d., . Authors' Addresses Samier Barguil Nokia Email: samier.barguil@nokia.com Kris Lambrechts Intwine Email: kris@intwine.net Chongfeng Xie China Telecom Email: xiechf@chinatelecom.cn Barguil, et al. Expires 2 May 2027 [Page 13]