NETCONF and YANG

I was just rummaging around here on PAOSS looking for an old post that I wrote giving a high-level description on NETCONF and YANG… only to find that I hadn’t written a a high-level description on NETCONF and YANG yet. I could’ve sworn that I’d written something a year or two ago but apparently I hadn’t. Anyway, here’s the article I didn’t write two years ago…

So what’s so important about NETCONF and YANG, and why am I pairing them up like we tend to do with SDN / NFV?

The Network Configuration Protocol (NETCONF) is a network management protocol developed and standardized by the IETF. It was developed in the NETCONF working group and published in December 2006 as RFC 4741 and later revised in June 2011 and published as RFC 6241. The NETCONF protocol specification is an Internet Standards Track document.
NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple remote procedure call (RPC) layer. The NETCONF protocol uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The protocol messages are exchanged on top of a secure transport protocol.”
Wikipedia
.

In a nutshell, it allows for network management via a human-readable XML language. Not only does the XML make it human readable, but it makes it easily diff’able (ie great for change management). IETF were the developers of SNMP, which has become ubiquitous for network health and statistics, but NETCONF came about because vendors were using command lines (CLI) for config management.

From an OSS perspective, this was a disaster. I worked on a tier-1 carrier project which had just about every switch/router platform offered by the world’s biggest name in switches/routers. Almost every one of them had CLI / response differences, meaning mediation device variants had to be spec’d and built separately. It was a nightmare, especially for regression testing purposes in the days when automated regression suites weren’t readily available.

The rapid uptake of NETCONF prompted the creation of YANG.
YANG is a data modeling language for the NETCONF network configuration protocol. The name is an acronym for “Yet Another Next Generation”. The YANG data modeling language was developed by the NETMOD [2] working group in the Internet Engineering Task Force (IETF) and was published as RFC 6020 in October 2010. The data modeling language can be used to model both configuration data as well as state data of network elements. Furthermore, YANG can be used to define the format of event notifications emitted by network elements and it allows data modelers to define the signature of remote procedure calls that can be invoked on network elements via the NETCONF protocol.”
Wikipedia
.

In other words, it’s a framework for modelling devices, as well as coherent modelling of services across those multi-domain device platforms.

BTW. I stumbled across this great NETCONF / YANG article from Tail-f earlier today, which is what reminded me to go looking for my non-existent blog on the subject. Tail-f was bought by Cisco and re-branded as their Network Service Orchestrator (NSO) tool.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.