Daniel Dib tweeted about an old comment of mine a few days ago, adding¹:

Not surprisingly, that was bound to upset a few people, and Roman Dodin quickly pointed out the EVPN interoperability tests:

Roman is absolutely correct. Vendors have been running EVPN interoperability tests for years, and recent results showed surprising levels of interoperability. Considering Daniel’s original scenario, you could also build a fabric where the spine switches run just an IGP, so you’d get almost guaranteed interoperability, but I’m digressing.

Looking back, vendors had been running OSPF or SIP interoperability tests for years², and still, it took a long time for the technology to stabilize enough for people who love not being on a frantic conference call with a network-down situation to start building multi-vendor solutions with those technologies³.

You see, there’s a fundamental difference in perspective if you consider multi-vendor interoperability as a runner-up box builder or a network builder using other people’s boxes. I understand that vendors get upset when people like Daniel or myself say, “I see no reason why I would make my life harder building a multi-vendor EVPN data center fabric,” however, it’s hard enough being the QA department for a single vendor⁴, let alone being an interoperability test bed and QA department for multiple vendors. It took some vendors years to get the VXLAN/EVPN gear they were selling to the point where it could be safely used in production networks. Why should we believe they’re doing a better job with multi-vendor interoperability?

Now for a slightly more nuanced perspective. Roman also argued that there’s a difference between EVPN services and MC-LAG and he’s absolutely correct.

However, due to the influence of PowerPoint creators and EVPN gospel spreaders on people who prefer believing vendors instead of doing their own research, every time someone mentions MC-LAG, a LinkedIn Engagement Farmer Thought Leader inevitably writes a comment saying “you should use EVPN ESI, that’s a standard” without realizing it takes more than the engine (EVPN ESI) to build a car (a solution in which two boxes pretend to be one). Some other parts of MC-LAG solutions are standardized (ICCP), while others are not. Yet you need all of those building blocks if you want to build a link aggregation group with member links connected to different devices. Stick to MC-LAG movement⁵ is not slowing progress but pointing out the inevitable reality⁶ to people who think a sprinkle of unicorn dust (EVPN ESI) solves a complex technology challenge.

I don’t care if some vendors believe they should implement MC-LAG with EVPN ESI technology while others think they should use anycast IP. It’s the vendors’ job to ensure the two types of solutions are interoperable in large fabrics, but that still wouldn’t persuade me to build a data center layer-2 domain⁷ with boxes from two vendors. Carrier Ethernet networks are a different story⁸, but even there, one should keep all endpoints of a link aggregation group connected to the same type of boxes for consistency reasons.

Last but not least, this saga proves vendors learned nothing from the OSPF debacle of the mid-1990s:

• The development of the EVPN RFCs was mostly vendor-driven (because nobody else would pay top-notch engineers to waste dedicate their time to arguing about the number of angels dancing on virtual pins).
• As usual, most parts of the EVPN standards were made optional because nobody in their right mind would agree to have something they haven’t implemented yet be MANDATORY.
• Vendors decided to implement different subsets of the EVPN standards and used standards in different creative ways, creating the whole interoperability mess in the first place.
• Don’t get me started on the crazy ideas of running IBGP over EBGP because (A) EVPN was designed to be used with IBGP and IGP, and (B) EBGP-as-IGP craze took over in the meantime.
• Rushing to market with broken implementations didn’t help build the end-user confidence either.

So, if you’re working for a vendor, don’t complain when old-timers like Daniel and myself say, “I love quiet evenings and would try to avoid multi-vendor fabrics as much as possible.” I know most of you weren’t there when this particular complexity sausage was being made. Still, your company might have helped create that sentiment in the first place (probably not starting with EVPN), and unfortunately, you have to share the consequences. However, I agree that (A) EVPN is probably the way to go if one wants to build layer-2+3 VPNs, and (B) interoperability matters, so please keep up the good fight!