The Big YANG Theory

At this point in the evolution of the network, we think it is important to outline the history, pros, cons, and future of YANG. The data model in YANG helps in managing configuration for both traditional and software defined networks (even SDN needs some persistent state). Standardized YANG models will help in managing true multi-vendor networks.

What Is YANG Exactly?

As I outlined in “The Current State of SDN Protocols,” YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls and NETCONF notifications. YANG was developed by the NETMOD working group in the IETF and was published as RFC 6020. 

In the past few years, YANG gained a lot of traction with the open-source community. There are tools developed to validate YANG and transform YANG specification into other formats. Some tools can even generate JAVA code given a YANG specification. Router vendors noticed the traction and started contributing to model definitions, standardization and eventual support in their products. 

My Experience

I got involved with YANG when the IETF’s I2RS (Interface to the Routing System) working group wanted to define an information model to allow read and write access to the RIB (Routing Information Base). Though data models were not chartered for I2RS, authors were encouraged to provide one. I worked on the data models for the RIB and network topologies. The drafts may be viewed at the links below:

• A YANG Data Model For Network Topologies
• A YANG Data Model For Layer 3 Topologies
• A YANG Data Model for Traffic Engineering Database 

Defining a YANG model is pretty straightforward. The YANG syntax is similar to that of SMIng and programming languages like C and C++. YANG chose the C-like syntax specifically for its readability, since YANG values the time and effort of the readers for models above those of modules writers and YANG tool-chain developers. 

Packet Design’s TE Explorer module of the Route Explorer system supports NETCONF/YANG for collecting RSVP-TE tunnel state from JunOS routers.

Shortcomings

The types of container data structures that YANG supports are not quite sufficient to model complex data types. For example, defining a recursive data structure is not possible with YANG. Authors are often forced to rethink the model in terms of lists and containers. 

Another major disadvantage is that the ‘grouping’ construct cannot be augmented in derived modules. One has to define a data node of the grouping construct and then augment it. These pitfalls were discussed with the YANG author and are being debated within the IETF NETMOD community. 

Strengths

The object-oriented nature of YANG is a big plus in defining models. The YANG tool chain has matured to the extent that it can be used in product development. The open-source community is so gung ho about YANG that a github repository has been set up to share models. Also, a fast track has been set up in the IETF to standardize YANG models. Open-source controller projects have adopted YANG as their primary modeling language; for example, OpenDaylight uses YANG for its Model-Driver Service Abstraction Layer (MD-SAL). Modeling help is available in the open-source community from YANG Doctors. 

What’s Next?

We will continue to see more YANG models defined in the open-source community and being standardized in the IETF. We will also see new features added to the YANG specification. YANG is being adopted as a default data modeling language for newer management protocols like RESTCONF (an HTTP programmatic interface for accessing data stores defined in NETCONF). 

We believe that YANG will play a significant role in shaping SDN. Packet Design’s Network Access Broker (NAB) uses RESTCONF/YANG to provision RSVP Tunnels via the OpenDaylight Controller. Packet Design will continue to contribute to YANG model standardization and support YANG in our SDN analytics and orchestration offerings.