I had the chance to sit down with Kyle Forster, Co-founder of startup Big switch networks discussing their presence at Interop, what to expect from Big Switch, and the future of OpenFlow.

Art Fewell: I’m here with Kyle Forster, the co-founder of Big Switch Networks, at Interop 2011. Kyle, why don’t you start by introducing yourself and talk a little bit about Big Switch networks and what you’re going to be showing at Interop this year.

Kyle: Sure. So this year the show we are primarily participating in the Interop lab, the OpenFlow lab itself. There’s is a booth with over 13 vendors that are all participating in it, very much in the original spirit of Interop, in a large-scale interoperability demo. We’re participating in that. We’re participating in another demo where we are showing some of the parts of our platform. And we’re actually helping a series of our partners their own demos. So it’s a very exciting, it’s an exciting spot for us. Because suddenly we are, not only, for us, starting to come out of a stealth mode and talk more and more about what we’re doing. But just as much we’re seeing a whole series of partners, and there’s a lot of equipment in that lab. But, for us it’s quite exciting because I think the world is just about to see the breadth of engineering initiatives that s going on around open flow, across the industry. There’s far more engineering being done here then press releases. So you can see it sort of altogether in the racks at the Interop Lab. It’s neat to see it.

AF: I think it’s an exciting time, and from my perspective, one of the big things that changed right now is that, there have been initiatives to try to open the world of networking to a more competitive model with a better application development ecosystem and so on. And a lot of initiatives in the past have failed. What I think is part of the reason why overflow is being so successful is that now it is it’s reaching the time where the application developers, the cloud providers are starting to realize hey now applications really need to be able to talk to the network and interact more with the network, for mobility and the cloud. And we see it with Hadoop and the cloud controllers, and things of that nature. And so, I think, it’s no longer Cisco making these decisions. We have application developers and the rest of the ecosystem really take a more active role. Do you see that is a big part of the momentum?

KF: Absolutely. You’re right, they’re trying to evolve the networking industry from the mainframe type of model to something that looks more like the service model. This is not a new concept. This has been tried before. But there are two things that are different. Let me actually say three things that are different. The first is the maturity of the set of technologies. Networking the rise of broadly available networking silicon. 3rd party available silicon fundamentally kind of changes the industry landscape in one direction. The emergence of OpenFlow as a technology standard changes things a bit. So there’s kind of a series of technology trends that I think are very interesting. There’s a series of large-scale market trends, as a number of vendors try to figure out how to compete against Cisco’s entry into the server market. The landscape there is changing and changing on us very fast. So that creates an industry dynamic we’ve never seen before. But I think that you hit on what, I think, is really the most important piece. And that’s these things are happening in an area where requirements for networks are actually changing. Certainly, on the data center side, we see the emergence of factory architectures to support Hadoop, we see the emergence of virtual machines, and VM mobility, and the rapid roll-on, roll-off of VM. A server no longer being tied to a switchboard fundamentally breaks very deep mental models around networking. And this is changing the requirements of what a network has to do. Even on the campus LAN side, we actually see … One of the beta customers that we’re working with, the exact same size networking team, today has double the number of devices on their network that they had compared three years ago. And the vast majority of those have nontraditional operating systems. Not only are they sort of mobile phones and iPads, but these devices include HVAC equipment, PCI compliant credit card swipers, and security cameras. So the explosion of these devices, each of which have their own security needs and their own compliance needs. Even on the campus LAN, it’s changing the requirements for networking. So these three things, the technologies being available, as long-term technology trends, you know, a huge amount of chaos in the industry landscape and with the very very large IT vendors. And the third part is just changing requirements. We think it’s really going to change the dynamics of a networking conversation. It allows the emergence for really new, really big technologies. And we think open flow can be one of those.

AF: It seems from the momentum that one of the things that, I think, has surprised everybody is, here we have the technology that, frankly, even among networking experts I talk to, they may have heard of it, may know what it is, they may not, and that’s across the board. And, all of a sudden, almost out of nowhere, OpenFlow is coming very rapidly … how long has ONF been formalized?

KF: About four weeks :-)

AF: Yeah, I mean it’s barely off the board and we already have the who’s who of everybody in the industry on board and in ONF and it’s blindsiding people right now. One of the things that, I think, is an interesting impact is Juniper is talking about Q fabric, Brocade is talking about VDX. Both of whom are saying that TRILL and 802.1aq, even though they haven’t been finalized and what have you, they’re already insufficient. And, so, OpenFlow can take a different perspective rather than looking at a TRILL or a 802.1aq perspective. Can you talk about that little bit? About how OpenFlow addresses the networking as an alternative to TRILL or SPB.

