Netconf and Yang

Cisco’s acquisition of Tail-f prompted me to look deeper into what Tail-f does. That in-turn made me dig deeper into Netconf and Yang. Netconf is a device configuration and management protocol and Yang is a modeling language that’s used by Netconf. Yang modeling can also be used outside Netconf’s context. From looking at the history behind Netconf and Yang, I realized that Network management as a whole was a widely ignored topic for quite sometime. The current Network management techniques used by Operators seems to be very arcane and the recent SDN wave has triggered a renewed interest in simplifying Network management. In this blog, I will cover the following:

• Shortcomings of SNMP.
• Netconf and Yang overview with examples.
• Comparison with Ovsdb and Openflow.
• Opendaylight’s use of Yang model
• Tail-f  NCS system’s use of Netconf and Yang.

Shortcomings of SNMP

This information RFC covers the important shortcomings of SNMP. Following are some key points.

• SNMP was designed as a management protocol, its cumbersome for configuration.
• Not transaction based, adds lot of overhead on upper level management layers to maintain state.
• Not suitable for Devops – makes it difficult to manage configs, do rollbacks, compare configs etc.

Netconf and Yang – Overview

This information RFC gives a good architecture overview of Netconf and Yang. If 2 network vendors implement their device configuration for a particular feature using a common Yang model, a common client can be developed and that would be inter-operable. This would allow a simpler management layer across Network devices. Following are some key characteristics of Netconf.

• Transaction based – can allow network wide transactions
• Supports rollback
• Supports any data model
• Clearly separates config from operational state
• Friendlier for Devops – can do save and restore, compare configs, etc

Yang is a data modeling language. Other data modeling languages like XSD was considered before Yang was started. As I understood, the other models were not networking friendly. Following are some key characteristics of Yang.

• Hierarchical data node representation
• Extensible
• Constraints can be placed on the data
• Human readable

Following picture from Tail-f shows the Netconf layering model and where Yang fits in.  There will be Yang models for Data definitions and RPC definitions.

Following is an example I picked up from the informational RFC that shows the Yang model for OSPF area.

       module example-ospf {
           namespace "http://example.org/netconf/ospf";
           prefix ospf;

           import network-types {  // Access another module's def'ns
               prefix nett;
           }

           container ospf {   // Declare the top-level tag
               list area {    // Declare a list of "area" nodes
                   key name;  // The key "name" identifies list members
                   leaf name {
                       type nett:area-id;
                   }
                   list interface {
                       key name;
                       leaf name {
                           type nett:interface-name;
                       }
                       leaf priority {
                           description "Designated router priority";
                           type uint8;  // The type is a constraint on
                                        // valid values for "priority".
                       }
                       leaf metric {
                           type uint16 {
                               range 1..65535;
                           }
                       }
                       leaf dead-interval {
                           units seconds;
                           type uint16 {
                               range 1..65535;
                           }
                       }
                   }
               }
           }
       }

The above model describes the syntax of OSPF area. Following are some characteristics:

• OSPF area has a namespace defined. This allows for clashing names across namespaces.
• Attributes can be imported from other modules like network-types in the example above.
• Container ospf is defined and this consists of a list of areas with key being area name and each area having a list of interfaces and each interface having interface name, priority, metric, dead-interval. Each of the leaf parameters have their data type mentioned along with range, default values and any other constraints.

Once Netconf client and server knows the model, there would be no confusion on how parameters are interpreted between client and server. Following is the XML encoded data that the Netconf client sends to the server for OSPF area configuration.

<ospf xmlns="http://example.org/netconf/ospf">

           <area>
             <name>0.0.0.0</name>

             <interface>
               <name>ge-0/0/0.0</name>
               <!-- The priority for this interface -->
               <priority>30</priority>
               <metric>100</metric>
               <dead-interval>120</dead-interval>
             </interface>

             <interface>
               <name>ge-0/0/1.0</name>
               <metric>140</metric>
             </interface>
           </area>

           <area>
             <name>10.1.2.0</name>

             <interface>
               <name>ge-0/0/2.0</name>
               <metric>100</metric>
             </interface>

             <interface>
               <name>ge-0/0/3.0</name>
               <metric>140</metric>
               <dead-interval>120</dead-interval>
             </interface>
           </area>
         </ospf>

Industry usage of Netconf and Yang

I have seen Netconf implementations from both Cisco and Juniper. For Cisco NXOS devices, Netconf is used with XML schemas rather than Yang model. I am not sure if Yang model is used as a schema by big Network device vendors yet. The beauty with using a schema(whether XML or Yang) is it makes it easier to automate Network configurations, and allows easier migration between software releases.

Comparison with Ovsdb and Openflow

Ovsdb is management protocol for managing Open vswitch. Openflow is a data flow management protocol for Network devices. Ovsdb also defines a schema like what Yang defines and ovsdb protocol is used to manage the ovsdb database. I see ovsdb as a parallel protocol to Netconf. Openflow is used for managing the low level flow details of the switch while Netflow is used to manage high level device configuration, so there is not much relation here.

Opendaylight’s use of Yang

Opendaylight uses the Yang model in SAL(Software abstraction layer) that acts as a glue between the controller modules and southbound plugins like Openflow, ovsdb, Netconf. Opendaylight calls this Yang layer as MD-SAL layer and this allows for automatic code generation for Northbound and Southbound interfaces. Following picture from ODL illustrates this model.

Tail-f’s use of Netconf and Yang

Following picture is a block diagram of Tail-f’s NCS system.

Following are some key points that I understood:

• NCS is a Network management system. Southbound interfaces like CLI, Netconf, SNMP, Openflow are used to connect and manage Network devices. Northbound interfaces like REST, Netconf are to the management applications and NCS takes care of converting the Northbound calls into appropriate southbound interfaces.
• Both device and service models along with embedded database are maintained in the NCS layer.
• NCS system makes design of management applications simple because it uses the transaction characteristics of Netconf and the conversion layer makes it device agnostic that allows it to work with different Network equipment manufacturers.
• NCS system allows it to work across heterogeneous devices which supports different southbound interfaces. Even for devices that supports only CLI, it tries to add rollback, transaction management etc.

Conclusion:

Many Network management protocols have come and gone, so its difficult to see why Netconf would become widely prevalent. The basic premise of Netconf which uses a transaction based approach is very important, so there is a good chance that it will become widely prevalent. Representing configuration data as a model like the way that Yang does makes it easy for multiple Network equipment manufacturers to implement a feature in a common way and it also allows flexibility to provide extensions. There are also newer protocols like RESTConf which has a REST based approach of accessing Yang model.  Since SNMP is efficient for monitoring, I think that would still continue. Also, for Performance monitoring, rmon and ipfix would have its own space.

References:

• Informational RFC on Network Management current state
• Informational RFC on architecture for Network Management using Netconf and Yang
• Network management presentation by Tail-f from TeamNanog
• NCS overview from Tail-f
• Yang central wiki
• Yang overview from Tail-f
• Opendaylight controller MD-SAL
• Tail-f white paper on configuration management
• Article from SDN tutorial
• Article from Network Heresy

Pictures used in the above blog are from the references.