要約

  • Stefan Wahlによると、彼が取り上げたIXPディレクトリは今も「単一のピアリングLAN」と「参加者ASN・ポート」の組み合わせを基本にしている。
  • 同じ交換拠点に複数のサービスがあると、各サービスの識別子がないため、許可プレフィックスや信頼設定、フィルターの適用先まで曖昧になる。

ディレクトリ上のIXPは一行で済む。ラックの中身はそうはいかない。RIPE 92でWahlは、単一のピアリングLANを前提とするモデルと、現在の運用を対比した。現場には遠隔ピアリング、クラウド接続、ホスト型キャッシュ、複数ASN、レイヤー2と3をまたぐサービスがある。

Route128のCTOでEuro-IX理事のWahlは、サンフランシスコの例を挙げた。ある交換拠点ではレイヤー3のサービスがレイヤー2のピアリング網と併存し、二つのVRFを介して両者の間に経路ができる。彼はこれを「Layer 2.5」と呼んだ。ディレクトリにはこのサービスをそのまま記述する場所がなかった。Wahlの説明では、これは将来案ではなく、すでにトラフィックを運んでいる構成だ。

サービスが複数あると、交換拠点全体に付けた一つのラベルでは足りない。どのサービスがどのプレフィックスを受け入れるのか。どのroute serverや接続点につながるのか。IRRの情報源やRPKIの信頼設定はどのサービスに適用されるのか。ディレクトリが「参加者がIXPに接続」としか記さなければ、下流の自動化は書かれていない境界を推定することになる。

Wahlの提案は、ディレクトリとAPIの双方で使えるサービス語彙と識別子を設けることだ。フィルターと信頼設定をサービス単位で結び付ける。IPv6-onlyのファブリック、link-localアドレス、VLANごとのプレフィックス上限も、共通フィールドに収まりにくい項目として挙げた。

ディレクトリ同士の統合、運用慣行の置き換え、リアルタイム検証器の構築を求めたわけではない。現場の構成状態と参加者の意図は、引き続き運用ツールが扱う。作業部会に残された問いは、各サービスに安定した公開上の住所を与えるか、それとも各クライアントに境界の推測を任せるかだ。RIPE 92の記録には提案と質問が残るが、採択や実装日程は記されていない。

出典