It's all happy up in the cloud, right?

For networking companies cloud computing could be the biggest boon or the biggest bane, or as is sometimes quoted - the road to (shareholder) hell is paved with good intentions.

Network companies have been relatively and somewhat strangely quiet about cloud computing. Sure we've seen some partnerships, some demonstrations, and a lot of rhetoric- but there really hasn't been a lot of action. There certainly has not been purposeful, planned, development. One of the reasons may be the school of thought that the network is an inherent beneficiary of cloud computing - certainly anything that spits more bits out and drives larger pipes is a win for networking, right? The darker side is that at scale cloud computing represents a fundamental shift in the balance of purchasing power and a massive consolidation of computing, and thus purchasing capability into a smaller number of larger companies.

We've already heard about search companies building their own servers and even rumors of them building their own networking equipment. When you have that much domain expertise consolidated and there is that degree of specificity about the features and capabilities required saving capex while lowering the power consumption reducing your overall operating costs against one of your biggest expense line-items is worth it to large enough providers. Plus many of these providers know exactly what features they do and do not need - and there is variability between providers based on their respective philosophies about redundancy, fault tolerance, accounting, traffic engineering, etc. Is this model for everyone? Certainly not. But for those with enough chutzpah, mass and the technical wherewithal, it seems to be working.

Now fast forward seven to ten years. (like when Bill Gates once famously proselytized a vision based on unlimited bandwidth and limitless computing power - what would you do?) Imagine 50% of the world's compute capacity is owned by five companies. The purchasing power would be immense, the value to a vendor of winning the deal is a make/break proposition to many start-ups and even mid-caps. The ability to squeeze margin out of the vendors and define the exact requirements for what needed to be built, unparalleled. High margins? Doubtful.

Where would the network be? Let's see, certainly my 'glass half full' self sees that there would be a large WAN opportunity and Internet core upgrades required to support the increase in mobile workloads and mix of elastic and real-time network traffic. Ideally there would be a way of consistently signaling a particular packet's requirement for real-time, lossless, or an elastic traffic profile across multiple network providers with some guarantee they adhere to the marking. Although with net-neutrality I doubt this will ever happen in any end-to-end consistent manner and the owners of the end-stations and clouds will over-provision capacity and use clever over-the-top mechanisms to solve this issue further reducing the carrier's value.

The main change for the network will be static and physical definitions of service bound to location shifting to much more dynamic addressing
and embracing workload mobility. The network needs to be able to move workloads to run on the server and in the location that can service that workloads performance and processing requirement in the most effective and efficient way possible. This will enable and drive demand for follow-the-sun, follow-the-kilowatt, and follow-the-tax-code portability and mobility requirements. This is not just moving a workload around the data center, this could be moving it from one continent to another, and not a one-time move, but a dynamic and elastic environment where resources are constantly being re-balanced to achieve operational efficiencies, meet customer SLAs, scale to add new customers or divest customers quickly, and ensure security/segmentation where appropriate.

As I have said before today's networks are not ready for this. The static addressing model is broken, the routing protocols are not designed for the scale or the change-rate, and the need for abstraction and management is different than any networking vendor has embraced yet.

Let's assume that the technical hurdles get solved, that really smart people who solved the addressing problems for mobile phone systems, local number portability, and global roaming can use some of the same principles and solve the issues around globalization of IP addressing, /32 host route mobility, and really large scale routing tables. Let's focus on what makes a networking system "cloud-ready" that is a bit more complicated than even these rather sizable network and routing architecture challenges- Religion. Politics. Business. Control.

Here's the big 'gap' in everyone's story. Right now each vendor views their own system at the core of this cloud. It's all about the network, server, VM, SAN, etc depending whom you are talking to. Everyone wants to take their castle and put it on a cloud, without giving the keys to above-said-castle to anyone else. This means a strong desire in every major player to keep business as usual and extend the current value proposition and operational models to the cloud as best possible, see what sticks, adjust, go from there.

I believe, depending how 'evolved' the segment is, this could be a major failure if the core capabilities of the technology are not designed around the principles needed in cloud environments: elasticity, self-provisioning, open APIs, programmability, trust, control, interoperability, etc.

Where are networking vendors failing and flailing? Largely around the management and configuration interfaces to their systems -- The CLI is dead to the new world order. Take every feature in a network operating system and write down the ones you use. Put them on individual note-cards on a desk and then put the ones that are machine-readable, software controlled/instantiated, centrally provisioned, and globally scalable in a box we call 'Cloud Ready' and put everything else in the 'Old World' box. If the Cloud Ready box is pretty empty, that vendor will be left with one thing to differentiate - PRICE.

Everything in the networking world is instantiated by a CLI. Every cloud operator I know wants a machine readable interface, they want their devices to plug into a common management framework, they want a single point of administration and control. For some this is home-grown, for some this will be VMware's vSphere, for others it may be another offering. This 'Cloud OS' does job macro-scheduling, enforces work flows, and provides elastic scaling and depends on machine readable interfaces into switches, routers, firewalls, servers, storage, and so on. It also will depend on consistency between managed devices - i.e. if stuff doesn't work identically between products the outliers are not likely to be adopted.

Many vendors are reticent to give their 'keys' to someone else's Cloud OS - i.e. if it can't be their own, they don't want to open the system up, to the operator this means now having to install multiple management systems when what they really want is one that can work with multiple vendors. The message I heard one cloud operator tell me was, "Be Open or Die."

Make the shift to building planned systems architectures, and intelligently using networking protocols to provide a consistent abstraction to a cloud OS, there is a chance to win big. Miss it, build fragmented systems with no management abstraction or not tie into the right eco-system of partners and risk rapid commoditization as the core value of your product can actually never be expressed to a customer/operator in a way they could use it. Unused features is simply higher cost with no incremental value.

a rainbow of fruit flavors for the network

Do you really use network quality of service within the glass house data center?  This is a question I have been pondering pretty much all day- I get that on the costly WAN links we almost all use it.  I also completely acknowledge that most engineers plan to use some of the QoS features within the data center, but what do we really use?  Which features are necessary and which are just... well...  extraneous?

Here's my thought-   I think there are some  QoS 'hit songs' implemented in the data center, and some that just are not that appropriate for this iMix.

Bad Boy Bad Boy, whatcha gonna queue....
No matter how many security products we surround ourselves with we all have the 'time out queue' for traffic that just isn't, well, good.  It's for those pesky control plane DoS attacks, the misbehaving broadcast storm NIC, or that one application that just won't shut up.

Voices Carry
For some reason I have the 80's Til Tuesday song in my head by the same name- but most engineers I have talked with seem to set up, by default, a strict priority queue for voice traffic, then never,ever touch it again because it just works.

Marky Mark and the Funky Bunch
We all use markers, especially at the edge where we can have maximum visibility to what comes from a single host, and mark it up appropriately so that we don't have to continuously re-inspect and re-apply policy everywhere.  Tag at the edge, queue in the core, shape on the WAN or point of massive congestion/cost.

(Don't) Drop it like it's Hot
No matter what religious SCSI encapsulation you love- FibreChannel, FibreChannel over Ethernet, iSCSI or even file based alternatives such as NFS or CIFS storage just performs better when is is not dropped.  As much as I love technologies like Aspera for moving large files from A-to-B, until it is integrated in my host stack (which would monumentally rock for copying my iTunes library to S3 btw, hint...) the world will be dependent on TCP-guaranteed or PFC/BCN guaranteed storage delivery for a while - so we need a "lossless don't-drop-me-please" queue.

Shape ya Tailfeather
As we hit congestion and contention for bandwidth in a well designed data center this happens at the cost-center link, i.e. the edge router: this is where I apply large buffers, shapers, and policers to ensure that traffic can en-queue long enough to get onto the link, we can also adhere to Peter Lothberg's long-time rule of providing enough buffer to handle a round-trip-response of around the world or ~300ms.  Shaping the previously marked-up traffic onto the link while trying to get all the right traffic on the link is the job of the core routers, usually not fixed switches.

That's it for now, any songs I should also think about including into the Data Center QoS Playlist?

dg

Tag, you're it!

Recently there has been some eloquent flaming back and forth between Cisco and HP over the VN-Tag, of course I have an opinion and figured I would vocalize it.  Scott Lowe has a good piece on this as well, focused more broadly on the implications to the unified computing system.

First off, I do not think there is a lot of innovation that comes directly out of the standards bodies.  However, i firmly believe that in today's mature networking market in order for a technology to get a decent traction and following it must at least be inserted into the standards process and be on a trajectory towards being multi-vendor and open/interoperable.

Secondly, I believe that innovation should be rewarded.  "To the innovator go the spoils" I say.  Innovation is risky, there should be a bit of light at the end of the tunnel.  I am not-so-subtly reminded of a conversation with about 20 customers I led a few months back.  I was getting a lot of pressure from a university customer to stop any development on anything that was not an industry standard- the gentleman from a large manufacturing company interrupted him and said, "I don't care what standard they support, as long as they solve business problems for me I will vote with my wallet. My CIO doesn't care if its PAGP or LACP, he cares that the network runs."

Lastly, and somewhat controversially, I think there are enough tagging formats out there already, and worse: most of them have no interoperability plan or architectural tie-in with each other.

Let's look at VN-Tag with these three lenses now....

1) VN-Tag was jointly developed by Cisco and VMWare to address a problem their customers were having: they could not bind a policy to a VM and have that policy move with the VM in a DRS or VMotion environment.  They also felt that traffic could go from one VM to another, bypassing any network policy for governance or regulatory compliance and thus have a tail-end/hop-off type of attack possibility for VMs on the same physical host.

