Well I have spent days slogging through what I can find about SDN and the role management will play as we plan out our research calendar for the coming year.  On the topic of management there is nothing.  Management as always is going to be an after thought, period. There is still a huge gap between perception and reality regarding SDN and as long as the overriding and misguided perception in upper level management centers on the idea that SDN will do for networking equipment what server virtualization did for the datacenter, misconceptions will continue to abound.

First and foremost, the people currently driving this effort the hardest are service providers and not the average enterprise network engineer. Service providers are always on the hunt for ways to reduce CAPEX and increase service based revenue streams. That is not to say that enterprise IT shops do not want to reduce CAPEX spending, but what is good for the service provider is not necessarily good for the enterprise, at least not yet.  While service providers often have teams of engineers that can design, build and support custom deployments, enterprise environments often lack the same depth of internal resources.  So for now it would appear and we plan to test this in an upcoming research report, enterprise networking pros are still largely in the research and perhaps early testing phases of SDN, but not yet deploying this technology. Further digging has also led me to believe that SDN is bifurcating in two major directions – one that addresses the needs of the system operations teams responsible for server virtualization deployments and one that addresses the needs of network operations teams responsible for physical networking hardware.

Two Approaches – Two Audiences

Currently two SDN approaches appear to be gaining the most attention: one that centers on SDN controllers and is mostly being driven by equipment vendors and the other initiative emphases building overlay networks.  The first approach is the one that centers on separating the forwarding and control planes and would make use of a software-based controller to handle the communication between the physical and virtual components.  A number of vendors such as IBM, NEC and HP have SDN controllers today. This method would have the best use case for network engineering teams that want to either flatten or simplify their physical networks that have become fragmented and difficult to expand. In theory this approach would allow them to more rapidly address performance issues since it would reduce the need to physically move cables or racks of equipment.

The second approach would be to create an overlay network that tunnels through existing network infrastructure, but that runs and is configured independently. VMware began adding the bits and pieces of this within their core platform and will seal the deal with the integration of Nicira.  The audience, the server virtualization team, can create private tunnels between their own internal infrastructures and/or one or more cloud service providers without direct involvement of the network operations or engineering teams.

Shades of Gray

What is not so clear is how things like soft switch/vSwitch technology will play into both of these approaches. Are they going to be the glue between the physical and the virtual? Soft switches are already out and in the market, so do they side with the controller approach or the tunneling approach or can they play both sides? Also what about monitoring and troubleshooting regardless of which approach, who owns that, who provides the tools? No one has said boo about the role SNMP will play, but clearly someone needs to take up the gauntlet and either extend existing SNMP MIBs or write new ones. There is much at stake here as everyone jockeys for position. VMware’s clear intention to take on the whole network virtualization puzzle its own way is clearly putting it at odds with vendors such as Cisco.

At the same time this message clearly resonates with the IT consumer community, who feels current network designs are becoming roadblocks to remaining competitive in the market. There are other signs of vendors trying to address this frustration. While Cisco’s onePK provides a set of network device APIs to improve network programmability, it is an interim step not a long-term solution. OpenFlow-based SDN controllers are already on the market and if a culture can grow up around them, fortified with features that would improve cross platform interoperability and greater application awareness, this could at least (for the near term) keep existing networking solutions relevant and viable as the market evolves and comes more into focus.

At the end of the day, I just do not see these two initiatives resolving themselves into a single clean cohesive solution, but rather fragmenting along the way drawing into question both scalability and interoperability of these approaches as they mature. This is about making existing infrastructure more flexible and adaptive and at the very least both initiatives address it in their own way.  It hearkens a change to the status quo, but whether for the better or worse in the near term it is hard to say. In any case, networking remains a hot topic and SDN will be the buzz for 2013.

Related articles
Enhanced by Zemanta