概要

  • Ketan Talaulikar が IETF で行った共同作業の記録は、3 つの関連する運用上の主題への人物レベルの経路を提供します。RFC 9256 における SR ポリシーの識別子と候補パスのルール、RFC 9552 における BGP-LS トポロジーレコードの記述子とエラー境界、RFC 9513 における OSPFv3 による SRv6 ロケーターとケーパビリティの可視性です。
  • これらの仕様は、異なる種類の証拠を定義します。ポリシータプルはヘッドエンドで意図されたポリシーを識別し、候補パスの状態は使用可能な代替を記録し、BGP-LS はコンシューマ向けにトポロジーオブジェクトを記述し、OSPFv3 は SRv6 に関するルーティング情報を公開します。これらの記録のいずれも、それ自体では、実行中の実装が生成したパケットパスを証明するものではありません。
  • したがって、運用契約は階層化されています。標準はセマンティクスを定義し、実装はそれらを実現し、オペレーターはポリシーを選択し、コントロールプレーンは現在の記録を公開し、転送観測は結果を示します。信頼性の高い自動化は、これらの層のいずれかがネットワーク全体であると見なすことなく、それらをリンクし続けます。

運用上の意味を中心に整理された人物レベルの記録

Ketan Talaulikar の IETF Datatracker プロファイルは、ルーティングエリアのリーダーシップとルーティングプロトコルに関する継続的な作業を記録しています。ここで検討する 3 つの標準は、彼を編集の役割で挙げており、それらの技術的主題との明確な人物レベルのつながりを作り出しています。RFC 9256 はセグメントルーティングポリシーのアーキテクチャを定義します。RFC 9552 は、BGP-LS がリンクステートおよびトラフィックエンジニアリング情報を配布する方法を定義します。RFC 9513 は、OSPFv3 拡張を定義し、SRv6 ロケーターおよびケーパビリティ情報をルーティングシステムで可視化します。

その帰属には慎重な境界が必要です。各 RFC は、複数の著者または編集者、ワーキンググループでの議論、レビュー、実装経験、および標準化プロセスによって形成された共同 IETF 作業です。この記録は、Talaulikar の文書化された参加に対するクレジットを裏付けます。それは、彼が単独でメカニズムを発明したり、オペレーターのポリシーを選択したり、特定の実装を作成したり、展開を制御したりしたという主張を裏付けるものではありません。また、顧客、インシデント、商業的成果、または測定された改善に関する主張の根拠も提供しません。

これは英雄的な伝記ではなく、運用上のストーリーです。自動化が安全に行動できるのは、対象オブジェクト、最新の記録、有効な代替、および入力が使用できなかった場合に何が起こったかを判断できる場合のみです。Talaulikar の帰属する標準記録がここで重要なのは、抽象的な意図がプロトコルの状態にならなければならないポイントで、ポリシー、トポロジー、およびケーパビリティを接続するからです。

崩してはならない 5 つの層

最初の層は標準です。標準は、SR ポリシーの識別方法、候補パスとの関係、BGP-LS レコードがトポロジーを記述する方法、OSPFv3 が SRv6 情報を運ぶ方法など、共有セマンティクスを定義します。それは、独立した実装間の契約を提供します。特定のネットワークでポリシーをインスタンス化したり、ビジネス目標を選択したり、パケットが到着したかどうかを報告したりするものではありません。

2 番目の層は実装です。ソフトウェアは、仕様をパーサー、データ構造、選択ロジック、プログラミングインターフェース、および運用出力に変換します。実装は標準に準拠しつつも、サポートされているオプション、容量、診断、リリース動作、および欠陥において異なる場合があります。RFC の存在は、特定のソフトウェアビルドがすべてのメカニズムをサポートしていることやすべての制限を正しく処理することを証明できません。

