Following up on my previous link about Cisco’s take on OpenFlow and SDN, here are Ivan Pepelnjak’s thoughts about it.
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.
onePK is the programming interface developers will be able to use to link Cisco’s networking gear to the rest of the stack. Equipment you already own will be much more integrable into new “cloud-ready” environments, provided you implement the rest of the automation/orchestration stack.
It was the piece that was missing to enable pictures like this one from Omar’s blog:
Left: just add programmability on top of what you have, so your Apps can dynamically provision certain network features.
Middle: want a controller-based network with an out-of-band control plane?
Right: abstract your physical network and enable the dynamic creation of overlays on-the-go.
All possible, choice is there.
