The industry has been busy discussing the nature of SDN.
They are wondering if SDN is Openflow. Or maybe it just programs the network through open APIs, which can be anything other than Openflow. Take, for example, Netconf/Yang. Or maybe it’s something traditional, like SNMP?
Unfortunately, this debate has had the effect of distracting everyone away from appreciating SDN’s true value.
So, I propose we talk about something that everyone agrees upon, which is that SDN makes a network more programmable and software-defined, thus enabling us to control the network the way we like.
This programmability and control of the network can only happen if we have a powerful central network management system in place.
Therefore, central network control/network management is the essence of SDN.
The data center, which is the first use case of SDN, is already bearing the fruits of this network programmability. Everything from configuration to monitoring and troubleshooting is done from a central place that has a view of the complete network. SDN development for LAN/WAN is slow. Yet some solutions have popped up. More recently, the SD-WAN (Software Defined WAN) is becoming popular. Because it can reduce dependency on expensive services like MPLS, but more so on its ability to configure services centrally in zero-touch provisioning style.
There is more to network management than just configuration. There is the analytics part, the ability to see end-to-end analytics and performance statistics from one place. All of these are the essential parts of the future software-based networks.
However, the concept of network management seems quite revolutionary when we look at the traditional networks deployed today. Why bother with network management tools for configuration when there is CLI? Partly because the vendors have not focused on evolving the network management systems to give a better user experience, and partly because we are trained and certified to run command line only.
So no matter how cumbersome it may be do box-by-box configurations, which can be error-prone, it is a fact that network engineers are very comfortable to use command line tools. Therefore CLI is not just a tool, but part of today’s network configuration culture. This is where the network engineers feel home at.
In my view, SDN will bring some culture change as the network engineers become used to an environment where central network management will become the norm and not an exception. They will see the benefits themselves to motivate them on use of network management tools.
Therefore, it would be better to start accepting the cultural change now and accept management tools as an important part of the network. Whether SDN or not, we should depend on them for configuration and analytics.
We shouldn’t just accept the tools as they are, but go further by driving our vendors to give us a perfect solution for the network management.
The next time you speak to your vendor, talk to him not only about the features of his box, but also about his management tools. Make it a part of your proof of concept to see how easy it is to configure network elements using management tools, and determine what kind of analytics are provided by the tool.
Let the vendors feel that network management is important to you. This mindset needs to be accepted in the industry.
You can wait for the SDN to bring cultural change, or you can prepare yourself by looking at your network to see which aspects would benefit most from management tools.