We had such a good response from our Dan Talayco interview that we decided to start a weekly interview series. This week, we’re publishing our interview with Rob Sherwood, an engineer at Big Switch Networks, and well-known for his efforts on FlowVisor, a controller proxy that acts as a virtualization layer between switches and a collection of controllers. FlowVisor has had a lot of visibility in the community and Rob was a critical element to its success.

Going forward each week, we’ll try to identify a member of the SDN community and conduct an interview with them. If you have suggestions, please feel free to send them to us at [email protected], along with any questions you might have for them.

Without further ado, here’s our chat with Rob:

SDxCentral: So, how did you first get involved in OpenFlow?

Rob: I was a Deutsche Telekom employee who worked as part of Nick McKeown's group at Stanford's Clean Slate Lab in 2008. This was right after Martin Casado graduated and formed Nicira. While at the lab, I worked with Guido Appenzeller and eventually ended up at Big Switch (Editor's Note: Guido is the CEO at Big Switch).

SDxCentral: Was FlowVisor the main project you worked on?

Rob: Yes, there was a big collective effort, but I was the primary author on the FlowVisor paper, along with Guido and Martin. FlowVisor is currently maintained by Ali Al-Shabibi at ON.lab, and I’m not as active as I used to be on the project. FlowVisor got started because there was a focus on network virtualization at Deustche Telekom, and DT contributed 3 engineers to the Clean Slate group to work on the project.

SDxCentral: Why was there a need for FlowVisor?

Rob: For network virtualization to succeed, we felt there was a need for a hypervisor equivalent in SDN. OpenFlow is an enabler of network virtualization but it’s more akin to an instruction set (like x86) than a hypervisor. FlowVisor is the piece that allows researchers building out new protocols to do their protocol testing on a shared production network. It provides strong isolation between potentially crazy runaway processes and the production stack. Using FlowVisor allowed for multiple controllers (like guest OSes running on VMware).

SDxCentral: That makes sense--CPU virtualization requires a hypervisor for isolation and protection, and similarly network virtualization needs FlowVisor. So, now that you’re not working as much on FlowVisor, what are you working on in SDN?

Rob: Aside from my day job of leading architecture for the engineering group at Big Switch, I’m involved in  standardization efforts, working with partners and evangelizing OpenFlow to a wider audience. For instance, I’m the vice-chairman of the testing and interoperability working group. We’re trying to drive OFTest to be the main testing standard for conformance going forward.

SDxCentral: I see, does that compete with what IXIA is offering for OpenFlow Testing?

Rob: Well, the best way to look at both offerings is that OFTest will be open-source, with no frills, bells or whistles. IXIA and other vendors like Spirent will provide a comprehensive commercial solution. Regardless, I expect both OFTest and commercial solutions will cover the OpenFlow protocol thoroughly. BTW, we’re still in the early days yet for testing. Many of the vendors use the same chipset and the hardware is very similar, so results might be more similar than not. The differentiation comes from either using external TCAMs, or in most cases, will come from the quality and performance of the OpenFlow software agent running on the switch. We’ve seen though that using external TCAMs can add undesirable latency.

SDxCentral: I’m sure that’s not a well-known fact and a good tidbit for our readers. Regardless, as OpenFlow hardware and software matures, where do you think the major innovation will come from in the next twelve months?

Rob: I think we’re learning lots of lessons around OpenFlow. And I see that many of the naysayers have been silenced by large organizations like Google coming out and saying that OpenFlow can be deployed in production. This bodes well for the future of OpenFlow, especially as we’re learning about production requirements of OpenFlow including making high-availability possible. I predict that we’ll see a large number of big name companies will come onboard the SDN bandwagon in the next year.

SDxCentral: BTW, what’s your take on the pausing of the OpenFlow specifications at version 1.3?

Rob: I think it’s a good thing. Generally, with OpenFlow, I see a need for collaboration between the hardware manufacturers and the software teams working on OpenFlow projects. It does take longer for the hardware manufacturers to come up to speed and many of them have just managed to support the 1.0 specification. The pause is needed. There are so many different aspects of a chip, like the L2, L3 lookup tables, the ACL tables, etc. The HW vendors have to figure out which of these tables to use and which aspect of the protocol can be supported (including some optional capabilities). That will take some time and potentially some cultural changes will need to happen at these places too—that will take longer.

SDxCentral: And what about our ever-popular topics—the Northbound API and the killer app—any words to share on those?

Rob: Look at the POSIX API standardization efforts for UNIX. That took many years to nail down. I think that premature standardization might ruin the Northbound API and early standardization may not even be necessary. As another example, look at the mobile phone market, with dueling APIs for iOS and Android. The mobile application world has certainly flourished. For Floodlight (an open-source controller that Big Switch is actively working on), there’s an evolving API for end-users to write applications to, and we’re constantly revising and getting feedback—it’ll take time to mature.

Regardless of how the API matures, I think that the real killer-app for OpenFlow is the long-tail applications. Cisco and Juniper (and other networking vendors) will also provide solutions for the most common issues. However, there’s a long-tail in networking applications that may not be commercially viable, but that end-users could use SDN/OpenFlow to implement. This allows teams with unique problems to solve them using an OpenFlow foundation with off-the-shelf commodity switches.

SDxCentral: Very interesting perspective, thank you very much for your time!