Northbound API: The Standardization Debate

During the last several months, several extremely informative articles and posts have been written about the significance of the northbound API (or NB API) within the context of software-defined networking (SDN).

We’ve seen two posts on the topic at SDN Central, one written in April by David Lenrow and another written by Roy Chua in early July.  Brent Salisbury, on his blog NetworkStatic, offered an excellent exegesis on the northbound API in June, and he touched on the topic again in a subsequent post in July that dealt with how he believes SDN APIs will evolve. At GigaOm, Stacey Higginbotham also has written on the subject, as have I both here and at TechTarget’s SearchNetworking.

Recently, Greg Ferro, of EtherealMind renown, provided an instructive overview on SDN APIs, opining that it is “unlikely that Northbound APIs will never standardise but I’m not aware of any initiatives in this area.”

I don’t know whether northbound APIs, as Greg suggests, will never standardize, but I do know that most knowledgeable observers (including the aforementioned parties) believe that there should no headlong rush toward standardization. The consensus is that SDN’s northbound APIs should be given an opportunity to flourish first, and that the market ultimately should vote with its feet and with its wallets.

Too Early?

That said, there are those who believe standards bodies should play a role, even at this nascent stage, in defining SDN’s northbound API.  In fact, the matter was raised yesterday on a discussion thread for the IETF’s software-driven network protocol (SDNP) BOF mailing list, where some argued that the Open Networking Foundation’s (ONF) reluctance to begin standardization work on the northbound API — the ONF reportedly will incorporate northbound-API discussions into deliberations of its recently formed architecture workgroup — opened the door for IETF involvement.

Often, but not always, proponents of near-term northbound-API standardization are representatives of legacy vendors familiar with the standards-definition process. (At this point, I feel strangely compelled to invoke the quote often misattributed to Otto von Bismarck regarding the similarity of laws to sausages: “Laws are like sausages. You should never watch them being made.” I believe this maxim also applies to IETF standards.)

The point here, though, isn’t to render a value judgment on who’s right and who’s wrong. What’s salient is that there is stark disagreement on whether the question of the northbound API can and should be settled by market forces or by vendor comity (and committee). Watching to see which players line up on either side of the divide, and how they defend their positions, will be instructive.

4 responses to “Northbound API: The Standardization Debate

  1. Very nice read as always Brad. I think I botched my reply a few days ago so reposting. Certainly honored to be referenced by you as I often look to your thought leadership on many topics. I tend to land with you on this that the industry will sort this out, but I think that is only if the southbound API falls apart. If the stovepipe if the networking industry never horizontalizes then it the best we come away with are token crowd sourcing and “open” proprietary APIs. The foundation being poured now needs to be dried and sealed before we get too far ahead of ourselves. As you pointed out to me the other day on the ONF dropping the WG on northbound, I think it falls in line with exactly what your articulation. Boy, the speculation is dated within 30 days of putting pen to paper! lol.

  2. Pingback: HP Announces Their SDN Controller

  3. IMHO, North Bound API should not be standardized, at least not before the South Bound interface is standardized. The south bound interface is the hardware software interface which forms the foundation of the SDN. Without this solid basis, any attempts to build the higher layer standard may fail. I’d like to think about what in the middle is an OS. It’s closely bound to the underlying network infrastructure. If this is not mature, it’s too early to expose any useful and longlasting API for upper applications.

  4. Pingback: Overnegation: Double negatives make a positive - Writing for Business - A Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s