Network Services Orchestration and YANG Data Models

What it is

NSO automates network services across many devices, and YANG is the modeling language that describes the data it works with.

A service, such as a customer VPN, touches many devices. NSO takes one service request and turns it into the right configuration on every device. YANG gives it, and other tools, a precise description of what that configuration looks like.

How it works

NSO combines a service layer, a device layer and a transaction engine, all built on YANG models.

The role of NSO

NSO is the Cisco Network Services Orchestrator. It sits above the devices and manages them as a single system. It has a few main parts:

• Service manager: holds the service models, and maps a service request to device changes.
• Device manager: talks to each device, through a network element driver (NED).
• CDB: the configuration database, which holds a copy of device and service configuration.
• Northbound APIs: REST, NETCONF, a CLI and a web interface, so that portals and scripts can call it.

A NED is a driver for one device type, so NSO can manage devices from several vendors with the same models. NSO can also learn the existing configuration from the devices, using a sync from the network.

Transactions and FASTMAP

NSO changes are transactional. A service change is applied to all devices, or to none. If one device fails, the whole change is rolled back.

FASTMAP is the method that makes this simple. The service author writes only how to create the service.

NSO records the configuration that the creation produced. To change or remove the service, NSO works out the difference for itself, and so you do not write delete logic.

admin@ncs# devices sync-from
admin@ncs(config)# commit dry-run outformat native

The dry run shows the exact commands that NSO would send to each device, and it sends nothing.

Service models and templates

A service in NSO has a YANG service model, which lists the inputs, such as customer name and site addresses. A template or a small piece of code then maps those inputs to device configuration. Because the model is defined once, the same service can be requested the same way every time.

YANG principles

YANG is a data modeling language. It defines the structure of configuration and state data, but it is not a data format itself. The same model can be sent as XML or JSON.

The main building blocks are:

A node can be configuration or read only state data. Types such as string, boolean and unsigned integers limit what values are valid.

module example-interface {
  namespace "urn:example:interface";
  prefix ex;
  list interface {
    key "name";
    leaf name { type string; }
    leaf enabled { type boolean; default true; }
    leaf mtu { type uint16; }
  }
}

This model describes a list of interfaces, each with a name, an enabled flag and an MTU. The name is the key, so each interface is unique.

Types of YANG model

Benefits of YANG

YANG is machine readable, so tools can validate a request before it reaches the device. A model is clear and consistent, and it is separate from the protocol. NETCONF, RESTCONF and gNMI can all use the same model.

Tools can read a model and generate code or documents from it. The structure also makes it possible to check the type and range of every value.