Will the real Ethernet Fabric please stand up…or, are some Vendors playing fast and loose with terminology (again)?

Will the real Ethernet Fabric please stand up…or, are some Vendors playing fast and loose with terminology (again)?

Many will remember the early days of fixed-format Ethernet Switches, when the development of resilient configurations was initiated as an alternative to existing Modular Chassis systems. While we can debate who invented what, and when – SynOptics, 3Com, and even Digital all fielded competing designs – the really significant thing about these solutions is that they were genuinely resilient. All were based on a backbone capability that virtualized what the traditional chassis relied on in hardware. Thus, “stacking” – in a true, resilient, integrated way was born.

Then, along came the pretenders. These were the vendors that wanted to share the spotlight even though they didn’t have anything innovative to bring to the party; even though some only daisy-chained switches, some used Spanning Tree, most consumed relatively low-speed front-panel uplink ports, and most didn’t support QoS. If they could manage two or more interconnected Switches with a single IP Address they wanted to stake a claim. Eventually, everyone claimed to do stacking, which ultimately commoditized and devalued the term. This sad state of affairs is the reason Avaya insists on using the term, “stackable chassis” for our genuine, full-featured technology.

The Software-Defined WAN (SD-WAN) label appears to be taking a similar journey, which again is causing confusion in the industry. Respected industry analyst Zeus Kerravala echoes my sentiments in a blog  discussing his frustration when the aspirations of marketing trumps the realities of engineering.

This is not simply an esoteric debate about the proper names to apply to respective technologies. When the same name is used to market vastly different capabilities, it lays the burden of decoding what’s what on the customers. So, rather than focusing on helping businesses solve specific real-world problems, this exercise in obfuscation just makes matters worse.

We’re seeing the same thing with use of the term, Fabrics – driven, it appears, by the need to ground Software-Defined Network (SDN) offers on some form of Fabric. The logic seems to be that in order to have a credible SDN story you also need to offer a Fabric. While there may be some basis in fact for the logic, it doesn’t automatically translate that any networking solution has the right to call themselves a Fabric.

This is part formal standards definition and part real-world capability. A few years ago, and at roughly the same time, the two main industry standards bodies – the IEEE and the IETF – both established working committees to address the question of Fabric-based networking. The IEEE eventually went with something called Shortest Path Bridging, (SPB, formalized as 802.1aq) and the IETF placed their bet on the rather funkily named Transparent Interconnection of Lots of Links (TRILL, formalized as RFC 6325, et al).

Unsurprisingly, both standards take a very different approach to solving what was meant to be roughly the same problem: creating agile, reliable, and scalable networks that seamlessly complement server/application virtualization in the Data Center, and next-generation networking initiatives at the network edge. In short, a Fabric.

Remembering that this is an opinion piece and not a white paper, I’m going to be unapologetically subjective: SPB is by far the superior of the two. At the risk of over-simplifying things, but in the interests of space and time, I’ll stake the claim that SPB represents a re-imagining of Ethernet for the 21st Century, while TRILL is simply Spanning Tree overdosing on steroids. But, I’ll at least give TRILL the credit of being a standard – indeed, at last count it’s about ten standards – and that’s more than most of these Johnny-come-lately “Fabrics” can claim.

TRILL’s biggest problem is that it’s not a particularly good Fabric technology and nobody seems very interested in implementing it — certainly not in a standards-compliant form. Cisco use a bit of TRILL in their FabricPath offering, while Brocade uses a different part in their Virtual Cluster Switching offering. Neither is pure TRILL and neither is interoperable, but at least they have the right to call their solutions a Fabric…more or less. Juniper took a shot at the Fabric challenge with QFabric, but this went largely unnoticed by the rest of the industry, and certainly by potential customers.

The only Fabric standard that has garnered wide-spread support is SPB. Avaya implements this as our Fabric Connect technology and we’ve been instrumental throughout the evolution of the standard (or, perhaps I should say “standards” as SPB is now standardized by both the IEEE and the IETF (6329)). The Avaya Fabric Connect implementation leverages the native extensibility of SPB to add significant Enterprise-centric capabilities in the areas of integrated L3 Virtualization, L3 Routing, and IP Multicast. However, all the while, we remain interoperable with other standards-compliant SPB implementers such as Alcatel-Lucent, Huawei, and even HP.

And that brings us to the pseudo-Fabrics being touted in the context of SDN. Perhaps answering these questions brings us to a conclusion:

  • Is a networking overlay that adds yet another layer of protocol and complexity – while making some wildly optimistic assumptions about topology, reachability, and failover – really a Fabric?
  • Is something that is limited to the confines of the Data Center, can only be run as a service on a computing platform, or is bottlenecked by a controller really a Fabric?
  • If so, where’s the end-to-end nature, the step-function in agility, scalability, and availability?

While the IEEE does not necessarily hold the mortgage on what is or is not a Fabric and any pioneer is free to innovative to their heart’s content, a pretty authoritative line has been drawn in the sand. There are, quite rightly, well-defined expectations of what constitutes a Fabric. Customers have a right to expect that a “Fabric-based” solution does – in fact – deliver Fabric-centric capabilities. And, crucially, it’s a solution that matches their business needs and expectations.

More and more, we’re seeing people appreciate that a Fabric – a genuine Fabric – is the delivery vehicle for the technological and commercial benefits that businesses desperately crave. After all, it’s not about the protocol, it’s about what it delivers.

To this point, Zeus Kerravala recently posted the “Network of 2020.” Interesting stuff, and it particularly resonates with me because of the clear and consistent alignment with the message that I preach day-in, day-out. I’d recommend that you pay particular attention to those attributes that businesses really need to focus on; those that will enable them to advance faster, avoid forklifts upgrade, and aren’t burdened with high capital investments and hidden operational complexity and cost.

If this has sparked some interest, then it would appear that I’ve done a good day’s work. Many of you already know that I’m pretty passionate about this subject and about what Avaya can offer. However, even if you’re considering alternatives from another vendor, I would simply encourage you to delve into exactly what’s been proposed with a good, hard look at what’s actually behind the top-level marketing message.

For those of you that are more than interested, the good news is that there’s a solution out there taking full advantage of the standardized Ethernet Fabric technology: Avaya SDN Fx™ Architecture is a standardized end-to-end Fabric-centric architecture that solves the challenges left over by decades of legacy multi-protocol client-server networking. It maintains backwards compatibility, while delivering next-generation capabilities; providing a seamless evolution to SDN. And it’s available today.

Do your research. Challenge your vendor to a proof of concept. Don’t buy simply on theoretical benefits and a hope that the future will deliver on the promises of today. Most importantly, make sure that you’re implementing technology solutions that are focused on driving positive business outcomes.