YANG

You just got promoted to network automation lead.
Your company has Cisco routers in one site, Juniper in another, and Arista in a third.

Your first task: add a description on the WAN interface of every router.
You open your terminal, and there is the problem: each vendor speaks a different dialect.

Figure 1 – Three vendors, three CLI dialects

Same task, three incompatible syntaxes.
To automate this with the CLI, your script has to learn every vendor's dialect, and any future IOS update can break your parsing.

You need a common vocabulary that every vendor agrees on.

One Model, All Vendors

This is where YANG comes in.
Instead of typing vendor-specific commands, you describe the change once using a shared data schema that Cisco, Juniper, and Arista all agree on.

Figure 2 – One YANG model, three vendors

You build your payload using ietf-interfaces, a standard YANG model published by the IETF.

Every modern device implements it.
Only the interface name changes: GigabitEthernet0/1 on Cisco, ge-0/0/1 on Juniper, Ethernet1 on Arista.

YANG stands for Yet Another Next Generation. It is a data modeling language.
Think of it as a way to write down what a router's configuration looks like, in a format every vendor agrees on.

Two RFCs define YANG: RFC 6020 for version 1.0 and RFC 7950 for version 1.1.
Both define the same language, with version 1.1 refining version 1.0.

What a YANG Module Looks Like

A YANG file is called a module.

It lists every field a device exposes and the type of value each field accepts.
Inside a module, the value-holding fields are called leafs.

Here is a simplified extract of the ietf-interfaces module:

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name        { type string; }
      leaf description { type string; }
      leaf enabled     { type boolean; }
    }
  }
}

You do not write YANG modules yourself.
Vendors and standards bodies write them.

Your job is to read them and send matching data.

Validation Before Apply

Before applying any change, the device checks your data against its YANG modules.

Figure 3 – YANG rejects the change before it applies

In the example above, the script sends "enabled": "yes".
R1 sees that enabled expects a boolean, finds a string instead, and answers with 400 Bad Request.
The running config stays untouched.