Gone are the days when it would take weeks to months to develop an adaptor for a new device, or different versions of the same device, to be integrated into an OSS for automated configuration management. We have referred to this as the adaptor tax. In addition to programming in the configuration attributes into the adaptor, additional coding is required to deal with error recovery when error conditions occur during the provisioning process. This has been the major drawback for any OSS to support a multi-vendor network.
Thanks to the introduction of NETCONF and YANG, the whole adaptor taxation penalty is being completely eliminated. It can now take only a few minutes to automatically build Network Element Drivers (NEDs) to integrate new NETCONF/YANG based devices into Cisco¹s Network Service Orchestrator enabled by Tail-f (NSO) for automated configuration management.
Looking at what OSS’s had to do in the past, it still amazes me how much work has been simplified by not having to develop adaptors. I recently wrote an Application Note on how organizations can integrate ConfD based devices into NSO. The application note highlights how ConfD’s northbound NETCONF interface along with the associated YANG model provides a simple and fast path to integrate a network element to Cisco Network Service Orchestrator enabled by – guess who -Tail-f (NSO). This application note was fun to write and discusses how to best configure ConfD for use with NSO, how to configure NSO to use NETCONF to communicate with a ConfD based network element, and how to test communication between NSO and a ConfD based network element using NETCONF.
Truly, this is unheard of when dealing with previous generations of configuration management protocols such as SNMP and CLI. Service Providers can now enjoy the full benefits of operating multi-vendor networks and reduce significantly the amount of time it takes to deploy new services for their networks. This is exactly what is needed in the world of NFVs operating in an SDN environment.