Cisco Network Services Orchestrator (NSO) - YANG

In the previous article, we saw, in brief, the parts that made up the NSO. It looked something like this:-

We have the northbound interfaces with which the operator could interact (small blue boxes at the top). We have the core components of NSO like the Service and Device managers which sort of helped us in abstracting the different services and devices we use in day to day life. And finally, we have the NED which helps us in processing the southbound interaction with the network devices. If the Network device did not natively support NETCONF then NED helps in modelling the interaction with the device either through native CLI or SNMP etc.

How do we intend to consume these NorthBound Interfaces?

The NSO CLI (Yeah NSO has its own CLI) and the WEB UI is primarily meant for us Network Engineers. It is more human-oriented.

The NETCONF and RESTCONF are used primarily for interaction with other platforms, think of machine to machine interaction. (OSS/BSS). Example:-NSO receiving instructions from Ansible to configure a bunch of devices.

SNMP might be used for monitoring the NSO system itself. Again these are possible use cases, but everyone uses the Northbound Interfaces differently. If you have a use case that differs do comment.

It's time to get into YANG & NETCONF

The RFC 3535 insisted on developing a programmatic interface for device configuration. We need to be able to differentiate between data involved in configuring devices (Think config statements) vs data involving the state (Think show commands) of the network devices. The RFC also insisted on the ability to configure services (say for example L2VPN)  without being all concerned about the devices involved (say the PE devices or the CE devices. Given the fact that the config that goes into these devices for successfully configuring the L2VPN service might be different ). And most importantly if there is a problem when committing the config changes to devices I need to be able to revert those changes in an appropriate order to restore the state.

THE NETCONF PROTOCOL and YANG - MODEL DRIVEN PROGRAMMABILITY

Simply put, NETCONF is the transport protocol for interacting programmatically with our network devices. The protocol and its intricacies figured in RFC 4741 & RFC 6241. A slight google search would reveal that there is a gap of 5 years between the RFCs. Also, the RFC for YANG RFC 6020 was released somewhere in 2010 which was out there because the community felt there was a need to streamline the data that is carried by the transport protocol (NETCONF) when interacting with devices. So, after the initial RFC for NETCONF in 2006, some changes were incorporated to NETCONF to include the modalities of YANG. The modified version of NETCONF RFC was out in 2011.

That begs the question " Is NETCONF the only protocol that could carry/transport YANG data to and out of devices ?" Protocols like RESTCONF and gRPC (It is again an open-source project from Google) could also be used to transport YANG data, but it depends upon the use case. Like gRPC is now heavily being used in the network community to transport Streaming telemetry data. The latest versions of IOS XR do support telemetry with gRPC to transport live statistics of the device(through YANG data models of course).

It helps to picture mentally picture the stack of what all can interact with YANG data. Here is a picture that helps us understand:-

So NETCONF is the protocol that carries YANG data. Drawing parallels to SNMP, NETCONF can be compared with the SNMP (the protocol itself) and YANG can be compared to the MIBs.

YANG - Yet Another Next Generation (Data/Data Model/Modelling language)

Let us ask ourselves a few questions to understand the YANG.

Why do I need a data model?

Data models typically describe our objects of interest called Entities. Suppose we own a Grocery store. We might have several products. So products are entities. There are so many ways to describe a product. They are the attributes of the product. Suppose I wish to standardise how I want to describe a product. Why do I need to standardise in the first place? Say I am procuring stuff from a wholesale dealer. He might describe his products in a different manner. When conveying to him there can be a misunderstanding. So between the grocery store and the wholesale dealer when data is exchanged for procurement wouldn't it be beneficial if they agree on the attributes about their entities of interest (products). Does it make sense?

So if we are talking about an interface of a network device (that is our entity) we need to make sure the attributes are agreed upon. How do we describe those attributes? How do we say " okay, an interface has the following attributes - It has speed in Mbps, bandwidth in Mbps, Input error count etc" - the YANG modelling language in this case helps us describe the attributes. Once we pen down the attributes it becomes a YANG data model. The actual value of the attributes we described earlier becomes the YANG data.

As a network engineer, what can we use YANG for?

To model device data and to model service data. An example of device data would be modelling interface data. An example of service data modelling would the one that describes a VRF or say a Layer 3 VPN.

Where do the models come from?

YANG models can be of two types. The industry-standard ones that are written by bodies such as the IETF( Github repo for yang models), ITU etc and the vendor-specific ones that are written by the vendors specific to their devices or Operating systems.

How do we represent a YANG data model?

A yang model can be described in the YANG language but most commonly it is described in an XML or JSON format. When we are looking from a NETCONF point of view the encoding supported is just the XML.

How to look into the tree structure of a yang file?

Pyang module helps us visualise the tree structure. Lots of tutorials available for Pyang visualisation. This brief video by Knox on YANG includes looking up tree structure using pyang.

How is a YANG model structured?

It is a hierarchical model of nodes. We can have a container to group the nodes. If I need to sequentially identify a set of nodes I put them in what's called a list. A node might have multiple attributes. So, each individual attribute is denoted by a leaf. A leaf has to have an associated data type.  Whoa. Let's take a pause and analyse this picture to understand the components of the hierarchical model. We will take a deeper dive into the YANG model in the next article, now that we have understood the need.

Again this has just been an introduction to NETCONF and YANG and there are more pieces in understanding the structure and the protocol itself. There might also be a question in our mind; "Is this series about NSO or YANG?"; why do we need so much of NETCONF and YANG for NSO. I think a clear understanding of NETCONF and YANG will help in understanding various concepts of modelling used in NSO.

Please do drop in your comments and suggestions.