THANK YOU FOR SUBSCRIBING
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 trump the realities of engineering.
“SPB represents a re-imagining of Ethernet for the 21st Century, while TRILL is simply Spanning Tree overdosing on steroids”
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.
SPB is by far the superior of the two.SPB represents a re-imagining of Ethernet for the 21st Century, while TRILL is simply Spanning Tree overdosing on steroids. 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 uses 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.Implementing this as its Fabric Connect technology, the company has 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)). This fabric technology 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, the fabric remains interoperable with other standards-compliant SPB implementers such as Alcatel-Lucent, Huawei, and even HP.
And that leads 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, network engineers 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.
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.