Who Does What and Where?

Going through regular strategy reviews the last few weeks brought some very lively discussions around network policy and network virtualization. The arrival of server based network virtualization solutions has perhaps as a side effect put a renewed focus and attention to network policy overall. A stickler for clarity and definition, my first instinct is to clearly separate them, then get my mind around how they are related, attached or not for that matter.

That stickler in me perhaps, but I get this strong sense that we have started to use the “network virtualization” term to indicate functionality that is way beyond what I hold as network virtualization. To me its simple, any physical network that allows logical separation of traffic at L2 or L3 is a virtualized network. Yes, a plain old ethernet network with VLANs is a virtualized network. Not very sexy, but it most certainly is virtualized. What TRILL, SPB and whatever other proprietary solutions have brought to the table is not so much the ability to virtualize, but to increase the amount of virtualized entities that can be supported beyond the 4k VLAN limit, a more up to date way to avoid loops while managing this network (if you can call 25 year old protocols up to date) and perhaps just as important, a way to remove large portions of manual configuration of end-to-end Virtualized LANs.

Even at L3 virtualization is not new. Multiple virtual routers have been around forever but similar to L2, the scale supported in hardware, the tools used to manage it (mostly extensions to BGP) have great improved the overall scalability, stability and effort in managing this entire infrastructure. Traffic is tunneled, IPSec VPNs existed way back, IP and GRE based tunnels for L3 virtualized networks are common place today.

But somehow today’s version of network virtualization seems to be used to indicate something different. We have gone from the definition that simply implies that we are separating tenants, to an all-in view that assumes that virtualization is moved to the datacenter servers in the form of vSwitches, configuration and policy is all centrally administered and applied through automated tools and GUIs and I have even found folks that lump service chaining into this mix as well. Network Virtualization needs to be careful not to become as sloppily defined as SDN.

Don’t get me wrong, we at Plexxi have stated repeatedly (and believe it) that virtualization out to the server edge makes perfect sense for many deployments. But perhaps the old and grumpy network guy in me has a problem with the simplicity by which we just lump everything together and are somewhat careless with the true understanding of what is what, who does what, who defines what and how this actually flows. In several articles here @mbushong and myself have talked about some of the complexities that come along with this, both from a career, personnel and workflow management perspective, as well as pure complexity of infrastructure, managed (virtual) elements and overall end-to-end functional and performance engineering. All of these items are complex but can be solved. In fact they all need to be solved if we want networking to get to its next level of functionality, performance and reduced complexity. They are hard, but there are lots of very smart people tackling all aspects of this evolution of the network.

The discussion we worked through here at Plexxi also included the separation of network virtualization (in its old and new forms) and network policy. Policy is a much larger entity and network virtualization really is an implementation of policy. Policy defines how I want communications to flow between applications and devices. Network virtualization is one specific method through which I can implement one aspect of policy, the need to separate some traffic from others. Policy does not end there. Policy decides whether applications needs to be inspected by firewalls, policed, intercepted, relatively prioritized, you name it. Network virtualization solutions then take their piece of the policy and implement it. Just like Plexxi takes its piece through Affinities and applies it to the creation and optimization of the L1, L2 and L3 network.

The morale of this article is less about a changing definition of network virtualization. Or the differences between policy and virtualization. It is more about the clarity created when you ask yourself “what exactly is it” a few times. There is the 5 Whys technique in cause and effect investigations. I think we need to step back at times and ask “what is it really” 5 times to turn our sometimes fluffy terms and definitions back into real actionable, implementable, deployable and manageable chunks that the engineer in many of us can spend many a sleepless night trying to solve. And there is no lack of problems to solve.