Skip Links

OpenFlow inventor: Network provisioning will inevitably be automated

Martin Casado, inventor of OpenFlow and CTO of stealth startup Nicira, talks about the future of OpenFlow, networking and the job of the network engineer.

By Art Fewell on Thu, 09/08/11 - 3:15pm.

2011 has been an exciting year for Openflow and software defined networking (SDN). Continuing my informal series on Openflow, I recently got the chance to have a conversation with Nicira CTO Martin Casado to discuss the future of SDN generally and OpenFlow specifically.

Nicira logo
AF: Please tell me a bit about yourself and Nicira.

MC: I used to work with secure networks in the federal market and at that time it was clear to me that market forces had failed to create networking gear sufficiently flexible to do things that were outside of what they were originally intended to do. It was in totally stark contrast to compute. You could take a computer and program it to have a security posture but with the network, you couldn't. You pretty much got exactly what they shipped to you: difficult to configure and very difficult to get the guarantees that we wanted and so forth. So I got enamored with this problem of "how do you make networking as flexible in the general purposes as compute?" That is, networking was really good at one thing, which is forwarding packets, but it wasn't so good at this other stuff.

Then I went to Stanford, and as part of my PhD, I looked at this problem.  I first focused on security: how do you change the network architecture to be more amenable to well-defined control.  Then [I worked on] generalizing the concept:, how do you turn it into something that can do anything--not just security, but, say, traffic engineering, or network virtualization, or better monitoring, better scalability, better flexibility, mobility, things like that. I wrote the first draft of OpenFlow and in early 2007, we started working on our first controller network operating system, and I have been involved in the drafting of OpenFlow since. As far as Nicira, of course, we're in stealth so there's not really much to say.

AF: With OpenFlow, you introduce programmability to something that didn't really have customizability and flexibility. I can see web services companies being first adopters -- companies that use a lot of open source, and are customizing those open source stacks to build services for their organization. Maybe they’ll use Hadoop and MapReduce and want the network to talk to the applications and dynamically deliver requirements. What do you see as the first or the most compelling benefit of OpenFlow and the first markets that are going to use it heavily?

MC:  The target user of OpenFlow is anybody that creates infrastructure technology. Tis is a systems builder, not a systems user, per se. I mean, Open Flow is like a low-level programming language or low-level interface. So a Facebook does a tremendous amount of work to build and program their infrastructure in compute and could see a whole lot of value in OpenFlow. Or take the government. They do a tremendous amount of development in compute for purposes like security, so they would also be interested. [Same goes for] any startup or company that's interested in building new infrastructure technology. So, I think it's less of a market segment. To ask "is OpenFlow going to go into the enterprise?" doesn’t make as much sense as asking, "Who is going to use Open Flow to bring a product to the enterprise?"

AF: That makes sense. Most enterprises that I deal with, in Global 500, financials and heavily regulated industries, have a clearly defined workflow that involves networking and they do that through scripting and more advanced automation. Outside of that, I don't see many enterprises having network programming capabilities or very interested in developing them. But it does seem to me that there could be ways that you could use OpenFlow, or other software-defined networking architectures, to create a controller-based local area network. It would be similar to wireless local networking during the transition from fat APs to thin APs in a controller-based model.  This is not necessarily saying "Hey enterprise, you need to do a lot of scripting and programming," but saying "Hey, here's a way to reduce operational costs and simplify how you operate your network by using a centralized controller.” Do you see that as something that's feasible?

MC:  The first users of Open Flow are going to be systems builders and those working in  the financial [industry]. They do a tremendous amount of innovation. I think the big web-service [companies] and infrastructure and services --  these are all system builders. And then I think you're going to see and ecosystem of startups that can tackle any area. For example, they might do home networks, small to medium business, the WAN. In fact I know of things going on in almost all of these areas and I think the question is less one of OpenFlow and more one of market entrance, product suitability. Open Flow could be a great technology unless someone builds a [crummy] product, right? But I do think that OpenFlow and SDN has the ability to improve all of these.

AF: I It seems like the traditional networking vendors are watching OpenFlow not with an active strategy towards driving it but being prepared in case it does take off. Is that what you see, too?

