Some of you might have missed Infoblox's announcement via FlowForwarding.org in mid-June about alpha availability of the LINC softswitch, written in Erlang. In the venerable tradition of open-source projects, LINC stands for LINC Is Not Closed. What's notable about LINC is that it implements version 1.2 of the OpenFlow standard, a notable feat because as of now, the number of soft-switches and controllers that support version 1.2 can be counted on the fingers of one hand (though diligent readers will remember CPqD's recent announcement of a 1.2 OpenFlow package). The other notable fact is that LINC is written in Erlang, a language designed for distributed, fault-tolerant applications. We last saw Erlang feature in FlowER, a set of OpenFlow libraries created to build controllers. Feeling curious, we reached out our old acquaintance Stu Bailey, CTO at Infoblox and a driving force behind the LINC project, and sat down with him last week for a chat.

SDxCentral: What is Infoblox's involvement in SDN?

Stu: “SDN is about taming IT complexity and enabling scale, and that’s the business that Infoblox is in. We’re seeing tremendous interest in SDN from our Service Providers and Enterprise customers. We’re also members of the ONF and very involved in standardization work. For example, I’m the vice-chair of the Configuration Management workgroup, working on the OF-Config protocol which is a companion protocol to OpenFlow. I was also the editor of the OF-Config 1.0 and 1.1 specifications. The other thing Infoblox has done recently with partners is to release an OpenFlow soft-switch through the SDN community organization FlowForwarding.org.”

SDxCentral: In your mind, what's the most exciting thing about the SDN movement?

Stu: “For me, I think the economics behind SDN is probably the most striking thing. Hardware for the switch will go the same way servers did many years back due to the proliferation of x86 architectures. There’s commoditization coming on the horizon. Hardware for switches will be like hardware for servers today. Just as the x86 commoditization allowed PC servers to be deployed in scale at a very low price, I expect the same for switches and other networking gear. With scale comes complexity, and I expect networking software will be developed, and will help us combat that complexity and enable scale—networking will become all about the software and I see that as extremely exciting.”

SDxCentral: What's your vision for SDN?

Stu: “SDN allows organizations to unleash the tremendous amount of compute power which is available today at commodity prices. SDN is a more fundamental and disruptive change in IT architecture than virtualization. Industry needs a new way to think about and control the network as a fundamental programming element. There’s an early stage of commercial SDN that is just about automation of tasks. I think the real power comes when the network is presented as a full-blown platform to the programmer. Imagine a single programmer routinely having 10,000 cores and their associated networks to write Big Data applications!  SDN enables new industrial applications like Big Data analysis in the same way the PC brought spreadsheets and word processors into the enterprise. It is very exciting times.

We’re already able to demonstrate Hadoop acceleration using OpenFlow and regular Ethernet networks instead of using much more expensive specialized interconnects like Infiniband. We have an early demonstration you can see on YouTube, and will continue to work on this the rest of the year.”

SDxCentral: Let’s visit again the LINC soft-switch announcement by both Infoblox and Erlang Solutions. What was the goal of doing that?

Stu: “Well, Infoblox is contributing to the LINC soft-switch, but it is community software hosted at FlowForwarding.org. The goal of that project is to demonstrate our support for the OpenFlow protocol standard published by the ONF. A second goal is to provide working and running code that is being released just as quickly or potentially even faster than the standards coming out of the ONF. This helps ensure that the ONF is publishing standards that are useful and implementable, and provides value to the open-source community. Our intention is to have both OFConfig and the OpenFlow 1.3 standard in LINC relatively soon.

Having said that, LINC is in still in alpha, with a lot of work that still needs to be done and we warmly invite other developers and organizations to contribute to the project.”

SDxCentral: Instead of building in Erlang, why not modify OVS to support OpenFlow 1.2?

Stu: “I think Open vSwitch is great, and I feel the same about Indigo from the developers at Big Switch. Nevertheless, it was surprising to us when we joined ONF that Open vSwitch did not support the latest versions of the OpenFlow standard.

I felt that the SDN community needed an OpenFlow switch implementation with specific focus that met different needs. From a standards participation perspective, I wanted a clean-room implementation and I feel it’s healthy, in general, to have a couple of open source implementations. The other aspect is that Open vSwitch is written in C, and my opinion is there are better languages to create reference implementations that allow faster feature velocity. My view is that Erlang allowed us to get working code much faster.

Even with LINC, I don’t feel there is competition with Open vSwitch. There will be many OpenFlow switch implementations, and that will create healthy market dynamics in terms of deciding what goes into the standards. For the record, at Infoblox, we have no plans to monetize the LINC switch, nor is it part of our current product roadmap.”

SDxCentral: Why pick Erlang as the language?

Stu: “I’m focused on emerging problems for which OpenFlow could have a big impact. Service providers and enterprises will increasingly become impacted by what some are calling the multicore crisis—large-scale distributed applications and big data services will create challenges and cause bottlenecks on legacy networks. Erlang is a tool designed to solve the multi-core crisis—it is both a language and part of an open source platform from Ericsson that was developed for multi-core systems and high performance networking. It was, therefore, a natural choice when picking the right language.

Additionally, Erlang provided us with the necessary feature velocity for our project. We started in March this year and had a 1.2 compliant soft-switch by June. That’s pretty impressive programmer productivity!”

SNDCentral: That’s great, but can Erlang run on embedded systems?

Stu: “Erlang runs on Linux and Windows, and I see it as even more embeddable than some other languages. It is already multi-platform—I’ve seen Erlang run on Android tablets and on a Raspberry Pi $35 motherboard. I understand that it may not be the top choice of embedded systems today, but I see underlying switch architectures converging quickly with general computing architectures. With the convergence of compute and networking, properties of embedded systems may be quite different in the future.

In any case, we were more focused on a proof of concept and wanted an implementation on which we could test various portions of the standard. For instance, we designed a user-space forwarding plane that’s not high-performance, but already others are replacing the user-land default forwarding plane with kernel forwarding planes in Linux, FreeBSD, and Windows and tying it into commercial, merchant silicon hardware. If others can commercialize our work in the near future, that’s great, but it wasn’t the main purpose of LINC.”

SDxCentral: What’s your view on OpenFlow and hardware versus software switches?

Stu: “I think OpenFlow should be pretty focused on future hardware, and not just existing or legacy hardware. Instead of trying to modify the standard to accommodate older forwarding planes, we should continue to push for OpenFlow to primarily meet the needs of emerging low cost/high performance hardware platforms.  SDN is in very early days. I think the focus needs to be on OpenFlow as an abstraction representing a simple standardized forwarding plane suitable for programming networks in a general way (it’s probably 80% there already). That’s why we put the LINC implementation out there—it’s a concrete implementation that everyone can see with use cases we can discuss publically. We’ll continue to push the LINC implementation forward and will have exciting plans to announce later this year.”

SDxCentral: Let’s switch topics for a moment. What's the biggest risk to SDN and OpenFlow adoption that you see?

Stu: “The hype is definitely a problem and it creates confusion. OpenFlow is something very concrete and real when it comes to SDN. And if we can’t tie SDN to real-world problems to be solved such as Big Data (e.g. Hadoop) acceleration, we are at risk.

If SDN doesn’t become sufficiently standardized, it is going to be a risk. There’s no way to tame the complexity with proprietary solutions. At the same time, it’s also critical to find the right place to standardize. I think the work on Quantum is a great example of the wrong place to focus on an SDN standard. The use-cases for Northbound (i.e. application facing) APIs are widely varied, complex, and  challenging—I think trying to standardize  a single Northbound API  right now is waste of time.

Another risk to SDN momentum is having the community confusing virtual networking with SDN. Virtual networking is a step-up in terms of automation for some simple applications but is not at all about the programmability of networks. In fact we have seen virtual networking (i.e. networking on top of hypervisors) add debilitating complexity to certain classes of distributed applications like Hadoop.

In general, I see market clutter and confusion as a huge risk to SDN adoption. There are many vendors (especially those with high-value hardware) that are driven to keep the economic benefit from the customer—that’s unhelpful friction. There are others who are claiming that the clear benefits of a hypervisor for servers can being translated to the networking domain – that simply has not been proven yet.

To reduce the risk, we need more concrete implementations and real-world examples of SDN providing hard economic value. I see market applications like Big Data or service provider security helping drive technical discussions and moving the state of the art forward.”

SDxCentral: Well, should the ONF be helping by pushing and sponsoring technical implementations?

Stu: “I think that the board member companies of the ONF have a history of supporting successful open-source implementations. Many of them are big technology consumers and I have hopes that they will be actively supporting and funding open-source OpenFlow based implementations. This will enable them to get their use cases into the discourse in a very public way. On the other hand, my take is that the ONF should continue to focus on publishing standards and not muddying the waters by funding technical implementations.”

SDxCentral: Earlier, you talked about the Northbound API being challenging. Why?

Stu: “For one, I’m not convinced that there is a market for standalone SDN controllers.  One would need to imagine a kind of universal SDN controller to justify a standardized northbound API.  My experience and expectation is that controllers will become embedded within the applications, perhaps within development platforms. It’s not clear at all to me that a productized OpenFlow controller is a real product that the market wants.”

SDxCentral: By the way, what do you think of the Nicira acquisition?

Stu: “VMWare acquired a network control plane which has a very strong involvement with OpenFlow.  It is more evidence about the fundamental changes happening in IT. Given that delivering software based network control planes is an Infoblox core competency, we are excited about the combination of VMWare and Nicira.”

SDxCentral: Finally, what are you passionate about?

Stu: “I am passionate about OpenFlow. OpenFlow is a fundamental way to expose the new economics of merchant silicon in the networking market. It is also extremely disruptive from a programming point of view. I see this as the beginning of a new era for computing systems with the network as a first class citizen. There are many distributed applications and exciting trends like Big Data that will require the next generation of infrastructure.. Google proved to the world that large-scale analytics can help with topline revenues. If an emerging SDN industry can provide affordable products to help the world to get 60% of what Google has done with their homegrown tools, they can unlock a lot of value.

ONF and OpenFlow is a foundational organization and  standard that is making progress cutting the market clutter of SDN.They have a great future ahead of them. My belief is that more focused standards bodies like the TCG and ONF can run faster and unlock more value than older standards organizations.Based on conversations with our world class customers, I’m very bullish on the future of OpenFlow.”

SDxCentral: Thank you for your time, Stu! And we wish you and FlowForwarding.org lots of luck and downloads!