Network Programmability, which is preferred? SNMP or CLI or Yang

Network Programmability, which is preferred? SNMP or CLI or Yang

Network programmability is directly linked to Software Defined Network (SDN). So, it is driven by real benefits like time and cost savings, reduction of human error, customization and innovation. The network programmability is now understood as a set of tools and best practices to deploy, manage and troubleshoot network device, but it’s way beyond that.

Network programmability is not new. From the screen scrapping, to bash and expect scripts. Those are part of the automation, try to reduce as much as human error. But what is new? The scale of network is grown exponentially and glowing every day. The agile nature and dynamic requirements of our network infrastructure cannot be realistically configured and managed one device at a time. Each vendor has defined and exposed API to handle their devices programmatically, specially repetitive and mundane tasks. Along with Zero Touch Provisioning (ZTP), a device can be brought up without the human intervention. Except the physical connection, rest of the reconfigurations are managed by SDN controller for the entire network.

In the modern internet era, the scale of the deployment is huge. Expectation of DevOps is to get the entire testing and development environments to be built and destroyed within minutes. The network should be flexible enough to adapt the new changes dynamically.

Yang vs. Other Approaches

CLI scripting was the primary approach to making automated configuration changes to the network prior to Yang. CLI scripting has several limitations, including lack of transaction management, no structured error management, and ever-changing structure and syntax of commands that makes scripts fragile and costly to maintain. The CLI was designed to use by human; we used for automation, but not for programmatic use-case.

SNMP is another approach, but, in practice, is mostly used for performance and monitoring applications. Reasons for this include the lack of a defined discovery process that makes it hard to find the correct MIB modules, limitations inherent in using the UDP protocol, and the lack of useful standard security and commit mechanisms.

Industry consortiums, like IETF, ONF, TIP, operator engagements, like OpenConfig, OpenRoadm etc are active working with vendors to support Yang as day-one feature. This is also important for product vendors to implement and release programmability support from the beginning of the product release itself.