Cisco Blogs

SDN: Are We There Yet?

October 19, 2012 - 13 Comments

True Story:  When my son was about 3, I took him to go see his first movie  in an actual movie theater.  They had just built a brand new theater near our home and he was suitably impressed with all the bright shiny lights.  Anyway, we got our popcorn and grabbed our seats just as the lights were dimming (you never really go anywhere quickly when an inquisitive toddler is involved). We got through the movie trailers, then, to my surprise, my son popped out of his seat and said he was ready to go home.  Being his first movie-going experience, he thought the trailers were the big deal and did not realize we had not yet gotten to the featured attraction.

I was reminded of this after watching some conversations around SDN and programmability unfold over the last few days.  If you believe to some of the folks out there, SDN is a settled matter–the technology is done, use cases nailed, and winning vendors already crowned.  All that’s left is for the janitors to sweep the popcorn off the floor.

Personally, I think we are still watching the trailers–as much progress as folks like ONF of the OpenStack Foundation have made to date, I don’t think either organization will tell you they are ready to stick a fork in it just yet.  More importantly, we are just starting to get an inkling of what is possible with programmable infrastrcture –and, yeah, I am thinking it might be a bit premature to crown any victors on the vendor front.
To that end, check out this PacketPushers Podcast recorded with our very own David Ward and Lauren Cooney.  Greg and Ethan lead a good meaty discussion on where things are going which I think you will find useful.  I’d also point out that this is not idle banter–David and Lauren are both actually building this stuff. Take a listen to the podcast (its about 45 min)–would love to hear what you think the future holds.


