Network Virtualisation and visibility of the lower layers

This isn’t much of the blog post, but more of a link to a fairly solid discussion that’s happening in the comments section of a blog post @jonisick recently wrote:

What Network Virtualization Isn’t

The premise of the discussion I think boils down to a bit of a disconnect in points of view of the proponents of Network Virtualisation and those who are trying to understand what introducing NV into their traditional switched/routed DC network environments will do to the operational complexity.

Anyway, head over to the Joe’s blog linked above for the full scoop, and don’t miss the comments.

TL;DR for the impatient: I believe that we need to sort out some kind of OAM at the points where NV platform consumes underlay IP transport services. I don’t know how it is going to shape up, but believe that this is a very important point that deserves a lot more attention than I’ve seen so far.

Good and better ways of extracting simplicity

Summary for the impatient

If your solution to a complex problem makes things simpler for you by making it harder for somebody else, you’re probably doing it wrong. I’m looking at you, VXLAN.

Applications on SDNs: Drivers or Passengers?

There’s a lot of talk about SDN giving control to applications over the network’s behaviour. I’m not too sure I buy a lot of it.

Necessary clarification: when I’m using term “application” in this blog post, I mean the applications that need network connectivity services to deliver their data to their users, rather than the specialised applications, designed for sole purpose of controlling data traffic flows.

My selfish view on what I want “the network” to be

Context

Definitions first: what “network”? In this case, a mid-size (serving between a handful and up to 2–4 thousand of network-connected physical devices – servers, appliances) Enterprise, or a managed services provider’s network. Yes, not the tens or hundreds of thousands. If you’re wondering why, please visit this entry on my blog.

Also, wishes are often shaped by a point of view. The one for this blog is that of a somebody who’s responsible for the infrastructure architecture; call it what you will. Somebody who is looking after the marriage of the technology and the business outcomes it produces at a mid-size managed IT services provider.

The wish-list

Warning: here be the unicorns.

Removing intelligence from the network kills value

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?

Stateless Transport Tunnelling Protocol (STT): a half-step too far?

This morning (our time) @martin_casado tweeted a link to a freshly minted IETF draft – draft-davie-stt-00, that describes a new product of Nicira’s engineering effort (with contributions from Broadcom, Rackspace, eBay, Intel and Yahoo!), “A Stateless Transport Tunneling Protocol for Network Virtualisation (STT)”.

Naturally, I was intrigued by the proposal, and would like to share what I’ve learned and some thoughts about it.

On square pegs and round holes

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.