8

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

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

0
13

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.

5

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.

0
1

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.

-2

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.

5
  • Firstly TRILL doesn't require L3 connectivity, it operates at L2 just like SPB. Hop count is a control plane concept and the control plane is run on the switch CPU, this has nothing to do with ASICs. May 12 '13 at 11:06
  • TRILL does however use a new encapsulation which means that only newer switching ASICs will be able to support this technology while SPB can be supported on older hardware. As both protocols are interoperable with legacy STP implementations this may or may not influence your selection May 12 '13 at 11:14
  • @DaveTucker, you're quite right, TRILL doesn't need L3, what I was thinking and what I wrote for that are at odds. However, Rbridges DO implement a TTL when interoperating (as opposed to being connected to a standard 802.1 switch) - that's very much NOT control plane
    – Olipro
    May 12 '13 at 11:44
  • you are right that TRILL allows temporary loops through the use of the Hop Count field which is carried in the TRILL Header, a terminology error on my part. It is the TRILL header though that drives the requirement for new ASICs. I can't agree with your assessment that L3-like forwarding is "costly" in terms of hardware. There are switching ASICs available today that implement TRILL. May 12 '13 at 12:21
  • it is in a relative sense; the hardware required for L2 forwarding is markedly cheaper than L3 - maybe you consider the overall price "cheap" still, not everyone does.
    – Olipro
    May 13 '13 at 4:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.