3 番目の層はオペレーターポリシーです。オペレーターは、自身の環境でどの色に意味があるか、どのエンドポイントが重要か、どの候補パスが存在すべきか、どの優先度を適用すべきか、どのトポロジーコンシューマが行動できるか、そして障害をどのように封じ込めるべきかを決定します。これらの決定は標準によって提供されるものではありません。それらは、構成と自動化を通じて表現されるローカルなガバナンスの選択です。

4 番目の層は現在のコントロールプレーンの状態です。これには、ヘッドエンドで現在認識されている SR ポリシーと候補パス、コンシューマが現在利用可能な BGP-LS レコード、現在リンクステートデータベースにインストールされている OSPFv3 アドバタイズメントが含まれます。これらの記録は時間に依存します。古い状態に結びついた正しく定義された識別子でも、自動化を誤った方向に導く可能性があります。

5 番目の層は観測された転送です。これは、実行中のシステムが行ったことの証拠です。どのネクストホップとセグメント指示がプログラムされ、どのパケットがどのパスをたどったか、更新またはエラー後に動作がどのように変化したかです。転送観測は標準や記録を置き換えるものではありません。意図された連鎖が実行に達したかどうかをテストします。信頼性の高いシステムは、5 つの層すべての間の区別を保持しながら、ある層から次の層に移るのに十分な相関関係を保持します。

RFC 9256 は 3 部構成のポリシー識別子から始まります

RFC 9256 は、SR ポリシーをヘッドエンド、カラー、エンドポイントのタプルによって識別します。そのタプルの簡潔さは重要です。「低遅延パスを使用する」といったフレーズを、スコープを決定できるオブジェクトに変換します。ポリシーは単なる望ましい特性ではありません。それは、特定のヘッドエンド、特定のカラー、特定のエンドポイントに関連付けられたポリシーです。

各コンポーネントは異なる種類のあいまいさを防ぎます。ヘッドエンドは、ポリシーがインスタンス化され、そこへのステアリングが行われる場所を識別します。カラーは、合意されたコンテキスト内で、トラフィックまたはルーティング情報とポリシー目的の間の関連付けを提供します。エンドポイントは、セグメントリストがトラフィックを運ぶことを意図している宛先にポリシーを固定します。いずれかのコンポーネントを削除すると、異なる所有者、入力、または運用上の影響を持つ可能性のあるオブジェクトがマージされるリスクがあります。

タプルは識別子であり、完全な動作記述ではありません。どの候補パスがアクティブか、どのセグメントリストがプログラムされているか、計算に使用されたトポロジーが最新か、または転送が選択されたパスと一致しているかどうかは明らかにしません。それらは関連する記録です。タプルをシステム全体の証明として扱うことは、識別子を状態に、状態を結果に崩すことになります。

ここではスコープ付きの一意性が重要です。自動化は、同じスコープで区別できない 2 つのポリシーオブジェクトを作成し、文書化されていないタイブレークに依存してはなりません。また、あるカラーがすべてのヘッドエンドですべての管理環境で同じ意味を持つと想定することも避けなければなりません。識別子の有用性は、その部分が明示的であり、そのスコープを記録できることにあります。RFC 9256 は共有アーキテクチャを提供しますが、実装とオペレーターは、構成、配布、選択、観測を通じてその識別子を正確に保持する必要があります。

ヘッドエンドは識別子をローカルな責任に変えます

ヘッドエンドは、ポリシーキーの単なるラベルではありません。それは、SR ポリシーが実行可能なローカルオブジェクトになるポイントを示します。そのノードはポリシーを維持し、利用可能な情報に従って候補パスを解決し、使用可能なセグメントリストをインストールし、適格なトラフィックをステアリングします。他のノードは結果の指示を転送するかもしれませんが、それによって同じポリシー決定を所有することにはなりません。

