What makes NETCONF/YANG different ?

Netconf is a device configuration and management protocol and Yang is a modeling language that’s used by Netconf.

Shortcomings of SNMP

This rfc3535 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 Developers – makes it difficult to manage configs, do rollbacks, compare configs etc.

Netconf and Yang
This rfc 6244 gives a good architecture overview of Yang and Netconf. 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 Developers – 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 is an example 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>

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.