9.518 min read

SOM + Itential + NSO: The Three-Layer Stack

Sections 9.3 and 9.4 showed SOM delegating directly to execution engines such as Cisco NSO, MANO, and SD-WAN controllers. That pattern works well when SOM has tight control over a small number of engines and the automation logic is simple. But in complex multi-vendor environments — where pre-checks, post-validation, compliance audits, and multi-step workflows are required before and after every network change — operators often insert an automation middleware layer between SOM and the device controllers. The three-sentence summary: SOM decides what to do (CFS→RFS decomposition, routing, lifecycle tracking). Itential decides how the automation runs (workflow selection, pre/post checks, API aggregation). NSO safely executes the network change (transactional commit, YANG/NED translation, rollback).

This section uses Itential as the concrete example because it is the most widely deployed automation middleware in this space. However, the pattern is vendor-neutral — any platform that provides workflow orchestration, API aggregation, and pre/post validation (e.g., Ansible Tower/AWX, StackStorm, custom microservices) could fill the same architectural role. The key insight is the separation of concerns: SOM should not contain automation workflow logic, and NSO should not contain business-level decision-making.

The Three Responsibilities

SOM: What To Do

SOM (Service Order Management) receives service orders via TMF641, decomposes CFS into RFS items using the service catalog, routes RFS work items to the correct execution engine, and tracks the lifecycle of each order item via TMF638. SOM understands service topology and cross-service dependencies. It does NOT know automation workflow details (e.g., which pre-checks to run) or device CLI syntax. SOM's job ends when it dispatches work items and resumes when it receives status callbacks.

Itential: How To Automate

Itential (or equivalent automation middleware) receives RFS work items from SOM, selects the appropriate automation workflow, assembles a multi-step execution plan (pre-checks → dry-run → commit → post-validation → audit), and aggregates APIs from multiple downstream controllers. It provides workflow visibility, retry logic, and compliance enforcement. It does NOT own service state or understand CFS/RFS decomposition — it treats each work item as an independent automation task.

NSO: Safe Network Change

Cisco NSO receives a config intent via RESTCONF, translates it to device-native configuration using YANG models and Network Element Drivers (NEDs), and executes a transactional commit across one or more devices with automatic rollback on failure. NSO provides atomic multi-device transactions, config audit/compliance, and a commit queue for queuing changes. It does NOT decide what to provision — it executes exactly what it is told, safely.

Three-Layer Flow Diagram

Three-Layer Stack — SOM decides WHAT, Itential decides HOW, NSO EXECUTES the network change

SOM dispatches RFS work items to Itential, which orchestrates pre-checks, calls NSO for the network change, runs post-validation, and reports back to SOM.

How Itential Fits Between SOM and NSO

The following 8-step walkthrough traces a single RFS work item from SOM through Itential to NSO and back. In practice, SOM dispatches multiple RFS items in parallel — each follows this same flow independently.

Request Flow: SOM → Itential → NSO → Network

SOM Receives Service Order

SOM

SOM receives a service order (TMF641) from COM containing one or more CFS items. SOM decomposes each CFS into RFS items using the service catalog.

SOM Dispatches RFS Work Items to Itential

SOM → Itential

Instead of calling NSO directly, SOM dispatches RFS work items to Itential via REST API or TMF652 resource order. Each work item contains the RFS type, target parameters, and required action (create/modify/delete).

Itential Selects Automation Workflow

Itential

Itential matches the RFS type and action to an automation workflow from its workflow library. For example, RFS:PE-VRF-Config with action "create" maps to the "L3VPN-Site-Provision" workflow, which includes pre-checks, dry-run, commit, and post-validation steps.

Itential Runs Pre-checks

Itential

Before touching the network, Itential runs pre-validation: device reachability ping, current config audit (does VRF already exist?), resource availability check (are IP addresses allocated?), change-window compliance (is this within the approved maintenance window?).

Itential Calls NSO with Dry-Run Then Commit

Itential → NSO

Itential submits the config intent to NSO via RESTCONF. First a dry-run (NSO calculates the device-level diff without applying). If the diff is clean, Itential triggers the real commit. If the dry-run reveals conflicts, Itential aborts and reports the issue.

NSO Executes Transactional Commit

NSO → Network

NSO translates the YANG service model to device-native config via NEDs (IOS-XR, Junos, SR OS), then pushes configuration to all affected devices in a single atomic transaction. If any device rejects the change, NSO rolls back all devices to their pre-change state.

Itential Runs Post-validation

Itential

After NSO confirms a successful commit, Itential runs post-checks: BGP neighbour verification (are VPNv4 sessions established?), ping test (can sites reach each other?), golden config audit (does the running config match the expected template?). If post-checks fail, Itential can trigger an NSO rollback.

Itential Reports Success to SOM

Itential → SOM

