SDN, Network Virtualization, and Twitter

I wrote this a few days ago, but didn’t have time to post, but it’s still relevant given all the discussion around SDN and Network Virtualization.

Getting into a long thread on Twitter is entertaining. You have to keep your thoughts short and concise and sometimes it’s hard to list every descriptive phrase known to man to articulate what you mean.  But…that also makes it fun! One example is the thread that happened last Saturday that I jumped into a little late.

There was a comment from Greg Ferro that said Cisco has failed to address SDN if Insieme ships hardware.

How is that a failure?  While I largely agree with Greg on SDN, network virtualization, x86, driving a sedan vs. F1, I still don’t understand how delivering hardware is a failure. 

I’ve stated recently I’m an advocate of network virtualization (fully de-coupled from hardware), but I still believe if a vendor wants to invest in hardware development to differentiate their total solution, have at it.  As a network architect, you can go down the path only architecting virtual network stacks, only architecting physical fabrics, or doing both.  If you are doing both or just physical fabrics (still in 2013), you will want solid and proven hardware.  It’s too early to tell what the future will be after 2 or 3 more refresh cycles.

So, if a single vendor chooses to offer both solutions meaning a physical network fabric and a *real* network virtualization solution, I stated I want fully integrated, automated, and orchestrated.  How do you disagree with that?  That should be valuable for all parties involved.

That said, Greg doesn't agree.  He wants abstraction, independence, and isolation.  It shouldn't have to be either or a disagreement, does it?   He also doesn't want interdependent failure.  Funny thing again, I fully agree.  Am I contradicting myself?  I’d hardly say so.  But hey now, let’s not forget choice.  Customer choice is always a good thing - let's throw that on the list too.

So what characteristics do we need in the data center?

• Solution foundation using hardware (don’t forget the hardware, please)
  
• Fully de-coupled network virtualization solution   -------  This should without a doubt inherently offer network abstraction, independence, and isolation.  
• We can’t forget about fully automated and orchestrated    --------  They should be able to be automated and orchestrated independently (meaning physical network and virtual network), but if they are coming from the same vendor, the ability to unify this would be a value add.  I don’t mean inter-dependence.  And if platforms are de-coupled, this does mean minimal change to the physical network, but whatever change there will be, let’s seamlessly automate that and at the same time make it easy to extract information and statistics from the network.
• Integration – both networks do not need to be integrated.  They could and should be able to be deployed independently, but again, if it’s the same vendor offering a single solution, I’d expect some value add here.  Maybe it’s enhanced visibility, maybe it’s provisioning, but I do not mean inter-dependence when I say integrated.  I’m referring to the feedback loop that should be easier to implement because it is a single vendor like Cisco physical + Cisco virtual + NAM/NetFlow data (general thought – haven’t seen this).  However, if there is integration between two companies using a third company to provide this *GLUE* via APIs, SDKs, connectors  or whatever, that’s great too because it gives choice across hardware and software networks and also config/automation stacks.
  

Why can’t I want two networks that can be built independently, but have the opportunity to provide more value by means of feature/functionality/usability or by reduced OpEx if offered together by the same vendor or using some pretty cool glue from another?

It doesn't have to be "either or," but it can be if you'd like.

-Jason

Twitter: @jedelman8