KF: I think you can take two paths there. The first path is to say that the OpenFlow protocol itself is expressive enough that we can write applications that, if you really want is exactly Trill, this can actually be implemented on top of and OpenFlow architecture. If you want is the benefits of Trill, I.E. multipath forwarding, Ì’d point out that I don’t know single OpenFlow vendor today that’s pushing an architecture that uses a Spanning Tree. Well, it’s not part of the protocol, I think it’s part of the architecture. So there’s the protocol, which is very tightly defined, there is the architecture, which is sort of the final bill of materials around a set of products that really all come together and do something. By nature, much , much richer, much more complicated, much more loosely defined. But I don’t know of a single architecture out there that is using a spanning tree.

KF: So, even just out of the gates, with these architectures, we’re actually quite a bit farther ahead in addressing some of the data center multi-pathing concerns that something like TRILL or 802.1aq would go after. Just by virtue of the technical architecture makes this a much easier problem to solve. With centralized control plane. And as a result, it’s become the state-of-the-art. If someone does an open flow architecture that involves spanning tree, my guess is that it’s not going to be competitive.

AF: So I have a question for your thoughts, we talked a little bit about virtualization, and there’s this idea of how we traditionally applied network policy. So the access layer has eroded and turned into the VMware vSwitch, I have found that most enterprises aren’t even applying network policy anymore. And the traditional models of doing so are just not feasible in a dynamic environment. So, I can’t, when I’m getting a new application, I can go turn to page 3000 of the manual, figure out what ports it’s going to be using, find out the IP addresses, those are all dynamic, way too much work up front. On top of that, I can’t write quality of service or security based on access lists, based on IP addresses in a dynamic environment. It doesn’t scale. As we look toward the future, how do you see OpenFlow being able to address that type of challenge?

KF: It’s a great point because I think that, really, some of the data center customers that I’m talking today, Enterprise data centers, I just look at meetings from the last six weeks, I see folks in two directions. There’s one direction that says I want, I’ve always had a highly locked down datacenter, I have a lot of security needs, I have a lot of compliance needs, so I need ACL’s all the way to the edge server and this is how I’m going to run. And that worked up until last year when we started rolling out the VMware. That’s usually where that conversation ends.

KF: I had a great conversation with a group that said, look, every time we roll out a new server, I lose a member of the networking team for two days. We used to roll out a new server every 8 to 10 weeks, so it wasn’t that big a deal. Painful, but we could manage it. Thanks to the server virtualization, we actually roll out a new VM every two weeks. So, every two weeks I’m losing somebody for two days. That’s a completely unacceptable drag.

KF: So you know they’re focused to kind of sit in this I need all ACL’s all the way to the server, you know, very lock down approach and that’s breaking. There’s the other crew which I, I actually an essential customer that gave us something interesting .. {They said} I let my data center] run like a mosh-pit. Everything can talk to everything as long as, if they can get through the outside wall. And they are keenly aware, so they have 800 pinholes in their firewall right now. And this vast number and this is their externally facing firewall and they are just vastly aware they this is a huge, while they’ve got some leg up on the manageability they’ve paid a massive price on the granularity. So you know I think with a couple of benefits with Openflow, but one of the benefits that at least we are really focusing on is this concept of virtual networks. Can I create a virtual network that really contains only the servers that I care about? Can that be managed by people who are really experts in this particular, you know, whether it’s this department that needs a virtual network or this application that needs a virtual network. So we kind of think of this a bit the opportunity to actually , get kind of the upside of these very, very highly lockdown networks but really manageability, at scale, at the scale that is required to in server virtualization and it’s speed to really do this well.

AF: I think that’s great, a great model, I’ve seen some models where, where certain vendors are saying, hey just the server administrator needs to use a GUI to drag a server connection into the clouds and some clouds can talk to other clouds in their interface, and I think that is something that when we are trying to do rapid provisioning that makes it easy. I’m wondering beyond that when I think of software refined networking. it’s kind of unfortunate that a lot of the networks benefits and services are going away in a lot of environments because what happens a lot of times when you have vulnerabilities is that a host become compromised if you don’t have that per host ACL, then all of a sudden that host has access to the rest of the hosts in the mosh-pit and then the organization gets into a bit of trouble there and so in Openflow right now it’s defining the interface between the controller and the network forwarding hardware. You know and beyond that I’d like to see a day come where the North bound interface is standardized and robust, and because it’s standardized every application can write to that API and say hey here is exactly what I need network, you do the security, quality, performance and all that happens automatically, do you see that happening?

