The third annual Open Networking Summit, an SDN conference organised by the Open Networking Foundation, convened this week just after ONF members Cisco and IBM unveiled a separate effort to define an open source SDN framework. Unlike the user-driven ONF, OpenDaylight is a vendor-driven project to cultivate a system of SDN applications, but it also raised suspicion of the group's real intent: Is it designed to stall SDN's momentum and the threat, real or perceived, it could pose to incumbent hardware vendors? ONF Executive Director Dan Pitt discussed some of these topics with Network World managing editor Jim Duffy at the Santa Clara, California conference.
Does OpenDaylight have an agenda?
I'm not inside it so I can't really speak to it. Most of the members of OpenDaylight are in ONF. In theory, it's a good idea. We want to see people get out there with an open source software experiment to meet user needs. They haven't involved any users at this point. It seems to have sort of slowed down the market a little bit in waiting to see what they do compared to all the stuff that's out there. That's been a problem I know for some companies. Everything that [IBM's] Inder Gopal said yesterday is good stuff, and he said, "Don't judge us by what we say, judge us by what we do." And we'll have to do that. I am putting a lot of faith in the Linux Foundation to make sure that this is merit-based, it's open to all comers. I haven't gotten a good answer as to why it's so expensive, or what if you don't join and you just contribute code. Is there a level playing field there, or is there not? I just don't know.
As the industry considers OpenDaylight, does that slow down the ONF's progress?
I don't see any effect on our progress. It's kind of encouraging that some consortium is implementing what we produced; and building on what we produced. That actually motivates us to speed up as we see that there's an immediate need for what we produce. And then the larger story is that when you add up the investment these companies are putting in in dollars and resources that are required for engineers, that's a big investment. That says there's a market that justifies that investment by these companies. And that makes our work even more imperative.
Does it muddy the waters or potentially confuse customers evaluating SDNs?
There are two sides of the coin on that. It certainly causes them to think about SDN. And I'm sure it causes them to ask what's the right approach for me on SDN - and I hope that they're talking to their vendors about that. One of the points I made in my talk yesterday was SDN means something unique to each company that deploys it. They're solving their particular problem. And that's what it does for them. So I haven't been one to say it has to have a common, agreed definition - for customer benefit we got these very high-level ones but they're not that useful. The question of course that it raises is, why do they have so many southbound APIs that are either proprietary or vendor controlled? They have OpenFlow there and they said in their announcement that OpenFlow is a southbound API. But their slides have shown a variety of other ones. We're here to make sure that this OpenFlow one is completely functional and meets the needs of users, which we've already seen in a number of deployments. And it should be a no-brainer. I want the customers to look at it and say, "Why would I want something proprietary when I can get something that's standard and not proprietary?"
But yesterday you said ONF is evaluating 20 different northbound APIs [on an SDN controller such an API lets apps and systems request services]. Couldn't OpenDaylight say, "Well, why do they have so many northbound APIs?"
It's not that we do. There are 20 some controllers out there in the market. And each one has its own northbound API. No one's really asked the question, why are they different? What do they do? What are their characteristics? So that's why we're doing that. We're just assessing what's out in the market and then we'll see what we learned from that. Some of our members said they wanted to experiment with some northbound APIs. To me, the proof is in the code. So you want to understand that and see where it takes us. We want to look at data models, experiment with data models across these northbound APIs. There may be several classes of northbound APIs being useful. It doesn't seem so hard to write one. People would rather write one than look at the 20-some out there and see whatever works for them. So these are not ours - we're doing a service to the user community to sort out what the situation is with them.
Is the northbound API an area where the ONF and OpenDaylight could collaborate?
We're doing this work which we hope will help implementers and deployers both. I would certainly hope that Daylight would look at what we've done. If they implement something we might want to compare that in the study we have. Our study will be finished before they define theirs, from what I understand. We'll see how that goes. Potentially, it's something to learn from the other. It's very dependent on the apps and scenarios. But again, I think that's for the market to decide. If some of the members say, "Our customers have these sorts of needs and we think this kind of an API would work so we're going to write one and develop it and try that," that's how it should happen. It'd be unusual for a standards committee to standardise a software API like that unless it's already there and they would like to have us say, "We thinks this fits well with some other thing." There's going to be a lot of choice out there and we don't want to reduce innovation or choice. Sometimes there's great benefit in having software producers have something stable to write to. We are driven by the user needs and the industry needs. So if we can help promote commercialization and especially deployment by doing something, we're happy to do that.
What are the challenges in SDN enabling legacy infrastructure?
If you look at how HP's switches helped the Stanford University network evolve to OpenFlow, they just added them one at a time. We've seen the overlay approach, which is sort of a starter tunnel through the legacy stuff, be attractive to a number of the customer of Nicira, now VMware. I think it's good to get some experience but I don't see that approach - adding complexity to something that's already complex - really following the motivations that drove us to develop SDN. Taking a legacy networking device that has a lot of complexity, a lot of control in it, a lot of custom ASICs and proprietary operating systems, and opening the lid, dumping some OpenFlow inside and closing it, and saying it's now SDN. The principles that govern us are simplifying the networking devices, simplifying operation, logically centralising control so that it applies to multiple switches and doesn't have to replicate them, and having a single place to have a programming interface and something that's robust - those are the principles that we adhere to. This doesn't seem to follow those same principles because it's adding complexity to complexity. And we're trying to extract simplicity from complexity. If it succeeds in the market, well that's something; but it's not our view of what SDN is for, actually.
Do you view Cisco's onePK as an SDN?
Let me just make an interesting observation here: As far as I understand, onePK defines some interfaces to the routing information base, the RIB. So it's an open interface in that you can program to it from the same company's controller. But I don't think you would have seen an open interface like this had it not been for OpenFlow and the SDN movement. So, what is its use? I think its use is in getting companies and their customers to think in new ways about the networking programmable.
Can you elaborate on the need for an east-west protocol? Is there work underway for a controller-to-controller protocol for federated SDNs?
We don't have any formal effort underway on that yet. If you look at the rate at which telcos roll stuff out, it will be a while before we get to that. We're doing the most important things first. It's certainly a very interesting question, there will be a need for that. The way people are doing it now, they're using BGP to connect these different OpenFlow networks. That will probably be around for a while. We have seen people like Google have hierarchies of OpenFlow controllers - a number of companies have done this - where master and slave are more peer relationships. There's a lot of experimentation going on there. And we'll have to find out what problems we can help the industry solve. Long term, I'm not sure BGP could be that protocol. It wasn't made for this. As much that can be leveraged will be leveraged, but I think it's too soon to say. If there is a simple right answer, that's what the industry will adopt.