Cisco ONE: More than just OpenFlow/SDN

As expected, Cisco launched its programmable networks strategy (Cisco Open Networking Environment – ONE) at Cisco Live US ... and as we all hoped, it was more than just OpenFlow support on Nexus 3000. It was also totally different from the usual we support OpenFlow on our gear me-too announcements we’ve seen in the last few months.

One of the most important messages in the Cisco’s ONE launch is OpenFlow is just a small part of the big picture. That’s pretty obvious to anyone who tried to understand what OpenFlow is all about, and we’ve heard that before, but realistic statements like this tend to get lost in all the hype generated by OpenFlow zealots and industry press.

The second, even more important message is “let’s not reinvent the wheel.” Google might have the needs and resources to write their own OpenFlow controllers, northbound API, and custom applications on top of that API; the rest of us would just like to get our job done with minimum hassle. To help us get there, Cisco plans to add One Platform Kit (onePK) API to IOS, IOS-XR and NX-OS.

Why is onePK important?

You probably remember the “OpenFlow is like x86 instruction set” statement made by Kyle Forster almost a year ago. Now, imagine you’d like to write a small PERL script on top of x86 instruction set. You can’t do that, you’re missing a whole stack in the middle – the operating system, file system, user authentication and authorization, shell, CLI utilities, PERL interpreter ... you get the picture.

OpenFlow has the same problem – it’s useless without a controller with a northbound API, and there are only two commercial OpenFlow controllers I’m aware of at the moment (Nicira’s NVP and NEC’s ProgrammableFlow controller), both of them solving niche problems. If I want to modify packet filters on my wireless access point, or create a new traffic engineering tunnel, I have to start from scratch.

That’s where onePK comes in – it gives you high-level APIs that allow you to inspect or modify the behavior of the production-grade software you already have in your network. You don’t have to deal with low-level details, you can (hopefully – we have to see the API first) focus on how getting your job done.

Open or proprietary?

No doubt the OpenFlow camp will be quick to claim onePK is proprietary. Of course it is, but so is almost every other SDK or API in this industry. If you decide to develop an iOS application, you cannot run it on Windows 7; if your orchestration software works with VMware’s API, you cannot use it to manage Hyper-V.

The real difference between networking and most of the other parts of the IT is that in networking you have a choice. You can use onePK, in which case your application will only work with Cisco IOS and its cousins, or you could write your own application stack (or use a third party one) using OpenFlow to communicate with the networking gear. The choice is yours.

More details

You can get more details about Cisco ONE on Cisco’s web site and its data center blog, and a number of bloggers published really good reviews:

