要約

  • Transport Class IDは運用者が定義する32ビットのColorであり、ローカルな分類を識別するが、SLAの内容そのものは符号化しない。
  • TEAのColor sub-TLV、BGP CTのTransport Class RT、サービス経路のColorが共存する場合、RFC 9832はこの順で具体的なスコープを優先する。
  • TRDBへの取り込み、次ホップ解決、フォールバック、FIB実装、パケット転送、SLA達成は連続した別状態である。

数字にはサービス定義が入っていない

RFC 9832のTransport Classは、単一の管理ドメイン、または緊密に協調するドメイン内で、十分に似たTE特性を持つと運用者が判断したトンネルの集合である。RSVP-TE、SR-TE、Flex-Algoなど、仕組みが違っても低遅延、保護、特定ノード回避といった目的でまとめられる。何を「十分に似ている」とするかは実装と運用の責任だ。

識別子は32ビットで、Colorとも呼ばれる。0はBest Effort用、1以上はPrivate Useである。したがって100という値に普遍的な意味はない。あるASでは低遅延、別のASでは異なる遅延上限や保護条件を含む可能性がある。同じ数字は、同じ測定窓、損失予算、障害時動作を証明しない。

必要なのは、Colorとともに、起源ドメイン、定義、所有者、適用範囲、版を保存することだ。数字だけを抽出すると、ローカルな設定を世界共通の契約へ誤変換してしまう。

優先順位は結果だけでは監査できない

Colorは異なる運搬体に入る。Tunnel Encapsulation AttributeのColor sub-TLVは特定のカプセル化に近い。BGP CT経路のTransport Class RTは、経路をTRDBへ取り込むRoute Targetであり、Resolution Schemeを選ぶMapping Communityにもなる。サービス経路のColor Extended Communityはオーバーレイ側の要求を示す。

7.10節は、TEAのColor sub-TLV、BGP CTのTransport Class RT、サービス経路のColorという順に優先する。これは曖昧さを決定可能にする規則であって、入力を捨ててよいという規則ではない。

監査記録には、受信したすべてのColor、属性の種類、ピア、適用したポリシー版、勝った値を残すべきだ。「effective color=100」だけでは、TEAの変更がサービス側の指定を上書きしたのか再現できない。

TRDBは転送完了証明ではない

各Transport Classには論理的なTransport Route Databaseがある。BGP CT経路はRD:endpoint、Transport Class RT、MPLSラベルまたは同等の識別子を運ぶ。ローカルにクラスが用意されていれば、RTのRoute Target役が取り込み先TRDBを決める。

RFCはTRDBを制御面の次ホップ到達性だけに使う表として実装できると明記する。中のトンネル経路は、次ホップ解決に使われない限り転送面の占有を必要としない。正しい表に経路があることと、サービスがそれを使い、ハードウェアに実装されたことは別だ。

Mapping CommunityはローカルのResolution Schemeを一つ選ぶ。Schemeは単一、または順序付きのTRDB列である。次ホップに対して最長一致を行い、前の表にendpointがない場合だけ次の表を使う。対応するSchemeがなければBest Effortが使われる。Mapping Community自体がなければ同様にBest Effortで解決し、BGP CT経路はクラスTRDBには追加されない。

到達性を保つ既定動作は有用だが、契約クラスが失われたことを隠す可能性がある。

フォールバックの理由を残す

二番目のTRDBが一致したという事実は、一番目が失敗した理由を示さない。トンネル障害、import policy、RTCフィルタ、endpoint誤り、クラス設定のずれ、転送技術の不一致などが考えられる。RFCは検索順を決めるが、原因を認定しない。

解決記録には、受信経路、ピア、Color属性、実効Mapping Community、Scheme版、TRDB順序、一致した表、endpoint、選択トンネル、fallbackフラグが必要だ。どの表にも一致がなければ経路はunresolvableになる。Best EffortのBGP CT経路が利用不能なら、それ以上伝播してはならない。

Route Target Constraintも経路の有無を左右する。外向きフィルタ作成では、同じRTC prefixのEBGP経路をbest pathだけでなく複数考慮する必要がある。届かなかった経路をトンネル障害と断定する前に、配布過程を確認しなければならない。

境界は数値を変換するだけだ

Color空間が一致しない例では、サービスのcolor:0:100500は維持される一方、各ドメインで500、300、100のTRDBに結び付けられる。境界ルータはTransport Class RTを500から300、300から100へ書き換える。

隣接ドメインごとに協調できるため、サービス層へ世界共通のColor表を強制しない設計だ。しかしローカルRTが証明するのは取り込み命令であり、両側のSLA同一性ではない。受信RT、送信RT、双方の定義、相互接続合意、ポリシー版、実行ノード、時刻、ロールバックを一緒に保存する必要がある。

FIBの先にも証拠がある

MPLS境界ノードがnext hop selfでBGP CT経路を再広告すると、新しいラベルを割り当て、受信ラベルをswapまたはpopして解決済みトンネルへ送る転送経路を入れる。BGP CT経路を制御面ピア用に選択的にFIBへ入れる実装も許される。

それでもハードウェアエントリ、共通カプセル化、実パケットを確認しなければならない。RFCの相互運用例では、MPLS専用ノードとSRv6専用ノードの間に共通転送技術がなく、受信したBGP CT経路は利用不能のままになる。

最後はサービス境界で、損失、遅延、可用性、保護切替、測定期間を測る。Color一致はSLA受領書ではない。RFC 9832はExperimentalであり、公開は採用や性能を示さない。現在のVerified erratum 8583は3か所のSN1をSN11へ直す編集上の訂正である。

Heng Luの「Internet is colorless」という視点は、ラベルではなく運用者にとって実際に働く効率で評価せよという原則として読める。Running-Code Primacyは属性、ポリシー、FIBの再現を求め、Reality Layersは識別子、行政的意味、制御面、転送、顧客結果を分離する。これはBTWの編集視点であり、IETF要件の追加ではない。

出典