Cisco, one of the vendors we’ve been watching on the path toward what we think is the critical symbiosis of the cloud and OpenFlow/SDN, has blogged (http://blogs.cisco.com/news/is-it-just-sdn/) about their view of the subject. I’m happy they did, but I confess to being a little confused by what they said. It seems that Cisco is arguing that OpenFlow and SDN, like other megatrends of the past, is perhaps a bit overhyped on its own, a topic that is more an element in a complex evolution than the driver of a radical revolution. While I agree with that, I think you have to use the water clock analogy here to get the real impact of SDN.
In a water clock, water drips into a bucket. For a while, nothing happens, but at some point the weight of the water is enough to overcome a resisting force and the mechanism moves, advancing the “clock” and dumping the water to start the process over again. I think that advances in tech, particularly in the current age of complex market interplay at both the technology and business level, work like this. You can see from Apple’s iPad that revolutions really do happen, and just because they build on something else (like the existence of wireless broadband in this case) doesn’t mean they’re less revolutionary.
Cisco is right that the SDN or OpenFlow or cloud revolution isn’t about only that thing. They’re even right that things like SOA and DevOps are a part of the story; it’s more than SDN. They’re right that a big element in SDN is making the flow of information between the controller and the controlled devices somehow bidirectional, so that state or intelligence can be extracted from the network. But they may be implying something that’s less than right, which is that somehow SDN has to be made to work like routing or switching works today to be effective, valuable. In fact, that would assure value could never be realized.
Network state in switching and routing is adaptively discovered, which is great if you’re in an age where it changes all the time, and where you intend to do something about it. In reality, though, we’re building networks to be much less failure-prone, and traffic over the Internet is best-efforts. So what we really need to have is a system whereby the individual switches in an OpenFlow world “tell” the controller what they see about network conditions on a regular basis. Are the neighbors alive, accessible? Are any trunks reporting congestion? The rub here is that it’s easy to envision an OpenFlow device losing touch with the controller because of a problem. It’s the classical “who watches the guards?” problem; you can’t report a problem because you’re having one. It seems insurmountable, except that I’m not proposing that OpenFlow or SDN principles replace the Internet. I think it’s a network for inside the cloud, something that can presume control telemetry reaches devices via another path, and that’s something that the blog doesn’t talk about.
I’m not picking on Cisco; they are presenting this week at the OpenFlow event and I actually think they have decent insight on the topic, better than any network vendor in big-picture terms, though Ericsson beats them in application of OpenFlow to optics. As I pointed out before, Cisco’s Donabe project may be the best DevOps hope, and DevOps may be what gives the software in an SDN the intelligence it needs about application connectivity requirements. I’m suggesting that Cisco is more right than they realize; we need to reconceptualize how we build networks because we’re reconceptualizing what a network is. It’s not about communicating anymore; the Internet isn’t valuable for connection, but for services. Connection only happens to be an element in how we create those services, and as our mechanism for service creation changes, so do connection requirements. And technology.
And market. Verizon is one of three Tier One operators that tell us they have OpenFlow projects underway at the lab level, and all of them say the cloud is a target. All also say that OpenFlow is just a piece of the puzzle, just as Cisco’s blog said. But the operators seem willing, determined even, to drive those pieces together, and that’s the one thing I’d have liked to have seen reflected in that Cisco blog.