14 comments:

  1. Don't want to sound negative or anything, but first things that pop into mind are:

    - Cisco's embedded software is notorious for its whack-a-mole software defects. Now we will have two additional layers on top of it: onePK API and applications that talk to your Cisco network via this API. Perspective of troubleshooting and bug-hunting in this cake sounds like fun (not).

    - onePK will only drive Cisco devices, and far from all of them to start with. Transitional period will be interesting. For those with hedged Vendor bets the perspective of having a schizophrenic management plane, like, *forever*, may present an interesting choice to be made. For me personally, if I was setting my Vendor/technology strategy anew, availability of onePK does not make Cisco any more attractive then it was before the announcement.

    - Looking at that onePK DE diagram above, I'm thinking "gosh, that is one ambitious project". Will be really interesting to see how long it will take for this to become reality across all these domains and devices. Also wonder which of the zillions of IOS trains/versions will be supported. All of them? Doubt it somehow.

    - Back to "Cisco-only", I hope everybody realises that onePK is *the* ultimate vendor lock-in. I'm struggling to think of anything that would lock you in tighter than that if you seriously bought into it. I'm not saying there's anything wrong with lock-ins, but this one may become a particularly difficult one to get out of, if down the line someone else offers a better alternative, or if Cisco falls short in delivering on the promise - unlikely, but not impossible.

    One possibility here is that onePK could get "cloned", or Cisco may choose to license it (maybe for free?) and other vendors would implement the southbound part of the API using their vendor-specific methods (netconf/snmp/xml/whatever). What is the likelihood of this happening? Don't know.

    Anyway, just a few grumpy late-Friday thoughs. ;)

    -- Dmitri
    Replies
    1. Totally agree with you ... and keep wondering why people developing applications for iOS/Windows or writing stored procedures for Oracle, MySQL or SQL Server don't complain about vendor lock-in. Haven't seen too many smooth migrations between any two of the above.
    2. Different stages of evolution. See @swardley's article that talks a bit about it here: http://blog.gardeviance.org/2012/03/tens-graphs-on-organisational-warfare.html, also @claychristensen talks a lot about it in his "innovator's" series.

      You know what at one point gave me hope? Quantum. It is waaay too simple, but in my mind the model is *the* right one. Open standard API, and vendor-specific plugins to make it work.

      Reality, however, is bitter - unless there's a strong incentive for Vendors to create those plugins, they have a snowflake in hell's chance, unless a significant market force similar to ONF appears and demands it.

      On the other hand, would be interesting to see if other networking vendors who have put some skin into the OpenStack game would wake up and put some effort into Quantum.
  2. Something sounds very familiar... ah wait, here it is.
    www.juniper.net/us/en/local/pdf/whitepapers/2000378-en.pdf
    Creating Innovative embedded applications in the Network with the JUNOS SDK. (2011)

    I think onePK is the only next logical step for Cisco. I'm sure the other vendors will follow suit in some similar fashion.

    OpenFlow has served its purpose in forcing Vendors to open up their boxes.
  3. Ivan,

    I've read of so many posts from you and other top bloggers on OpenFlow.

    I still have no clue what it is.

    May I request a 'one sentence' explanation? Is it just a means to allow other groups to add features to a company's software (ie IOS) and if so how in the world would another company know where to start? Is it an actual protocol running at some layer in the OSI?

    I'm a seeing as believing person and just cant get my head wrapped around this.
    Replies
    1. Since nobody else responded... I'll take a shot. OpenFlow is a specification for programming a switch's FIB from a centralized controller. All of the "intelligence" then resides on the controller rather than in control plane protocols on the switch itself.

      The advantage of this is that you can centralize forwarding logic and explicitly direct (or drop) traffic based on out-of-band information such as NMS, inventory systems, load, costs, etc. A common simple example is to eliminate dynamic address learning by programming MAC-to-port mappings or IP-to-MAC mappings explicitly based on an out-of-band database. You could do stuff like completely eliminate frame flooding this way, but it comes at the price of having a totally different way of thinking about networking. Any control or management features that you're used to would have to be reimplemented in a pure OpenFlow network.

      Cisco's onePK is a set of APIs for programmatically manipulating the *existing* control, forwarding, or management planes of IOS devices.
    2. I still cannot visualize openflow more than a database of Policy based routing (PBR) route-maps which is not stored on router or switch itself but stored externally on controller and controller communicates to router or switch to push those PBR route-maps into FIB.

      And I guess openflow spec defines protocol to do this and Cisco One PK provides API to write those PBRs. Is this correct?
    3. Your first paragraph is a decent analogy as long as you realize that in "pure" OpenFlow, there is no other intelligence in the switch at all. After the code matches a flow, all it can do is set one or more of the OpenFlow actions (output, drop, set group, change TTL, set queue, or a couple of other things). No routing protocols, no LLDP, STP, etc.

      However, people are talking about a "hybrid" model where there is a normal control plane that will handle packets that aren't handled by OpenFlow.

      Cisco's onePK, on the other hand, is an API directly into any flavor of IOS, so you can do anything the hardware and software supports. It's much more than just controlling the FIB (although you can do that too).
  4. Dimitri,

    As one of the architects of onePK, I appreciate your comments. We have a very software mindset - quality and usability for developers is top of our mind. It does sound a little ambitious but we have been working on it for quite a while and now have a lot of working code across Cisco platforms. So we do have working proof points; it is not just fancy ppt :-).

    We see this as the natural evolution of the network into a developer platform, just as we the desktop, server, and mobile platforms have been opened up to a broad development audience.

    Regards

    John
    Replies
    1. John,

      Thank you for the comment, much appreciate it.

      I wasn't saying that it doesn't work or that it's a ppt. I believe that you guys see it as very important and put a lot of effort behind it.

      I guess it must be the old wounds speaking, when on a number of occasions we were let down by the IOS code quality, and adding onePK on top isn't making things any simpler or less complex.

      Don't at this point see any apparent remedy for this, apart from giving it time and seeing how it will turn out.

      Cheers,

      -- Dmitri
  5. As usual, Cisco provides a belated yet well thought out and impressive vision. Whether or not their vast Enterprise customer base actually uses OnePK, who knows, and who cares? Not Cisco.
    Calm down the hype and anxiety? Mission Accomplished (i think).
  6. I still cannot visualize openflow more than a database of Policy based routing (PBR) route-maps which is not stored on router or switch itself but stored externally on controller and controller communicates to router or switch to push those PBR route-maps into FIB.
  7. Hi,
    Interesting post. How do you see OnePK v VMware/Nicira's NSX?
    They basically want to virtualize networking like they did it with servers. It opens up interesting possibilities. While OnePK is more like a significant improvement in network management/operation (provided it will work as described). Someone up there made a point of how quick this thing will really fly with all the variety of IOS strains. VMware kinda looks more attractive in that sense.

    In any case - both are vendor lock. The benefit with VMWare is they don't care about hardware. Cisco wants both.
  8. http://developer.cisco.com/onepk/capi/index.html
Add comment
Sidebar