このローカルな責任は、「ネットワークにはポリシーがある」というフレーズが監査できないほど曖昧になるのを防ぎます。2 つのヘッドエンドは、同じカラーとエンドポイントを使用しながら、異なるトポロジービューを持ち、異なる候補パスを受信し、異なるセグメントリスト制限をサポートし、異なるオペレーター制御を適用する可能性があります。それらのポリシー識別子は、ヘッドエンドがタプルの一部であるため、区別されたままです。したがって、自動化システムは、どのポリシーが意図されているかだけでなく、それがどこに存在することが意図されているかを問い合わせる必要があります。

この区別は転送の証拠にまで及びます。コントローラーはポリシーが配信されたと報告するかもしれません。ヘッドエンドは候補がアクティブになったと報告するかもしれません。転送プレーンはプログラムされたセグメントリストを示すかもしれません。トラフィック観測はパケットが実際にそれをたどったかどうかを示すかもしれません。これらは連続した証拠の断片であり、交換可能な確認ではありません。ヘッドエンドを識別子に含めることで、RFC 9256 はオペレーターに、単一のレコードにグローバルな権限を与えることなく、それらを関連付けるための安定したポイントを提供します。

カラーは普遍的な命令ではなく連想を作成します

カラーはしばしばタプルの中で最も過剰解釈を誘う部分です。それはルートまたはトラフィッククラスを意図されたポリシー特性に関連付けることができますが、数値それ自体には普遍的な自然言語の意味はありません。その運用上の意味は、それが使用されるポリシーと管理コンテキストから生じます。ある環境での解釈を、単に数字が一致するからといって、別の環境に安全に輸入することはできません。

そのため、カラーはガバナンスの表層になります。オペレーターは、どの値が使用中か、どこで意味を持つか、どのポリシーを選択するか、誰がマッピングを変更できるか、変更されたマッピングがどのように伝搬されるかの記録を必要とします。記録は衝突や古くなった関連付けを見えるようにする必要があります。一意だが誤ってマッピングされた値は安全ではありません。正確だがスコープが曖昧な値は十分ではありません。

したがって、自動化はカラーを決定への 1 つの入力として扱い、他のすべての証拠を無効にする命令として扱うべきではありません。ポリシーが存在しない、非アクティブ、または現在の状態と互換性がない場合、責任あるシステムは境界のある応答を必要とします。ステアリングアクションを拒否するか、意図的に定義された代替を使用するか、可視的な例外を発生させることです。カラーを「十分近いことをする」と暗黙のうちに解釈することは、タプルが提供するように設計された正確な関連付けを破壊します。

エンドポイントは意図を転送先に固定します

エンドポイントコンポーネントは、SR ポリシーに宛先コンテキストを与えます。エンドポイントのないカラーは広範な目的を表現できますが、ヘッドエンドがポリシーを構築または選択すべき宛先を識別しません。エンドポイントがそのギャップを閉じます。ヘッドエンド、カラー、エンドポイントが一緒になって、ポリシーがどこで始まるか、どの関連付けを表すか、どこに向けられているかを識別します。

エンドポイントは依然としてコントロールプレーンの値であり、到達可能性の証明ではありません。関連するトポロジーは変更される可能性があります。候補パスが無効になる可能性があります。セグメントリストが意図したように解決しなくなる可能性があります。実装が選択された指示をプログラムできない可能性があります。これらの条件を通じて、エンドポイントはポリシー識別子の一部であり続けますが、ポリシーの運用状態はその周りで変化します。

この持続性は、記録された変更セマンティクスに役立ちます。オペレーターは、「同じポリシーが非アクティブになった」ことと「別のポリシーがそれを置き換えた」ことを区別できます。自動化は、作成、候補の追加、優先度の変更、アクティブパスの遷移、撤回、回復など、タプルにキー付けされたイベント履歴を保持できます。安定した識別子がなければ、これらのイベントは無関係なスナップショットと誤解され、継続性の確立が難しくなります。

候補パスは代替を明示的にします

