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?
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?
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.
MC: It really is about innovation because, if you couple layers, it’s very difficult to innovate on one layer without the rest holding you back. So if you look at a server, you’ve got a very well defined interface, your Intel CPU, then you have an operating system on top of that, which you have very well defined interface on top of that for writing applications, and often applications have very well defined interfaces on top of them. But if you look at networking gear, the hardware is proprietary, the operating system is built by the same people that built the hardware and often the applications that sit on top of that are written by the same people, too. So you can’t innovate one without modifying the other two; they’re much more tightly coupled than you normally see. I think working with a horizontally integrated model, where you’ve got open interfaces on every layer, is good for competition and it’s the right methodology for building a system, where you want to evolve each layer independently.
Nicira's vision of the virtualized network.
AF: If an application has network requirements … quality, security, what have you -- it’s hard to find this information and communicate the information between applications and the network, and today, that’s typically a very manual process. If OpenFlow defines one interface that exists between, say, a controller and the forwarding hardware, that could potentially be an interface that applications could directly communicate with. I’m thinking of a northbound API from a controller. Is there work, standards-wise, that’s being done on that northbound API, or do you see applications integrating directly into the OpenFlow stack, and communicating directly with forwarding hardware?
MC: Yeah, this has been discussed a lot. My personal opinion is that we need to stay very, very focused on one layer right now. I’d be very interested in seeing OpenFlow coming out, having general support in hardware, having multivendor support, having a good ecosystem on products that use it. Even though this comes up all the time, I think we should all focus on one piece of the puzzle. That said, clearly, you do want kind of a higher way of interacting with the network. But it’s not clear to me that this is a northbound API, it’s not clear to me that this is something that sits on top of a network operating system; it’s not clear to me how this will look. This is so totally embryonic. I view OpenFlow almost as a BIOS. It’s kind of a nice independent way of talking to the hardware, and that’s it. And I think if we just get this accomplished, we’ve done a great thing, and then the rest will follow.
AF: Yeah, it’s funny, when I described OpenFlow, one of the ways that I describe it is it’s kind of like what the Phoenix BIOS was to the IBM PC. If look at how computing has evolved, and Phoenix BIOS was a huge piece of it, but it relied on a lot of other things happening in the ecosystem before it was really able to bring the value to market.
MC: Exactly, I really believe you should build systems first and then worry about standardizations later. We should be really driven by engineering and design. And so, in order to get hardware compatibility, you need something like OpenFlow, you need to have that BIOS. But let’s let the operating system evolve organically, because otherwise, you’re going to have a bunch of people in a room and they’re going to come up with something, and it’s not clear that it’s going to solve any problems at all. So I really believe, just get the BIOS out and then let the community at it. People will go crazy, they’ll build great systems, and out of that, we’ll naturally evolve a system that maybe then we can standardize on later. But I think that just having OpenFlow alone will totally unleash the fury.
AF: That’s how the computing model evolved, right? That’s how it started with Phoenix BIOS and Microsoft came out and even though it’s proprietary it built a much more open software development environment and a lot of great openness evolved from that like Linux and BSD variants.
MC: Horizontal integration just means that you can mix and match the pieces like Lego pieces right, but each one of those individual pieces, they could be closed or they could be open. You brought up Microsoft and I think that’s perfect. Microsoft is a closed product, but it’s in a horizontally integrated market. So you can run Windows or Linux on top of an x86. Networking needs that level of horizontal integration. And that doesn’t mean that the big vendors don’t come out with big proprietary pieces of the layer, I think that’s good, we should all encourage that, this is how innovation happens. I think Cisco is a fantastic company trying to solve some really hard problems. If this technology gets them there quicker, I think they’d be very interested in figuring that out.
AF: Cisco makes great products but I think the market could use a little more diversity. With Cisco having 80% market share, how does a startup get their foot in the door? Either Cisco buys into it or they don’t, and historically that has defined what can become successful in the networking industry outside of little specific niche markets where we see Arista, Juniper and Force10 having some success. I think everyone would benefit from having this ecosystem develop and a lot more horizontal integration to bring innovation to the industry.
MC: I would agree.
AF: Both Big Switch Networks and Nicira came out of Stanford and seem to be charting similar paths. Is there any sort of division or contention between the two groups? Is there anything you could tell me about what Nicira’s go-to-market strategy will be, what markets you’ll be attacking, or comment on the timeframe you think you’ll be announcing something?
MC: As for Big Switch I know Guido very well, he’s a good friend of mine, but they are kind of off doing their own thing, I think it’s in a very different area, but we don’t keep any tabs. As far as our announcement, Nicira has never issued a press release. So we are very much about customer engagements. We’re heavily involved in those right now. When we feel like we are in the right place, we’ll announce, but until then …
AF: Any comment on the types of customer’s your engaging with at this point?
MC: All types