Today, service automation is a must-have feature for network operators. A multi-vendor network has always presented challenges for service automation applications. Although these challenges can be mostly addressed with a lot of scripting using non-standard APIs, it is very complex and time-consuming and results in difficult issues to address. In today’s networks, the challenges have grown exponentially due to the agility required in configuring and monitoring the heterogeneous network elements which comprise these networks.
The NETCONF standard (RFC 6241) solves several configuration management problems. First, by being a standard management protocol, and, second, by supporting transactions, automatic rollbacks, and other essential features identified in RFC 3535. Data managed by NETCONF is described using a standard data modeling language called YANG (RFC 7950). Together NETCONF and YANG deliver a standards-based, data model-driven management API. When it comes to automation, it certainly helps if the elements in a network support a common, standard API such as NETCONF and YANG.
However, implementing and testing a NETCONF and YANG implementation for compliance with the standards is not enough to enable automation done right. In order to provide the best automation support possible when designing network elements, you must first learn about what enabling automation using best practices means. These best practices are called the Service Automation Criteria which are described in the NETCONF & YANG Automation Testing (NYAT) User Guide. Beyond that, you should learn about the problems that can surface with NETCONF and YANG implementations and how to solve them.
In order to assist with this learning, our latest application note, “Automation Principles for Designing Network Elements”, discusses various problems, and their solutions, which can be found when testing NETCONF and YANG implementations against the Service Automation Criteria. Problems such as configuration dependency on state data, configuration ordering requirements (dependencies introduced by the device’s management layer logic), and breaking transactionality principles, are just some of the problems discussed in the application note.