SR ポリシーは複数の候補パスを持つことができます。その設計は、代替を不透明な計算に埋もれさせるのではなく、名前付きのコントロールプレーンオブジェクトに変えます。アーキテクチャ内では、候補パスはプロトコルオリジン、オリジネーター、ディスクリミネーターを通じて独自の識別子を持ちます。これらの要素は、候補がどこから来たかを保持し、同じポリシーに関連付けられた他の候補との区別します。

出所が重要であるのは、代替が異なるメカニズムや意思決定者を通じて到着する可能性があるためです。ローカルに構成された候補と別のコントロールコンポーネントによって提供された候補は、同じエンドポイントへのパスを記述するかもしれませんが、運用上は同一ではありません。それらは異なる権限、更新タイミング、制約、ロールバック動作を持つことができます。自動化がその出所を剥奪し、結果のセグメントリストだけを保持する場合、後の選択や撤回を説明するために必要な証拠を失います。

候補パスは、使用可能な転送指示を表現する 1 つ以上のセグメントリストにつながる可能性があります。アーキテクチャは、候補が特定の瞬間に使用可能でなくても存在できるため、候補をアクティブな結果から分離します。解決は現在の情報とサポートされている動作に依存する場合があります。セグメントリストは、候補の転送処理内で重み付けを持つこともありますが、構成またはアドバタイズされた重みは、発生したトラフィック分布の測定ではなく、実装への指示のままです。

選択ルールは代替をアクティブな状態に変えます

候補パスは、アクティブなポリシー状態との決定論的な関係を必要とします。RFC 9256 は、その関係を構造化するために優先度と有効性を使用します。適格な候補は使用可能でなければならず、優先度がどの有効な代替が選択されるかを決定します。運用上の重要なポイントは、優先度の数字だけにあるのではありません。それは、候補アイデンティティから有効性を通じて、ヘッドエンドが実際にアクティブにしたパスまでの記録された連鎖です。

有効性は時間に依存します。昨日解決した候補が、今日は入力が変更されたために失敗する可能性があります。セグメントリストが利用できなくなったり、必要なケーパビリティが見えなくなったり、パスを導出するために使用されたトポロジーが置き換えられたりする可能性があります。ポリシータプルは一定のままでありながら、選択された候補が変わる可能性があります。自動化は、安定した識別子と状態遷移の両方を保持する必要があり、以前のアクティブな候補が適格性を失った理由も含まれます。

優先度は観測された品質と誤解されるべきではありません。より高い優先度の候補は、構成またはシグナリングされた順序を表します。それは、より低い遅延、より大きな容量、改善されたセキュリティ、またはその他の測定された成果を証明するものではありません。これらの特性には別個の証拠と、該当する場合には現在の観測が必要です。選択メカニズムは、「これらのルールの下でどの有効な候補がアクティブであるべきか」に答えるものであり、「どのパスがすべての次元で客観的に最良か」ではありません。

有効な候補がないケースは特に重要です。実装は、ポリシーオブジェクトの存続の背後にそれを隠すべきではありません。ポリシーは認識されていても非アクティブである可能性があります。その状態は、ステアリングロジック、監視、および変更管理に見える必要があります。境界のあるフォールバックはオペレーターによって意図的に定義されるかもしれませんが、自動化層によって暗黙のうちに発明されてはなりません。意図されたパスと利用可能なパスの違いを保持するため、明示的な非アクティブ状態は推測された等価性よりも安全です。

ステアリングは別個の運用上の決定のままです

ポリシー選択とトラフィックステアリングは関連していますが異なります。候補パスのロジックは、識別された SR ポリシーのアクティブな転送処理を決定します。ステアリングはどのトラフィックがそのポリシーに入れられるかを決定します。有効なアクティブポリシーは特定のトラフィックフローを受信せずに存在でき、ステアリングアソシエーションは意図されたポリシーが非アクティブな間に存在できます。この 2 つを単一の緑色のインジケーターに結合すると、重要な障害状態が隠蔽されます。

