Open Networking Foundation (ONF) created a ginormous amount of OpenFlow hype, declared Mission Accomplished, and never even tried to focus on what interface the SDN controllers will offer to the outside world.
Nor surprisingly, every controller vendor used a different API, creating another layer of lock-in, but ONF never cared about that, because the most influential founding members planned to write their own controllers anyway.
A decade after I wrote this blog post the debate is moot – there are not enough OpenFlow controllers out there to worry about being lock-in – but we’re experiencing the same dilemma in network automation and intent-based networking space.
On a totally unrelated note, nothing ever came out of Cisco ONE marketing machinery, but we did get REST API on Nexus OS and decent NETCONF on Cisco IOS XE.
Published on , commented on July 19, 2022
SDN Controller Northbound API Is the Crucial Missing Piece
Now imagine none of those APIs would be standardized (various mutually incompatible dialects of Tcl used by Cisco IOS come to mind) – that’s the situation we’re facing in the SDN land today.
If we accept the analogy of OpenFlow being the x86 instruction set (it’s actually more like the p-code machine from UCSD Pascal days, but let’s not go there today), and all we want to do is to write a simple script that will (for example) redirect the backup-to-tape traffic to secondary path during peak hours, we need a standard API to get the network topology, create a path across the network, and create an ingress Forwarding Equivalence Class (FEC) to map the backup traffic to that path. In short, we need what’s called SDN Controller Northbound API.
There Is No Standard Northbound API
I have some bad news for you: nobody is working on standardizing such an API (read a great summary by Brad Casemore, and make sure to read all the articles he linked to).
Are you old enough to remember the video games for early IBM PC? None of them used MS-DOS. They were embedded software solutions that you had to boot off a floppy disk (remember those?) and then they took over all the hardware you had. That’s exactly what we have in the SDN land today.
Don’t try to tell me I’ve missed Flowvisor – an OpenFlow controller that allocates slices of actual hardware to individual OpenFlow controllers. I haven’t; but using Flowvisor to solve this problem is like using Xen (or KVM or ESXi) to boot multiple embedded video games in separate VMs. Not highly useful for a regular guy trying to steer some traffic around the network (or any one of the other small things that bother us), is it?
Also, don’t tell me each SDN controller has an API. While NEC and startups like Big Switch Networks are creating something akin to a network operating system that we could use to program our network (no, I really don’t want to deal with the topology discovery and fast failover myself), and each one of them has an API, no two APIs are even remotely similar.
I still remember the days when there were at least a dozen operating systems running on top of 8088 processor, and it was a mission impossible to write a meaningful application that would run on only a few of them without major porting efforts.
There might be several good reasons for the current state of affairs:
- The only people truly interested in OpenFlow are the Googles of the world (Nicira is using OpenFlow purely as an information transfer tool to get MAC-to-IP mappings into their vSwitches);
- Developers love using standard libraries and APIs other people created, and figure out all sorts of excellent reasons why their dynamic and creative work couldn’t possibly be hammered into tight confines of a standard API;
- Nobody is interested in creating a Linux-like solution; everyone is striving to achieve the maximum possible vendor lock-in;
- We still don’t know what we’re looking for.
The reality is probably a random mixture of all four (and a few others), but that doesn’t change the basic facts: until there’s a somewhat standard and stable API (like SQL-86) that I could use with SDN controllers from multiple vendors, I’m better off using Cisco ONE or Junos XML API, otherwise I’m just trading lock-ins (as ecstatic users of umbrella network management systems would be more than happy to tell you).
On the other hand, if I stick with Cisco or Juniper (and implement a simple abstraction layer in my application to work with both APIs) at least I could be pretty positive they’ll still be around in a year or two.
One organization needs to take place over here and start a standard for all the following SDN APIs. It happens to C before ANSI C reach us and now it's happening here.
Other solution could be a compiler (like gcc) for all the platforms that want to support SND (joking but it wouldn't be strange at all that someone think in this as a possible solution).
Thanks for share to the rest of the world this enormous problem that no ones cares about.
Please can you briefly explain "umbrella network management" for those people like me that have not heard of this before.
I think people are and will be more so interested in OF or anything standard as soon as products start getting developed. Few can manage DevOps or the buzzword coming out now NetOps. Haven't we had NetOps for years? How much silicon can vendor x y z convince us is needed in edge equipment is something I am wrangling with. I reckon Quantum is I think the first NB "ecosystem" api, and that came from grass roots, maybe it is doable. In that case the Quantum API is only as effective as the vendors commitment to developing product hooks into their gear which are all wildly different. Anything but horizontalization. Great post!
I agree that it would be highly desirable to have the API’s published but I’m not sure it’s critical to standardize them. We don’t have standard API’s across any type of operating system today (server, PC, tablet, smartphone), so one could argue why it should be done only for network o/s’s. API’s related to OF will likely converge to some extent and apps will figure out a way to be portable across multiple controllers.
I’m sure no controller vendor wants to remain just the "man-in-the-middle". The apps provide the real value and every controller vendor will therefore want to have their own apps. Maybe that’s what’s holding back publishing of the APIs. Of course the reasons you’ve mentioned likely hold as well.