There are plenty arguments going on around how making network equipment “dumb” and programming it from a centralised location will save a ton. Well, saving a ton it may be, but I would like to focus on what might be lost or compromised by doing so.
As an aside: looking at the evolution of the OF protocol, the amount of “stuff” that switches will need to be able to do to support it is increasing quite rapidly. Wonder how long will it take for the complexity to be back in the devices in force, just under a different banner?
Brad Casemore wrote an excellent post about the raising tension between the traditional networking vendors and the ONF, or rather between the “traditional” and “new” ways of doing things in networking, i.e. “distributed” vs. “software-defined”. In this blog post, I would like to take a stab at the questions of “what might have contributed to this?” and “what are the some of implications to mid-market Service Providers and Enterprises?“.
Would you like to miss your boat? Here’s how to do it.
While there would inevitably be many constituents, I am of an opinion that the best way to miss an upcoming disruption is to listen to your best customers. They are largely happy with your products (or they would have walked), and in most cases, when confronted with changes, will inevitably frame their wishes and desires for improving things around the ways they have done things traditionally. This is the very case of the quote that is attributed to H. Ford, where he allegedly says that if he asked his customers what they wanted, they would have told him it was a faster horse.
Since Nicira’s coming out of “stealth” earlier this week, a lot has been said about SDNs, from hand-wringing to nice balanced analysis, however the common topic that’s been kicked around a lot is “what does it mean for the traditional networking”.
Here’s my feeble attempt on this: I think that both SDNs and traditional networking (let’s call it “MPLS” for the sake of this post) have their weak and strong sides, and could potentially be combined in a meaningful way to reap the benefits on both sides of the fence.
DC network vs. vSwitches and Network Team vs. Virtualisation Team
Judging by blog posts I’ve seen of late, one of the questions in the minds of “cloud builders” today is “who owns and is responsible for the soft switch, the one that resides in hypervisor hosts?”
So far I’ve seen no clear-cut answer. This blog post is my take on it in light of network virtualisation.