ステアリングはまた、標準だけではなく、オペレーターポリシーに属します。RFC 9256 はアーキテクチャ上のメカニズムとルールを提供しますが、オペレーターはどのトラフィックがどのポリシーを使用すべきか、ポリシーが利用できない場合に何が起こるべきかを決定します。通常の宛先ベースの転送へのフォールバック、ホールド、または別の境界のあるパスは、異なるコンテキストで適切かもしれません。重要な要件は、その選択が意図的で観測可能であることです。

ここで、「インテントベースネットワーキング」に関するスローガンが証拠を上回る可能性があります。意図は、識別されたオブジェクト、現在の候補状態、明示的なステアリング、実装サポート、および観測された転送を通じてのみ運用可能になります。Talaulikar のポリシーアーキテクチャに関する帰属する作業が役立つのは、まさにそれらの中間契約を露出させるからです。それは契約が常に満たされることを約束するのではなく、独立したシステムにそれらを表現し検査する共通の方法を提供します。

RFC 9552 はトポロジーをレコードとして消費可能にします

RFC 9552 は、異なるが関連する問題に対処します。BGP-LS を介してリンクステートおよびトラフィックエンジニアリング情報を配布し、外部アプリケーションがトポロジービューを消費できるようにすることです。BGP-LS は、基礎となるリンクステートプロトコルを置き換えたり、SR ポリシーを選択したり、パケットを転送したりしません。定義されたインターフェースを通じてルーティング情報から導出されたレコードを運びます。

その区別は自動化にとって重要です。パス計算コンポーネントは、単一のデバイスを超えたノード、リンク、プレフィックスのビューを必要とする場合があります。BGP-LS は、ネットワーク層到達可能性情報と関連属性を通じて標準化された表現を提供します。この表現により、アプリケーションは無関係なデバイス出力をスクレイピングしたり、あるベンダーのプライベートフォーマットを想定したりすることなく、トポロジーオブジェクトを区別し、そのプロパティを解釈できます。

結果として得られるデータベースは導出されたビューです。それは、発信システムによって収集された情報、その情報のエンコーディング、BGP 配布、選択動作、およびコンシューマの処理に依存します。BGP-LS レコードは、最近のトポロジーイベントに対して正しくエンコードされていながら古い可能性があります。アプリケーションの制約に対して不完全でありながら最新である可能性があります。転送テーブルがそれと一致することを証明せずに、コントロールプレーンの知識を記述できます。

記述子はトポロジーオブジェクトに安定した識別子を与えます

トポロジーアプリケーションは、「リンク」や「ノード」について抽象的に安全に推論することはできません。関連するルーティングコンテキスト内で特定のオブジェクトを識別するのに十分な記述子が必要です。RFC 9552 は、その必要性を中心に BGP-LS レコードを編成します。ノード記述子は、プロトコルおよびドメインコンテキストでノードを識別します。リンクレコードは、ローカルおよびリモートのノード記述をリンク固有の記述子と関連付けます。プレフィックスレコードは、到達可能性情報を適切な発信コンテキストに添付します。

記述子は、レコードを読み取り可能にするだけではありません。それらは、2 つのアドバタイズメントが同じトポロジーオブジェクトを参照するか、異なるオブジェクトを参照するかを決定します。実装が識別子の必要な部分を削除すると、レコードが衝突する可能性があります。不安定な値を識別子に追加すると、1 つのオブジェクトが無関係なオブジェクトのストリームとして現れる可能性があります。いずれの障害も、パス計算が始まる前にコンシューマを誤解させる可能性があります。

識別子のスコープが中心です。自律システム番号、プロトコル識別子、ルーティングドメイン識別子、ノード識別子、インターフェースアドレス、またはプレフィックスには、特定の境界内で意味があります。単一のフィールドが必ずしもオブジェクト全体をグローバルに識別するわけではありません。複合記述が必要なコンテキストを提供します。自動化は、そのコンテキストを保持し、すべてのノードやリンクを一意でないかもしれない便利なラベルに平坦化するべきではありません。

