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.
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?
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?
MC: It's totally inevitable that the network becomes an automatically provisioned piece of the infrastructure, everything else is, right? I think you said it right early on: If I want to deploy an application, I don't want to mess around with a network. If I want to move my application, I don't want my network to constrain me. This actually has nothing to do with OpenFlow, it's just an absolute reality of where we're going. We should no longer have to worry about manually configuring box-by-box, we should have a network and have that network respond to how I deploy applications and how they move around, because at the end of the day, we want the infrastructure to get the hell out of the way. I want to go from zero to deployed in as short an amount of time as possible, because everything else is overhead. Right now, one of the long poles in the tent is the network. Now, does OpenFlow do that for me? No, it's just an interface. However, it's capable of doing that for me, and if I have a solution built on that I can use it with multiple pieces of gear.
AF: I do hope that the enterprise environment around OpenFlow does continue to improve and increase because what I've kind of observed in my sphere of customers is that VMware came along and the server guys completely changed the way that they do business. In some cases it was an improvement, in other cases they made trade-offs. They lowered some standards in some areas to be able to take advantage of business benefits in others. When I look at a lot of networking departments, they're still doing things the same way, the biggest thing that they've changed is that now in some cases they've tolerated the vswitch to exist, and they've tolerated letting server guys run with deploying things on the vswitch. I think it's time for the networking teams to start getting into that model to where they understand, they're willing to change some of their traditional criteria, and really understand what's driving value for the business. And I think OpenFlow methodologies and SDN creates the possibility for the networking team to really get in that type of environment and add that type of value like VMware's done for the server teams.
MC: Right, and I agree with almost everything that you're saying except for the fact that whatever solution will be a product. That product can be built with or without OpenFlow. There's no magic in OpenFlow. The important thing is A) we know that OpenFlow is good enough to build products like this because people are doing that, and B) It will provide horizontal integration if you do use OpenFlow -- meaning that multiple providers can offer a product like this. This is where we want to go. I definitely agree that OpenFlow can take us there, if someone uses it to build a very good product.
AF: Because it’s open, OpenFlow makes it easier for developers to write code for the network and for a lot of standards-based products to come out, which will drive competition in the industry.