我知道有三种 TRILL-ish 实现：

• 来自 Cisco 的 FabricPath - 正确的路由协议 (IS-IS)，错误的封装格式；
• Brocade 的 VCS Fabric - 正确的封装格式，错误的路由协议 (FSPF)；
• 来自 HP 的 TRILL - 似乎没问题

因此，目前零供应商间互操作性。

正如其他人所说 - 如果有人用枪指着我的头并告诉我做 L2 DCI，我会首先尝试使用 OTV（它也可用于 ASR 1K），否则，TRILL 将是第二不可怕的选择。

基于这个问题，我假设您在谈论 L2 DCI……出于多种原因，它被广泛接受为“糟糕的策略”。

但是假设您不关心这些原因中的任何一个，一个好的起点是说 FabricPath != Trill。就像 STP != PVSTP 和 MST/RSTP != RPVST。这是 TRILL 可能提供的思科专有版本，但它不是 TRILL。从而使其无法与其他供应商合作。

如果有人用枪指着我的头并告诉我实施 L2 DCI，我会使用几个地理上不同的链接，并尽可能地将它们连接起来。如果您有实际支持该标准的设备，您可能会使用 TRILL。

关于 TRILL 是否是一种可行的 DCI 技术，我不确定。当我上次检查时，TRILL WG 没有被特许从事跨数据中心 TRILL 解决方案，尽管以下草案显示了这样一个解决方案“可能”的样子draft-aldrin-trill-data-center-interconnect-00

增加 TRILL 域的大小会带来一些可扩展性问题（昵称耗尽），也会增加故障域的大小。对于 DCI，我会查看一些经过多次尝试/测试的模型（例如 VPLS），并且很想将每个 DC 留在它自己的 TRILL 域中。

TRILL 让我印象深刻，因为它正在吠叫错误的树；就系统资源和支持它所需的硬件的复杂性而言，它的成本很高，因为它需要从通常的 802.1 标准到完全重新定义人们习惯的行为的新“RBridge”对交换机架构进行全面改造来自以太网帧：例如，您的 L2 转发硬件现在必须关心跳数，使 L2 的行为更像 L3，这在硬件方面非常昂贵，因为普通的旧交换 ASIC 不会削减它。

更好的解决方案（在我看来，我应该补充）是 802.1aq AKA SPB 或最短路径桥接 - 由 IEEE 而不是 IETF 开发，SPB 的主要好处是，与 TRILL 不同，它不需要第 3 层-像硬件转发功能，以便操作。在这方面，FabricPath 比 TRILL 更类似于 SPB，因为它仍然位于普通的旧以太网之上。

因此，我敢打赌，SPB 是最有可能被供应商采用的协议，并且在像今天的 MST 那样具有更广泛的互操作性方面有更好的机会。