正確なレコードには変更セマンティクスも必要です。撤回されたリンクは、属性が変更されたリンクと同じではありません。異なるルーティングコンテキストを通じて見られたノードは、自動的に重複ではありません。プレフィックスの更新は、発信記述子に付属したままであるべきです。コンシューマは、オブジェクトが追加されたか、修正されたか、置き換えられたか、削除されたかを説明できるべきです。安定した識別子と記録された遷移は、トポロジーフィードを切断されたスナップショットのシーケンスではなく、監査可能な入力に変えます。

順序付けは表面的なフォーマットではなく相互運用性のルールです

RFC 9552 は、順序付けをレコード契約の一部としています。記述子要素には定義された配置があり、正規の順序付けにより、フィールドが異なる順序で到着したというだけで、同等の情報が明らかに異なるオブジェクトとしてシリアル化されるのを防ぎます。これは、エンコードされたネットワーク層到達可能性情報がルートの識別子と比較に参加する場合に特に重要です。

正規の順序付けがなければ、2 つのスピーカーが同じ記述子値で同じノード、リンク、またはプレフィックスを記述しながら、異なるバイトシーケンスを生成する可能性があります。受信システムは、両方を異なるルートとして保持したり、それらを交互に使用したり、コンシューマに重複かどうかを推測させたりする可能性があります。基礎となるトポロジーは変化していないにもかかわらず、表現がチャーンを生み出す可能性があります。順序付けは、運用上の価値のない自由度を削除します。

それでもルールは意味的な正確性を保証しません。完全に順序付けられたレコードに誤った識別子や古いトポロジー情報が含まれている可能性があります。逆に、非正規の入力を検出したパーサーは、すべての順列を静かに祝福するのではなく、標準の互換性とエラーの境界内でそれを処理しなければなりません。順序付けは決定論的な構文を提供します。正確性はソースと現在のコントロールプレーンの状態に依存し、有用性はコンシューマの解釈と、その決定がチェックされる転送証拠に依存します。

互換性は有用で境界のあるものでなければなりません

ルーティング標準は、すべての実装が一度に変更されるわけではないネットワークで進化します。したがって、RFC 9552 は、現在のレコード契約を厳格化しつつ、以前の BGP-LS 動作との互換性に対処する必要があります。互換性は、既知の表現間での制御された移行を可能にする場合に価値があります。あいまいなエンコーディングをすべて受け入れ、意図されたトポロジーオブジェクトを推測する許可として解釈される場合、危険になります。

境界のあるアプローチは、認識された歴史的なバリエーションを不正な形式または意味的に矛盾するデータから分離することから始まります。レシーバーは、どの形式を受け入れるか、それらをどのように正規化するか、失われる可能性のある情報は何かを文書化できます。レコードの発信元を保持し、互換性処理が呼び出されたときに公開する必要があります。コンシューマは、その違いが信頼性に影響を与える可能性がある場合に、現在の正規形式で到着したかのように正規化されたオブジェクトを見るべきではありません。

これらはいずれも、RFC が特定の製品のアップグレード計画を指示することを意味しません。標準は相互運用可能な動作と境界を定義します。実装は具体的な診断とリリースサポートを選択します。オペレーターは展開シーケンスとリスク許容度を決定します。現在の BGP-LS レコードは受信されたものを示し、ダウンストリームの動作はコンシューマがどのように行動したかを示します。これらの層を分離しておくことで、昨日の曖昧さが明日の永続的なトポロジーエラーの源になることなく、互換性が継続性を保持できます。

エラーハンドリングは悪い入力を観測可能な状態に変換します

トポロジー自動化は、不完全、不正な形式、不整合、サポートされていない、または古い可能性のある入力にさらされます。RFC 9552 のエラーハンドリング境界が重要なのは、トポロジーコンシューマが使用できない入力を静かに信頼できる状態に変えるべきではないからです。不正な形式の記述子長、欠落した識別子コンテキスト、矛盾する記述、またはサポートされていない要素は、健全な現在のトポロジーレコードと同等ではありません。

