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.
- Derick Winkworth is underwear-throwing excited about Cisco ONE
- Jason Edelman did an initial analysis of Cisco’s SDN material and is waiting to see the results of the Cisco ONE announcement.
- Colin McNamara’s blog post is a bit more product focused.