KF: I mean let me give you a sense you know, just right outside here. On the show floor we are actually showing a REST API Controlling Forwarding in a network.

AF:Nice

KF: the, you know I think there are two pieces there, first of all you need software that is flexible enough to keep up with modern API’s and it’s all the infrastructure components that come with keeping up to date there, so you need a software architecture that is flexible enough to do that. You also really need a set of primitives about, what is your data model about a network look like that’s both solid enough and simple enough to make it very, very practical for developers to write applications that straddle the, you know an application running the IT ecosystem and the network of the IT ecosystem. And so that for us is part of what drives our thinking around what and how we need to expose the innards of our controller data structures.

AF: So, now I don’t know what you can talk about and can’t talk about today, obviously you are demonstrating some of your features on the show floor today so in terms of primitives what type of fundamentally different approaches are you taking, and what can we expect to see in your initial controller release, I think some intelligent led-balancing, muti-pathing, you know controller base model, what , what other cool features do you see?

KF: Let me tell you what I think is going to be for us the really, really interesting feature, and it’s more than a feature, for us it’s more of a full fledge application, um we like to think of it as the VMware for networking.

KF: We have a concept of an architect that can pick two ports from here, three ports from over there, you know, five ports from another switch roll them all together with a user name and password and delegate that out to an administrator who logs in, and to that administrator, this thing just looks and feels like a single switch. Now the ports can be very, very widely distributed, some of these ports may even you know, say port three is attached to, rather than saying a physical port, port three is attached to a vm named payment server. If the payment server moves around, well the architect might know that but from the administrators perspective it’s just always plugged into port three. So this separation of saying, hey the administrator actually gets a virtual, their virtual network is one big switch.

AF: Yeah, that is an interesting perspective because you know, one of the ways that a lot of the traditional network companies are trying to tackle this is rather than looking at a new way of doing things or maybe in addition to, they are saying that, keep your traditional, static network policy and we will have it automatically follow your device around as vmotion moves, or what have you, as you move into stateless environments and I like that idea that, as workloads move it may moved physically around the network but it still appears to be on the same switchport , you know that may have tremendous implications on operations.

KF: It is sort of the old meets new, lets take the old concept of a switch and lets keep it.

AF: You mentioned earlier about the industry with a mainframe mentality and the fact that the network industry has been very vertically integrated. Openflow is a step, to get there, but at the end of the day you still don’t have the standards around a development environment directly on a controller, and then beyond that the Northbound API’s. What is Big Switch doing with the controller API’s but then beyond that, where do you think the standards are going with the API’s to and development environment for network operating systems.

KF: You know, to me I think the best answer for that. The Openflow standard followed only after Openflow had actually already been implemented and rolled out in several buildings at Stanford and in several other campuses as well. I think it was actually rolled out in eight campuses before the standard was even drafted. So I think about it less, I don’t think about lets build a standard and then a product second. I think more, lets build a really good product, you know, let a thousand flower bloom, some of these are going to be incredibly useful for end customers and those are the ones we want to standardize. So I see very much the standards process of, you know, the standards process gets to sort of pick and choose, especially on the Northbound API front, you know here are some of the really, really useful things that are being built, now lets standardize those.

AF: And I kind of like this idea of moving forward, the standardization process can really slow growth. It takes a lot of time, there is a lot of arguing, and I like the way a lot of the standards are being, in the open source movement, is go do it, open it up let other people contribute, it still may not have as many sources of control or input, but at least it is making progress and it may become more of a de facto standard. At the end of the day the market needs some level of standardization and sometimes it is best to let the market decide so we can continue to make progress rather than fighting and bickering. So, where do you see, how do you see the market being disrupted, and what do you see as the initial applications for Openflow?

