QuickQuip: “Networking Doesn’t Need a VMWare” < tl;dr
I admit I was enticed by the title of the blog and the introductory paragraph certainly reeled me in with the author creds:
This post was written with Andrew Lambeth. Andrew has been virtualizing networking for long enough to have coined the term “vswitch”, and led the vDS distributed switching project at VMware
I can only assume that this is the same Andrew Lambeth who is currently employed at Nicira. I had high expectations given the title, so I sat down, strapped in and prepared for a fire hose.
Boy did I get one…
27 paragraphs amounting to 1,601 words worth that basically concluded that server virtualization is not the same thing as network virtualization, stateful L2 & L3 network virtualization at scale is difficult and ultimately virtualizing the data plane is the easy part while the hard part of getting the mackerel out of the tin is virtualizing the control plane – statefully.*
*[These are clearly *my* words as the only thing fishy here was the conclusion…]
It seems the main point here, besides that mentioned above, is to stealthily and diligently distance Nicira as far from the description of “…could be to networking something like what VMWare was to computer servers” as possible.
This is interesting given that this is how they were described in a NY Times blog some months ago. Indeed, this is exactly the description I could have sworn *used* to appear on Nicira’s own about page…it certainly shows up in Google searches of their partners o_O
In his last section titled “This is all interesting … but why do I care?,” I had selfishly hoped for that very answer.
Sadly, at the end of the day, Lambeth’s potentially excellent post appears more concerned about culling marketing terms than hammering home an important engineering nuance:
Perhaps the confusion is harmless, but it does seem to effect how the solution space is viewed, and that may be drawing the conversation away from what really is important, scale (lots of it) and distributed state consistency. Worrying about the datapath , is worrying about a trivial component of an otherwise enormously challenging problem
This smacks of positioning against both OpenFlow (addressed here) as well as other network virtualization startups.
Bummer.
Related articles
- What’s Nicira? Read this and find out. (gigaom.com)
- Bits Blog: What Is Nicira Up To? (bits.blogs.nytimes.com)
- A Contentious Question: The Value Proposition & Target Market Of Virtual Networking Solutions? (rationalsurvivability.com)
- What is Nicira really up to? (ioshints.info)
- The Killer App For OpenFlow and SDN? Security. (rationalsurvivability.com)
@beaker:
I have come to a radically different conclusion than you with regard to the intent of the second paragraph you highlighted. I think they are saying that SDN/OpenFlow will help solve the distributed state problem and that people shouldn’t focus on the “guts” of whats happening within and between nodes in the network. The focus should be on the controller and whatever SDN magic is built on top of it. The controller will manage the nodes and whatever stuff is happening there for us. “Never think about the network again” is one Nicira’s taglines.
I don’t think Nicira is “against” OpenFlow at all. I’ve pointed out in the past that the reference implementation of OpenFlow comes with Nicira’s extensions (including NAT). Nicira basically owns the Open vSwitch project. The value proposition of Nicira is that they are shielding the complexity of the network from the user with the controller and other software. OpenFlow is critical to this. However, they honestly feel that OpenFlow is getting too much attention relative to the broader SDN message, and thus also taking away from *Nicira’s* product message.
Of course it is. At least from people like myself, Ivan Pepeljnak, and Greg Farro. We are network engineers and our focus is on how the network works. We’re going to need to understand how a Nicira controlled set of nodes operates because we will install and troubleshoot the system. Its true that (potentially) on top of all this there will be SDN magic interacting with the controller. Some very interesting magic. But the bottom line is.. we need to know whats happening to the packet from point A to point B. We do. We can’t ignore this or assume everything will just work all the time. It won’t.
But I digress. This message was clearly aimed at Big Switch, I believe. Go to Big Switch’s website and click a few links. “Networking needs a VMware” is one of Big Switch’s messages.
Derick Winkworth