- Silicon Valley's 19 Coolest Places to Work
- Is Windows 8 Development Worth the Trouble?
- 8 Books Every IT Leader Should Read This Year
- 10 Hot Hadoop Startups to Watch
Network World - The third annual Open Networking Summit, an SDN conference conducted in cooperation with 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, Calif., 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?"