We have seen a huge transition as more and more network engineering teams move towards a service-oriented approach to network management. With this transition, most have or are starting to leverage the IETF’s NETCONF protocol and YANG data modeling language, to realize the benefits of network programmability and remove time, cost, and manual steps involved in network element configuration.
To level-set, I want to address what I am talking about with regards to these two elements. NETCONF is the standard for installing, manipulating, and deleting the configuration of network elements and YANG is used to model both conﬁguration and state data of network elements.
The reason for this post is that I have heard a number of network professionals say something like YANG is important and really all they need or they simply deemphasized what NETCONF brings to the table. Understanding that most network elements offerings have their unique stories and capabilities, these misguided folks are missing half of the solution when it comes to being able to deliver a fully programmable solution.
We know that YANG is wonderful, but by itself, you only get a description of what the data is, how it is organized, and the relationships between the data. Yet, without NETCONF, you are missing how the data is manipulated, how is it read or written. However, NETCONF also provides something very important in addition to just manipulating the data. It writes that data in a transactional manner.
Transactions are a fundamental piece to any network programmability story and provide a robust stable network management system. As a key of programmability is you, of course, must have a mechanism to read and write data. However, how we do that can have a big impact and is important. By using transactions, it is ensured that the set of data is consistently written – if it all succeeds, then deploy. If it all fails, then all configuration stays as it was in order to keep the network functioning as before. Support for transactions is a must in order to do programmability right. NETCONF gives up this transactional support as a “built-in” feature.
We recently released a whitepaper “Managing Distributed Systems Using NETCONF and RESTCONF Transactions” that helps users to further understand the value of transactions in distributed systems. This paper looks at the importance and benefits of doing transactional programmability across the entire network. The foundation on which this is built is the programmable network element.
Transactions are very important to read and write to the network. But the write is where you see the power of transactions across the network, without NETCONF this isn’t easily possible. Before rolling out something across the network it is critical to make sure everything that is being done is valid. With NETCONF, you can effectively and simultaneously write A, B, & C and ensure they are all written properly without having to deal with recovery code methods after the fact. This ensures that the changes happened and that those changes all succeed or all fail.
Robustness, stability, efficiencies, far less code to develop. Circle back, remember it is NETCONF that brings transactions and not YANG. So, they are equally important to programmability.
NETCONF is a critical part of any network programmability story because it delivers robustness, stability, and efficiencies while requiring far less code development. Beyond these features, by implementing NETCONF and YANG together, organizations gain an advantage of cost and time savings for the network management structure. By producing a programmable network element which the power of transactions, you gain a competitive advantage over those that are bogged down in code as a direct result of lack of transaction support.