With the Open Networking Summit about to kick off it’s obvious that there’s going to be a lot of things going on with respect to SDN and cloud networking. The problem we have, in my view, is that all of this is a race to an unknown destination. We’ve picked apart the notion of SDN and we’re busy claiming supremacy in itty bitty pieces of it, but we’re unable to tie the pieces into a functional whole that would then justify (or fail to justify) SDN use.
Right now there are two big public issues in the SDN world; the controller process (largely because of the OpenDaylight project and some counterpunching by vendors like Adara) and “virtual networking” via overlay technology by players like Nicira/VMware and Nuage/Alcatel-Lucent. People email me to say they can’t understand how these fit, either with each other or in the broader context of SDN value.
Let’s start with that. Networks connect things, so it follows that the goal of a network architecture is to create a route between points that need to be connected. There’s two pieces of that process—knowing where to go and knowing how to make traffic get there. The second piece is the individual device forwarding process; a packet with this header goes in this direction. The first piece is a combination of a topology map of the network (one that locates not only the connecting points but also the intermediary nodes) and policies to permit which of what are certainly going to be a multiplicity of route choices should be taken. In classical networking the topology map is created by adaptive discovery and the policies are implemented in a “least-cost” routing protocol that optimizes something like capacity or hops.
Classical SDN, the original research effort, works to replace the topology/policy stuff that’s currently distributed in devices with a centralized function. That function needs then to control the forwarding in devices, which is what OpenFlow does. The OpenFlow controller is a function that manages the exchange (via OpenFlow) with the devices. It doesn’t decide on routes or policies, it only controls devices. All that deciding and policyfying goes on north of those often-referenced “northbound APIs”.
What does this have to do with virtual networking, Nicira, and so forth? Nothing, frankly. Virtual networking is a way of creating application-specific network partitions to isolate cloud applications and to make it possible to spin up a network that connects a community of components that are related to each other but have to be isolated from everyone else. You don’t need OpenFlow or any sort of SDN principle to drive this because it’s a software-based tunnel overlay. There are differences among the implementations, though. Nicira has been presented dominantly as a VLAN strategy, limited to the data center. Nuage and Alcatel-Lucent have presented a broader model that can emulate IP and port-level connectivity, which means it’s pretty easy to make their virtual networks run end to end, data center to branch or cloud to user.
The challenge that nobody is really talking much about is creating that high-level value, that central intelligence, that application-and-user specificity that would make all of this highly useful. We need a connection mission to justify connectivity management, and all of the stuff that purports to be SDN is still picking at implementation details amid the fog of possible applications where nothing stands out. Add some tools to OpenFlow and you can create core routing like Google did. Add different tools and you can manage data center flows to better organize switches and eliminate the traditional multi-tier networks. But you can do both these things without SDN, and if you want to do them with SDN you need more than an SDN controller.
We are starting to see some promising developments in the SDN world. Alcatel-Lucent’s recent Nuage announcement is an advance because it makes it possible to visualize a clear delineation between virtual-network connectivity management (Nuage) and route management at the network device level (Alcatel-Lucent), but a delineation that provides for feedback from the former to the latter to create manageable networks. The problem is that because we’re not owning up to the problem, the fact that SDN needs a connection/application mission to be valuable, we don’t hear about these developments in the right context.
When you go to the ONC next week, look past the fights over how many SDN angels can dance on the head of a controller, to the top-to-bottom, end-to-end, vision that a given SDN vendor actually supports—supports with functionality and not with vague interfaces. That will separate reality from SDN-washing.