Native YANG models: IETF vs Openconfig vs Cisco
The modern-day network is amazing. There are so many moving parts to it. Likewise, modern networks are typically distributed between different geographic regions. Between connecting different business sites, securing networks, and making those information networks as fast as possible, network operators have a huge task in front of them. So, they need a way to help configure and maintain those networks.
That's where YANG comes in. YANG is a data modeling language used to help configure the autonomous network. There are different versions of YANG, though. For instance, there is the home-grown version of YANG developed by the IETF natively, a consortium vendor-neutral version called OpenConfig, and vendor-specific versions made by companies like Cisco.
So, which version of Yang should you use? Should you use the IETF version of YANG, OpenConfig, or Cisco's version of YANG? Of course, there's no easy answer, so keep reading to find out.
What is YANG?
Yang stands for Yet Another Next Generation. It's a data modeling language similar to XML. At its core, YANG is a data modeling language. It is used in conjunction with NetConf and RestConf for configuring networking equipment like routers and switches.
Netconf was originally made as a way to manage the autonomous network. Originally network operators used SNMP to manage networks. Over time the limitations of SNMP became more noticeable, though. As enterprise-level networks became more complicated and increasingly more autonomous, SNMP started to lack features that network operators needed. SNMP was slowly ignored for other network management tools. When Netconf was released, it became clear that network operators needed a data modeling language to use with it, though. The IETF learned their lessons from previous attempts to create a data modeling language, though, so instead of making YANG protocol neutral, it was designed specifically for Netconf.
Currently, the YANG modeling language is maintained by a group called Netmod that works within the Internet Engineering Task Force (IETF). It was initially published as an official standard in October 2010 under RFC 6020.
YANG consists of various building blocks:
Each module describes a hierarchy of nodes. Containers are those related nodes or a collection of those nodes. Each list identifies specific nodes. Leafs are the individual attributes for each node. And the Type describes the type associated with the Leaf.
Each model can be used to configure the hardware itself or a service. For instance, the models for a networking device will control things like its interfaces and VLANs. A model configuring a service would control things like an access control list or the BGP protocol.
YANG is very module driven like Python. In fact, Python is the most popular programming language of choice to create, analyze, and deploy YANG configs. This is typically done with a library called PYang.
On top of YANG being an easier way to manage the autonomous network programmatically, it has other uses as well. For instance, YANG abstracts network configuration away from the command line interface. Traditionally network operators would need to use the CLI to configure each device in the network individually. This created tons of documentation and the potential for mistakes. Because YANG can be programmatically deployed through Netconf, it reduces the amount of work needed to both configure and maintain the network.
Likewise, YANG allows the ability for network control and access to be segregated to individual workflows with specific access restrictions. While using the command-line interface to configure networking devices, network operators require having all the keys to the kingdom so to speak to perform their jobs. Of course, this isn't desirable from a security standpoint. Different network operators only need access to specific functions of the network. Because YANG can be used with other network management tools, access can be heavily restricted to strictly defined network operator profiles which reduce the amount of reach network operators have access to.
YANG Models: IETF vs Openconfig vs Cisco
When the IETF first standardized YANG, they understood that they needed to create data models that could be used between multiple vendors. Hardware vendors needed something to model their versions of YANG on top of. It was understood that networking hardware needed a way to manage devices more efficiently but leaving those mechanisms solely to the individual vendors would create further fractures in the ecosystems. That fracture would make mixed-vendor environments almost impossible to work with.
The IETF version of YANG is limited in what it can do, though. It is widely considered the easiest version of YANG to start with. The IETF version uses fewer lines of code as well as simpler modules. That comes at a cost, though. The IETF version of YANG is much more limited in scope with what it can configure between multiple vendors.
Because of those limitations, vendors started creating their own data models within their own versions of YANG. Vendors like Cisco and Juniper made versions of YANG to control their networking equipment with features specific to their equipment.
This certainly helped advance YANG. With vendor-specific data models, network operators were able to fully configure their network fabrics through YANG programmatically and autonomously. Of course, this still made administering mixed-vendor networks difficult since different scripts needed to be created and maintained for different devices.
Eventually, OpenConfig was created. OpenConfig is a YANG standard that is interoperable between multiple vendors while expanding on the capabilities that the IETF version of YANG offers. Today, various hardware vendors, like Cisco and Juniper, support OpenConfig, but OpenConfig still has a long way to go for complete interoperability.
Nonetheless, OpenConfig made advancements in their data models in YANG that made configuring things like BGP possible between various pieces of vendor equipment. The informal working group that maintains OpenConfig is pushing and working with vendors to support more hardware-specific features through this open, vendor-neutral network management language.
Should I use IETF, OpenConfig, or Cisco's version of YANG?
It's typically recommended that anyone first learning to use YANG for network management should start with the IETF version. As we mentioned above, the IETF version is much easier to use despite it being much more limited in what it can do. Nonetheless, it is a great way to learn how data models and YANG work.
A lot of network operator professionals suggest not using the IETF version of YANG in a production environment because of how limited it is. Instead, many people suggest using OpenConfig as much as possible. OpenConfig works between multiple vendor's networking equipment so scripts can be re-used between different devices. This makes maintaining and deploying YANG to the autonomous network far easier over time.
On occasion, because OpenConfig cannot configure every piece of the network equipment from different vendors, you may still need to use vendor-specific YANG. It's perfectly acceptable to mix using both OpenConfig data models with Cisco-specific YANG. It is recommended not to use both OpenConfig and Cisco for configuring the same parameters, though. For instance, if you need to configure BGP through YANG, use either OpenConfig or Cisco but never both.
Advances are still being made with OpenConfig, too. We may get to the point where network operators don't need to use mixed versions of YANG within their network environment. As these advances are made, network operators can remove vendor-specific code and replace those blocks with OpenConfig compatible versions, instead. Again, this makes maintainability far easier over time.
We've covered a lot of information in this article. We know that YANG was created as a way to use Netconf within the networking environment to configure and deploy network configurations. We know that YANG is much easier to maintain than using the traditional command-line environment for configuring individual network devices, and we know that most network equipment vendors support YANG in one form or another in some or all their products.
So, the question comes down to whether you should use IETF, Openconfig, or Cisco's version of YANG. Though we largely answered this question above, let's recap quickly. Use the IETF version of YANG to learn YANG. The IETF version is easy to learn and simplistic, but it is limited in scope.
You will most likely have to use two different versions of YANG if you have a mixed vendor environment. Either way, it is recommended to use Openconfig as much as possible while only using the Cisco version of YANG when needed. Likewise, never use two different versions of YANG to configure the same functions in the data models. Also, never use more than two versions of YANG in your environment in general.
delivered to your inbox.