What role does the concept of a “network fabric” play in the march towards commoditization of networking?  Well, let’s discuss!

The Whole Shebang

There can be no doubt that an organization’s relationship to networking is to the aggregate thing they call “the network.”  When there are issues, non-network folks say wonderfully vague things like “The network is dropping packets!” or “I can’t login… must be the network.”  This intuition, to think about the network as a whole, rather than as a collection of systems, is right:  Collectively, the network is supposed to produce desirable aggregate behavior.

This is an important clue as to how networking will evolve in the future.  SDN is a step in this direction.  Intelligent software will undoubtedly coordinate the actions of the underlying constituent systems, on behalf of an operator or an application, to achieve some policy goals.  This software need not exist solely in the form of a network controller.  Indeed, here at Plexxi, our switches can coordinate on their own to achieve aggregate behavior.  This is why you can stand up a Plexxi network, and pass traffic, without the need for a centralized controller.

A network fabric should have the goal of managing network workloads according to a higher-level policy.  However, many fabrics do not do this.  They may have some desirable fabric features, but for edge policies operators must still log into individual devices to achieve their goals.  This, of course, is the fundamental problem of networking that SDN hopes to solve:  Let intelligent software perform these menial tasks, and let the organization, or the operator, express network-wide policy to the software.

The Value of the Network

What is the value of the network?  Fundamentally, the network has one feature that matters: paths.  The job the network, first and foremost, is to facilitate the movement of data between it’s edges.  The more paths a network has, the better.  We even see this in leaf-and-bufferspine designs.

Administrative, control, voice, video, bulk, and garbage are just some of the workload types requiring different treatment in the network.  When you have fewer paths in the network, it becomes increasingly difficult to manage workload conflict that arises when multiple types of traffic converge on an egress interface.  Quality-of-Service has always represented a sort of white flag of surrender before conflict even occurs, and let’s be honest, it’s been an absolute nightmare to manage on the ground.  Aggregate flow characteristics change throughout the day (burstiness, packet size distribution, differing workload types), making static policies difficult to implement.  The best you can hope for is a policy that represents the lowest-common denominator compromise.

Even when you have multiple paths in the network, it’s virtually impossible to manage and move differing workload types.  How frustrating it has been that spanning-tree cut the usable bandwidth down drastically in the data center.  Even if we could use it, how to move only some workloads?  Imagine doing this when you have multiple types of workloads just within HTTP!  Transferring files, web traffic, API calls for automation systems… all in the same encapsulation.

QoS is obviously the product of legacy network thinking:  Fewer paths and indiscriminate workload placement, resulting from the erroneous belief that universal reachability for packets is the primary goal of the network.  Build just enough paths to be redundant, put the routes in… and hope for the best.  Are we done being amazed that we can make packets go yet?  Can’t we do better than making a sequel to “The Hangover” because we can ping?  Aren’t we tired of failing to deal with the complexity of networking as a whole?  Then let’s stop using legacy stuff to accomplish our goals.

Network Commodifabricization

The value of the network goes up as more paths are added.  However, the old way of workload placement in the network, as well as the old way of handling workload conflict, just isn’t going to be manageable by hand.  Adding value to the network should be as simple as adding paths, and adding paths should actually be simple both physically and logically.  A commodity network means lots of paths, which are the primary value of the network to begin with.  It also means intelligent software that manages the many types of workloads on the network by distributing them across those paths.  That same software will present an intuitive policy interface to humans who just want “the network” to work.

Where does that leave the current trend of some companies seeking to commoditize on legacy networking?  Well, like cloud, it would seem that many folks are banking on the idea that IT is done evolving.  Including networking!  Obviously, this is not the case.  What we are experiencing right now is the “big crunch” of IT.  If the mainframe represented some primordial IT state that exploded into the constituent pieces of the IT universe, like the big bang of tech, then the data center of the future represents the big crunch of these pieces.  Lots of intermediate layers will disappear, from the guest OS of a VM, to maybe even the IP protocol!  Will linux-based switches and routers with a subset of legacy network features really have a role here?  Perhaps in the short-term, but not for long.

Intuitive network fabrics are the true start down the path of commoditization, making the real value of the network directly and easily manageable.

[Fun fact:  One time, I drove a bulldozer into a pond.  People get really mad when you do that.  Also, it makes the bulldozer inoperable.  Hmmm... if only there had been a "path" around the pond.]

The post Commodity Network Fabrics appeared first on Plexxi.