データセンターの切り替えとTRILLに関する質問

2つのデータセンターの相互接続で、TRILLは長期的なソリューションですか？

Cisco（FabricPath）のTRILL実装は他のメーカーと相互運用できますか？

私が知っている3つのTRILLっぽい実装があります。

• シスコのFabricPath-正しいルーティングプロトコル（IS-IS）、間違ったカプセル化形式。
• BrocadeのVCSファブリック-正しいencap形式、間違ったルーティングプロトコル（FSPF）。
• HPからのTRILL-OKのようです

したがって、現時点ではベンダー間の相互運用性はゼロです。

そして、他の人が言ったように-誰かが私の頭に銃を構えてL2 DCIをするように言った場合、私は最初にOTV（ASR 1Kでも利用可能）を使用しようとしますが、失敗すると、TRILLは2番目に恐ろしいオプションになります。

あなたがL2 DCIについて話していると私が思う質問に基づいて...それは多くの理由で「悪い方針」としてかなり広く受け入れられています。

しかし、これらの理由のいずれも気にしないと仮定すると、FabricPath！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がそれをカットしないため、ハードウェアの面で非常にコストがかかります。

より良い解決策（私の意見では、追加する必要があると思います）は、IEEEではなくIEEEによって開発された802.1aq AKA SPBまたはShortest Path Bridgingです。SPBの主な利点は、TRILLとは異なり、レイヤー3を必要としないことです。動作するためのハードウェア転送機能のような。この点で、FabricPathはプレーンな古いイーサネットの上にまだ存在しているため、TRILLよりもSPBに似ています。

結果として、SPBはベンダーによって採用される可能性が高いプロトコルであり、MSTが今日のように広く相互運用可能であるという点で優れていると思います。