Now With SDN for More Forwarding Goodness in Every Lookup!

19 September 2012 by 6 Comments

All of the networking vendors want to be included in the software defined networking club. Anything they can do to point out, “We have an SDN strategy! No really, we do,” they’re doing. We that evaluate, recommend, and ultimately purchase networking equipment need to be careful to figure out what a vendor is actually delivering when they claim SDN capability. What a vendor wielding “SDN” on a slide deck wants you to think is that they are delivering some brand new, powerful, flexible, or simpler way to make the packets move around your network. A few solutions actually deliver applications along these lines. Think Embrane (not precisely in the packet pushing business, but I like the way they abstract resources). Think Plexxi’s notion of Affinity Groups.

But most vendors are not delivering integrated SDN solutions, not so far. In fact, if the most notable SDN success story is Google…well, they built it on their own, and still used a lot of legacy protocols to do it. Hmm.

One form of SDN marketing hyperbole is equating an application programming interface with SDN. “We have an API; therefore you’ll have an SDN if you deploy our gear.” Sorry, but an API does not a software defined network make. An API from a networking vendor is merely a tool (albeit a powerful one) that offers you a documented and hopefully predictable way to make something special happen with the packets that scurry around your data center. Assuming the API allows manipulation of forwarding tables, all you’ve really bought is a potentially software defined network. You still need to fulfill your wild-eyed SDN dreams with your own programming skills. “You want an SDN? Fine,” some vendors are saying. “Write the code yourself, and good luck with that.”

So…an API, to me, is decidedly not equal to delivering an SDN. Software *definable* network? Okay, I will go that far with you, dear vendor. You could even say “SDN Ready.” But software *defined*? Well, it just isn’t, is it? Not merely because you’ve got an API available. Am I splitting hairs? I don’t think so. I want a simpler network that integrates with my other IT assets. I don’t want to figure out for myself how that’s going to happen. I still want the network-in-a-box. I still want centralized, orchestrated network provisioning, application-oriented service monitoring, and the ability to write custom forwarding policies based on criteria I define. But mostly, I want that simplification. I want to move away from what I recently heard described by Russ White as “the pile of protocols.” As of yet, I don’t see the vendor offerings heading in this direction. APIs are indeed powerful tools, but they probably make my network more complicated if I have to deal with them myself on a large-scale. Not less. Are APIs necessary? Absolutely – I’ve argued in their favor. I like the API idea. I think APIs are the layer needed to truly abstract the network while allowing existing product lines to continue. But I don’t want to become a programmer to make my own software defined network, anymore than I want to have to create my own word processor to write this post. I want vendors to give me a complete set of applications before they claim they’re selling me an SDN.

Mass market adoption of SDN is far off in the distant future. I think I can still see it on the horizon…maybe. Hard to tell. I think the focus is getting blurrier than it was six months ago.

  • Little guys don’t know why they need SDN. And mostly don’t care. “Does it do 10G? Okay, good, because we have a lot of that 10G stuff showing up on the dock.”
  • Big guys possibly need it, but for reasons that vary as widely as the environments they represent.
  • Standards bodies are scrambling to determine where to put the SDN stake in the ground, while vendors are doing their earnest best to manipulate that process to their advantage.
  • OpenFlow is limited in scope, is not an open standard, and is seeing slow vendor uptake as the versioning progresses.
  • The message of just what SDN is is becoming diffuse and indistinct. SDN has about as much meaning as “cloud”. Can pros that run cloud networks define “cloud”? Sure they can. But to the marketing organizations of the IT industry, cloud as a term has been beaten into meaningless twaddle attached to everything in the IT space. SDN is rapidly heading in that same direction, especially from vendors who want you to keep buying the same stuff you’ve been buying for years. SDN is a marketing sticker you slap on the front of the same old switch…”NOW WITH SDN FOR MORE FORWARDING GOODNESS IN EVERY LOOKUP!”

Now is a good time to be skeptical. To be cynical. To ask a lot of questions…that is, if SDN actually matters to you in the purchasing process. I have a concern that if SDN continues down the road it’s been on lately, maybe no one’s going to care all that much.

And that would be a shame. We’re right on the edge of something great.

Filed Under: Blogs, SDN Tagged With: ,
About Ethan Banks

Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions, and technology corporations. Ethan is a host of the Packet Pushers Podcast, which has seen over one million unique downloads, and today reaches a global audience of over ten thousand listeners. Also a writer, Ethan covers network engineering and the networking industry for a variety of IT publications. He is also the editor for the independent community of bloggers at PacketPushers.net. Follow @ecbanks.

  • http://www.facebook.com/james.braginton James Braginton

    Hahahahahaahahahaahahahah,,,,excellent.

  • http://twitter.com/netmanchris Chris young

    hi Ethan, I’m with you 100% on the current state of the definition grab on the whole SDN term. I actually wrote on blog on this last week. I don’t have any answers, but after a lot of thinking, reading, and arguining; I’m starting to think that the real key is that of useful abstractions. OpenFlow and the promise of it is delivered because of the useful abstractions that allow a programmatic interface to “the network” as a system instead of individual devices.

    I believe that there are other useful abstractions though, such as management plane abstractions allowing for the configuration of a multivendor network through a common, consistent API of some kind.

    Having watched what’s happened with the cloud washing of products in the last few years, I agree 100% that we have to be very careful on how we let the vendors define the term SDN or we will wake up tomorrow with another meaningless term that confuses everyone and offers no useful taxonomy that allows customers to differentiate between solutions.

    But, I also think that there we can’t be too restrictive on just allowing a definition that restricts this to ONLY control plane abstractions. It does appear that OpenFlow is the current winner, but if we are too restrictive does it create a situation where it restricts innovation because of a definition. words are important, but sometimes too much restriction is just as bad as too loose if all it does is leaves us arguing over semantics.

    Full Disclosure: I work for HP Networking and we do have a product that has these qualities.

    • http://twitter.com/maschipp Michael Schipp

      I believe that there are other useful abstractions though, such as management plane abstractions allowing for the configuration of a multivendor network through a common, consistent API of some kind.

      Have a look at Netconf for this.

  • http://twitter.com/MrsYisWhy Mrs. Y.

    Great post and reminds me of the brouhaha surrounding the IPAM buzzword a few years ago. So many vendors promised to purge our organizations of the dreaded spreadsheets used for address management, to make the arcane world of BIND easier to configure. So many promises left undelivered. The problem is that most organizations develop internal processes to meet these needs and implementation of the COTS product means retooling said processes. This can be a bigger hurdle than the deployment of the solution. Especially when many network engineers are resistant to anything that might take away their CLI. Because we all know that real men don’t use no stinkin’ GUI. Then there’s also the fear that it may eliminate their jobs.

  • Ben

    Great post and interested thoughts, bunch of marketing bs. I’ve found a new firewall/router from halon security (called vsr ) that pretty much cover my/client needs and I was amazed how nicely everything was packaged with various platforms (mostly played around in VMware) and their way to show configuration revisions.

  • returnofthemus

    Very entertaining read, espeacially when read in the context of the ramblings of an old man showing first signs of dementia. On the one hand vendors are being chastised for at implementing open APIs and on the other for selling equipment, as though they should all be singing from the same hymn book, well Hello?
    Although, I’m sure that the networking industry is very much looking forward to being called upon to create and support the custom apps for those that can’t be bothered to program, alternatively I’m sure they are more than happy to sell the equipment they have been for years in the usual way.
    Other than that there is always the cloud, as they say the choice is yours and there’s plently of it!