YANG and the Road to a Model Driven Network
In the previous article we introduced the concept of NETCONF and we illustrated that NETCONF on its own doesn’t describe the Data, however it describe the procedures of how to query the data and how to carry it. Having this standard approach to query and transport the data is a important, however have a consistent way to model (Describe) the data is critical in the evolution towards simplifying how we interact with Network nodes. In this article, we will try to illustrate what is the definition of Data Model and how YANG was born and how it is used now with other protocols like NETCONF.
Background
As we illustrated in the previous article, in 2006 when the IETF first standardized the NETCONF as the de-facto protocol for configuration management it didn’t define a common model to represent the data carried by NETCONF. So again it was left to each vendor implementation to implement his own data Model and each vendor defined his own XML Schema file to represent the XML Data carried by NETCONF. This might be the reason that NETCONF was not widely adopted at this stage.
In 2010 IETF established the YANG Data Model as the de-facto Modeling language for NETCONF in order to model the data carried by NETCONF. With this move there was a common language that all vendors must bind to in order to model their configuration and operational data.
What is a Data Model?
In order to clearly illustrate the concept of Data Models we will try to compare it with Natural languages.
- The below diagram illustrates the first case that we are in. Think of the teacher as the NMS taking to three different vendor equipment. It needs to talk to each device with his own CLI/language. This is very inefficient, also consider the impact of adding a new vocabulary word (new feature) or adding a completely new student (new Vendor)
- The Other approach is that we all agree to use a common language (Model) to communicate with each other, thus the communication is more efficient. However, with this model each Vendor (Student) has his own dialect (idioms) so he is still different, but still the Core language is the same.
So the most easy way to think of YANG is that it is a Language by which we can describe the configuration and operational state of any router. It can also be extended to describe network Services like L3VPNs and L2VPNs.
YANG Main Components?
Like Any language, YANG has some key structures that defines the syntax of the language and how it is used, again in order to present it in a clearer manner, this time we will compare YANG with the programming language Like Python and C.
Structure
Yang files are called Modules very similar to python Modules (scripts). It also supports hierarchy with other Modules in order to re-use the code. The below diagram outline the Hierarchy of YANG modules
We can import other modules, however submodules are only usable within the parent module.
YANG Data Types and Data structures
The below table briefly describes the different building blocks of the YANG language and how it compares to python
YANG Module Types
After understanding the semantics of the YANG modeling language, we need to know who publish these modules. Currently there are three main publishers for the YANG Modules
Vendors
- Each vendor publishes his own YANG modules that describe the how to configure the device (configuration state) and how to retrieve information from the device (operational state).
- They are commonly called native YANG modules and these modules all bind to the same language structure and semantics however each vendor describe his own node.
- So on the NMS side instead of having to deal with different CLI for each vendor, it can have multiple YANG files per vendor to manage each vendor equipment.
- In order to ease the management of different YANG models and in case of there is a new feature that was introduced in a new code, the IETF part of RFC 6022 introduced a new NETCONF Capability called ietf-netconf-monitoring. With this feature enables NETCONF clients (NMS) to discover data models supported by a NETCONF server (routers) and defines a new NETCONF <get-schema> operation to retrieve them.
IETF
- IETF defines common YANG Modules that describe how to configure interfaces, QOS, and define other common datatypes (like Ipv4, IPv6,etc..). The Modules need to be supported by the Vendor equipment in order to be utilized.
OpenConfig
- It is an initiative lead by google and other OTT and operators to define common YANG models that all vendors should support to configure mission critical features (like BGP, BGP Policies, Interfaces, VLANs, etc..). With the push of this consortium of operators and OTT, multiple vendors are starting to support OpenConfig YANG models.
Where does it Fit?
With the introduction of YANG, the whole management landscape for the network has evolved to cope with YANG in both Configuration management as well as operational state collection.
In terms of configuration management each vendor either using Native YANG models or IETF/OpenConfig models describe all its configuration hierarchy and all the supported features using YANG. These YANG Models are then encoded in XML and transferred using NETCONF or any other API (like RESTCONF or gRPC).
For the operational state as well, the Vendor describes all the operational state of the different interfaces, protocols currently running on the box and this information can be retrieved by one of two ways
- Using NETCONF using GET RPC and other custom RPCs defined by the vendor, much similar to SNMP.
- Using Telemetry in order to define the fields that need to be monitored and sending the telemetry information to a collector.
The following diagram outline the use of YANG in both Configuration and operational data modeling
YANG Toolbox?
In order to start experimenting with YANG the below table summaries some of the key tools that make YANG modules more easy to work with (all are python tools).
YANG Example
In order to better understand YANG and how it is used to model the configuration data on a network node, the following figures outline the same configuration on Cisco IOS-XR router modeled using the both Cisco IOS-XR native YANG models produced by Cisco and the OpenConfig models. On the same router both Models are available and both are used to mode the same data. It is choice of the NMS system to choose which model to query and configure.
CLI Configuration
RP/0/0/CPU0:xrv1#sh running-config interface
Sat May 13 09:44:21.716 UTC
interface MgmtEth0/0/CPU0/0
ipv4 address 172.16.0.13 255.255.255.0
!
interface GigabitEthernet0/0/0/0
shutdown
!Cisco Native YANG Models
<interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">
<interface-configuration>
<active>act</active>
<interface-name>MgmtEth0/0/CPU0/0</interface-name>
<ipv4-network xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-io-cfg">
<addresses>
<primary>
<address>172.16.0.13</address>
<netmask>255.255.255.0</netmask>
</primary>
</addresses>
</ipv4-network>
</interface-configuration>
<interface-configuration>
<active>act</active>
<interface-name>GigabitEthernet0/0/0/0</interface-name>
<shutdown></shutdown>
</interface-configuration>
</interface-configurations>OpenConfig YANG Models for Interfaces
<interfaces xmlns="http://openconfig.net/yang/interfaces">
<interface>
<name>MgmtEth0/0/CPU0/0</name>
<config>
<name>MgmtEth0/0/CPU0/0</name>
<type xmlns:idx="urn:ietf:params:xml:ns:yang:iana-if-type">idx:ethernetCsmacd</type>
<enabled>true</enabled>
</config>
<ethernet xmlns="http://openconfig.net/yang/interfaces/ethernet">
<config>
<auto-negotiate>false</auto-negotiate>
</config>
</ethernet>
<subinterfaces>
<subinterface>
<index>0</index>
<ipv4 xmlns="http://openconfig.net/yang/interfaces/ip">
<address>
<ip>172.16.0.13</ip>
<config>
<ip>172.16.0.13</ip>
<prefix-length>24</prefix-length>
</config>
</address>
</ipv4>
</subinterface>
</subinterfaces>
</interface>
<interface>
<name>GigabitEthernet0/0/0/0</name>
<config>
<name>GigabitEthernet0/0/0/0</name>
<type xmlns:idx="urn:ietf:params:xml:ns:yang:iana-if-type">idx:ethernetCsmacd</type>
<enabled>false</enabled>
</config>
<ethernet xmlns="http://openconfig.net/yang/interfaces/ethernet">
<config>
<auto-negotiate>false</auto-negotiate>
</config>
</ethernet>
</interface></interfaces>
In the next article we will illustrate how to drive the BGP configuration for both JunOS and IOS-XR using a common OpenConfig YANG model.
References and Resources
BRKSDN-1903 — A Model-driven Approach to Software Defined Networks with Yang, Netconf/Restconf
https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=84149&backBtn=true
Netconf and YANG — explained in a layman’s term
Towards the path to Network Innovation