Itential sends a status callback to SOM with the result (success/failure), execution log reference, and any post-check results. SOM updates the service order item status and service inventory (TMF638).

Worked Example: Enterprise L3VPN Through Three Layers

Section 9.3 walked through an Enterprise L3VPN provisioned via direct SOM→NSO integration. Here we show the same scenario with Itential in the middle — same outcome, but with added automation safeguards.

In the direct SOM→NSO pattern from Section 9.3, SOM builds the RESTCONF payload and calls NSO directly. This is simpler but places all automation responsibility on SOM.

SOM decomposes CFS:L3VPN-Service → RFS:PE-VRF-Config (3 sites)
SOM builds RESTCONF payload with VRF name, route targets, BGP peers, interfaces
SOM calls NSO RESTCONF API directly — no pre-check, no dry-run unless SOM implements it
NSO commits to PE routers atomically
SOM polls NSO commit queue or receives callback for status
No post-validation — SOM assumes success if NSO returns 200 OK
No compliance audit — golden config check would require a separate tool
If BGP sessions fail to establish, SOM only discovers this via a separate assurance system (if one exists)

What Itential Adds That Direct SOM→NSO Doesn't

The three-layer pattern adds capabilities that neither SOM nor NSO provide alone. The following comparison highlights the key differences across nine dimensions.

Direct SOM→NSO vs SOM→Itential→NSO

Capability	Direct SOM→NSO	SOM→Itential→NSO
Pre-checks before change	SOM must implement its own or skip — typically skipped	Itential runs device ping, IPAM check, change-window validation as standard workflow steps
Post-validation after commit	Not performed — SOM trusts NSO 200 OK as success	Itential verifies BGP sessions, runs ping tests, audits golden config after every commit
Compliance enforcement	Requires separate compliance tool or manual audit	Itential enforces compliance policies as workflow gates — blocks non-compliant changes
API version insulation	SOM tightly coupled to NSO RESTCONF API version	Itential abstracts NSO API — SOM only talks to Itential REST; NSO API changes are isolated
Multi-controller support	SOM must integrate with each controller individually	Itential aggregates multiple controllers (NSO, MANO, SD-WAN, cloud APIs) behind a single workflow interface
Retry and error handling	SOM handles retries at the RFS dispatch level	Itential handles step-level retries within a workflow — retries a failed post-check without re-running the entire commit
Change window enforcement	SOM may queue orders, but lacks fine-grained maintenance window logic	Itential checks per-device or per-region maintenance windows before executing
Workflow visibility	SOM tracks order status (pending/in-progress/complete) — no step-level detail	Itential provides step-by-step execution log with timestamps, inputs/outputs, and per-step status
Operational complexity	Lower — fewer moving parts, fewer systems to maintain	Higher — adds a system layer, requires workflow maintenance, increases integration surface

When NOT to Use the Three-Layer Pattern

The three-layer pattern adds value in complex, multi-vendor environments but is unnecessary overhead when: (1) you have a single network controller (NSO) with few device types — direct SOM→NSO is simpler and sufficient; (2) your automation needs are minimal — no pre/post checks, no compliance requirements, simple commit-and-done workflows; (3) your SOM already has strong built-in orchestration with dry-run support and post-validation — adding Itential would duplicate these capabilities; (4) your team lacks the skills to maintain a third automation platform — the operational cost outweighs the architectural benefit. Start with direct SOM→NSO and add the middleware layer only when the pain of missing pre/post checks, multi-controller aggregation, or compliance enforcement justifies the complexity.

Ownership & Source of Record

Three-Layer Stack: Source of Record Mapping

Entity	System of Record	System of Engagement	System of Reference	Notes
Service Order (CFS lifecycle)	SOM	COM (captures order)	Product Catalog	SOM owns end-to-end service order state
Automation Workflow Definition	Itential	NetOps team (designs workflows)	Runbook documentation	Workflow library maintained in Itential
Execution Log (per-step audit trail)	Itential	Itential (auto-generated)	—	Retained for compliance and troubleshooting
Device Configuration (running config)	NSO (CDB)	NSO (commits changes)	YANG models	NSO CDB is the intended-state SoR for managed devices
NED / YANG Model Library	NSO	Platform team (installs NEDs)	—	One NED per device family per OS version
Compliance Policy	Itential (or policy engine)	Security/compliance team	—	Golden config templates and rule sets

Progressive Detail

Think of it like a construction project. SOM is the project manager — it knows what needs to be built (the blueprint), breaks it into tasks, assigns them, and tracks progress. Itential is the automation engineer — it receives a task, plans the exact steps (safety checks, tool selection, quality inspection), and coordinates the execution. NSO is the network technician — it takes the specific instruction ("configure this VRF on these three routers") and executes it safely, rolling back if anything goes wrong.

