The Tale of the Right SDN/NFV Questions

There are always a few announcements or news items in a week that by themselves don’t make the grade in justifying extensive comment, but that might demonstrate something as a collection.  This week we have just that, with announcements from Arista Networks, Mellanox and 6WIND, and BTI Systems.

All of these announcements are cast in an SDN mold, and by now I’m sure you realize that I’m skeptical of the exploding hype cloud surrounding SDN.  All are also, under the covers, grounded in technology evolution and not SDN revolution.  That’s not necessarily a bad thing because we do have to evolve to SDN, but it demonstrates the balance being fought today in the network market.  It’s a war between the need to achieve press visibility by latching on to the concept de jure while at the same time selling your heart out to get revenue to make your venture backers or stockholders happy.

Arista is in my view a good example of a company who’s working to solve the special problems of the cloud, and in particular the problems of the cloud data center.  They offer a line of switches that are based on custom network software, and that software handles a host of issues that have plagued cloud data center designers.  Think spanning tree, monitoring, visibility of VMs and associated network segments, and the old bugaboo of adaptive network behavior.  There is no question that the concept is valuable, no question that cloud networking is important, but there is a question of whether this fits the real model of SDN or whether it’s an argument (and potentially a quite successful one) whether we need central control to resolve the issues of today’s distributed networks.

Mellanox is another interesting contrast.  On the one hand they are, with their long-standing support of InfiniBand switching, arguably the dominant player in fabric switches.  On the other hand, most enterprises in our survey never heard of the company.  Their alliance with 6WIND, a company I’ve noted as the first to make a credible positioning in the Network Functions Virtualization space, is aimed at creating a fabric-based, server-optimized architecture for the hosting of network functions in the cloud or the creation of componentized service-layer technology for network operators.  This is again a very good idea, and the alliance is actually more than sufficient to validate their position, but their launch got next to no notice despite the fact that Light Reading has now committed itself to covering NFV.

With BTI we have yet another slant.  The company talks about “cloud interconnect” and “data center interconnect” and “SDN” in their positioning, and certainly there is a need for 1) intra-cloud connectivity, 2) data center linkages inside a cloud, and 3) software control of connectivity in the cloud.  BTI demonstrably provides at least credible support for all three of these things, but they just can’t pull them together into a compelling story.  Why is “data center connect” not more an application for the fabric or switching solutions inside the data center?  Most connected-data-center applications I’ve seen have hundreds of ports in the data center and perhaps two or three to connect data centers.  What are the applications that generate intra-cloud or data-center-connect needs?  Horizontal traffic among applications would seem a logical reason to connect two data centers; is it the only one and why is it likely to be increasing now when presumably we’ve not had a major problem up to this point?

The common theme here is that “the cloud” is a new relationship between IT and networking, one where networks are a resource to applications as much as memory or CPU power or storage.  It defines a harmony of resources and not the connection of things, and because of that it puts new demands on the networks and the IT processes.  Both must evolve; both are evolving.  What we need to do is to address the goals of the evolution, frame an architecture that represents the model of the future cooperative network/IT relationship, and evolve both networks and IT into conformance with that new model.  Simple, right?

What we are doing is trying to force that balance I talked about.  We want to make the goal not the harmony of the cloud but the individual baby steps we’re taking.  SDN is not the wrapper for every vendor claim that involves software, networking, or definition, it’s a specific notion to replace distributed adaptive network behavior with centralized control.  We have three SDN camps today.  One (the centralists or OpenFlow purists) is actually pursuing the original goal, but they’re way behind the curve in defining all the pieces.  Another (the distributionists or “evolutionaries”) is sustaining most or all of the current distributed network behavior and adding centralized technology to bound or override it.  A third is simply erecting an SDN billboard and calling a press conference.  NFV, which is becoming the latest media hot button, is a bit behind SDN in terms of cynical evolution toward a Roman spectacle, but clearly heading for the same fate.

Arista, in my view, is representing a valuable and maybe even vital discussion, which is whether we need to consider centralization of network connectivity and forwarding control to meet the goals of cloud networking.  Mellanox and 6WIND are asking whether the data center has to be better coupled to the network than traditional network-layer server middleware could achieve.  They’re also asking what would host virtualized functions for NFV.  BTI is asking whether the metro network of the future is going to look totally different based on the explosion of hosting that will emerge from the combination of profit-driven cloud adoption by operators and the hosting of newly virtualized functions extracted from devices.  But none of them are asking the questions the right way, and so none are moving us closer to an answer.

Leave a Reply