Today's network management discipline has numerous problems that will affect software-defined networks (SDNs).
The trouble with network management
Most management systems require complex installation and configuration processes for a successful implementation, for example. This is the opposite of the SDN premise, which is to simplify networking. I've frequently seen popular management systems languish (I call these "shelfware," indicating that they've been installed but really do nothing more than sit on the shelf instead of providing useful visibility into network operations).
Another complaint is that most network management systems (NMS) do not provide useful or actionable information. For example, you might consider a Top-N display of interface utilization useful until you begin to wonder about the period covered by the information. Is it a Top-N from the last five minutes, the last hour, the last day, or the last week? Determining the reporting period would take some serious investigation.
In another case, I've seen a system in which the interface discard counters reported zero, while the QoS system encountered congestion and dropped packets in an oversubscribed queue. Because the problem involved dropped packets, it affected application performance. The organization hadn't set up the NMS to report QoS queue drops, so the congestion was invisible.
Configuration management of an SDN is entirely different than the configuration-per-box approach that current NMS products include. These products rarely include any type of policy definition from which configurations should be built. This approach won't work with an SDN that requires policy definitions for proper configuration and operation.
The end result is that existing network management is ill suited to monitoring and managing a modern SDN.
Here are some characteristics that an SDNMS should have:
Some of these characteristics are identical to non-SDN NMS requirements. But most vendors of existing products provide only basic NMS functionality, placing responsibility for configuring anything beyond the basics on the administrator. Device and interface grouping can significantly reduce the amount of effort required for monitoring and reporting configuration. This is a function that is rarely found in NMS products today. With SDNs, these functions are going to be more important because the SDN itself will be based on similar groupings.
I wish that more NMS products included good auto discovery and auto configuration. For some reason, vendors seem to think that a lot of configuration is acceptable. But this is one of the reasons that so many products become shelfware. To fit into an SDN environment, an NMS must incorporate more automatic configuration and operation. The network will be changing too quickly for manual configuration practices to succeed.
NMS vendors are going to have to get smarter about SDN technology and adapt their systems to work in the new world. The additional challenge they face is that SDN is a developing technology. I think that the vendors that move soon and learn to adapt quickly (i.e., via agile software development) are going to be winners in the world of SDN monitoring and management.
To answer my introductory question: Does software-defined networking need software-defined network management?
I think the answer is, "Yes." NMS vendors will need to design products specifically to handle the unique functionality an SDN provides.
A longer version of this article appeared on No Jitter.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
