I was very interested to hear from Avaya at Interop New York. They were the company I knew the least about. I knew the most about them from the VoIP side of the house, but they’ve been coming on strong with networking as well. They are one of the biggest champions of 802.1aq, more commonly known as Shortest Path Bridging (SPB). You may remember that I wrote a bit about SPB in the past and referred to it as the Betamax of networking fabric technologies. After this presentation, I may be forced to eat my words to a degree.
Paul Unbehagen really did a great job with this presentation. There were no slides, but he kept the attention of the crowd. The whiteboard supported his message. While informal, there was a lot of learning. Paul knows SPB. It’s always great to learn from someone that knows the protocol.
One of the things I keyed on during the presentation was the way that SPB deals with multicast. Multicast is a huge factor in Ethernet today. So much so that even the cheapest SOHO Ethernet switch has a ton of multicast optimization. But multicast as implemented in enterprises is painful. If you want to make an engineer’s blood run cold, walk up and whisper “PIM“. If you want to watch a nervous breakdown happen in real time, follow that up with “RPF“.
RPF checks in multicast PIM routing are nightmarish. It would be wonderful to get rid of RPF checks to eliminate any loops in the multicast routing table. SPB accomplishes that by using a Dijkstra algorithm. The same algorithm that OSPF and IS-IS use to compute paths. Considering the heavily roots of IS-IS in SPB, that’s not surprising. The use of Dijkstra means that additional receivers on a multicast tree don’t negatively effect the performance of path calculation.
I’ve Got My IS-IS On You
In fact, one of the optimized networks that Paul talked about involved surveillance equipment. Video surveillance units that send via multicast have numerous endpoints and only a couple of receivers on the network. In other words, the exact opposite problem multicast was designed to solve. Yet, with SPB you can create multicast distribution networks that allow additional end nodes to attach to a common point rather than talking back to a rendezvous point (RP) and getting the correct tree structure from there. That means fast convergence and simple node addition.
SPB has other benefits as well. It supports 16.7 million ISIDs, which are much like VLANs or MPLS tags. This means that networks can grow past the 4,096 VLAN limitation. It looks a lot like VxLAN to me. Except for the reliance on multicast and lack of a working implementation. SPB allows you to use a locally significant VLAN for a service and then defined an ISID that will transport across the network to be decapsulated on the other side in a totally different VLAN that is attached to the ISID. That kind of flexibility is key for deployments in existing, non-green field environments.
If you’d like to learn more about Avaya and their SPB technology, you can check them out at http://www.avaya.com. You can also follow them on Twitter as @Avaya.
Paul said that 95% of all SPB implementations are in the enterprise. That shocked me a bit, as I always thought of SPB as a service provider protocol. I think the key comes down to something Paul said in the video. When we are faced with applications or additional complexity today, we tend to just throw more headers at the problem. We figured that wrapping the whole mess in a new tag or a new tunnel will take care of everything. At least until it all collapses into a puddle. Avaya’s approach with SPB was to go back down to the lower layers and change the architecture of things to optimize everything and make it work the right way on all kinds of existing hardware. To quote Paul, “In the IEEE, we don’t build things for the fun it.” That means SPB has their feet grounded in the right place. Considering how difficult things can be in data center networking, that’s magical indeed.
Tech Field Day Disclaimer
Avaya was a presenter at the Tech Field Day Interop Roundtable. They did not ask for any consideration in the writing of this review nor were they promised any. The conclusions and analysis contained in this post are mine and mine alone.
The ‘on all kinds existing hardware’ is mainly the ERS8000 platform, and any newly released switch model (VSPxxxx). You’re SOL if you have other existing models, like the not-that-old ERS5600 (which was/is their 1GbE ToR offering).
I like SPB, but Avaya’s software QC trackrecord has us very wary of software updates, and you need the latest and greatest for the SPB featureset.
In all fairness, the ERS5600 series was introduced in 2008, most switch manufacturers typically build for a 3-5 year product lifecycle. I would not necessarily expect a 5+ year old switch to support a 2 year old standard in hardware unless it had FPGAs instead of ASICs. Avaya seems to have a much better track record than the rest of the industry when it comes to product lifecycle.
always thought, that for 802.1aq no new ASICs are needed at all?
Pingback: The Alignment of Net Neutrality | The Networking Nerd
Pingback: Avaya and the Magic of SPB
Pingback: Avaya SPBM dan IS-IS Infrastructure - Viram Gunawan Yanuar
Pingback: Migrating from FabricPath to EVPN/VxLAN - Gestalt IT