2) It was submitted to the IEEE, but is not a standard yet, thus to be binary it is 'proprietary' although it seems the companies are not holding onto the IP specifically, they just want to execute on a time-to-market advantage.  (this is no worse and the ongoing CEE vs. DCE debate (note: there both are proprietary...  DCB is the IEEE standard))

3) It is 'yet another' tagging format.  If you trust that MAC addresses will not change dynamically the same problem-set could have been solved by binding network policy to the MAC address of a host.

Was VN-Tag necessary?  maybe...maybe not.   Personally, I think many of the same problems could have been solved if the MAC address was used to instantiate policy.  There is a legitimate concern that the MAC address could be spoofed, but then again so could a multi-byte tag structure too unless it has signing/authentication/etc.

Is it proprietary?  Yes.  Although all indications are Cisco and VMWare are working to shape an industry 'de jure' standard and are trying to gain a time to market advantage over merchant silicon based players. (I would argue that innovation should be rewarded so a time to market advantage in silicon is not out of the question and probably shouldn't be demonized).

Is it well implemented?  Here is the rub of the whole thing.  Implemented broadly this is a promising capability for a network to have.  VM's are, after all, the building block of many leading edge new data centers.  However, VN-Tagging does not seem to be broadly embraced across the portfolio of products in the data center.  At least I can see no indications of shipping products or announcements of how this capability is going to be brought into the security products, application networking products, routing products, rest of the Nexus line, etc.  Broadly implemented in a coordinated fashion- this would be a powerful capability.  Sporadically implemented in one or two products will lead to little impact.
This will probably get flamed a bit, so am finding the nearest asbestos store...dg

the day Altiris was installed... (client retrospective)

When networking was in its hey-day growth phase in the mid-late 1990's through the dot-com crash of 2001 we were a nerdy group of people. We didn't have to worry about change control when the systems were not mission critical, we could use the classic "I tripped over the power cord" emergency change-control procedure. The advanced and automated ticketing systems were not in place, there was only one enable password, and we router jocks loved the fact that we were our own masters of the universe.

The features developed, delivered, and sold by the networking vendors catered to us, the operators, admin, engineers, etc. Think about them- the features we all remember and still tend to use were designed to make our jobs easier, not harder. Features like EtherChannel, speed/duplex auto-negotiation (although for many vendors that was a big #fail), IGRP/EIGRP (turn it on, it just works, for three desktop protocols, on one process!), VTP - okay, we all remember the VTP Bomb, but the concept of auto-propagation of VLAN ID and auto-pruning of unnecessary VLANs was nice although the initial implementation was rather like a liquid-center flourless chocolate cake.

What happened?

Why, since 2001 and the dot-com bust have networking vendors stepped away from supporting and embracing the loyal network operators and delivering features and capabilities that make their jobs easier and simpler and instead seem to focus on things that in many cases make the job harder. I mean, how many encapsulation types do I need? How many differing non-interoperable segmentation mechanisms? How many security tags/constructs/products with little integration? How many differing UIs and code-trains?

I like building things that make peoples jobs easier. It's a personal passion of mine, because they tend to get used and deployed, and heck- they make people happy! (as I write this 'Sweet Child o' Mine' comes on the overhead speakers and I have to pause a minute during one of the most memorable guitar solos ever...) ok, back on track... umm, where was I?

Oh yeah- features that make network operators lives easier?

One I always wanted to do was a global port profile. Basically an object oriented port based configuration that is synced across a reasonably sized autonomous system of network devices. Then I can make changes to the port object and have it sweep across the switches and be swiftly implemented. All the ports map to the object, the object is the point of change. This gets very interesting when it is integrated between physical and virtual devices so that I can have a policy that moves as I execute a P2V operation and maintains consistency regardless of where the workload runs.

Just a thought. I am sure there are more... any other things you wish your network did? (I also wish there were native Opsware agents on my network devices... for more food for thought...)

dg