KF: You know I think for us I look at, you know specifically for us? I look at the sort of one big switch, the network virtualization fees as being, you know in my mind for our company I think it’s kind of where we expect the first rivet option of Openflow to happen in the enterprise data center, right? Campus LAN we can also talk about but the enterprise data center is something that we see as folks who are making this transition from enterprise data center to a private cloud, you know and for us it’s less of a technology transition and more of a org chart transition. It says hey rather than one team doing everything there should be a small central team that effectively creates a large number of self service tools that look a lot like Amazon EC2. Hey, you want 10 VM’s great, here you go, knock yourself out, if you get yourself all in a tangle your, your problem. You know, right now the issue that we see is folks kind of make this transition over to private cloud on the compute side, says everyone, OK you want 10 VM’s great, go to town, and I’ll just use some really mundane examples. Say uh, say within there somebody flips on Windows load bouncer, now all of a sudden amongst their VM’s they are now actually flooding broadcast traffic all the way across the network and suddenly they are no longer being a good neighbor. It doesn’t take very many of those to have a private cloud concept. So you start to break down on the edges. So we look at it as this transition from data center to private cloud has been very successful on the compute side, but on the networking side, we have some very very core fundamental problems to solve. And that’s really where we see things, in this sort of virtual switch sense that its an architect whose actually on a central team working on the data center as a whole. And both understanding the physical typology and the virtual typology on top within their application teams and they really don’t care about the substrate underneath them they just care about, here are my servers, here’s my network, if I do something wrong I’m not going to hurt my neighbors. If my neighbors do something wrong they’re not going to hurt me. All I need to worry about is just making my application, getting it up and running, and keeping it healthy. And I take out alot of the variables that sit on my left and on my right.

AF: Will your initial marketing efforts be targeted more towards enterprise, service provider, traditional network service provider, cloud, ASPs, or data center providers, where’s your area of focus going to be?

KF: We’re really going to focus entirely on the enterprise, we focus on the enterprise data center, on a partially virtualized, not 100% virtualized, but partially virtualized data center, and we focus on the enterprise campus LAN.

AF: OK. So you have a campus LAN application as well? I say that, I think the data center, there’s a lot of room up for grabs because the traditional networking team only has so much influence in the data center, so there’s a lot of other influencers that help to make the decisions there. Big inflection point. and this is probably a very popular analogy but I’ like to hear your perspective on it. I think enterprise will be a little bit ripe towards controller networking because of what’s happened in wireless LAN. They’ve already gone through the same transition from fat APs to thin APs that basically wiped fat APs out and I think its much the same thing and I think they’re going to be ready for it if we draw the proper analogies do you think?

KF: My job used to be the product manager of one of the alliance of Cisco one of those main controllers, I couldn’t agree more.

AF: Very good. I think that’s all the questions I have. Do you have any other plugs, any features that we missed?

KF: You know I appreciate it more than anything else, I would just say the biggest thing I’d like to plug is this show, what’s happening right now, is a sentimental moment, kind of a coming out party for OpenFlow.

AF: That’s funny that’s exactly what I said, in my article about OpenFlow.

KF: Perfect, that’s perfect, that really sums it up. I mean when you walk over there and you see the sheer number of vendors who are sitting there in those racks, this is, this is the start.

AF: Yeah and I think its going to go from a technology that only the industry strategists and the have heard about, and the academics, to something that becomes one of the biggest buzz words. I think that this was going to be the coming out party for it, and I really think that within a few months its going to be the big buzz in networking. Last question, I thought of one more that I would like to ask, out there on the show floor, I’ve been anticipating in the initial thing some controller based networking I already saw from what Dell was doing that they were basically doing port to port VPNs so that you could have access to a cloud service provider and get a physical hardware provision as though it was on your local LAN. What other interesting applications are there out there other than just your controller model, and integrated load balancing as a primitive, what else have you seen out there that’s kind of interesting?

KF: I look at that demo as one of a whole class of interesting areas that says, here’s how we can dynamically re -broadcast domains, and it doesn’t sound as sexy. To me it says that we can take a very very complex network typologies in the physical sense and overlay them with the intuitive and simple, here’s the broadcast domain that I want. And I think that we’re seeing a whole series of a variance of that theme. Out in that lab and in a couple of other booths in the show room floor. And that to me is a really, when you start to see the variance, and that a number of these variances come from a central concept, its actually going to be very very powerful. And very exciting, that’s just something that you cannot do with strictly networking today.

AF: Awesome, well, its been exciting to talk to you, I think we’re probably going to get kicked out of the room pretty soon, so I thank you for taking the time. I for one am very excited about what OpenFlow is going to do to the industry, hopefully it will bring a lot of new competition, a lot of new innovations and I think networking has been the slow boat that falls behind Moore’s law and Hitachi’s Law. But what I hope is that OpenFlow takes it, and we actually start to surpass Moore’s and Hitachi’s and we start to become the leading force in the elements that make up the cloud solution.

KF: I hope it goes well.

AF: I appreciate it, thank you very much.
If you would like to see the original videos, they can be viewed here: