Cisco and the SDN

If you keep your ear to the ground, you’ll already know Cisco announced a new jump into the SDN space this week. I sat around the table and talked about the announcement with Greg, Ethan, and the gang here on Packet Pushers, so you probably already know some of my reaction to this announcement, but I figured it’s always worth talking about twice, so…

First, this is a good thing because it breaks the SDN mold. Software Defined Networks isn’t just about one API, it’s a collection of ideas about making networks simpler to run but more complex at the data plane at the same time. Applying software principles to network operations and design is a good path into the future, one every network engineer should be paying attention to, and getting their hands dirty in, wherever possible. Will SDNs be a silver bullet that solves all our problems? No. We’ll end up trading one type of complexity for another, in the long run, and we’ll have to learn how to handle these tools with care over time.

Second, this is a good thing because it will, at least to some degree, get us back to foundational ideas, and away from the arms race in line cards and backplane speeds. Speeds and feeds are clearly important, but they aren’t the end-all-be-all of network design and architecture. Neat new line cards are neat, and new, but while line cards can be replaced, the time and energy spent learning the features of each every new line card can’t.

Third, don’t forget that Cisco, like all companies,  is in this game to make money. One of the nice things about OpenFlow is that it’s a standard set of APIs. Like all standard APIs, OpenFlow has a large set of problems that can be eliminated by tying it more closely with a particular vendor’s software. Horses are prettier than camels, but that thoroughbred horse is quite expensive… There’s going to be the usual tradeoff between vendor lock-in and open standards to be settled here. The dance of the protocol standards body isn’t going to end any time soon.

Fourth, don’t forget that Cisco, like all large companies, is, after all, a large company. And like all large companies, Cisco has it’s fair share of politics, infighting, and conflicting visions. As a fifteen year veteran of Cisco, having worked in every major piece of the company, I’ve seen more than my fair share of politics trumping technology and common sense.

The bottom line —don’t think a single announcement by Cisco is going to turn the world around. Take the good for what it’s worth, keep your eye on the bad, and continue apace.


  1. says

    SDN/OpenFlow is like using assembler on a modern PC. SDN will only fly of if the eco-system flies of. It will need intuitive user interfaces with north-bound interfaces to OSS/BSS and management systems. Cisco understands that and introduced the southern part of the config I just described. Now it is up to the software-vendors. We are working very hard to complete the stack.

      • says

        Of course I am exaggerating a bit. A higher level programming language might be more appropriate. What I am saying here is that although I really like OpenFlow and the whole SDN concept, we really need to integrate it using sensible API’s. I give Cisco kudos for delivering what they did, delivering the connectors we missed until now.

        • riw777 says

          Assuming we get to sensible APIs… I’m not certain, given the record of the O/S market, that we’ll get there. What we’ll probably have is some form of Java (or Java itself) as one option, various cross-platform tool sets, and then some vendor specific sets of tools that will all co-exist. I don’t think we should see this as the beginning of “one big happy API” land –even the Cisco announcement, with it’s vendor lock-in in some components, points us to what the future is probably going to look like…

          • says

            The vendor lock-in is indeed bothering, but I was expecting that already. I am afraid no vendor will really open up their stack completely with standards, afraid to be commoditized. We have seen that with Netconf/YANG and we are starting to see it already here. To that extent one big happy API is like Utopia.

          • riw777 says

            Hopefully, we only end up with two or three major APIs, and not have 5000 of the things. I think that’s what’s likely to happen, though. What I’m most interested in is figuring out how this impact network design and architecture… So that’s where I’ll be putting thought in the next several months. :-)

          • says

            Like you I still have to give this some thought, but I expect that once we can abstract this in the right way we will have some interesting design opportunities.

    • riw777 says

      I’m not certain I buy that the network needs an “intuitive user interface,” simply because no such “network interface” exists today. I’m not certain a single user interface can capture or express the complexity of network design and architecture.

      On the other hand, I wouldn’t call it “using assembler on a modern PC,” either –it’s more complex and simpler at the same time. It’s closer to using an early implementation of C –the underlying abstractions and facilities are there, but they aren’t all available, so people are going to have to do some funky stuff (drop to assembler) to get around the limitations inherent in the available interfaces until things mature a bit more.

      I suspect the end result will be much like the applications market today –a messy combination of roll your own, commercial, and open source on top, with a messy combination of proprietary and open standard APIs on the bottom. There’s nothing wrong with that –so long as the tools do useful things within their complexity tradeoff.

      • says

        The intuitive network interface is indeed hard to build, but we did our fair thing and are now doing our best to integrate with SDN/OpenFlow. The most difficult part is like you say expressing the complexity of network design and architecture and operating a network from that.

        Some 3GL language would indeed fit better, but you describe perfectly the limitations we are facing.

        Totally agree with the last part.

  2. says

    “The bottom line —don’t think a single announcement by Cisco is going to turn the take the good for what it’s worth, keep your eye on the bad, and continue apace.” Great quote!
    I just want to pet the pretty pony and taste a tear or two.
    Northbound API is the prize, or at least imo the few billion dollar market wall street projected a few weeks back. I think the southern end possibly needs to firm up with another round or two of hardware to allow for wiggle room in tables. For a controller to negotiate programmability and resources from a switch is clearly is not a trivial task to balance a flexible protocol and not create a plate of spaghetti I bet. I would think there is plenty of value a Cisco could bring by tailoring a decoupled NOS to it’s HW and support other vendors through OF (or whatever standardizes). Base instruction support for agnostic hardware, coupled with differentiation in feature support buy purchasing Cisco gear feels like a reasonable business model (I think/hope). Thanks for taking the time to share your insight.

Leave a Reply

Your email address will not be published. Required fields are marked *