The project manager (SOM) does not need to know which safety checks to run — that is the automation engineer's job. The network technician (NSO) does not need to know why this VRF is being created — that is the project manager's concern. Each system focuses on what it does best.

The three layers communicate through well-defined API contracts. Understanding these interfaces is key to implementing the pattern correctly.

SOM → Itential: REST API or TMF652 Resource Order. SOM sends a work item with RFS type, action (create/modify/delete), target parameters, and a callback URL. Itential returns a work item ID for tracking.
Itential → NSO: RESTCONF (RFC 8040) using NSO's YANG service models. Itential constructs the YANG payload from the work item parameters. Dry-run uses ?dry-run=native query parameter; commit uses standard RESTCONF PATCH/PUT.
NSO → Devices: NETCONF (RFC 6241), CLI (SSH), or gNMI depending on the NED type. NSO abstracts this — Itential never talks to devices directly.
Itential → SOM (callback): REST webhook or message queue. Itential posts the execution result (success/failure), log reference, and post-check summary back to SOM's callback endpoint.

The three-layer pattern introduces three distinct rollback scopes, and understanding which scope handles which failure is critical to avoiding double-compensation or orphaned state.

NSO device-level rollback: If any device in a multi-device transaction rejects the config, NSO automatically rolls back ALL devices in that transaction to their pre-change state. This is atomic and handled entirely by NSO — Itential does not intervene.
Itential workflow-level rollback: If post-validation fails (e.g., BGP session not established within timeout), Itential triggers an NSO rollback of the committed transaction, then reports failure to SOM. If a pre-check fails, Itential aborts without touching NSO at all.
SOM saga cross-service rollback: If one RFS item succeeds but a related RFS item fails (e.g., VRF created successfully but underlay transport path failed), SOM owns the cross-service compensation decision — it may ask Itential to undo the successful VRF, or it may retry the failed transport path.

Double-Compensation Risk

If Itential triggers an NSO rollback AND SOM also sends a compensating "delete" work item for the same RFS, the delete will fail (resource already rolled back) or worse, delete a different resource. The contract must be clear: if Itential handles the rollback, it reports "rolled back" to SOM and SOM does NOT send a separate compensation. If Itential reports "committed but post-check failed" without rolling back, then SOM owns the compensation decision.

When to Choose Each Pattern

Pattern Selection Guide

Factor	Direct SOM→NSO	SOM→Itential→NSO
Number of controllers	1–2 controllers (NSO + maybe MANO)	3+ controllers (NSO, MANO, SD-WAN, cloud, IPAM, DNS)
Pre/post check needs	Minimal or none — trust NSO commit result	Mandatory — regulatory, SLA, or operational policy requires pre/post validation
Team skills	Network engineers comfortable with NSO and YANG	Mixed team — network, cloud, and automation engineers; need a common workflow platform
Stack complexity tolerance	Low — prefer fewer systems, simpler architecture	High — willing to operate an additional platform for the automation benefits
Change management requirements	Basic — commit and verify	Strict — change windows, approval gates, audit trails, compliance checks
Typical deployment	Tier-2/3 operators, single-vendor network, greenfield	Tier-1 operators, multi-vendor network, brownfield with legacy integration

ODA Mapping: Three-Layer Stack

In TM Forum ODA terms: SOM maps to the Service Management & Orchestration component — it owns service order lifecycle and CFS/RFS decomposition. Itential maps to the Resource Order Management (ROM) / Automation Controller role — it receives resource-level work items and orchestrates their execution. NSO maps to the Resource Controller — it manages the actual network resources via southbound interfaces. TMF652 (Resource Order Management) is the natural API between SOM and Itential, carrying resource order items that Itential decomposes into automation workflow steps. TMF638 (Service Inventory) remains SOM's domain for tracking instantiated service state.

Section 9.5 Key Takeaways

The three-layer stack separates concerns: SOM decides WHAT (CFS→RFS decomposition), Itential decides HOW (workflow orchestration), NSO EXECUTES safely (transactional commit with rollback)
Itential adds pre-checks, post-validation, compliance enforcement, and multi-controller aggregation — capabilities that neither SOM nor NSO provide alone
The pattern insulates SOM from NSO API details — SOM sends work items; Itential handles RESTCONF payload construction, dry-runs, and YANG mapping
Three distinct rollback scopes exist: NSO (device-level atomic), Itential (workflow-level), SOM (cross-service saga) — contracts must prevent double-compensation
TMF652 is the natural API between SOM and the automation middleware layer, carrying resource order items that map to automation workflows
The three-layer pattern is not always necessary — direct SOM→NSO is simpler and sufficient for single-controller, low-complexity environments
Post-validation (BGP check, ping test, golden config audit) is the single biggest value-add — it catches silent failures that NSO 200 OK cannot detect
Start with direct SOM→NSO integration; add the middleware layer when operational pain (missing pre/post checks, multi-controller complexity, compliance requirements) justifies it