要約

  • RFC 5330は、帯域値ゼロでシグナルされたTE LSPの数を広告する。数えられた主LSPが保護を要求したか、利用可能なdetourやbypassを持つか、故障時に切り替わるかは証明しない。
  • 管理システムで設定・プロビジョニングされたLSPは計数から除外でき、sub-TLVの欠落はゼロではなく情報の欠落を表す。保護率を計算する前に、計数人口と保護人口をそれぞれ再現できなければならない。

一つの分母が二つの台帳を隠した

仮にリンクAが80というRFC 5330値を広告しているとする。画面は80本すべてを「FRR対象」と表示する。理由は単純で、記事や設計文書にゼロ帯域TE LSPとFast Rerouteを組み合わせるモデルが書かれており、実装側が二つの集合を同一視したからだ。

しかし80が表すのは、広告元の計数規則に入り、そのリンクを通り、帯域値ゼロでシグナルされたTE LSPである。各LSPがlocal protectionを要求したか、どのPLRが担当するか、どのdetourまたはbypassに対応するか、バックアップが現在利用可能かは別の台帳に属する。

主LSP人口と保護人口は重なることがある。等しいとは限らない。分母を共有させるには、個々のLSPをキーで結び、時点も合わせる必要がある。

単に80を緑色にすることは、照合ではない。

ゼロなのは予約要求の値

RFC 5330はUnconstrained TE LSPを、帯域がゼロでシグナルされたTE LSPと定義する。このゼロはパケット数、転送速度、重要度、物理容量を測っていない。

文書が想定するモデルでは、そのようなLSPをフルメッシュで展開し、MPLS TE Fast Rerouteによってリンク、SRLG、ノード障害から保護できる。TE metricがIGP metricと同じなら、トラフィックはIGP最短路に従うこともある。

つまり、予約帯域ゼロのLSPは実際のトラフィックを運べる。保護対象にもなり得る。ゼロを「空」と読むと、主経路の負荷もバックアップ側の必要容量も見えなくなる。

カウントが増えたとき、増えたのは広告人口である。必要なバックアップ帯域が同じ比率で増えたとは限らない。減ったときも、トラフィックやリスクが減ったとは限らない。

RFC 4090の保護関係は別に作られる

RFC 4090は、one-to-one backupとfacility backupという異なるローカル修復方法を扱う。前者では保護対象LSPごとのdetourを作る。後者ではラベルスタックを利用し、一つのbypass tunnelが複数のLSPを保護できる。

この違いだけでも、主LSP数からバックアップ数を推定できないことが分かる。80本の主LSPに80本のdetourが対応する設計もあれば、少数のbypassを共有する設計もある。さらに同じ主LSPが各hopで異なる保護状態を持ち得る。

必要な保護receiptには、主LSP識別子、保護対象hop、PLR、merge point、方式、バックアップ識別子、関連づけ時刻、現在状態、共有容量、障害シナリオ、最後の試験を含める。

RFC 5330値はこの関係を運ばない。主人口を数えるfieldに、保護グラフの役割を負わせてはならない。

準備完了は要求済みとも確立済みとも違う

保護の証拠にも段階がある。LSPがlocal protectionを要求したこと、PLRが候補を計算したこと、バックアップがシグナルされたこと、転送状態がインストールされたこと、必要容量が残っていること、対象障害で切替可能なこと、実際に切替が成功したことは同じ事実ではない。

facility backupでは、一つの共有資源が平常時には十分に見えても、相関故障で複数の主LSPが同時に流入すれば不足する可能性がある。SRLGやノード故障は単一リンク故障とは異なる集合を起動する。

したがって「80/80 protected」という表示には、分母の計数契約だけでなく、分子の状態定義も必要だ。要求済みを数えるのか、確立済みを数えるのか、容量検証済みか、試験成功済みか。定義が変われば率も変わる。

緑色の割合は、定義を省略すると最も危険な表示になる。

計数人口はローカルポリシーで変わる

RFC 5330は、管理システムで設定・プロビジョニングされたゼロ帯域TE LSPを報告値から除外してもよいとする。

そのため、主LSPの計数自体が完全なインベントリーとは限らない。保護台帳が管理システム起源のLSPを含み、RFC 5330値がそれを除外すれば、単純な割合は分子と分母で異なる人口を比較する。

逆に、あるソフトウェア版が管理起源を含め、次の版が除外すれば、物理経路も保護関係も変わらないまま「保護率」が跳ねることがある。

人口契約には、プロビジョニング源、対象となるシグナリング状態、make-before-break中の重複、追加・削除の時点、管理起源の扱い、設定とソフトウェアの版、発効時刻が必要である。

保護率を履歴で比べる前に、その契約が連続しているかを確認しなければならない。

