The future of openness involves software models that separate function from implementation.
If there's one movement that's clear, in our chaotic networking industry, it's the movement toward "openness." From a marketing perspective, you could argue that the most popular adjective is "open," and we're struggling to find new things to apply it to. The question is whether anything is really happening under the covers. What does an open network even look like?
Network users and operators have long told me they consider "open" to mean "supporting free substitution of components." If I have Box A in my network now, and if I can substitute Box B in its place, I have an open network. OK, but does that mean you can simply drop in one box to replace the other, that the interfaces are all totally identical? Could we accept as an "open" network a network requiring minor tweaks to support substitution? Could we even support major ones?
A complicated future
Traditional device networking had three types of interfaces. One class supported port/trunk data plane connections. Another supported control interactions like advertising routes, and a third supported device management. Software components are in a sense like devices. They have their own interfaces, typically called "application program interfaces," or APIs, and placing network software APIs into the same three classes as device interfaces is tempting. In point of fact, network software like a hosted router instance will have those three classes of interfaces, but they'll also have a whole set of APIs that devices never showed -- and these APIs are what make openness complicated in a software-defined future.
Suppose you want to host a single software element you call "Virtual_Router." You have to be able to deploy it on a server, which is going to require software and a set of APIs. You have to be able to manage the server, and manage the router instance, which is another API set. This, remember, is in addition to a router's three standard interfaces.
Read the rest of this article on No Jitter.