Questions about datacenter switching and TRILL

Question

In a interconnection of two datacenters, Is TRILL a long-term solution ?

Is the TRILL implementation of Cisco (FabricPath) interoperable with other manufacturer ?

Answer 1

There are three TRILL-ish implementations out there that I'm aware of:

• FabricPath from Cisco - correct routing protocol (IS-IS), wrong encap format;
• VCS Fabric from Brocade - correct encap format, wrong routing protocol (FSPF);
• TRILL from HP - seems to be OK

So there is at the moment ZERO inter-vendor interoperability.

And as others said - if someone held a gun to my head and told me to do L2 DCI, I would try to use OTV first (it's also available on ASR 1K), failing that, TRILL would be second least horrible option.

Answer 2

Based on the question I assume you're talking about a L2 DCI...which is pretty widely accepted as a "bad policy" for a multitude of reasons.

BUT assuming you don't care about any of those reasons a good place to start is by saying that FabricPath != Trill. Just like STP != PVSTP and MST/RSTP != RPVST. It's Cisco's proprietary version of what TRILL might deliver, but it is not TRILL. Thus making it inoperable with other vendors.

If someone had a gun to my head and told me to implement a L2 DCI I would use several geographically diverse links and bond them where I can. You might could get away with TRILL if you have devices that actually support the standard.

Answer 3

With regard to whether TRILL is a viable DCI technology, I'm not sure. When I last checked the TRILL WG wasn't chartered to work on cross data center TRILL solutions although the following draft shows what such a solution "could" look like draft-aldrin-trill-data-center-interconnect-00

Increasing the size of the TRILL domain has some scalability issues (nickname exhaustion to name one) and also increases the size of the failure domain. For DCI I would look at some of the more tried/tested models (VPLS for example) and I'd be tempted to leave each DC in it's own TRILL domain.

Answer 4

TRILL strikes me as something that is barking up the wrong tree; it's costly in terms of both system resources and the complexity of hardware required to support it since it requires a total do-over of a switch architecture from the usual 802.1 standards to the new "RBridge" which totally redefines the behaviour one would be accustomed to from Ethernet frames: for example, your L2 forwarding hardware now has to care about a hop count, making L2 behave more like L3, this is quite costly in terms of hardware since a plain old switching ASIC won't cut it.

A better solution (in my opinion, I should add) is 802.1aq AKA SPB or Shortest Path Bridging - developed by the IEEE rather than the IETF, the primary benefit of SPB is that, unlike TRILL, it doesn't require Layer 3-like hardware forwarding capabilities in order to operate. In this respect, FabricPath is more akin to SPB than TRILL since it is still sitting on top of plain old Ethernet.

As a result, My bet is that SPB is the protocol that's more likely to be picked up by vendors and have a better shot at being widely interoperable in the way that MST is today.