In part two of our Q&A with Allwyn Sequeira, CTO and vice president of cloud, networking and security, we delve into VMware's position on OpenFlow.
Does the VMware networking strategy include support for OpenFlow?
Allwyn Sequeira: We are part of original team with the Open Networking Foundation and part of the founding team of ONRC [Open Networking Research Center] Labs.
Read Part One of our Q&A
VMware networking CTO on software defined networking and network virtualization
If you look at SDN and OpenFlow, [they] prescribe a certain way of doing things. Extract the control plane, control the forwarding plane via the OpenFlow protocol, and have a centralized management scheme.
We are mostly there today. If all the equipment on the network were OpenFlow-enabled, we would be able quickly manipulate all boxes in the network via OpenFlow, and life would be good.
The reality is that less than 1% of enterprise switches today are OpenFlow-enabled. So for our specific view, we will take an intermediate step. We will do SDNs and notions of Ethernet abstractions, network service abstractions like firewalls, load balancers, etc. It all dovetails with software defined networking, with a centralized control plane. With things like VXLAN we overlay the current network. And yet at a higher level from SDN perspective, we still realize the same services that SDN provides. Give me a network, allow me to add VMs to that network, plug in a firewall service; it preserves northbound APIs. But on the southbound side, rather than start with programming OpenFlow agents, we have overlay networks and VXLANs.
Now as OpenFlow agents become available in the enterprise, we can map VXLANs on top of OpenFlow. VXLAN is an encapsulation that rides across the network. If the underlying network is OpenFlow-enabled, we can map the VXLAN and program the VXLAN across the underlying network. In the meantime, all the investments our customers made with northbound APIs and network virtualization, with VXLANs, all that is preserved. Then we can continue to evolve that network and go more into leveraging native OpenFlow when it has meaningful penetration of the enterprise market.
It's the same thing we did with server virtualization. In the early days we used to be on the outside looking in. Once you reach the point with 50% virtualization, you begin to optimize for virtual environments and bridge to the physical. The same [will happen] with networks. We are beginning to optimize for network virtualization and VXLANs. When OpenFlow reaches 50% penetration, we will optimize for OpenFlow. I look at this as a continuum rather than OpenFlow versus VXLAN. This allows us to bring OpenFlow into an organization gently versus a forklift upgrade. OpenFlow is a specific way to program the network, but SDN doesn't mean you can only do it with OpenFlow.
If OpenFlow or some other SDN protocol takes off and you're able to abstract directly at each device rather than relying on an overlay technology, what kind of value can you derive from that?
Sequeira: I think what we have today is good enough for most of what we are trying achieve for network virtualization. Ultimately the number one problem we're trying to solve in enterprise data centers is speed and agility of provisioning and efficiency. The whole point of a software-defined data center is to virtualize the rest of the data center. VMware-enabled provisioning allowed provisioning of servers within two minutes and for $300, whereas in the past it took 10 days and $10,000.
The rest of the problem is it takes five days to provision the rest -- VLANs, IP address management, firewalls, storage availability. If you can provision these networks quickly, you have solved that problem. We believe with VXLAN and SDN we have solved that problem substantially. So customers aren't asking us for OpenFlow. They are asking for agility of provisioning and seamlessness of experience when they start to bring up compute with network and storage alongside. In that particular instance, OpenFlow doesn't bring you immediate value.
Then why even consider OpenFlow in the data center? With OpenFlow you get a lot more granularity of visibility and control. With overlays, for the most part, it works. Most people build their fabrics and have headroom in their fabric. With OpenFlow you can be much more efficient, much like Google showed in their WAN. You can program each flow; you can bring up applications and say, 'I want this application to take this specific path through the network.' When you want much more specific control over your traffic, then you can look at OpenFlow. Likewise, you can ultimately get a lot more diagnostic capabilities because you know what is happening when an application has an issue with a server. You can quickly pinpoint what went wrong with the server.
But people aren't ready for it yet. Today people want to monitor networks with existing tools. Even if the technology was 100% there today, it takes a while for organizations to change people and processes. If you have 200 Stanford Ph.D.s and you own your own fiber and can build your own boxes in your backyard and you own your own traffic and have proprietary applications, then [Openflow] is for you [now].
So enterprises don't need OpenFlow, and they will probably wait until somebody commercializes it?
Sequeira: Exactly. If all you are doing is working on your own proprietary applications like Google, Facebook or Zynga, that's one problem. Our problem is very different. The reason VMware is so solidly grounded in enterprises is because 90% of these applications have been running in networks for years and years. VMware enabled these existing applications to be containerized and you're able to insert the virtualization layer, which allows you slip in new hardware without touching the applications. All these new applications we talk a lot about -- big data and Hadoop -- that's not what most enterprises are facing today. It's the 95% of applications in enterprise that we want move forward.
Do you see VMware competing with Nicira Networks, Big Switch Networks and NEC?
Sequeira: The real question is: Are Nicira and Big Switch a feature in VMware? We are not looking to compete with them. The onus is on them to find an important and relevant area that solves a unique problem. Solving network virtualization in the context of a VMware stack? We've got that nailed. In other words, we don't believe that we need an outside answer to solve a virtualization problem for our VMware stack.
Click here to read part one of this Q&A