YANG Data Models for Network Service Configuration

YANG data models give network service configuration a machine-readable contract in place of a set of CLI instructions. Their operational value depends on enforcing that contract through transactional protocols and a shared OSS data model. Together, these elements make qualification, design, activation, and assurance repeatable and auditable, while giving AI agents defined limits within which to act.

What YANG actually is and what problem it solves for service configuration

CLI-driven automation treats text intended for human operators as an interface between systems. That interface differs from vendor to vendor, so platforms that deliver the same service need separate playbooks. Commands run in sequence also have no shared transaction boundary, so if a step fails, they can leave partial configuration without automatic rollback. Configuration drift occurs when those changes no longer match the service as intended. The missing element is a common, enforceable schema.

YANG is a schema language. It defines the structure, constraints, and relationships of configuration and operational data, while NETCONF and RESTCONF transport that data. This separation lets validation engines reject invalid input before a change reaches a device, rather than exposing the error during service operation. Automation can then be repeated across devices and used across vendors that expose the same model. Structured payloads also make changes traceable in change management systems, giving operators an auditable record rather than command text that must be interpreted after the event.

How NETCONF and RESTCONF turn the YANG schema into transactional, governed operations

NETCONF gives the schema an execution boundary. It operates over SSH on port 830 and exchanges capability advertisements through a hello message, allowing a client to discover the YANG modules and capabilities a device supports. Where the candidate datastore is supported, proposed changes can be staged without altering the running configuration. The client locks the candidate, submits an edit-config operation, validates the proposed data against YANG constraints, and commits atomically or discards the changes. With the supported transactional mechanisms in place, a failure takes execution back to a known-good state instead of leaving a series of commands only partly applied.

Capability discovery keeps automation from assuming that all devices behave the same way. A client that finds no candidate datastore can fall back to direct running-config edits, but that path does not provide the same staged workflow. Datastore support therefore shapes how the OSS executes a change. The candidate holds a design waiting for activation, the running datastore holds the active configuration, and startup keeps configuration through device restarts. The schema sets out which data are allowed, while the protocol and supported capabilities control how changes take effect.

RESTCONF exposes the same YANG-modeled data over HTTP/HTTPS. This gives orchestration layers and service portals access without requiring them to speak XML/SSH. The schema remains shared across those interfaces. However, a common data model does not make every transport interaction equivalent to NETCONF’s candidate-and-commit sequence. Governed service delivery depends on preserving both the model’s constraints and the execution guarantees required by the workflow.

The three-layer YANG hierarchy that connects customer service intent to device configuration

RFC 8309, developed through IETF OPSAWG, describes the hierarchy connecting customer service models, network service models, and network element models. Each layer serves a different operational audience. A customer or service orchestrator works with bandwidth, SLA, and VPN topology, while a controller works with BGP policies, TE tunnels, and interface parameters. The device layer expresses the configuration a router or switch receives. Intended network configuration is derived from the service model, and intended device configuration is derived from the network model.

These derivations connect qualification to execution without requiring a human to translate the service at every handoff. Qualification checks whether the network has the resources for the requested circuit, while provisioning applies the configuration drawn from that request. Both can use the same structured representation of the service. RFC 9182 defines L3NM, and RFC 9291 defines L2NM. Providers have implemented these models to automate BGP-based L3VPN and EVPN/VPWS deployment, giving the hierarchy a practical role beyond architectural documentation.

The TE Service Mapping draft, version 18 of October 2025, carries that link across domains by mapping service requests from customers to TE tunnels and Virtual Networks. It enables the MDSC to coordinate VPN service mappings onto TE resources through the customer mapping/translation and virtual service coordination functions described in RFC 8453. This is especially relevant to CLECs and wholesale operators with multi-domain footprints. Service catalogs and templates alone do not enforce such relationships. A schema-driven implementation uses the hierarchy at runtime, so service changes can propagate through network and device layers without manual re-derivation.

Where the IETF standards stack stands today and what gaps real deployments have exposed

Production use of L3NM and L2NM has exposed places where published models are too coarse for service delivery requirements. L3NM supports static routes within a VPN and allows an operator to request BFD. Its static-route sub-tree, however, offers only a boolean bfd-enable flag, without controls for the minimum receive interval or multiplier at that level. Critical services may need more precise settings for failure-detection. The gap is not the absence of a model, but insufficient parameterization within it.

IETF working groups can refine the schema around requirements that operators encounter in production, although operators cannot always wait for a revised RFC. IEEE 802.3 is launching an open-source project to produce YANG modules for Ethernet standards, bringing this approach into the Carrier Ethernet provisioning stack used by CLECs and wholesale operators.

The TE Service Mapping draft says its main use is for monitoring and diagnostics of management systems, showing how service requests map onto the resources beneath them. Its references to “new and advanced parameters” and that monitoring role also appear in earlier versions, rather than representing changes unique to version 18. Published RFCs and drafts that are still changing thus have different roles in a plan for implementation. Operators building on L3NM and L2NM should design abstraction layers to handle YANG module versioning, so they can change models without having to rebuild the whole implementation.

