When Cisco announced its ONE architecture I was pleased that they were addressing the issue of higher-layer SDN intelligence. As I blogged at the time, and as I still believe, there is no practical commercial conception of SDN possible absent a set of layers on top of the SDN controller to couple forwarding table entries to a true conception of a connection service. Cisco took the lead in recognizing the need for this “higher vision” of SDN, and it was and is a good thing.
Then, apparently under some pressure from the “virtual networking” announcements related to Nicira and Xsigo being acquired, Cisco’s CTO Padmasree Warrior blogged a bit on SDN last week, and some of the comments she made left me confused, not about SDNs but about what Cisco plans for them.
First, Warrior implies that SDNs, network virtualization, and overlay networks are the same thing (“choose your favorite descriptor”) and I have to disagree. Yes there are similarities; one of the properties of virtual networks is that connection behavior doesn’t map 1:1 with physical infrastructure connectivity. VLANs and VPNs, in the best of the implementations, are segments of Ethernet and IP connectivity. So is Nicira’s network virtualization, but I think there is a very fundamental difference, the difference between being on it and in it.
Overlay networks of any sort, including Nicira’s, inherit the properties of the underlying network as USERS OF THAT NETWORK would. They can only present, in some form, what’s offered from below. They’re “on it”, network-wise. But if the virtualization strategy is recognized by the network nodes, embedded in the forwarding processes, it can be managed co-equally with normal network protocols, be given separate QoS, etc. These protocols are “in it”, and so they are very different from overlay approaches.
Here’s an analogy. Suppose I have a trucking company that runs a thousand trucks on a couple hundred routes, and my trucks carry containers. I use some big trans-shipping centers to offload and reload trucks and route containers. I can hub and spoke and get stuff to a bunch of destinations efficiently.
Somebody could create a “virtual trucking company” by buying containers and taking advantage of my trucks and routes and shipping centers. They can serve fewer destinations, segment shipping zones differently, but they can’t go anywhere I don’t go or get there any faster than I do. That’s an overlay strategy. These guys are just shippers on my service like anyone else.
Somebody could also buy their own trucks and use the same shipping centers, but manage their loading and even their routing between centers differently. They may have to run on the same roads as I do, but they run their own stuff at their own speed, prioritize trans-shipping in their own way. They can build source-to-destination routes through different transit shipping points. These guys aren’t overlays, they’re real.
The whole point of “software defined networking” is defining networking, and to most that means doing something to network behavior in a direct sense. That, in turn, means having some way of controlling traffic handling, meaning forwarding. Certainly OpenFlow does that, so it’s “in” the network. I agree with Cisco’s assertion that other VPN and VLAN mechanisms that live at the forwarding level can also be made to respond to software control, but certainly OpenFlow has the same credentials, so it’s not the same as overlay networking or Nicira’s virtual networking. You can’t pick your favorite descriptor if they don’t all describe the same thing.
Lumping SDNs with overlay tunnel segmentation may lead to the next problem I have, the blog’s characterization of the SDN goal as “network slicing” or “multi-tenancy”. As I already noted, segmented connectivity is a property of virtual networking so you can do it with SDNs and OpenFlow. Some of the research projects have focused on creating more flexible Level 2 partitioning as the blog points out. But this isn’t the singular goal of SDN, nor is it the only application that’s been demonstrated. SDN is about software control of virtual network services at any layer. You can do that at Layer One or Two or Three, and even in a shim layer above it (the “overlay networks”). Sure SDNs can create limitless segmentation in both Ethernet and IP, which is network slicing, but that’s not all.
SDNs can combine layers and simplify operations. SDNs can mimic physical layers and help groom traffic in OTN. They can eliminate discovery and autonomic route selection in favor of traffic managed central control. They can build an IP core or a data center network, a CDN, or a cloud, and in all of these missions they can offer benefits incremental to vanilla IP and Ethernet. And sure, maybe at some future point with the right components in place, SDNs could be built right on simple, cheap, switches that didn’t run traditional protocols at all. This is the SDN fast lane, the place where it can be a distinctive value-add, and it’s not network slicing. (If you’d like to view our three-part tutorial on SDN that includes commentary on the various deployment models that parallel and augment Ethernet and IP, click HERE for the first video in the series.)
It’s hard not to think that the blog’s point that SDNs don’t commoditize existing equipment isn’t the whole purpose of the exercise. There’s been a lot of buzz around virtual networks, and perhaps Cisco thinks it has to put a stake in the ground. And it’s true that overlay virtual networks don’t commoditize network equipment, and you can watch my Hangout on Nicira dealing with that very question of commoditization to see why. But remember that SDN isn’t an overlay, it’s an “inlay”. The no-commoditization conclusion leads from the false premise that SDNs are just overlay networks that support multi-tenancy. That’s not what SDNs are.
So DO SDNs in their true sense commoditize network equipment? The answer to that is both “no” and “yes”. “No” in you can’t build a virtual network without a real network built from real devices. It’s far from clear whether even in a decade SDNs will be built on anything other than traditional switches and routers, so don’t expect cheap SDN switches to sweep the market. But “Yes” in the sense that SDN principles can draw valuable features out of both IP and Ethernet, reducing differentiation and thus commoditizing. And they will if vendors don’t address SDN’s real value.
I’m not saying Cisco has no SDN strategy, has a totally cynical one, or has a bad one. I’m just becoming concerned that it has a purely defensive one. The question for Cisco has always been whether its support for the most general case of SDN (which is what they have done) would be offset by an internal resistance to adopting any of the more radical, revolutionary, and potentially compelling interpretations that grow out of that general case. Is Cisco’s characterization of SDNs as “network slicing” true in Cisco’s vision, because they’ve painted a thin coat of “overlay” on a rich SDN tapestry?
Cisco didn’t step away from SDN in the blog. They did step aside, into a kind of “SDN slow lane” that tries too hard to accommodate and preserve the present, and when you do that someone can get past you. Somebody is going to do this right. It could still be Cisco, but it’s hard to see why they’d take the stance the blog post takes if they intend to draw the full potential from their ONE positioning on SDN. And that’s disappointing.