Dan left an interesting comment on one of my previous blog posts:

It strikes me that the entire industry lost out when we didn’t do SPB or TRILL. Specifically, I like how Avaya did SPB.

Oh, we did TRILL. Three vendors did it in different proprietary ways, but I’m digressing.

TRILL was a zombie the moment VXLAN appeared. TRILL requires new chipsets on every switch in the path whereas VXLAN runs over IP. Apart from slightly shorter packet headers, it provided nothing IP had not had for decades.

SPB was a mess. They couldn’t decide whether to use VLAN tags or PBB header for extra encapsulation, resulting in SPBM and SPBV. In the end, only SPBM remained, but the damage had already been done.

SPB’s development in IEEE (instead of IETF) didn’t help either. The IEEE standardization process reeks of CCITT (remember the guys creating X.25?), it was either hard or impossible to access recent standards (let alone drafts), and they thought everything they created had to look like Ethernet. IEEE went as far as overcomplicating IS-IS to prevent micro-loops because they refused to add a hop count to the data-plane encapsulation¹. In real life, some vendors skipped that part when implementing SPBM, assuming that the networks wouldn’t be bothered (too much) by an occasional forwarding loop (yeah, that sounds reassuring).

The original EVPN required an MPLS data plane, which was a perfect match for service providers already running MPLS. Since the early days of MPLS, you could also run MPLS over GRE, enabling a gradual deployment of MPLS over IP networks. In any case, EVPN was just another service using MPLS LSPs. Adding EVPN to an existing MPLS network was utterly non-disruptive.

Adding VXLAN encapsulation to EVPN was the watershed moment. Finally, you could decouple the end-user services from the transport core network and implement the virtual networks on edge nodes (hypervisors) with no control-plane interaction with the physical network.

SPBM required end-to-end PBB encapsulation and tight integration of edge- and core switches (every switch had to run IS-IS). You could not deploy it gradually on top of an existing bridged network; the network core had to run SPBM. While Avaya eventually added PBB-over-IP (or was it GRE?), that addition was proprietary and too late to matter. VXLAN had already won.

Now for the technical details:

IS-IS, as an interior routing protocol, can handle 1000s routers. We don’t need anything more scalable like BGP unless you’re AWS/Microsoft/Google/Facebook.

I’ve been saying the same thing for years, and intelligent people (including those who designed AWS fabric with OSPF) know that. Only the EBGP-as-better-IGP cargo cult followers think you need² BGP as an underlay routing protocol in a data center fabric.

IS-IS doesn’t need addressing because it’s an ISO protocol. As long as the interface can run Ethernet, an adjacency can form. No IPv4 or IPv6 addresses needed, link-local or otherwise.

IS-IS needs CLNS node addresses to run but does not need layer-3 interface addresses. However, if you want to run your transport services on top of IP (see above), you need IPv6 LLA and (at minimum) IPv4 loopback addresses.

Keep in mind, all this “Interface EBGP Session” stuff is needed to bootstrap all the other stuff we will need: multi-protocol BGP, adjusting the NLRI in BGP, VXLAN-GPO, loopbacks for the VTEPs, routing protocols to coordinate with the devices in the overlay (e.g., firewalls), etc.

The “interface EBGP session” stuff is there only to please the cargo cult followers (or hyperscalers buying Arista and Cisco gear). EVPN using IBGP between loopback interfaces works just fine.

However, you need something to propagate endpoint reachability information between fabric edge devices. My Avaya (now Extreme) friends tell me IS-IS works fine for typical enterprise use cases. Still, I’m pretty sure we would eventually hit some limits of IS-IS LSPs (I wrote about the details almost exactly a decade ago).

Finally, EVPN advertises endpoint MAC addresses in BGP updates, which allows load balancing and ESI-based multihoming. SPBM (like traditional bridging) relies on datapath MAC learning. Comparing EVPN to SPBM is a bit like comparing a boring 4WD family sedan to a roadster³.

As for “routing protocols to coordinate with the devices in the overlay,” that’s the bane of every “disruptive” greenfield solution (including SD-WAN). Life is simple if you limit yourself to VLANs and directly connected IP prefixes. Once you want to integrate your solution with the existing customer network, you must implement routing protocols and two-way redistribution, and your solution becomes as complex as MPLS/VPN or EVPN. For example, (according to my vague recollection of a lunch discussion) Avaya’s SPBM solution had a lovely (proprietary) IP Multicast implementation that worked great as long as the multicast domain was limited to the Avaya fabric and you did not insist on using PIM.