How YANG-based incident management closes the loop between service health and the data model that delivered the service

Provisioning data becomes more useful when faults can be interpreted against the service it describes. RFC 8632 addresses alarms, while RFC 9375 addresses performance monitoring, but these data can reside at different layers in separate management systems. As services grow, the resulting volume of alarms and metrics can overwhelm conventional OSS processing. Explaining the service impact requires relationships between the affected resources and the services that depend on them.

The IETF NMOP working group’s network incident management draft, version 18 of October 2026, defines a YANG module for reporting, diagnosis, troubleshooting ticket reduction, and probable root cause analysis. Its mechanism is to correlate alarms, metrics, and anomalies from multiple layers into aggregated incidents. A failed protocol interface, for example, may generate many alarms but produce one incident tied to that interface. Dependency relationships turn those separate observations into a structured account of the fault. The draft remains work in progress.

An incident that references the service model used during provisioning lets the OSS identify affected customer services without reconstructing that relationship in a separate correlation step. The draft explicitly identifies AI and ML as technologies for processing large data volumes and complex correlations. A structured incident schema gives those tools input in a consistent form in place of raw alarm text. Connected provisioning and incident models then allow AI to reason about service health against the intended service state.

What AI agents actually need from a data model before they can act on service configuration safely

The move toward agentic AI in telecom operations in 2026 changes what governance must cover because agents can orchestrate tasks as well as recommend actions. An agent able to commit configuration needs enforceable constraints, a transaction boundary that limits the scope of a change, and an audit trail. YANG supplies the schema foundation for these controls. Protocols and the OSS must enforce the rest, consistently for human and machine operators. An agent cannot receive a separate execution path that bypasses the checks applied to an engineer.

Per-change records should identify the model version, supplied inputs, confidence threshold at execution time, executing principal, and result of pre-execution verification. These fields support investigation after a degradation event. Structured payloads make the information capturable, but the OSS must actually record it. If an agent acts outside the shared APIs and permission structures, the ability to trace its work breaks down where the machine starts to execute.

Attackers may tamper with an agent’s goals or behavior, and compromised training data or injected false telemetry could cause mass rerouting. Consistent schema enforcement limits what an agent can commit, even though it does not establish whether the agent’s reasoning is sound. Ericsson’s 2026 integration of agentic AI into its OSS/BSS platform, including its Intelligent Automation Platform and OSS/BSS Business Value Pathways, provides an early production example of zero-touch operations. Before touching the live network, agents should test the actions they propose against a YANG-modeled digital twin that tracks the real service state in place of a static snapshot.

Why legacy OSS architectures cannot host YANG-governed AI operations and what a unified model requires

A digital twin cannot provide reliable service context if qualification, design, provisioning, and assurance each maintain an incompatible account of the service. In that architecture, schema continuity breaks at the handoffs. Structured data may leave one system as unstructured input to another, losing constraints and relationships along the way. Middleware can bridge the systems without removing that fragmentation. Downstream agents then receive a degraded representation of service state, even if an upstream component uses YANG correctly.

FTTH consolidators building multi-state footprints are advised to harmonize OSS/BSS and address data early to avoid stranded assets and provisioning friction. Many ILECs and CLECs also need middleware between older systems and modern OSS. The architectural requirement goes beyond exchanging records. Qualification, design, provisioning, and assurance need to read and write the same underlying YANG-modeled service representation.

Shared data must also mean shared governance. Human operators and AI agents need to use the same APIs, permission structures, and audit logging when they work with that model. Otherwise, a unified interface can conceal separate rules for executing changes. TM Forum research from November 2025 found that only a minority of CSPs had successfully embedded AI in more than three OSS or network functions. That finding is consistent with the architectural constraint, although it does not by itself establish its cause. Fragmented service data limits how far governed AI operations can extend across workflows.

What YANG-native OSS operations look like end to end, from qualification through activation

In a YANG-native workflow, qualification begins with the model for the requested service type, including FTTH, dedicated internet, or Carrier Ethernet. The service parameters are checked against the network model and available resources. Because the qualified request remains in the shared model, design can derive network configuration without reconstructing the customer’s requirements in another system. L3NM, L2NM, and TE mapping provide the network-layer structure for BFD settings, BGP policies, and TE tunnel assignments within the supported model constraints.

Provisioning then moves the design into an execution boundary. NETCONF’s candidate datastore holds the proposed configuration for validation before commit, where the device supports that workflow. Atomic commit semantics keep a failed provisioning operation from leaving a partially configured state within that transaction. Activation is therefore tied to the validated design, rather than to the successful completion of an unstructured command sequence. Post-activation assurance uses the incident model to link what is observed in operation to the same service definition, so anomalies can be checked against the intended configuration.

An agent consumes the constrained service representation, proposes a design change, and tests it against the digital twin before execution. If it executes, it uses the shared API, permissions, and audit trail. Its authority comes from that governed path. YANG-native service delivery makes the service definition an enforceable contract throughout its operational life, with no exemption when the operator is a machine.