| Internet-Draft | SOYA | October 2026 |
| Lambrechts & Larsson | Expires 30 April 2027 | [Page] |
This document defines the Service Orchestration with YANG-modeled Abstractions (SOYA) framework for building layered orchestration systems. Each layer exposes YANG-modeled service intent and operational state, and uses business logic to translate intent into configuration for the layer below. The framework describes the boundaries between layers, the propagation of configuration and state, and the separation of service processing from management protocol implementation. These principles apply to layers hosted within one orchestrator or distributed across several orchestrators.¶
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 30 April 2027.¶
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.¶
Delivering a network service requires a service provider to translate service requirements into network and device configuration. This translation involves decisions at different levels: what service is required, which network resources and functions will provide it, and how those functions are configured on particular devices. Combining these decisions in the same automation logic couples service delivery to the details of the underlying infrastructure.¶
Service abstractions provide boundaries between these decisions. For example, a device replacement may change how a network function is configured without changing the service that depends on it. Such boundaries also support delegation between teams: one team can request a capability while the team providing it retains responsibility for its implementation. To preserve these boundaries, each abstraction needs a defined interface and clear authority over the configuration used to realize it.¶
These responsibilities continue after initial provisioning. Accepted service requirements may not yet be realized, configuration changes may complete only partially, and failures in shared resources may affect several services. Each abstraction therefore needs to relate its requested services to their dependencies and report whether those services have been realized and remain healthy.¶
YANG ([RFC7950]) can describe configuration and operational state at each level of abstraction. Building an orchestration system from these models also requires rules for how the abstractions interact: where translation takes place, which component may change configuration, and how observations are interpreted as service state.¶
This document defines the Service Orchestration with YANG-modeled Abstractions (SOYA) framework to describe these interactions. Each layer exposes a YANG-modeled service interface, translates its accepted intent into configuration for the layer immediately below, and derives its service state from operational observations. The framework defines schema and datastore boundaries, configuration ownership, and processing responsibilities. These rules apply whether layers are hosted within one orchestrator or distributed across several orchestrators.¶
SOYA leaves the number of layers, their schemas, and their business logic to the deployment. A layer may decompose one service into several lower-layer service instances, or combine several inputs into configuration for a shared resource. YANG defines the data and its constraints; executable business logic supplies the mapping between abstractions. The framework accommodates different mapping implementations and management protocols without prescribing a common service schema or a distributed transaction mechanism.¶
[RFC8309] describes network service models, and [RFC8969] provides a framework for automating service and network management with YANG. SOYA develops the layer boundaries and processing rules for an orchestration system built around such models. Existing service, network, and device models can be used at suitable layers.¶
The Service Assurance for Intent-Based Networking (SAIN) orchestrator defined in [RFC9417] could be integrated with a SOYA Orchestrator to derive an assurance graph from service intent and the corresponding configuration generated for lower layers and devices. The SOYA orchestrator would configure the SAIN orchestrator with the necessary context about the services and their dependencies through the YANG modules defined in [RFC9418]. The resulting health scores and symptoms, gathered by a SAIN collector, could be fed back to the business logic at the relevant SOYA layer.¶
The terms "datastore", "configuration datastore", "applied configuration", "system state", "operational state" are used as defined in the Network Management Datastore Architecture (NMDA) (Section 3 of [RFC8342]). The running configuration datastore (<running>), candidate configuration datastore (<candidate>), intended configuration datastore (<intended>), and operational state datastore (<operational>) also follow the definitions in that document.¶
This document defines the following terms:¶
A SOYA Orchestrator receives, stores, and processes service intent for each layer it hosts. Each layer must provide, at a minimum, a logical <running> configuration datastore as defined in Section 5.1.3 of [RFC8342]. Its contents represent the current intent accepted by that layer.¶
A change to the running configuration triggers the layer's business logic. That logic determines the configuration needed at the next lower layer. At the lowest service layer, it determines device configuration, submitted through a YANG-based device interface or an adapter. Creation, modification, and deletion of service instances all follow this processing model.¶
A layer may also collect operational state from other layers or from the devices it manages. Its business logic evaluates these observations and may update its own service state, generate notifications or alarms, or revise configuration for the next lower layer. Reactions to state follow the same configuration ownership and layering rules as the processing of incoming intent. Only the lowest service layer generates device configuration.¶
A single-layer SOYA Orchestrator hosts one service layer. Its northbound interface accepts intent and exposes state for that layer. Its southbound integration delivers generated configuration to the next layer or to managed devices. Several single-layer orchestrators can form a complete orchestration stack.¶
A multi-layer SOYA Orchestrator hosts several service layers within one instance. Each layer retains its own schema, logical datastore context, and business logic, following the rules in Section 3. The implementation may share processes, storage infrastructure, or reusable code while preserving these logical boundaries.¶
A layer's business logic reads intent only from its own layer and submits configuration only to the layer immediately below it, or to devices when it is the lowest service layer. Communication between co-located layers may use internal interfaces, provided that schema validation, configuration ownership, and state semantics are preserved. Co-location does not permit bypassing an intermediate layer.¶
A service layer defines a level of abstraction and the business logic that realizes services at that level. An NMDA datastore defines a logical context for storing and accessing YANG-modeled data ([RFC8342]). The layer determines what the data represents and how it is processed, while its datastores distinguish accepted configuration, intended configuration, and operational state.¶
NMDA describes datastores in terms of device configuration and state, but the same concepts apply to service layers within an orchestrator. Each SOYA layer has its own logical datastore context, whose contents describe that layer's abstraction, such as VPN services or a desired network topology. The <running>, <intended>, and <operational> datastores describe data within that layer; they are not separate service layers. Transforming configuration within this context is distinct from generating configuration for the next SOYA layer.¶
For example, a layer's <intended> datastore may describe the VPN services to be realized. Its business logic translates these services into connectivity requests for the layer below, where they are processed within that layer's own datastore context. As lower layers apply configuration and report observations, each layer uses those observations to determine the applied configuration and service state it exposes through <operational>. The VPN layer expresses these results in terms of VPN services, while lower layers express them in terms of their own abstractions. Each layer therefore maintains its own configuration and state at its own level of abstraction, even when several layers are hosted within one orchestrator.¶
Within each layer, <operational> contains applied configuration, represented by "config true" nodes, together with system state represented by "config false" nodes. Service health, realization progress, and failure information are examples of state that a layer can model using "config false" nodes. Each layer should define what it means for its configuration to be applied and distinguish this from the health of the service it provides. For example, a VPN's configuration may remain applied while a supporting resource failure degrades its connectivity.¶
A SOYA system consists of one or more service layers, each responsible for a particular abstraction. A layer's schema comprises the YANG modules, enabled features, and deviations supported in that layer's datastore context. YANG validation takes place within that context. XPath expressions, leafrefs, and augmentations must resolve within the layer's schema and data trees; they cannot access another layer's datastore.¶
Layers can reuse common modules, types, groupings, and identities. Importing shared definitions, as described in [RFC7950], does not give access to another layer's data. Similarly, a YANG module retains its namespace when used at more than one layer. The separation between layers is established by their schema and datastore contexts, rather than by assigning a new XML namespace to each layer.¶
The following subsections describe how intent is translated down through the layers and how operational state is interpreted and published upwards. They also discuss configuration ownership, service dependencies, and the processing needed to maintain services when realization is interrupted or only partially completed.¶
Translating intent through successive layers keeps each layer's implementation details within its own scope. Restricting configuration updates to the layer above preserves responsibility for generated configuration and prevents independent writers from making changes that conflict with, or are overwritten by, that layer's processing.¶
Intent originating outside the orchestration system enters at the highest service layer through the northbound interfaces, as described in Section 4. Each layer's business logic translates its own intent into configuration for the layer immediately below. The generated configuration becomes the receiving layer's intent and is validated against that layer's schema.¶
Lower layers must accept configuration updates only from the layer above. Their configuration may be exposed to authorized outside observers for inspection, but those observers must not modify it. The same ownership rule applies when a state change causes a layer to generate new configuration as part of a recovery action.¶
The lowest service layer translates its intent into configuration expressed through the YANG models exposed by the managed device or its adapter. The southbound interfaces described in Section 5 carry these updates to the target. Protocol implementation belongs to the southbound integration; the business logic determines which configuration is needed to provide the service.¶
The state of individual resources does not by itself establish whether a service meets its requirements. Each layer interprets observations using its knowledge of the services it provides and their dependencies. Publishing the resulting service state allows higher layers to assess their own services without reproducing lower-layer interpretation logic.¶
Each layer's business logic maintains and publishes the state of the services it provides. Derived information, such as service health or realization progress, is exposed as "config false" YANG-modeled data. The distinction between this information and applied configuration is described in Section 2.3.¶
A layer may read operational state from anywhere in the stack, subject to authorization. The preferred pattern is to consume state from the layer immediately below and publish an abstraction for the layer above. Access to operational state does not grant authority to modify the observed layer's configuration or use its running configuration as an additional source of intent.¶
For example, the lowest service layer may evaluate device interface state to determine whether a tunnel is available. The layer above can combine that tunnel state with other dependencies to determine whether a connectivity service is healthy. A failed interface need not imply a failed service if a working alternative still satisfies the service's requirements. Each layer is responsible for the meaning of the state it publishes.¶
Each layer should retain the association between a service instance and the lower-layer configuration it creates or uses. These associations support fault correlation, updates, recovery, and removal of obsolete configuration. Stable identifiers allow an observation or failure at a lower layer to be related to the affected service instances. The identifiers and associations are maintained through the layer's internal implementation; they do not require cross-layer references such as YANG leafrefs.¶
One service instance may depend on several lower-layer configuration elements, and one lower-layer configuration element may support several services. The layer generating the configuration is responsible for reconciling these demands and resolving conflicts before submitting an update. If several orchestrator instances host the same logical layer, they need an ownership or coordination mechanism so that their writes do not conflict.¶
Deleting a service removes the configuration that is no longer required for that service. Shared configuration elements must remain while they are needed by other services. A layer should retain enough association and processing state to complete or retry cleanup after an interruption, even if the original intent has already been removed from its running configuration.¶
Schema validation determines whether intent conforms to a layer's YANG schema. Realizing valid intent can still fail because of unavailable resources, service policy, communication failures, or errors at a lower layer. A layer may check feasibility before accepting intent where possible, and reports failures discovered during subsequent processing through its operational state.¶
A layer should distinguish acceptance of intent, progress in realizing it, and the resulting service health. The layer's models define the status information and its meaning. Observations should be correlated with the service instance and the intent revision or processing attempt they describe. A delayed result for an older request must not be treated as confirmation that the current request has been realized. Missing or stale observations should be distinguishable from a confirmed service failure.¶
Processing continues after the initial intent update. Following a restart, missed observation, or failed update, a layer reconciles the configuration it has generated with the desired result derived from its current intent. Repeated processing of unchanged intent should converge on the same result without duplicating resources. The southbound integration may retrieve target configuration to synchronize or verify delivery; this does not make target configuration an additional intent source for the layer's business logic.¶
A datastore operation on one target does not provide an atomic transaction across all layers or devices. A layer must account for partial completion and uncertain outcomes, including loss of a response after an update was applied. Its business logic decides whether to retain completed changes, compensate for them, or pursue another realization of the service. The protocol integration or adapter performs the corresponding target operations. Affected service state should remain visible while recovery is in progress.¶
A northbound interface exposes the YANG-modeled service intent and operational state of an orchestration layer. At the highest layer, clients may include operations support systems and business support systems (OSS/BSS), customer portals, or other applications. At a lower layer, the client submitting intent is the SOYA Orchestrator hosting the layer immediately above, as described in Section 3.1. The same interface therefore serves as the northbound interface of the lower layer and the southbound interface of the upper layer.¶
Each interface must preserve the schema and datastore boundaries of the layer it exposes. A multi-layer SOYA Orchestrator may use separate endpoints or explicitly selected logical server contexts. Each context exposes the datastores and schema of the selected layer. Clients should be able to discover its supported modules, revisions, features, and deviations using YANG Library ([RFC8525]). The deployment defines how the client selects a layer; YANG Library describes the schema within that context. If multiple protocols expose the same layer, they must provide a consistent view of its data. Access control must enforce the ownership rules in Section 3.3 and Section 3.1.¶
Incoming intent is validated against the receiving layer's schema before it is accepted into the running configuration. Changes to the running configuration trigger that layer's business logic. A successful protocol response confirms completion of the requested datastore operation. The layer's operational state reports the progress and outcome of service realization separately, as described in Section 3.4.¶
Clients may retrieve operational state on demand. An implementation may also offer notifications or datastore subscriptions, such as YANG-Push ([RFC8641]), using supported protocol bindings. Clients need to account for interruptions in state delivery and obtain a current view after reconnecting.¶
A SOYA Orchestrator may expose a layer as a NETCONF server ([RFC6241]). Clients submit intent using <edit-config> against <running> when the :writable-running capability is advertised, or against <candidate> followed by <commit> when the :candidate capability is advertised. Edits to <candidate> alone do not trigger realization of the intent. Validation failures and other request errors are returned as <rpc-error> elements.¶
Clients retrieve configuration with <get-config> and running configuration together with state data with <get>. When the NETCONF NMDA extensions are supported ([RFC8526]), <get-data> provides explicit access to <operational>, including applied configuration. The configuration returned by the legacy <get> operation is the running configuration and should not be treated as evidence of what has been applied.¶
A SOYA Orchestrator may expose a layer as a RESTCONF server ([RFC8040]). Service instances are represented as YANG data resources using XML or JSON encoding. Clients create intent resources using POST or PUT, replace them using PUT, modify them using PATCH, and delete them using DELETE. GET retrieves configuration and operational state. HTTP status codes and RESTCONF error responses report request failures. Clients should use conditional requests with entity-tags to avoid overwriting concurrent changes.¶
When the RESTCONF NMDA extensions are supported ([RFC8527]), clients can explicitly retrieve the layer's operational datastore through the {+restconf}/ds/ietf-datastores:operational resource.¶
A southbound interface carries the configuration generated by a layer's business logic to the next lower orchestration layer, or to managed devices at the lowest service layer. The SOYA Orchestrator acts as a client of the receiving system. Its business logic translates intent into configuration that conforms to the receiving system's schema. The interface also provides access to operational state that the business logic uses to derive its own layer's state.¶
The northbound and southbound protocols of a SOYA Orchestrator may not be the same. For example, intent received over RESTCONF may result in configuration delivered over NETCONF. The business logic determines the configuration to generate, while the southbound integration handles protocol operations and target capabilities. For YANG-based targets, this includes discovering the supported schema through YANG Library ([RFC8525]), when available.¶
The integration reports configuration results and communication failures to the sending layer. Protocol-level retries and recovery are performed by the integration, while the business logic decides how to respond at the service level. The reconciliation rules in Section 3.4 apply when several targets are involved or an operation's outcome is uncertain.¶
For a NETCONF southbound interface, the SOYA Orchestrator acts as a NETCONF client ([RFC6241]). It inspects the server's advertised capabilities and selects the appropriate configuration workflow, such as editing <candidate> and committing it, or editing <running> directly. Locking coordinates edits to shared datastores. Optional validation, confirmed-commit, and rollback-on-error capabilities provide additional controls when supported. A failed edit can leave partial changes depending on the selected error handling. After an error or a lost response, the client determines the target's state before retrying operations that could conflict with previous work.¶
The client processes <rpc-error> replies and retrieves configuration with <get-config> and running configuration together with state data with <get>. With the NMDA extensions ([RFC8526]), <get-data> on <operational> provides applied configuration and system state.¶
For a RESTCONF southbound interface, the SOYA Orchestrator acts as a RESTCONF client ([RFC8040]). It maps the generated configuration to the target's YANG data resources and applies it using the appropriate HTTP methods. Conditional requests can protect updates against concurrent changes. The client processes HTTP status codes and RESTCONF errors, and retrieves operational state using GET, including access to the operational datastore when the target supports the NMDA extensions ([RFC8527]).¶
Managed devices may expose interfaces that do not use YANG, such as a command-line interface, SNMP, or a vendor-specific API. Such devices can be integrated through an adapter that exposes a YANG-modeled interface to the lowest service layer for both configuration and operational state.¶
The adapter is responsible for all operations associated with implementing the device's management protocol. This includes protocol communication, translation between YANG-modeled data and native device representations, command sequencing and execution, state collection, and protocol-specific error handling. Protocol-specific validation, retries, and rollback are also implemented by the adapter where supported. The adapter exposes collected device state and configuration operation results through its YANG-modeled interface, together with any limitations in the operations it supports. The exposed models should provide a way to indicate unavailable or stale state. The adapter uses those model-defined semantics so that a missing observation is distinguishable from a confirmed failure or successful operation.¶
The lowest service layer's business logic consumes the adapter's interface as it would a YANG-modeled device interface. It translates service intent into the configuration submitted to the adapter and uses the state exposed by the adapter to determine and publish the layer's own service-level operational state. Service-level recovery decisions remain with the business logic, based on the results and limitations reported by the adapter. This separates service intent processing from the implementation of the device's management protocol.¶
Consider a Layer 3 virtual private network (L3VPN) connecting two customer sites, requested using the L3VPN Service Model (L3SM) in [RFC8299]. The request describes the sites, their network accesses, and connectivity requirements. Three SOYA service layers realize the request, as shown in Figure 1. The network and device abstraction layers use deployment-specific YANG models.¶
Customer / service application
| ^
| L3SM intent | L3SM state
v |
+------------------------------------------+
| Service layer |
| L3SM (RFC 8299) |
+------------------------------------------+
| ^
Network intent | | network state
v |
+------------------------------------------+
| Network layer |
| Deployment-specific network model |
+------------------------------------------+
| ^
Function intent | | function state
v |
+------------------------------------------+
| Device function layer |
| VRFs, customer interfaces, ... |
+------------------------------------------+
| ^
Device config | | device state
v |
+------------------------------------------+
| Device model level |
| YANG-capable devices or adapters |
+------------------------------------------+
The service layer maps the customer sites and requirements to provider-network endpoints and connectivity. It expresses the result as configuration in the deployment's network model, which becomes the network layer's intent.¶
The network layer decomposes that intent into requests for functions on selected devices: for example, a virtual routing and forwarding (VRF) instance, routed interfaces, BGP neighbors, and bandwidth policies. These requests form the intent consumed by the device abstraction layer.¶
The device abstraction layer translates function requests into configuration conforming to each target's supported device models. Its business logic handles differences in device schemas and capabilities. The southbound integration or YANG-facing adapter performs all management protocol operations, as described in Section 5.¶
If an interface fails, the device abstraction layer reports the affected function's state. The network layer associates that function with the VPN connectivity it provides, and the service layer derives the customer-facing service state through (augmentations to) the L3SM. Any recovery action follows the same layer boundaries.¶
This memo includes no request to IANA.¶
A SOYA Orchestrator translates accepted intent into changes that may affect many services and devices. Management connections must authenticate their peers and protect the integrity and confidentiality of exchanged data. Each layer must authorize configuration changes, operations, and access to state. NETCONF and RESTCONF deployments can use the Network Configuration Access Control Model ([RFC8341]) to express these permissions.¶
Authorization must preserve the ownership rules described in Section 3.1. A client permitted to submit intent at the highest layer must not thereby gain write access to lower layers. Co-located layers need equivalent isolation in their internal interfaces. Access to configuration and operational state should also respect tenant boundaries, since either can reveal customer identities, topology, or service dependencies.¶
Orchestrator and adapter credentials should be limited to the targets and operations required for their roles. Business logic and adapters are trusted components: faulty or compromised translation code can turn an authorized request into unintended configuration. Schema validation should be supplemented with policy and resource checks appropriate to the service. Configuration generated for a lower layer is subject to that layer's own validation and authorization.¶
Operational observations can trigger automated recovery. Their source, integrity, and freshness therefore matter as much as those of incoming intent. A layer should account for stale, replayed, or missing observations before generating changes. Audit records should relate incoming intent, generated configuration, relevant observations, and recovery actions to the affected service instances. Logs and retained associations require protection appropriate to the sensitive data they contain.¶