Few would disagree that the greatest disruptive shockwave the networking sector has seen in many years is SDN, or Software-Defined Networks.  It has the potential to turn traditional networking best practices upside down and to revolutionize the way we plan, deploy, and operate networks.  SDN is perceived by some as a huge threat and by others as a huge opportunity.  Marketing hype is at its peak, and confusion is rampant.

My colleague Tracy Corbo and I have been spending a lot of time talking to vendors and studying the SDN hype-trend, in order to try and peel back the hyperbole to reveal the essential truths that mainstream enterprises will need to understand. Along the way, we have formulated a couple of key foundational conclusions:

  1. The SDN universe can be roughly divided into two categories:  Virtual/soft overlay networks (think VMware/Nicira and BigSwitch) and the “let’s commoditize the delivery plane” group (think OpenFlow and ONF).  Tracy wrote a great post on this that goes into more detail.
  2. To date, virtually all real-world deployments of SDN have been in academia, service providers, or really huge on-line commercial entities (a la eBay, Google, Amazon, Facebook).  While interest is growing within mainstream enterprise, it is still just interest, in part because the enabling technologies, while really exciting, require small legions of programmers and staff to deploy and maintain.
  3. Across the board, significant hurdles remain in terms of stable, reliable, deterministic management and monitoring. In fact, we are marveling over the stunning lack of progress on the management side of SDN.

In many ways, management “lag” is not surprising. Management is often an afterthought when a new networking technology (or most any IT innovation) comes about. However, it is not a question of if, is a question of when management best practices must emerge if SDN is ever going to be ready for use by the mainstream.

One big question is whether or not SDN–based networks can be addressed using traditional network and security management technologies.  On the plus side, most of the underlying architectural concepts are really not all that different from others that have preceded SDN, and so it should be possible to adapt existing systems. On the downside, complexity and dynamicism are going to increase radically, and not all existing management tools will be able to accommodate the scale and rate of change that is coming.

For overlay network types of SDN, we simply need to adapt existing tools for recognizing the new virtual network protocols and constructs, instrumenting them to measure performance and availability, and extend configuration and provisioning tools to support them.  The big challenge here is defining, discovering, and recognizing the relationships and touch points between the virtual overlay and the underlying true physical network.  This knowledge is crucial for responsible planning as well as for any hope of effective monitoring and troubleshooting.  Orchestration will play a huge role, as will advanced performance analytics and root cause analysis.

For OpenFlow types of SDN, there are separate sets of challenges.  Many of the basic physical managed components will be the same as before SDN, except that we now must also understand the critical role of the Controller. Further, there is an entirely new technology – OpenFlow signaling – that must be included and accounted for across the full lifecycle of planning, deployment, monitoring, troubleshooting, maintenance, etc. Because OpenFlow is control traffic, it can be a source of useful operational intelligence, but it must also be closely monitored as a new breakpoint and threat point in the architecture.

Further, there are two categories of control traffic to understand and accommodate. The first category is requests that will be coming into an SDN controller from some number of sources that are seeking network services. The second category is the commands that are subsequently sent out from the controller to the networking layer. Some big questions still exist with these layers. How do we assure that the commands are real/valid? How do we deal with resource contention? How do we arbitrate between competing or overlapping requests or commands? Much of this will be solved within the controller architectures, but these are precisely the sorts of issues that may be the root cause of poor performance or non-performance at the delivery layer.

What we are facing is the need to adapt prior art in terms of network and security management technologies and practices and bring them into the mainstream of enterprise planning and operations. This is what we at EMA are calling Responsible SDN – deploying SDN with full confidence that it is production ready, enterprise grade, secure, and manageable.

Tracy and I, along with Scott Crawford, who leads EMA’s security management practice area, will be looking into the Responsible SDN topic much more deeply in enterprise-facing research due to start in January 2013. If you have ideas or opinions about this topic, we would love to hear them!

Enhanced by Zemanta