As we see more netconf/confd coming along – is there a good document/jive page, place on devnet to learn about the difference when creating XML/YANG based services?
We are proficient with CLI based NED XML/YANG based services and need to understand how that will change with a confd interface.
With NETCONF support on devices getting wider adoption, there is no need for a specialized NED on the orchestrator side anymore.
The NED logic is pushed down to the device supporting NETCONF. ConfD can be used to add a NETCONF interface to any device.
Going southbound, the orchestrator will speak NETCONF to the device based on the device yang model instead of CLI commands.
Today when you create your service applications using CLI NEDs, you map your service YANG model to the NED YANG model, using XML and/or Java (Python). When the device supports NC/Y then it is exactly the same. The NED YANG model in this case happens to be the same as the device YANG model, so the NED is very thin (and automatically generated, instead of developed by engineering)
This is why the “No Integration Tax” (http://info.tail-f.com/noadaptertax) campaign is so important. By putting NC/Y support on the device (physical, virtual) we drive cost out of the integration. This has been a huge revenue source for OSS vendors for decades, and a huge cost for the service providers.
confD is available at devnet https://developer.cisco.com/site/confD/
As part of its distribution you have examples where you can gracefully start
Once a device is Netconf/Yang all you need to do at NSO side is to create a generic NED and point to the device supplied (or ConfD) yang files, as part of the ncs-make-package
Then you just ass the device as any other device under the control of NSO
Once the vendor releases the Yang for his devices, the responsibility and accuracy of the device model and device instrumentation is under his control, that how it should be as he would know best what and how the device instrumentations should apply
So is there a netsim or netconf device where we can gain experience with this methodology?
Actually, this is exactly what netsim is. A netsim device is a ConfD instance with NETCONF enabled. The reason for selecting NETCONF for the netsim solution is precisely what we are talking about here: there's no need for engineering NED work, to implement all the CLI/SNMP/REST/... quirks. You can just take the YANGs and go.