YANG Data Modeling

What it is

YANG is a language that describes the structure of configuration and status data on a network device.

It does not carry data and it is not a protocol.

It is a blueprint. It says that a device has interfaces, that each interface has a name and a state, and what type each value has. Protocols such as NETCONF and RESTCONF then use the blueprint to read and write real data.

How it works

A model is built from a small set of node types, and many models are shared.

Why a data model is needed

Every vendor has its own command line, and every command line changes between releases. Scripts that parse text break easily. SNMP MIBs mostly describe monitoring data, and they are hard to use for configuration.

A data model gives one machine readable description of both configuration and status. A program can then check its data against the model before it sends it, and the device rejects data that does not fit.

YANG building blocks

Leaf values have types such as string, boolean, uint16 and enumeration. A model can also mark a node as configuration, or as read only status data.

A small example

module example-interfaces {
  namespace "urn:example:interfaces";
  prefix exif;

  container interfaces {
    list interface {
      key "name";
      leaf name { type string; }
      leaf enabled { type boolean; default true; }
      leaf mtu { type uint16; }
    }
  }
}

The module has a container called interfaces. Inside it is a list called interface, where name is the key, so each entry is identified by its name. Each entry has three leaves with their types.

A tool such as pyang can show the model as a tree, which is easier to read.

module: example-interfaces
  +--rw interfaces
     +--rw interface* [name]
        +--rw name       string
        +--rw enabled?   boolean
        +--rw mtu?       uint16

In the tree, rw means read and write configuration, and ro means read only status. The star marks a list, and the text in square brackets is its key. A question mark marks an optional leaf.

The same data in JSON

The data that follows the model can be written in JSON.

{
  "example-interfaces:interfaces": {
    "interface": [
      {"name": "Gi1", "enabled": true, "mtu": 1500},
      {"name": "Gi2", "enabled": false}
    ]
  }
}

The container becomes an object, the list becomes an array of objects and each leaf becomes a key with a value. The module name is the prefix on the top key. The same data can also be written in XML for NETCONF.

Families of models

IETF and OpenConfig models are portable, but they cover a limited set of features. Native models cover the whole device, but they work only with that vendor.

How models are used

• NETCONF sends and receives XML that follows a model.
• RESTCONF uses the model names in its URL paths and in JSON.
• gNMI and streaming telemetry also use models to name the data that is sent.

A device lists the models that it supports. NETCONF does this in its capabilities exchange. You can then find the paths that you need and build your requests.

Benefits

• One structured description for configuration and status.
• Data can be checked before it is sent, so errors are found early.
• Tools can create code, documents and tests from the model.
• Models can be shared between vendors and tools.
• Scripts are less likely to break when a release changes the command line.