In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. This is a great conversation happening here – all strong feedback and also good comments – please keep them coming!

    There are multiple solutions that vendors are providing for SDN today, but there are also multiple needs in the market for these solutions. With onePK, we are looking to consistently and proactively allow for users to now access their OS in easier ways than before – so you no longer have 3 operating systems, but actually an abstraction layer that allows for you to harness the power of all 3 via the interface. This interface, while currently in Java and C, will also be RESTful (soon) and we are looking at other languages as well (Python is one, and we’d like your feedback on that).

    SDN means many things to many people. What it comes down to is the problem folks are trying to solve. onePK is just one aspect of Cisco’s solution (see for more info) but we have more coming down the pipeline soon. Dave Ward & I will be following up with a podcast in the next month with more details on this – and we’d love to hear what you’d like us to talk about. At the end of the day our job is to build what you, our customers and users, need – and your feedback is essential to that, so please do engage!

    You can reach me directly at my address below or my twitter account – and look forward to more dialogue!

    Lauren Cooney
    Sr. Director, Software Market & Developer Strategy
    NOSTG, Cisco Systems

  2. Regarding REST, we demonstrated a onePK REST interface at Cisco LIVE back in June, and we will have more specifics on our roadmap and direction with regard to REST soon!

    Kevin Woods
    Director, Product Management, NOSTG

  3. I understand why you need an SDK to provide an intermediary layer to talk to network operating systems built without an API in mind like IOS. However an SDK is another layer (proprietary) of code and complexity that will increase overall system complexity. It has to run somewhere.

    There is a big difference between SDK’s and API’s and so far Cisco interchangeably uses both terms which is disingenuous. Dictating languages like Java and C is another problem. Plus the SDK route means new languages mean additional development time and maintenance cycles for Cisco. What we really need is a proper RESTful API that doesn’t require another layer of language dictated SDK.

    Again I understand you can’t bolt API’s onto something like IOS, but I wonder if some players will move to a network operating system that was built from day one to provide a proper API that I can interact with with any language I choose.

  4. Omar,

    Is there a way to get access to Cisco’s proof-of-concept openflow controller and agent? Secondly, which hardware is supported?


    • Hey AJ:

      Thanks for the interest. Its a closed beta right now, but ping me at osultan at cisco dot com and we can chat some more.



  5. Here’s specifically what I have a hard time grasping. At the 10:30 minute mark, in trying to describe the positioning of onePK, David refers to northbound and southbound APIs of the OpenFlow agent.

    Now, I know SDN means different things to different people and vendors. But one widely accepted definition is the separation of CP and DP via a Controller-led network with northbound APIs between the user/applications and the Controller (to my knowledge, none have been defined yet) and southbound APIs between the Controller and the switches (e.g. OpenFlow and NETCONF).

    What I’m looking for from Cisco is a tutorial on the following: Using the definition of SDN above, where does onePK sit and what value does it bring? Thanks.

    • I believe you have to forget that definition of SDN. The CP and DP are not separated but reside in the router/switch. They provide the onePK API. An OpenFlow agent can run on top of IOS and talk to the relevant onePK API’s on the south side while talking the OpenFlow API on the north side. This would mean some of the onePK API’s would support OpenFlow functionality. The “controller” that talks to the OF client would thus be quite different from a centralized controller visualized by ONF.

      • Ashwin:

        You are correct–we can build an OpenFlow agent for a given switch using onePK. One benefit of this approach is that it can take full advantage of the capabilities of the underlying hardware.

        Thanks for helping to clarify.



    • Umair:

      Check out this post – onePK Plays Well With Others –
      and see if it answers your question–if not post another comment and let me know.



      PS – As part o the formal release of onePK, we will have all sorts of tutorials, sample code etc to help bring folks up to speed

  6. Good blog. I’m very skeptical of cisco and would challenge that the podcast really was just idle banter. They are threatened by SDN and so are in a defensive position. Although outwardly they say they love it. OnePK is simply a proprietary answer to critics in order to defend their turf. They want SDN to go away. It won’t. Too many companies are embracing SDN and Openflow for cisco to successfully dismiss the challenge. They better hope they sell a lot of ip phones next year…

    • Hey Pete–

      Thanks for reading. I can certainly understand your perspective. Many folks expect us to be defensive about SDN and certainly some of our competitors would like to believe we are too doddering to do anything about it. 🙂 Simply not true.

      So, is onePK proprietary–only to the degree it is designed to work only with Cisco gear–but that is the nature of an SDK on the southbound side–Juniper’s SDK only works with their stuff and even at a lower-level, Broadcom and Intel/Fulcrum SDKs only work with their respective silicon. BTW this is not necessarily a bad thing–it allows the SDK to tap the full capabilities of the hardware as you will see later on. Anyway, the most of the action is happening on the northbound side. There, things are anything but proprietary. onePK exposes an immense amount of information–onePK is the exact same development environment (no secret squirrel APIs) our own engineers use to create features for our operating systems, so you that should give you an idea of how powerful the develop tools are–you are getting the keys to the kingdom–perhaps this also answers Umair’s question a bit too.

      Anyway, with this SDK on the northbound side you can do some interesting things. You can directly access the hardware via onePK–currently with C and JAVA, other languages coming soon. However, we will also release agents that allow you to access the hardware via other mechanisms–for example, this summer we demoed an OpenFlow agent–down the the road, as other protocols emerge (IRS, PCE, etc) we can quickly and easily stand up agents to support those technologies.

      So when we do these podcasts, I ask everyone to keep things conversational–the kind of chat you would have over a beer. The reasons is these are complex topics and I want to keep them accessible to folks–we are trying to be educational, not demonstrate how smart we are. That being said, its important to recognize that David is currently the chair of the Technical Advisory Board at ONF (check out this post for a snapshot of all the folks we have contributing to ONF efforts and he is also the CTO for the SP engineering teams so things he is talking about on the podcast are the things he is advocating in the standards bodies (i,e, IRS) and building for Cisco.



  7. Umair:

    First of all thanks for your continued readership of my posts. I am glad its more than just my mom reading these things, 🙂

    In terms of providing more detail, we realize onePK is a meaty topic and we will be bringing out many more assets to help folks get a better handle on the topic.

    That being said, can you give me an idea of some of the specific questions you have–I am sure you have questions, other folks do too.



  8. I listened to the podcast, but honestly, I was a bit stumped with how Cisco onePK offers value. The virtual whiteboard was not good enough. I rewinded several times to play back, but struggled to understand the applications and use cases. I know a follow-up show is scheduled for onePK use cases, but I would appreciate a detailed tutorial as well. I particularly appreciated your 3-part writeup series on VXLAN last year. That answered a lot of my questions. I hope to find a good primer, if not tutorial on Cisco’s onePK applications soon. The existing documentation does not suffice, nor does this particular PP show unfortunately.