MC: I've actually been really surprised with how open some of these guys have been. I used to be really skeptical and think they just want to keep their enemy close and blahditty blah, but actually I'm not as cynical as I used to be. I think some of these people genuinely want to see a broader ecosystem that will kind of unlock some of this flexibility.

AF: I think it's necessary. There's been a lack of competition in the networking industry. Look at some of the primitives that exist in some of the OpenFlow systems and the trials and demos going on. It highlights that even the most basic elements of routing and switching haven't changed in the past 10-15 years besides increasing “speeds and feeds.”   

MC: I'd also say there are a lot of very real problems out there that aren't being adequately solved. There is so much interest in virtual networking, there is so much interest in dealing with scale of data centers. There are a lot of [changes in], the dynamics of the data center, or the security requirements of the cloud, or the security requirements of enterprise, or low-latency trading. There are so many vectors pushing on networking today that really require it to respond, and I think that everybody benefits when that happens, I think the incumbents benefit just as much as anybody else if they have a solution that addresses the problem.

AF: Yes. And one of those areas that I don't think is being met very well right is in the new data center -- enterprises that are virtualizing traditional enterprise applications. It used to be that when I was going to deploy a new application, I was doing it by the book. That would mean figuring out what ports the applications used, who its peers were, what other applications it had to talk to, if there were any other quality or service guarantee requirements, and then writing ACLs for the security and what have you. As VMware has taken hold, the access layer has kind of eroded, and I see most enterprises deploying new servers and applications without any network services. For good reason, they're too difficult to try to employ in a dynamic and agile environment. How do you see software-defined networking being able to attack that?

MC: There are actually some fairly good solutions that are popping up to this today. They're not ready yet, but Cisco and VMware have both been really pioneers in this area, and I think that over the next three years we're going to see a lot of growth and a lot of new solutions outside of OpenFlow. Neither VMware nor Cisco have used OpenFlow to do this. The great thing about OpenFlow is that it will be a standard way of doing it. But, there's a tremendous amount of innovation from the incumbents on this. There's going to be a lot more innovation from up-and-comers and I don't think that it's because of OpenFlow per se, though I think it's a great way to do it,  and in a way that's open and hopefully cross-platform and doesn't lock you into a particular solution. One thing that's worth pointing out is that many of these solutions actually take an SDN-style approach, meaning they don't use peer distribution, but they have some sort of an orchestrator or a supervisor that controls multiple nodes within the network. Whether or not they're part of Open Networking Foundation (ONF) and whether or not they believe in SDN, they actually take a very, very similar approach.

AF: Today, there’s a problem with how to tackle this market.  We’ve got Cisco opening up more APIs, Arista EOS, and Junos Space, etc.  Service provider users are large enough to have an  ecosystem  develop. One or two  large contracts from them allow system makers to stay in business. In the mid-market, standardization of these interfaces becomes really important because Cisco has so much control over their own API, and their development environment. A standards-based mechanism needs to be in place for a software development ecosystem to be able to be built, targeted at mid-market enterprises, for the SDN methodology.

MC: That's exactly right. There are two questions a system builder should ask: Is this a proprietary interface? And is it sufficiently flexible? With OpenFlow, it is an industry standard, so anybody that supports it you should be able to use. It is sufficiently flexible because of what's [already] been built on it.

AF: You have the systems builders being very innovative and bringing about new capabilities, using open-source as a significant portion of their code base to cut costs while building innovative and unique differentiators on top of that. With the move towards the cloud and grid computing models, I am glad I work for a technology manufacturer, but if I were an enterprise network engineer, I'd be concerned that, with everything moving towards the cloud, what's left for me? By focusing on what these system builders are doing and trying to follow these capabilities, that will help the enterprise engineers build services in their organizations that can help them to hopefully keep their jobs from being outsourced, and help provide better value for their companies. What are your thoughts on these sorts of changes?

On The Web
Blog Roll
Network Heresy
enterprise efficiency
Ethereal Mind
Twilight in the Valley of the Nerds
Big Switch Networks Blog
The Tao of Innovation
Art Fewell on Silicon Angle