Does SDN Really Need Two Controllers? – InApps Technology 2022

Perhaps the Internet has spoiled us: We’ve grown accustomed to single standards for global communication, or at least with choosing one way to communicate certain classes of data. The Web’s principal protocol is and always has been, some form of HTTP. When we built Web services and Web applications, we started with SOAP, and then we shifted to JSON for exchanging API calls. We’ve had several standards before, but we usually lean towards one at a time.

Yet developers have never relied entirely upon one programming language. Veteran developers have historically argued that no single language expresses every conceivable workload. Cloud-native computing platforms have become, nearly by definition, “polyglot” — they facilitate multiple languages concurrently, and they let you build distributed applications using more than one language.

The central tenet of the open source movement has been that a single forum for the sharing of open standards forestalls any vendor or commercial entity from obtaining a lock on a process necessary to everyone. In recent years, that movement has thrived on the notion that a plurality of participation, benefits everyone sooner than a single project undertaken in a locked basement.

But in the field of software-defined networking, the open source community, working in concert with data center technicians and network engineers, have managed to boil down the centers of gravity among software-based controllers to a solid pair: ONOS, a project led by some of the creators of OpenFlow protocol, to enable scalable network functions on telcos’ infrastructure; and OpenDaylight, now used predominantly by data centers that host network functions using OpenStack.

Deplaning

In a software-defined network, the data comprising network traffic is separated from the data that keeps the network running. As a result, there are two planes — the control plane and the data plane.  An SDN controller is a virtual appliance in this network, conducting so-called southbound communications with routers and switches (both the physical and virtual kind) and enabling northbound communications between the applications running on the network, and the controller itself. These communications make it feasible for SDN networks to do what can’t be done with all physical networks: reshape the data plane to suit the requirements of the applications.

So why would any network need two separate classes of SDN controller, both of which are effective at accomplishing these same basic tasks? When we put this question to the leaders of ONOS and OpenDaylight (ODL), we got a variety of answers. But they all played to a common theme: Neither controller is surrendering its place in the spotlight anytime soon.

“There is a certain group that has really wanting to write the story about ONOS / ODL bad blood, and then ended up actually writing it at some point,” related Neela Jacques, Executive Director of the OpenDaylight Project. “And they’ve asked me this question twelve times come Sunday. ‘I mean, come on!  You hate them, don’t you? I mean, you really hate them! Tell me how they suck!’

“My true business answer is as follows: Inside of OpenDaylight, I have multiple groups with different ideas… I promise you, Ericsson and HP have different ideas of how to build a VPN, and what should be in a VPN, and if I try and force them and force a winner [on] day one, whoever loses will leave. In a volunteer organization, if you come in and go, ‘I want to play baseball,’ and you go, ‘Nah, you’re gonna play ping-pong,’ people don’t go say, ‘Fine,’ and drop the baseball bat. They find other people to play baseball with.”

Jacques’ implication with that statement is that, when multiple vendors participate in an open source organization, there’s a danger of losing some of them when the others’ ideas get chosen or take precedent. Of course, this doesn’t directly address the question of why there need to be two standards addressing largely the same problem. But it could explain why the two efforts lead to a high degree of overlap, perhaps deliberately: Both organizations may be trying to be as accommodating as possible. In fact, this is one way they may actually be competing with one another: by being more accommodating and less dismissive than the other.

Arguendo

“I think there is enough scope for multiplicity, for multiple reasons. One is, if nothing else, competition is good, even in open source,” stated Prof. Guru Parulkar, the executive director of the Open Networking Research Center, the leader of the ONOS effort, and the co-creator of the OpenFlow protocol with which virtual and physical network devices communicate with one another today.

“ONOS people are on their toes, because they hear about what ODL is doing, and whenever they have successes, that challenges ONOS,” continued Prof. Parulkar.  “Whenever ONOS is succeeding at that level, that is a good thing.  Another thing is architecturally, ONOS and ODL are very different.  And really, I don’t think today, as much as I believe in ONOS, that architecturally I can say, ‘You know, this is the clear winner.  This is the only way to do things.’”

Parulkar makes the point that prior to the onset of the open source movement, each individual vendor in the networking space maintained multiple proprietary platforms simultaneously. It was an early effort at vendor lock-in, for a market that simply could not support the principle: Communications on a global scale cannot be about maintaining boundaries and monopolizing supply and demand.

So it may seem a bit hypocritical, from his vantage point, for vendors to be demanding a single standard for SDN controllers now, when prior to open source, they might have been perfectly satisfied with as many as a hundred.

