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 standardize 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.
Sign up for Computerworld eNewsletters.