The fate of the cloud is also the fate of the network vendors, as I’ve noted before. There is nothing that will stop the use of OpenFlow and SDNs for data center networking, and while arguments that “merchant silicon” can produce the optimum OpenFlow switch are false, it’s true that commodity switches could produce results so close to optimum that other factors would stomp out the differences. April’s Netwatcher will talk about how the two forces of today’s market—the cloud and OpenFlow—might combine.
Cisco, HP, and Juniper are in their own ways fighting for the future of “cloud” networking when they’re fighting for the future of the data center. Juniper had a lead in this when they announced QFabric over a year ago, then followed it up with the WAN-optical-core PTX. The problem is that they muddled the whole positioning in the first place and in the second apparently didn’t see the real connection with the cloud and thus didn’t provide for it at the technical level. Enterprises tell us that they still position QFabric as being a response to the cloud, but not a UNIQUE one, meaning that they don’t tout specific cloud features, only cloud traffic. Cisco is said to be pushing a new spin-in that might be around OpenFlow, or maybe cloud storage, or maybe nothing at all, given that Juniper’s QFabric launch hasn’t created the market pressure Cisco feared. HP seems to believe that all it needs to do is to embrace OpenFlow as an option on Ethernet switches, which would argue that it would have no impact on hardware design.
OpenFlow isn’t going matter if it never moves beyond being an option on an Ethernet switch or an open-source controller. Many of the benefits can never be realized in this limited application, and most users probably wouldn’t see the value in adopting it. The real value of OpenFlow is to replace traditional switching/routing in applications where the number of flows is manageable. That means inside the cloud and inside the data center…and of course the former implies the latter.
There are two issues with OpenFlow that all vendors need to consider. First is the way that its use could impact the transit path between network points. In theory, an OpenFlow switch could have as many trunks as ports, creating more of a mesh, because it’s not limited by Ethernet bridging principles in setup. If OpenFlow switches had cut-through switching capability they could be the foundation of a mesh architecture that would likely make further evolution toward a fabric unnecessary for most applications. Who says that? Nobody. In theory, OpenFlow switching works because application awareness can be pushed down to the flow level, which is the whole point of software-defined networking. But how does that happen? Nobody says.
There’s every chance that today’s vendors really want OpenFlow to fail, but most could benefit from its success if they positioned it properly. Cisco could shut down Juniper’s data center hopes, Juniper could create the first true cloud network, and HP could rain all over every network vendor’s switching position. But not the way it’s going today. Vendors need to first articulate a real position in what an OpenFlow switching architecture would look like, how the elimination of the bridge model of Ethernet and implicit or discovered connectivity would free connectivity. They also need to articulate how applications control flows. Right now, this isn’t happening even for vendors in the OpenFlow space, and it’s whoever gets this right that wins.