But most competitions of ideals, be they technological or political or purely philosophical, are efforts at reaching consensus. If the endgame is, by design, an agreement to disagree, then how do the rules of this game evolve? In the arena of ideals and the marketplace of technologies, when we allow the people to reach consensus, don’t the majority of them choose one way to work, one concept, one approach? More to the point, if ONOS isn’t competing with ODL to win, and vice versa, then why are they competing?

“In the case of ONOS, who are our customers, per se? These are service providers,” responded Guru Parulkar. “Service providers, a majority of them are a hundred billion dollar businesses. They have very technically competent people. If they tell me, ‘Oh my god, I cannot make a decision, I’m waiting for the market to make a decision for me,’ I think that provider has a more serious problem: They can’t make up their minds.”

Because ONOS and ODL are both open source projects, he continued, there’s no barrier for any prospective customer to download and try both. “If you can’t find one or two software engineers to spend a couple of weeks to go through this exercise and come to their own [conclusions], then you deserve to get what you get.”

One of the recent trends in open source controller development has been a movement among both OpenDaylight and ONOS, as well as other players in this space, to implement an architecture that moves as much logic as possible off the controller. This has the benefits of reducing controllers’ size and scope, and making them easier to implement. It also has the obvious side-effect of making the functions that controllers perform, fewer in number.

Intent

Which means, inevitably, the overlap between OpenDaylight and ONOS, at least categorically, grows. I asked OpenDaylight’s Neela Jacques, why not merge at this point?

“If you go back and look at the video, Guru and I have had some huge arguments about things on stage,” responded the man who, earlier in our talk, commented on how the tech press overplayed their differences.

At a recent OpenDaylight Summit panel, Jacques related, he argued the importance of good governance in open source projects, and Parulkar responded by contending there are multiple models of open source projects, and a key metric of success should be the impact their products have on the market. Jacques called this discussion a “huge argument,” which a viewer of the panel’s video may conclude would be like calling a curling match “blazing hot.”

During that panel, Parulkar did concede that governance was important for an open source group, but what may be more important is the end product of its collaboration.  Jacques referred to this concession as a major victory.

Another recent trend, to which Jacques referred, is the adoption of the concept of intent.  In the SDN market, an intent-driven platform is one that acquires API calls from its clients, interpret the intent of those calls, and dynamically determine the best strategy for responding to them — rather than expecting client applications to make direct requests for specific network resources. (It’s a very intriguing discussion with respect to resource orchestration in container-based networks, which today involves commands that request specific network overlay resources — the opposite of an intent-driven platform). Jacques says the philosophical meaning of intent, is one of the ongoing arguments he maintains with Parulkar.

“Invariably what’s beautiful is, not only can we take inspiration off each other, but when he says, ‘YANG NETCONF is useful,’ not only can he take that and implement it, he can go look at our code and our implementation.  He can pick up our code and run a performance test if he wanted; he doesn’t have to do it blind, like an IBM, going up against Oracle, has to try to reverse-engineer it and then go do it.”

For his part, ONOS’ Guru Parulkar makes the point that the points of contention between his group and ODL concern matters of infrastructure and lower-level architecture — matters that both groups’ collaboration partners, especially service providers and telcos, no longer consider of any differentiated value anyway. In other words, if ODL and ONOS merged, or one were to be declared the “victor” in a market Battle Royale, who cares?

“They will all benefit a great deal if that infrastructure can be built in a way that helps them compete more effectively with OTT [over-the-top] providers, and they catch up,” said Parulkar. “Then they can focus their energies on the services on the top, and keep inventing new services.

“At this point — I mean, honestly — do you really think, even though they advertise it on the TV, there is that much difference when you get a 100-megabit connection between Verizon and AT&T, that the bits-per-second or whatever, or the packet loss, make any difference?  I don’t think it makes any difference. That whole connectivity infrastructure, and all that network stuff, is — I don’t think — much differentiated.” He cited the video services market, which he characterized as around 20 times bigger than the cloud connectivity market.

“If this connectivity part, if these service providers can come together and figure out how to do it very effectively and turn it into a platform on which they can create new services — it’s in their interest to do it.”

It could, in the bright spotlight of history, end up being much ado about nothing. There may be huge — but not hugely huge — arguments between the two factions in SDN networking. Perhaps they’re consequential enough to justify their separation from one another and inconsequential enough to merit their continued discussions with and against each other. Certainly Neela Jacques finds their philosophical distinctions of value. One gets the feeling he and Guru Parulkar would miss their little debates if the market, or technological evolution, or an abundance of interest, or an absence of interest, made them end too soon.