Got this comment to one of my L2-over-VXLAN blog posts:
I found the Avaya SPBM solution "right on the money" to build that L2+ fabric. Would you deploy Avaya SPBM?
Interestingly, I got that same question during one of the ExpertExpress engagements and here’s what I told that customer:
TL&DR: If you’re OK with being locked into a single vendor, Avaya’s SPBM would be a perfect fit. Are you OK with that?
Before going into the details: I love some of the things Avaya did, and most of them make perfect sense. Would I recommend Avaya’s fabric to a customer? I might, after carefully explaining the implications of the rest of this blog post.
Avoiding lock-in (or not)
To be fair, it’s really hard to avoid some sort of lock-in, and you’d be in exactly the same position when considering Cisco’s ACI or FabricPath, Juniper’s Junos Fusion or Virtual Chassis Fabric, or Arista’s CVX/CloudVision.
However, while you can’t avoid some sort of lock-in, you could try to minimize it (if that’s your goal), sometimes trading lock-in for complexity. In this particular example, you could use EVPN over MPLS or VXLAN to get similar results that you’d get with Avaya’s fabric (apart from ease of deploying IP multicast).
EVPN used with MPLS or VXLAN is definitely more complex than running a single routing protocol (IS-IS within SPB) that carries core topology as well as L2VPN and L3VPN address families, but it’s a standard solution, scales beyond a single IS-IS area, and you can deploy it over any MPLS or IP core. Avaya’s fabric (like any of the solutions from other vendors I mentioned above) requires an end-to-end Avaya network.
- SPBM is a standard technology, and you could build a multi-vendor SPBM fabric. However, all the interesting features (IP routing, L3VPN, distributed router functionality) are Avaya’s extensions to SPBM and are currently not implemented by any other vendor (that I’m aware of).
- One might argue that it would be theoretically possible to build a multi-vendor SPBM core and deploy Avaya switches only at the edges. I don’t think that would work in all cases - if I understood their approach, sometimes they need the core switches to set up multicast distribution trees based on Avaya-specific IS-IS information.
Using well-known technologies
Sometimes you have to look beyond technology and consider soft factors, for example readily-available skills. There are zillions of engineers familiar with IP and IP routing protocols, and thousands of engineers familiar with MPLS. Fewer people had in-depth exposure to PBB (SPBM data plane) and only a few have hands-on SPBM experience (not to mention experience with Avaya’s extensions).
Also, all other vendors are moving to L2-over-VXLAN-over-IP with EVPN control plane. It remains to be seen whether that’s a wise technology decision or a lemming reflex, but regardless of implementation differences the skills gained working with gear from Vendor A remain somewhat relevant even if you move to Vendor B. Working in an VXLAN+EVPN environment is thus better for your career prospects than working in an SPBM environment.
There might be a whole alternate universe out there that I’m not seeing that relies heavily on PBB and SPBM. If you happen to be living in that universe and reading my blog please write a comment.
More on VXLAN transport
You could build an Avaya fabric on top of IP fabric using VXLAN as the transport mechanism, but you wouldn’t get line-rate performance (going from PBB to VXLAN encapsulation cannot be done in a single pass through the Broadcom’s Trident-2 chipset), and you’d have an interesting tunneling challenge.
While most VXLAN-based solutions build automatic tunnels based on egress VTEP IP address, Avaya’s SPBM-over-VXLAN solution uses what looks like point-to-point VXLAN tunnels and runs IS-IS on top of them, and is thus ideal when you want to link SPBM islands across an IP core, but not when you’d like to connect edge switches across an IP transport network.
To use or not to use?
Sometimes it makes sense to use a well-integrated proprietary product, particularly if you’re building smaller islands connected to a standards-based core. Sometimes it makes sense to build a network based on open standards that is easily extended with gear from multiple vendors. The choice is yours, and if you need a second opinion beyond the generic thoughts outlined in this blog post, there’s always ExpertExpress online consulting service.