欠落は未保護でもゼロ本でもない

Unconstrained TE LSP Count sub-TLVは任意である。RFC 5330は、欠落をリンクについての情報がない状態として解釈するよう求める。

欠落をゼロに変換すると、保護画面では二重の誤りが生じる。主LSPがゼロ本と推定され、保護すべき対象もゼロ本だと推定される。実際には計数が届いていないだけかもしれない。

データモデルは少なくとも、明示的なゼロ、正の値、欠落、不正形式、未対応、未観測を分けるべきだ。欠落中は保護率を算出不能にする方が、完全保護を示すより正確である。

以前の値を保持する場合も、その値の観測時刻と失効条件を見せる必要がある。古い80を現在の分母として扱えば、今度はstaleな確実性を作る。

重複sub-TLVは主人口さえ分岐させる

RFC 5330のtype 23は、IS-ISでは2オクテット、OSPFでは4オクテットの値を持つ。該当コンテナ内で複数回現れてはならず、二つ目以降があれば最初だけを処理する。

一般的なlast-write-winsデコーダが後の値を残すと、ルータが使った主人口と保護プラットフォームが使う分母が違ってしまう。保護関連が完全でも、率の説明は破綻する。

wire receiptにはプロトコル、広告元、リンク、LSAまたはLSPキー、sequence、checksum、取得点と時刻を残す。parse receiptには全インスタンスの順序、位置、長さ、値、選択された最初の項目、無視理由を残す。

IANAの登録はtype 23の意味を合わせる。実際に届いた順序や、特定実装がどの値を使用したかまでは保証しない。

新しい広告は瞬時のインベントリーではない

LSPの追加、移動、削除に合わせて毎回細かく広告すれば、OSPF LSAやIS-IS LSPの洪水量が増える。RFC 5330はorigin triggerを規定せず、変化に対して過度に細かい再生成を避けるよう注意する。

その結果、若いageや新しいsequenceを持つ広告でも、内部のカウントは閾値や時間窓でまとめられている可能性がある。これは規格違反を意味しない。消費者がgranularityを理解する必要があるという意味だ。

保護台帳がイベントごとに更新され、主人口の広告がバッチ更新なら、同じ時刻のように見える二つの集合も観測窓が違う。比較にはlast recompute、trigger policy、aggregation window、許容stalenessを付ける。

既知のchurn中に値が止まっているなら、安定と判定せず、広告粒度と収集経路を確認する。

カウントはアルゴリズムの入力であり、判定結果ではない

RFC 5330は、等コストの候補に対して、集約トラフィックに関する統計的仮定のもとでLSP数を利用できると説明する。一方、具体的な負荷分散アルゴリズムは規格の範囲外である。

同じ数を持つ二つのリンクが同じ負荷を持つとは限らない。Consumerは、人口契約、値とage、他のメトリック、候補、アルゴリズム版、選択、実測結果をdecision receiptに残す必要がある。

自動化がLSPを移動すれば、次のカウントはその介入の影響を受ける。自ら作った変化を独立した成功証拠として扱わないため、decision IDと観測窓も保存する。

故障影響はLSPの先にある

RFC 5330は、リンク故障で影響を受けるゼロ帯域TE LSP数の評価にも値を使えると述べる。しかしLSP数は顧客数でも障害件数でもない。

故障後に必要なのは、実際にその時点でリンクを通ったLSP、運んでいたトラフィックとサービス、適用された保護関係、切替イベント、収束後の転送、損失と遅延、アプリケーション結果である。

保護が成功しても一部パケットが失われることがある。制御面の切替が完了しても、サービスの期限を満たさないことがある。逆に、計数上は多くのLSPが影響対象でも、実トラフィックが少ない時間帯なら顧客結果は限定的かもしれない。

RFC 5330値は調査の優先順位を付ける。結果を先取りしない。

緑色にする前に七つのreceiptを結ぶ

運用判断は段階的に作るべきだ。まずwire receiptで何が届いたかを保存する。parse receiptで何を選んだかを保存する。count receiptで存在状態、値、origin time、観測時刻とageを保存する。population contractで含有・除外規則を説明する。

次にLSP receiptで実際のパスと状態を確認する。traffic receiptで時間窓ごとの負荷を測る。protection receiptで主備関係、方式、準備状態、容量と試験を保存する。最後にdecisionとimpact receiptで切替、転送、サービス結果を閉じる。

共通コードポイント、標準文書、ローカル設定、実行状態、結果は別の現実層である。文書は共通語を作る。実装は選択を行う。観測が動作を証明する。結果はさらに後で測る。

その順番を守れば、LSP数は有用な入口になる。守らなければ、主経路の一覧が存在しないバックアップへの保証書に変わる。

情報源