The Open Networking Foundation appointed Sarwar Raza, HP Networking's director of cloud and SDN, as chairman of...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
its new Northbound Interface Working Group (NBI-WG).
Raza will lead the group's efforts to define use cases and data models for northbound interfaces, which let network applications run on SDN controllers. Without common northbound interfaces, developers have to burn through resources to code their apps to run on multiple controllers. The industry is still debating whether northbound interfaces should be standardized. The NBI-WG won't necessarily create standards for northbound interfaces, but it will consider them.
Raza spoke with SearchSDN about the working group's mission and how it will operate.
Why is there a need for a northbound interface working group?
Sarwar Raza: We are witnessing the proliferation of many controller implementations, many SDN solution implementations, which is a great thing for the industry and for consumers. But for every controller implementation out there, you have a separate interface. A lot of those solutions today are trying to solve the same or similar sets of problems. So you end up with a dozen or so different ways to do the same thing. It's challenging for customers and also challenging for application vendors who want to benefit from the paradigm shift that SDN provides.
[Developers] are finding that in order for them to have a good chance of addressing a sizable segment of the market, they have to code their applications to multiple interfaces and multiple APIs [application programming interfaces]. At the end of the day, they're spending more time trying to force-fit their applications to as many different controllers as possible versus being able to invest in the app itself.
We hear it from [HP's] partners. Partners often had to make a difficult choice with respect to which controller they will land their application on, and that is ultimately stifling the SDN ecosystem.
Is the goal here for the working group to create a common interface that can be used on any controller, and would that be considered an industry standard?
Raza: We are very firmly stating that we believe that there will be multiple interfaces defined by this group. And those interfaces will exist at different latitudes and longitudes in an SDN system. It's very important to note, especially with regard to APIs and interfaces, that paper standards are hardly useful. So we are starting off with the development and definition of these information models -- these data models -- followed by implementations. One of the things you'll see us do is drive for implementations of the models we come up with.
Standardization is something that could happen. We're open to exploring standardization of any work product we put out that meets common criteria -- it's adopted by vendors, adopted by open source, customers like it. At that point it makes sense to have a discussion about whether or not it ought to be standardized. But anything prior to that I think is just premature.
We also don't want one API to rule them all. We fully expect that controllers and controller vendors will have their own ideas about what the APIs for their particular products ought to look like. We're not prescribing a programming language or a type of API or anything like that. We're prescribing an information model for a set of common use cases. Pick a particular use case and we will define the end-to-end information model and the particular data model that our members -- who comprise operators, vendors, users -- [agree on]. Then it's up to the controller vendors to implement those models inside their particular framework.
From the consumer perspective and application developer perspective, when you look down below, you see that use case X has this common information model implemented across several controllers, so your task of coding between one controller to another is now orders of magnitude easier. It may be just going from one language to another versus having to completely rewrite your own internal model to match the controller.
The notion of data modeling sounds similar to what Dell is trying to do with the Object Management Group [OMG] and SDN.
Raza: We've spoken with the leaders of that effort in OMG and we'd love to find a way to converge efforts around northbound interfaces. Their particular stance -- although I am not speaking for them -- is from the [understanding that] OMG has a great standards-making machine, so let's go ahead and start building standards for this.
Our approach is that the standard or standards will emerge over time. We'd rather start with making sure we've got the use cases identified and we've got running implementations before we rush to standardize. I am not current on what the current status of that product is, but we are really open to working with other SDOs [standards developing organizations] and groups, as evidenced by a working group face-to-face we had two weeks ago. We had representation from ETSI NFV, IETF, ITU, TM Forum, OpenDaylight, OpenStack, UCI Forum, OpenGrid. We're fairly open to working with other groups in this domain.
Do you think the majority of the vendors that are playing in the SDN space will adopt these data models that you are trying to define?
Raza: If you look at the mix of participants in the effort, we actually have a good number of controller and app vendors, as well as operators and end users. So whether or not the output of this working group makes it into their commercial offerings right away, that's a question for those vendors to answer. We're very hopeful based on the interest that controller vendors have shown and the use case proposals and the framework proposals that are coming from controller vendors. We think it's very likely that some of these vendors will adopt of these NBIs.
What is the role of OpenDaylight here?
Raza: When we put out our call for our [initial] face-to-face meeting, we got a lot of interest from leaders in the OpenDaylight community. There were enough Daylight steering committee members in the room that they practically had a quorum. That is an expression of interest on their part, that they see these things as potentially complementary.
OpenDaylight is a code-producing body. They don't necessarily care about standards or the standardization process. They are more about putting stuff into production and implementing it. For us, that's actually interesting, in that one of our goals is to make sure that the interfaces we define have concrete implementation. We would like to have at least one open implementation of each NBI and hopefully start getting vendors to implement them within their frameworks. OpenDaylight … would be a great partner to land some of our NBIs in. But of course the way OpenDaylight works, you show up with a proposal and the coding muscle to implement it. It remains to be seen if the backers of OpenDaylight are willing to free up resources to work on this cooperatively. I would say the exchange of ideas and information during our face-to-face meeting was excellent.
What kind of northbound interface data models need to be defined?
Raza: We're taking a use case-based approach. We're going to take a small set of use cases, some relating to the data center and cloud virtualization space, others that may have more of an enterprise focus, and others with more of a security focus. We will try to determine what the attributes and operations are that a controller needs to provide and instrument for. We hope to generate that model for the use cases and hope that controller vendors say, 'I'm now offering support for feature X,' which corresponds with use case X on our side. I would say the use cases are what are most important here. We think we will select two or three use cases to focus on in the first year.
Are the calls for the NBI-WG open?
Raza: They are open to [ONF] members.
What about documentation?
Raza: Generally, working documents are not publicly posted, and even the lists are for members only. Once a working group has finished its work and that work has been ratified by the board -- after a review period -- all of that work is put out in the public. That's how the OpenFlow spec is developed as well. The OpenFlow spec is free and available to anyone, but that occurs after it has been signed off on by the board.
Is it safe to say that if there is a vendor out there in the SDN landscape that is not a member of the ONF, they're not going to have much visibility into the work you're doing?
Raza: Not while we're doing it. However, we had this two-day work group face-to-face two weeks ago in Santa Clara, and day one was completely open. We did have non-members there and groups that we do not have formal liaisons with in the room. We're looking to be as accommodating as possible with respect to being able to cooperate with folks who are not necessarily inside the ONF fold formally. I don't know if we will have more open meetings. My guess is that we probably will.
What about participation from end user community? Do you see any value in getting contributions from the research and university community?
Raza: One of the unique things about ONF, even though membership is mostly vendors, our governing board is all users. So the folks who approved this charter and who are overseeing this work are uber-SDN users -- Facebook, Yahoo, Verizon, Deutsche Telekom, Goldman Sachs. To presume that end users are not part of the mix is not accurate. They are driving this. We do have some programs specifically for research and academic affiliations where I believe folks can participate without regular membership process. There is lots of interaction with that community.
The board of uber-SDN users you mentioned are really big shops with unique environments. Do you see use cases that might be specific to different types of enterprises that may not be represented by that board?
Raza: Yes. In fact, we have a collection of use cases that are being driven not by networking vendors but by application vendors on behalf of customers like that. Microsoft, for example, is a very strong advocate of some of these enterprise use cases. We're not just talking about data center virtualization and network virtualization use cases. These are end-user applications. HP is another [example]. We obviously have our own SDN platform and solutions and a lot of our focus is on the enterprise and campus use cases for SDN versus the data center use cases that everyone seems to be talking about.