正確なプロトコル応答はエラークラスと適用可能な BGP 手順に依存し、可視的な運用応答は実装にも依存します。これが、標準を製品の主張に崩してはならないもう 1 つの理由です。標準は、情報を安全に処理できない場合を定義できます。実装はそのルールを適用し、有用な診断を公開する必要があります。オペレーターは、レコードの喪失が計算を無効にするか、境界のある代替をトリガーするかを決定する必要があります。

可観測性はいくつかの事実を保持する必要があります。どのピアまたはオリジンがレコードを供給したか、どのトポロジーオブジェクトが影響を受けたか、ルートが拒否または撤回されたかどうか、属性のみが使用不能だったかどうか、イベントがいつ発生したか、そしてどのアプリケーションが前のバージョンを消費したかです。一般的な「BGP-LS エラー」カウンターは、影響を判断するのに十分ではありません。オブジェクト識別子と状態遷移は証拠の一部です。

RFC 9513 は OSPFv3 を通じて SRv6 ロケーターとケーパビリティを公開します

RFC 9513 は、分析を発信ルーティングドメインに戻します。これは、SRv6 のための OSPFv3 拡張を定義し、SRv6 ケーパビリティとロケーターに関する情報のアドバタイズメントを含みます。目的は可視性です。ルーティングシステムは、OSPFv3 コンテキスト内でノードが利用可能にする関連する SRv6 機能またはロケーター情報を示すプロトコルレコードを必要とします。

ロケーターは SRv6 識別子のためのルーティング構造を提供します。ロケーター情報をアドバタイズすることで、他のルーティングコンポーネントは、その構造がどこで到達可能か、広告システムとどのように関係するかの現在のビューを構築できます。ケーパビリティ情報は、特定の SRv6 関連の動作がサポートされていると表現されていることをピアやコンシューマに伝えます。これらのレコードは一緒に、計算、検証、ポリシー解決への入力になります。

アドバタイズメントはスコープ付きのリンクステート情報のままです。ルーティングプロトコルのメカニズムと境界に従って、発信、フラッディング、インストール、更新、撤回されます。自動化は、どのアドバタイジングルーターとエリアコンテキストがレコードを供給したか、いつデータベースに入ったか、新しいインスタンスがそれを置き換えたかどうかを知る必要があります。そのコンテキストから切り離されたコピーされたインベントリは、現在のリンクステートレコードよりも弱い証拠です。

ロケーターの可視性は必要ですが、転送の証明ではありません

SRv6 ロケーターアドバタイズメントは、ロケーターが現在のプロトコルビューに存在することをルーティングシステムに伝えることができます。それ自体では、関連するすべての動作がプログラムされていること、パケットが意図された完全なパスを通過できること、またはその情報を使用する SR ポリシーがアクティブであることを証明できません。可視性は情報に基づいた制御の前提条件であり、実行証拠の代替ではありません。

同じ注意がケーパビリティにも当てはまります。ケーパビリティアドバタイズメントは、ノードによって供給されたプロトコル状態を表します。それは容量を測定したり、すべてのオプションを検証したり、隣接する実装とのすべての組み合わせを認定したりするものではありません。オペレーターは、アドバタイズされたケーパビリティを、構成された意図、実装サポート、転送プログラミング、および制御された観測と比較する必要があります。不一致は、楽観的な仮定を通じて解決されるのではなく、可視的であるべきです。

古さは重要な境界です。ロケーターまたはケーパビリティが撤回または置き換えられた場合、古いレコードに基づくポリシー計算はもはや安全ではない可能性があります。コンシューマは、キャッシュされた計算や候補パスの有効性に到達する更新および撤回処理を必要とします。以前に導出されたパスをレビューなしでそのままにして、トポロジーデータベースを更新するだけでは不十分です。