OpenDaylight, Netconf, Restconf & YANG

An excerpt from chat with Tomas Olvecky:

Q.YANG is a modeling language written to support netconf based devices. But in opendaylight we are using it to describe the structure of data provided by controller components. Well there are couple of tutorials on internet which makes me believe that netconf and yang are inseparable. Please throw some light on it.

A. In opendaylight, yang is being used as a general purpose modeling language. There are two code generators that drive this:

1) MD-SAL Generator

It uses Restconf i.e provides a restconf endpoint. MD-SAL generator is used as typesafe layer to ease development of datastore related components so that when component A wants to communicate with B over md-sal (which can be local or remote call), it does not have to care about (de)serialization. MD-SAL as whole is driven by yang models, basically using it as validation, similar to xsd.

2) Config Generator

It uses Netconf i.e. provides a netconf endpoint. Config subsystem also uses models to generate code. It’s scope is to provide dependency injection and configuration during server runtime. This is somewhat similar to blueprint in OSGi, but externalizes the XML from jar files. So you can connect to running ODL via netconf and push xml that will reconfigure the server. Let’s say you want to mount new netconf/bgp/openflow node, you just connect via netconf and push the change. This is contrary to how blueprint works, because in blueprint you have to edit xml for each bundle, then repackage, then deploy and then start the container. Yang in config subsystem is used mainly to generate config java skeletons, and also as type safe layer, so that netconf client can do partial validation.

Q. It sounds confusing because netconf is more of a southbound protocol and restconf is more of a northbound protocol. Is it correct to say that in md-sal and config context we are using them more generically?

A. Both restconf and netconf are just protocols to get/edit configuration data, operational data, call rpcs and receive notifications. A good analogy for me of md-sal is XML database. Config is more like spring with dynamic reconfiguration. But both can be looked as xml databases. So MD-SAL database is accessible through Restconf and Config subsystem database is accessible through Netconf.

Q. Is there any particular reason we chose config subsystem to implement a netconf server?

A. Netconf server is actually plugable, currently we have only config subsystem bridge & we might have md-sal bridge in future which will allow to access MD-SAL database using Netconf.

References

https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:MD-SAL_Document_Review:Architecture#Model-Driven_Network_Management.2FProgrammability