[Art] If you look at what's happening with OpenFlow today, with OpenFlow in the physical hardware. There's a lot of people saying, "Well, what if I just did an API here rather than using OpenFlow, maybe leave the control plane." I think there's one point in there that's very related to the automation but maybe a different level of sophistication. That is, first we need the automation because when you move virtual machines around, and we deploy virtual machines, or other applications we need that policy to automatically follow that and so OpenFlow can facilitate that. I can do that through a number of other means, but I think one of the things about OpenFlow that's really key there is understanding the current exact state of what configuration and what policies are following that virtual machine or that application around at a given time. I think as we get into this app-ifying of networking, having the current state it really becomes critical.
[Rob] Absolutely. I've definitely said publicly a number of times that I think OpenFlow is very valuable but it's also, it's a technical solution to a business problem that we've had. This is to say, if you flashed back 7, 8 years when I started working on this; the idea that you could actually buy a switch and put your own software on it and there was enough hardware documentation and enough open source software to make that happen, it was actually, it just wasn't even on the table. The next best thing that we could hope for was a remote API into the low level forwarding plane on the box. That was how the OpenFlow was designed. Fast forward to today, we have things like, if I could put a small plug-in for my open source project, Open Network Linux.
[Art] Please do, yes. We're big fans.
[Rob] You can grab something like that and either deploy our OpenFlow, or write your own OpenFlow, or write something else. We have people using it creating custom protocols. OpenFlow, the concept is extremely useful, which is let's expose the raw channel memory to an RPC. OpenFlow as a specific protocol, whether it's the ONF OpenFlow or just something else that does that same process, I think as the open source evolves, as things like the Open Network Linux take off, I think that specific detail will be less important.
[Art] There's all this language challenge around SDN. What exactly does SDN mean? In some cases it is only OpenFlow, in some cases it's only OpenFlow in the physical hardware, or other people define it as these really broad things. From my perspective, that all started from the first Open Networking Summit when as soon as SDN looked like it might be a hyped term, every vendor out there came back and said, "What we already have today is SDN. That new stuff coming out of those star-eyed visionaries over there in the academic space, that's not really SDN." What I saw is kind of as a result of that, there was a little doubling down on "No, OpenFlow is SDN."
Sign up for MIS Asia eNewsletters.