confd vs. CLI NED

[khgrant]

Hi Team,

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.

Thanks, JA

[khgrant]

Hi JA,

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.

Cheers,

Nabil

[khgrant]

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.

Cheers,

KJ.

[khgrant]

So is there a netsim or netconf device where we can gain experience with this methodology?

JA

[khgrant]

Hi Julie,

1. When working at the service layer (service-package, serviceàdevice mapping), we shouldn’t need to care whether the southbound device is CLI/REST/NETCONF etc. The NED abstracts out the device specifics and presents it as an easily consumable YANG model.

1. Is it that it’s easy to comprehend the device model for CLI based NEDs as the model generally translates 1-1 to the exact CLI. So performing the serviceàdevice mapping is straight forward. For devices that have a NETCONF/REST etc. this nexus may not always be that obvious?

Thanks,

1. Bilal.

[khgrant]

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

Noam

[khgrant]

JA,

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.

Best Regards,

/jan