要約

  • 入口LSRは適切なパケットフィールドをフローキーとして選び、負荷分散関数を実行してELを得る。転送LSRはラベルスタックの値を使い、ペイロードを深く調べずにECMPまたはLAGの選択へ利用できる。
  • ELはフォワーディングラベルではなく、シグナリングされるものでもない。ルート作成、経路確立、ポリシー変更、新しいLSPを許可しない。予約値7のエントロピーラベル指示子（ELI）はELの直前に置かなければならず、挿入時にはスタックが2エントリー増える。
  • 機能利用には能力の前提がある。出口がトンネルについてエントロピーラベル能力を広告し、入口がELI/ELを挿入するか判断する。能力を持つ出口は、両方を含むパケットと含まないパケットを扱えなければならない。RFC 7447はRFC 6790のBGP ELCAを非推奨とし、現在の一般的なシグナリング機構として扱えない。
  • RFC 8012は、ELを使うECMPを調べるため、LSPおよびPW ping/tracerouteにエントロピー対応のマルチパス情報とフラグを加える。ただし、拡張方式のエンドツーエンド対応を検証することは範囲外である。

仕組みの境界

ELの値は予約ラベル範囲0から15に入れてはならない。ELIは予約値7を使い、下流ノードがELをアプリケーションラベルと区別できるようにする。EL自体に転送の意味はなく、暗号学的なセキュリティ制御でもない。この設計はELIとELという2つの追加スタックエントリーと引き換えに、FECごとの制御プレーンおよびフォワーディング状態の増加を抑える。フローを別々の経路へ移すとジッター、遅延、パケット再順序化が起こり得るため、フロー単位の一貫性が目的となる。

これは障害検知ではない。BFDは到達性の状態を変えるが、ELはフローごとのハッシュ入力を公開するだけである。BGPの経路広告、検証、伝播、セッション動作を扱う話でもなく、すでに選択されたトポロジー内のMPLSデータプレーン分散の話である。HTTP Priorityはアプリケーション要求の緊急度を表し、ELは転送ノードに不透明な負荷分散用エントロピーを渡す。MP-DCCPは新しいサブフローを認証・受け入れするが、RFC 6790は経路を受け入れたり認証したりせず、MPLSラベルスタック上で動作する。

運用上の判断経路

  1. 対象トンネルについて、出口の能力広告と、入口・転送・出口のELI/EL処理の合意を確認する。能力広告を経路の許可と解釈しない。
  2. ラベルスタックの深さ、装置の上限、混在実装、OAM処理を棚卸しする。単一のハッシュアルゴリズム、フローキー集合、運用しきい値、展開順序をRFCは指定していない。
  3. 経路ポリシーを変えない対照条件で、限定した戻しやすいフローを選ぶ。フロー内の安定性、ECMP/LAG分布、遅延、再順序化を確認し、結果を普遍的な改善率として書かない。
  4. RFC 8012のエントロピー対応ping/tracerouteでマルチパス情報を要求し、どのノードがEL、IP、その他のラベルを使ったかを記録する。成功しても全ノードの拡張方式対応や、全トラフィックが測定された全経路を通ることは証明しない。
  5. スタック深度、相互運用性、可観測性が許容できなければELI/ELを挿入しない。粗いラベルハッシュ、可能な場合の深いヘッダー検査、その他の既存方式へ戻せるが、どれも経路権限を委譲しない。

検証フィクスチャ

  • スタックフィクスチャ：ELI（ラベル7）の直後にELが来るパケットと、両方を持たないパケットを作る。ELが0–15以外であること、挿入で2エントリー増えること、能力を持つ出口が両形式を処理することを確認する。
  • 一貫性フィクスチャ：組織が実際に定義した同じフローキーを繰り返し使って対応経路を観察し、定義済みのキーを一つ変えた場合と比較する。RFCは唯一のキー集合やハッシュ方式を規定しないため、実際の選択を記録する。
  • 経路フィクスチャ：RFC 8012のエントロピー対応LSP/PW pingとtraceroute、および対応するフラグでマルチパス情報を要求する。結果を各転送ノードのEL、IP、その他のラベルによる選択と照合するが、エンドツーエンド対応の証明とはしない。
  • 否定フィクスチャ：挿入前後のルート、LSP、ポリシー状態を比較し、ELによる新しいルート、新しいLSP、ポリシー変更がないことを確認する。BFDの状態は別に記録し、障害とエントロピー分布を混同しない。

RFCは現在の普及率、統一された利用率向上、事故削減率、運用しきい値、展開順序を定めていない。均一に見えるエントロピー値も、ルーティングポリシー、容量計画、障害復旧が正しいことを示さない。

出典