Zenn
🗂

RFC 9552: BGPを使用したリンクステートとトラフィック・エンジニアリング情報の配布

2024/05/10に公開
#
rfc
#
bgp
#
routing
tech

要旨

多くの環境では、ネットワークの外部コンポーネントは、ネットワーク・トポロジとトラフィック・エンジニアリング(TE)情報を含むネットワーク内の現在の接続状態に基づいて計算を実行する必要がある。これは通常、ネットワーク内のIGPルーティング・プロトコルによって配布される情報である。

本文書では、BGPルーティング・プロトコルを使用して、リンクステートとTE情報をネットワークから収集し、外部コンポーネントと共有できるメカニズムについて説明する。これは、BGPネットワーク層到達性情報(NLRI)符号化フォーマットを使用して実現される。このメカニズムは、物理および仮想(トンネルなど)IGPリンクに適用され、ポリシー制御の対象となる。

この技術の応用には、アプリケーション層トラフィック最適化(ALTO)サーバやパス計算エレメント(PCE)が含まれる。

本文書はRFC 7752を完全に置き換えることで廃止する。以前の仕様に若干の変更と明確さが加えられている。本文書は、RFC 7752加えられた更新を組み込むことで、RFC 9029も廃止する。

本文書の位置付け

これはインターネット標準化トラックの文書です。

本文書は、インターネット標準化過程の文書である。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 7841のセクション 2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9552 で入手できる。

著作権表示

Copyright (c) 2023 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

リンクステート・データベース(LSDB)やIGPのトラフィック・エンジニアリング・データベース(TED)の内容は、IGPエリア内のリンクとノードのみを表現している。エンドツーエンドのトラフィック・エンジニアリング(TE)のような一部のアプリケーションでは、1つのエリアや自律システム(AS)の外側を可視化することで、より適切な意思決定ができるようになる。

IETFは、複数のTEDの可視性を横断するエンドツーエンドのTEパスの計算を実現するためのメカニズムとして、あるいはCPUを大量に使用する計算や協調された計算を必要とするものとして、パス計算エレメント(PCE)[RFC4655]を規定している。IETFはまた、抽象化されたネットワーク・トポロジを生成し、ネットワーク対応アプリケーションに提供するエンティティとして、ALTOサーバ[RFC5693]を規定している。

PCEとALTOサーバはどちらも、その機能を果たすために、ネットワークのトポロジとケーパビリティに関する情報を収集する必要がある。

本文書では、BGPルーティング・プロトコル[RFC4271]を使用して、リンクステートやTE情報をネットワークから収集し、外部コンポーネントと共有できるメカニズムについて説明する。これは、BGPネットワーク層到達性情報(NLRI)符号化フォーマットを使用して実現する。このメカニズムは、物理リンクと仮想(トンネルなど)リンクに適用され、ポリシー制御の対象となる。

ルータは、任意のエリア内のノードとリンクに関するリンクの状態情報を格納するために、1つ以上のデータベースを維持する。これらのデータベースに格納されるリンク属性には、ローカル/リモートIPアドレス、ローカル/リモート・インタフェース識別子、リンクのIGPメトリック、リンクのTEメトリック、リンクの帯域幅、予約可能な帯域幅、Class-of-Service (CoS)ごとのクラス予約状態、プリエンプション、および共有リスク・リンク・グループ(SRLG)が含まれる。ルータのBGPリンクステート(BGP-LS)のプロセスは、これらのLSDBからトポロジを取得し、本文書で指定された符号化を使用して、直接またはピアBGPスピーカー(通常は専用のルート・リフレクタ)を介して、コンシューマに配布する。

リンクステートとTE情報の収集とコンシューマへの配布を次の図に示す。

fig01
図1: リンクステートとTE情報の収集

BGPスピーカーは、配信する情報に設定可能なポリシーを適用できる。したがって、LSDBやTEDから実際の物理トポロジを配信することもできる。あるいは、抽象化されたトポロジを作成し、仮想の集約ノードを仮想パスで接続することもできる。集約ノードは、例えば、Point of Presence (POP)内の複数のルータから作成できる。抽象化されたトポロジは、物理ノードと仮想ノード、物理リンクと仮想リンクを混在させることもできる。さらに、BGPスピーカーは、ネットワークからコンシューマへの情報フローが減少するように、コンシューマに情報が更新されるタイミングを決定するポリシーを適用できる。トポロジを集約または仮想化するメカニズムは、本文書の範囲外である。

本文書は、IGP由来の情報の発信と、BGP-LSを介したそれらの伝播に関する仕様に焦点を当てている。また、ノードにとってのローカルな設定または導出された情報のBGP-LSへの広告についても記述する。一般的に、本文書の手順は基本BGP-LSプロトコル仕様の一部であり、BGP-LSに導入される他のソースからの情報にも適用される。

本文書は、[RFC7752]を完全に置き換えるもので、その文書を廃止する。付録Aに記載しているように、以前の仕様に若干の変更と明確さを加えている。

1.1. 要件言語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

2. 動機と応用力

このセクションでは、要件を導き出すためのユースケースについて説明する。

2.1. PCEを使用したMPLS-TE

[RFC4655]で説明しているように、PCEは「ドメイン」内(IGPエリアなど)または複数のドメイン間(マルチエリアASや複数のASなど)でMPLS-TEパスを計算するために使用できる。

  • 単一エリア内では、PCEは個々のルータでは利用できない強化された計算能力、高度なポリシー制御とアルゴリズム、そしてエリア全体にわたる計算の調整を提供する。
  • ルータがIGPエリア全体のMPLS-TEパスを計算したい場合、ルータ自体のTEDは完全なトポロジの可視性に欠ける。つまり、ルータはエンドツーエンドのパスを決定できず、最適なパスのために適切な出口ルータ(エリア・ボーダー・ルータ(ABR))を選択することさえできない。これは、コア・ネットワークを個別のエリアにセグメント化する必要があるが、それでもMPLS-TEを活用したい大規模ネットワークにとって問題である。

以前のソリューションでは、ドメインごとのパス計算[RFC5152]に使用していた。ルータはパスに沿った最初のエリアのトポロジの完全な可視性を持つが、それ以外のエリアの可視性を持たないため、ソースルータは最初のエリアのパスしか計算できない。ドメインごとのパス計算では、出口ABRと他のABRまたはASボーダー・ルータ(ASBR)がルースホップ[RFC3209]として選択され、パスの残りの部分ではIGPが計算した最短パスのトポロジを使用する。これにより、最適ではないパスが発生し、代替/バックアップ・パスの計算が困難になり、TEパスが存在するにも関わらず見つからないという結果を招く可能性がある。

PCEは、複数のIGPエリアまたはASを可視化したり、他のPCEと連携して分散パス計算を実行する計算サーバを提供する。PCEは、サービスを提供するエリアのTEDにアクセスする必要があるが、[RFC4655]はこれがどのように達成されるかは記載していない。多くの実装では、PCEがネットワークの最新状態を学習できるように、IGPに受動的に参加するが、ネットワークが高いチャーンにさらされている場合や、PCEが複数のエリアを担当している場合には、最適ではない可能性がある。

次の図は、 PCEが本文書で説明するメカニズムを使用して、TED情報を取得する方法を示している。

fig01
図2: TED同期メカニズムを使用する外部PCEノード

本文書のメカニズムでは、必要なTED情報をネットワーク内のIGPから収集し、設定可能なポリシーに従ってフィルタリングし、必要に応じてPCEに配布することができる。

2.2. ALTOサーバ・ネットワークAPI

ALTOサーバ[RFC5693]は、抽象化されたネットワーク・トポロジを生成し、ウェブサービスベースのAPI経由でネットワーク対応アプリケーションに提供するエンティティである。アプリケーションの例としては、ピアツーピア(P2P)クライアント、トラッカー、コンテンツ配信ネットワーク(CDN)などがある。抽象化されたネットワーク・トポロジは、パーティション識別子(PID)へのプレフィックスの割り当てを指定するネットワーク・マップと、ネットワーク・マップにリストされたPID間のコストを指定するコスト・マップの2つのマップの形で提供される。詳細は、[RFC7285]を参照のこと。

ALTOの抽象化されたネットワーク・トポロジは、基礎となるネットワークの物理トポロジから自動生成することができる。この生成は通常、オペレータが設定したポリシーとルールに基づいて行われる。プレフィックス・データとTEデータの両方が必要になる。プレフィックス・データはALTOネットワーク・マップを生成するために必要であり、TE(トポロジ)データはALTOコスト・マップを生成するために必要である。プレフィックス・データはBGPで伝送・発信され、TEデータはIGPで発信・伝送される。本文書で定義しているメカニズムは、ALTOサーバは基盤となるネットワークから必要なすべてのプレフィックスとネットワーク・トポロジ・データを取得できる単一のインタフェースを提供する。ALTOサーバは、ネットワーク・データを取得するために他のメカニズム、例えば、複数のIGPおよびBGPスピーカーとのピアリングを使用できることに留意する。

次の図は、ALTOサーバが、本文書で説明されているメカニズムを使用して、基盤となるネットワークからネットワーク・トポロジ情報を取得する方法を示している。

fig03
図3: ネットワーク・トポロジ情報を使用するALTOサーバ

3. BGP-LSにおけるBGPスピーカーの役割

図1では、BGP-LSを使った情報配信において、BGPスピーカがさまざまな役割を担っていることが分かる。このセクションでは、BGPスピーカーのさまざまな役割を説明する用語を紹介する。これらの用語は、本文書の残りの部分で使用する。

BGP-LSプロデューサ: BGP-LSプロデューサという用語は、リンクステート情報をBGPに送信するBGPスピーカーを指す。BGPスピーカーR1、R2、... Rnは、基礎となるリンクステートIGPプロトコルからBGP-LSにリンクステート情報を発信する。R1とR2が同じIGPフラッディング・ドメイン内にある場合、通常は同じリンクステート情報をBGP-LSに発信する。R1は、IGP以外のソース、例えばローカルノード情報からも情報を発信することがある。

BGP-LSコンシューマ: BGP-LSコンシューマという用語は、BGPスピーカーではなく、コンシューマ・アプリケーション/プロセスを指す。BGPスピーカーRR1とRnは、収集したBGP-LS情報をコンシューマ・アプリケーションに渡す。BGPプロトコルの実装とコンシューマ・アプリケーションは、同じノード上に存在する場合もあれば、異なるノード上に存在する場合もある。本文書では、BGPの実装のみを扱う。コンシューマ・アプリケーションと、BGPとコンシューマ・アプリケーションの間のインタフェースの設計は、実装に固有の可能性があり、本文書の範囲外である。情報の通信は一方向(つまり、BGPスピーカからBGP-LSコンシューマ・アプリケーションへ)でなければならず(MUST)、BGP-LSコンシューマは、BGP-LSへの発信のためにBGPスピーカーに情報を送信してはならない(MUST NOT)。

BGP-LSプロパゲータ: BGP-LSプロパゲータという用語は、リンクステート情報に対してBGPプロトコル処理を実行するBGPスピーカーを指す。BGPスピーカーRRmは、BGPスピーカーRnとBGPスピーカーRR1の間でBGP-LS情報を伝播する。RRm上のBGP実装は、BGP-LS情報を伝播している。BGP-LSのUPDATEメッセージの処理を実行し、どの情報を伝播するかを決定するBGP決定プロセスを実行する。同様に、BGPスピーカーRR1はR1、R2、RRmからBGP-LS情報を受信し、BGP決定プロセスを実行した後、その情報をBGP-LSコンシューマに伝播している。

上記の役割は相互に排他的なものではない。同じBGPスピーカーが、あるリンクステート情報では、BGP-LSプロデューサとなり、他のリンクステート情報ではBGP-LSプロパゲータとなり、同時にその情報をBGP-LSコンシューマに提供することもある。

本文書の残りの部分では、その役割に固有の手順を説明する際、その役割について言及する。役割が指定されていない場合、前述の手順はすべてのBGPスピーカーに適用される。

4. IGP情報をBGP-LSに広告する

BGPを介したIGPリンクステート情報の発信と伝播は、IGPドメインのトポロジの一貫した正確なビューを提供する必要がある。BGP-LSはIGPの仕様を抽象化したものを提供し、BGP-LSコンシューマはさまざまなタイプのアプリケーションである。

IGPからBGP-LSに広告されるリンクステート情報は、OSPFリンクステート広告(LSA)またはIS-ISリンクステート・パケット(LSP)を使用して構築されたIGP LSDBから導出される。ただし、発信元ルータのLSDBをそのまま反映したものではない。1つのリンクステート・オブジェクトが複数のLSA/LSPの情報をまとめられている可能性があるため、LSA/LSPのシーケンス番号情報は含まれていない上、LSA/LSPで伝送される情報のすべてが、BGP-LS経由での広告に必要または適切であるとは限らない(例えば、OSPFのASBR到達性、OSPF仮想リンク、リンク・ローカル・スコープの情報など)。パージまたは期限切れになったLSA/LSPは、(IGPフラッディング目的など)LSDBに存在することがあっても、BGP-LSの広告には含まれない。LSA/LSPの情報のうち、無効な情報、不正な情報、あるいはそれぞれのIGPプロトコルの仕様によって無視する必要のある情報も、BGP-LS広告には含まれない。

リンクステート情報の広告のためのIGPとBGP間のインタフェースの詳細は、この文書の範囲外である。場合によっては、BGP-LSにリンクステート情報を広告するために、IGPの処理から得られた情報(例えば、複数のLSA/LSPにまたがるリンクステート・オブジェクトの組み合わせ、到達性と双方向接続性チェックの活用など)が必要になる。

5. BGPでリンクステート情報の伝送

リンクステート情報は、BGP UPDATEメッセージで次のように伝送される。(1) リンク、ノード、またはプレフィックス・オブジェクトを記述するMP_REACH_NLRI属性とMP_UNREACH_NLRI属性で伝送されるBGP NLRI情報と、(2) リンクやプレフィックスのメトリック、ノードの補助ルータIDなど、リンク、ノード、またはプレフィックス・オブジェクトのプロパティを伝送するBGPパス属性(BGP-LS属性)である。

リンクステート情報は、この属性のプロトコル・ソースへの依存を最小限に抑え、IGPに中立な方法でコンテンツを表現することが望ましい。これにより、リンクステート・トポロジを知りたいアプリケーションは、OSPFやIS-ISプロトコルの詳細を知る必要はない。

このセクションでは主に、BGP-LSプロデューサがリンクステート情報をBGP-LSに発信する手順について説明する。

5.1. TLVフォーマット

リンクステートNLRIとBGP-LS属性の情報は、「タイプ/長さ/値」のトリプレットで符号化される。TLVのフォーマットは図4に示されており、NLRIとBGP-LS属性の両方の符号化に適用される。

fig04
図4: TLVフォーマット

長さフィールドは、値部分の長さをオクテット単位で定義する(したがって、値部分を持たないTLVの長さはゼロとなる)。TLVは4オクテットのアライメントにパディングされない。未知やサポートされていないタイプは、NLRIとBGP-LS属性の両方で保存され、伝播しなければならない(MUST)。未知や予期しないTLVが存在する場合、NLRIやBGP-LS属性が不正な形式であるとみなされてはならない(MUST NOT)。予期しないTLVの例として、TLVが関連付けられていると指定されたもの以外のリンクステート・オブジェクトの更新とともにTLVを受信したものがある。

未知のTLVを持つNLRIを比較するために、NLRI内のすべてのTLVはTLVタイプの昇順に並べなければならない(MUST)。1つのNLRI内に同じタイプのTLVが複数ある場合、同じタイプを共有するTLVは、最初に長さフィールドに基づく昇順に並べ、次に値フィールドに基づいて昇順に並べなければならない(MUST)。値フィールドの比較は、フィールド全体をOpaqueなバイナリデータとして扱い、辞書順に並べることによって実行する(つまり、バイナリデータの各バイトを比較対象のシンボルとして扱い、シンボルは数値順に並べる)。上記の順序付け規則に従わないTLVを持つNLRIは、BGP-LSプロパゲータによって不正な形式と見なされなければならない(MUST)。この正規順序にこだわることで、複数のBGP-LSプロデューサから同じNLRIの複数のバリアント・コピーが作成され、そこから生じる曖昧さを確実に防ぐことができる。

NLRIとBGP-LS属性部分の両方で、必須または特定の条件下で必須と明示的に指定されている場合を除き、すべてのTLVはオプションとみなされる。

BGP-LS属性内のTLVは、TLVタイプの昇順に並べる必要がある(SHOULD)。TLVが順番通りに並んでいないBGP-LS属性は、不正な形式とみなしてはならない(MUST NOT)。

複数のBGP-LSプロデューサによって同じリンクステート情報が生成されると、オプションのTLVが含まれるか含まれないかによって、差異や不一致が生じることがある。NLRIのオプションTLVが異なると、同じリンクステート・オブジェクトに対して複数のNLRIが生成される。BGP-LS属性内のオプションTLVが異なると、部分的な情報が伝播される可能性がある。このような不一致に対処するには、BGP-LSコンシューマは重複する情報を認識し、マージするか、欠落している情報に対処する必要がある。このような状況を軽減するには、同じオプションTLVセットを一貫して発信するBGP-LSプロデューサーの導入が推奨される。

5.2. リンクステート NLRI

MP_REACH_NLRI属性とMP_UNREACH_NLRI属性は、Opaqueな情報を伝送するためのBGPのコンテナである。この仕様では、ノード、リンク、プレフィックスのいずれかを記述する3種類のリンクステートNLRIタイプを定義する。

すべての非VPNリンク、ノード、およびプレフィックス情報は、AFI 16388 / SAFI 71を使用して符号化するものとする(SHALL)。VPNリンク、ノード、プレフィックス情報は、AFI 16388 / SAFI 72を使って符号化するものとする(SHALL)。

2つのBGPスピーカーがリンクステートNLRIを交換するには、BGPケーパビリティ広告を使用して、そのようなNLRIを適切に処理できることを保証しなければならない。これは、[RFC4760]で規定されているように、機能コード1(マルチプロトコルBGP)を使用し、BGP-LSにはAFI 16388 / SAFI 71、BGP-LS-VPNにはAFI 16388 / SAFI 72を使用することで実行される。

将来、新しいリンクステートNLRIタイプが導入される可能性がある。アドレスファミリ内でサポートされているNLRIタイプの値は、マルチプロトコルBGP(MP-BGP)ケーパビリティ[RFC4760]で表現されていないため、BGPスピーカーがBGP-LSのサポートを広告しているものの、特定のリンクステートNLRIをサポートしていない可能性がある。伝播パス内のすべてのBGPスピーカー(ルート・リフレクタなど)をアップグレードする必要なく、将来的に新しいリンクステートNLRIタイプをシームレスに導入できるようにするために、本文書では[RFC7606]のセクション5.4(段落2)で指定されているリンクステート・アドレス・ファミリーのデフォルトの処理動作から逸脱している。実装は、未知のリンクステートNLRIタイプをOpaqueなオブジェクトとして処理し、それらを保持し伝播しなければならない(MUST)。

リンクステートNLRIのフォーマットを以下の図に示す。

fig05
図5: リンクステートAFI 16388 / SAFI 71 NLRIフォーマット

fig06
図6: リンクステートVPN AFI 16388 / SAFI 72 NLRIフォーマット

総NLRI長フィールドは、NLRIタイプ・フィールドやそれ自体を含まない、NLRIの残りの部分の累積長がオクテット単位で含まれる。VPNアプリケーションの場合、Route Distinguisherの長さも含まれる。

タイプ NLRIタイプ
1 ノードNLRI
2 リンクNLRI
3 IPv4トポロジ・プレフィックスNLRI
4 IPv6トポロジ・プレフィックスNLRI

表1: NLRIのタイプ

Route Distinguisherは[RFC4364]で定義され、議論されている。

ノードNLRI(NLRIタイプ = 1)を以下の図に示す。

fig07
図 7: ノードの NLRI 形式

リンクNLRI(NLRIタイプ = 2)を以下の図に示す。

fig08
図8: リンクNLRIフォーマット

IPv4とIPv6プレフィックスNLRI(NLRIタイプ = 3とタイプ = 4)は、次図に示すように同じフォーマットを使用する。

fig09
図9: IPv4/IPv6トポロジ・プレフィックスNLRIフォーマット

プロトコルIDフィールドは、以下のいずれかの値を含むことができる。

プロトコルID NLRI情報ソース・プロトコル
1 IS-ISレベル1
2 IS-ISレベル2
3 OSPFv2
4 直接(Direct)
5 静的構成(Static configuration)
6 OSPFv3

表2: プロトコル識別子

BGP-LSがローカル情報を取得する場合、「直接(Direct)」および「静的構成(Static configuration)」プロトコル・タイプを使用する必要がある(SHOULD)。他のプロトコルに由来するすべての情報については、対応するプロトコルIDを使用しなければならない(MUST)。BGP-LSがインタフェース情報に直接アクセスでき、ローカルリンクを広告したい場合、プロトコルID「直接」を使用する必要がある(SHOULD)。セクション6で説明しているような仮想リンクのモデル化には、プロトコルIDの「静的構成」を使用する必要がある(SHOULD)。

ルータはOSPFまたはIS-ISの複数のプロトコル・インスタンスを実行することができ、それにより複数のIGPドメイン間のボーダー・ルータになる。OSPFとIS-ISは両方とも、同じリンク上で複数のルーティング・プロトコル・インスタンスを実行することもできる。[RFC8202]と[RFC6549]を参照のこと。これらのインスタンスは独立したIGPルーティング・ドメインを定義する。識別子フィールドには、8オクテットのBGP-LSインスタンス識別子(インスタンスID)番号を持ち、NLRIが属するIGPルーティング・ドメインを識別するために使用される。同じIGPルーティング・インスタンスからのリンクステート・オブジェクト(ノード、リンク、またはプレフィックス)を表すNLRIは、同じBGP-LSインスタンスIDを持つ必要がある。異なるBGP-LSインスタンスIDを持つNLRIは、異なるIGPルーティング・インスタンスからのものとみなされる。

複数のIGPインスタンスをサポートするために、実装はルーティング・プロトコル・インスタンス・レベルでユニークなBGP-LSインスタンスIDの設定をサポートする必要がある。BGP-LSが動作しているネットワーク内にプロトコル・インスタンスが1つしかない場合、BGP-LSインスタンスID 0を使用することが推奨される(RECOMMENDED)。ネットワーク・オペレータは、特定のIGPドメイン内のすべてのBGP-LSプロデューサに同じBGP-LSインスタンスIDを割り当てなければならない(MUST)。異なるIGPドメインで動作するルーティング・プロトコル・インスタンスには、ユニークなBGP-LSインスタンスIDを割り当てなければならない(MUST)。これにより、BGP-LSコンシューマは、BGP-LSインスタンスIDに基づいて正確な分離されたマルチドメイン・トポロジを構築することができる。

前述のセマンティクスと推奨事項に従わない場合、複数のBGP-LSプロデューサが展開されているとき、BGP-LSコンシューマは同じノード、リンク、プレフィックスに対して複数のリンクステート・オブジェクト(それぞれが異なるBGP-LSインスタンス IDを持つ)を認識する可能性がある。その結果、BGP-LSコンシューマは不正確なネットワーク全体のトポロジを取得することになるかも知れない。

各ノード・ディスクリプタ、リンク・ディスクリプタ、およびプレフィックス・ディスクリプタは、次のセクションで説明するように、1つ以上のTLVで構成される。これらのディスクリプタTLVは、表2にリストされているプロトコルのノード、リンク、プレフィックスNLRIタイプに適用される。新しいNLRIタイプやプロトコルでBGP-LS仕様を拡張する文書は、それらに対応するNLRIディスクリプタを指定しなければならない(MUST)。

リンクステートNLRIにTLV/サブTLVを追加、削除、または変更する場合、BGP-LSプロデューサーは、MP_UNREACH_NLRIに含めることで、古いNLRIを撤回しなければならない(MUST)。そうしないと、BGP-LSテーブルに重複した一貫性のないリンクステート・オブジェクトが残ることになる。

5.2.1. ノード・ディスクリプタ

各リンクは、基礎となるIGPで使用されるルータIDのペア、つまり、IS-ISの場合は48ビットISOシステムID、OSPFv2とOSPFv3の場合は32ビットのルータIDによって固定される。IGPは、主にトラフィック・エンジニアリングの目的で、1つ以上の追加の補助ルータIDを使用することがある。例えば、IS-ISは1つ以上のIPv4とIPv6 TEルータID[RFC5305] [RFC6119]を持つことがある。設定されいれば、これらの補助TEルータID (TLV 1028/1029)は、セクション5.3.1に記載されているノード属性に含めなければならず、セクション5.3.2に記載されているリンク属性に含めてもよい(MAY)。TEルータIDの広告は、BGP-LSコンシューマが複数のリンクステート・オブジェクト(例えば、異なるIGPインスタンスやエリア/レベルなど)をネットワーク内の同じノードに関連付けるのに役立つ。

ノード・ディスクリプタ内のルータIDの割り当ては、グローバルにユニークであることが望ましい。しかし、グローバル・レジストリが存在しないルータIDスペース(ISOなど)があるかも知れないし、さらに悪いことに、[RFC1918]に記載されているプライベートIPの割り当てに従ってルータIDが割り当てられているかも知れない。BGP-LSは、セクション5.2.1.1で説明しているように、ルータIDを曖昧にしないために自律システム番号を使用する。

5.2.1.1. グローバルにユニークなノード/リンク/プレフィックス識別子

解決しなければならない問題の1つは、IGPノードをグローバルに識別する機能である(ここでの「グローバル」とは、相互に通信するすべてのBGP-LSスピーカーが収集したBGP-LSデータベース内を意味する)。これは、以下の2つの要件によって表現できる:

(A) 同じノードを2つのキーで表してはならない(MUST NOT)(そうでないと、1つのノードが2つのノードのように見える)。
(B) 2つの異なるノードを同じキーで表してはならない(MUST NOT)(そうでないと、2つのノードが1つのノードのように見える)。

「IGPドメイン」とは、OSPFエリアID、ルータID、プロトコルID、 マルチトポロジ識別子(MT-ID)、BGP-LSインスタンス IDの組み合わせによって、各ノードがユニークなIGP表現を持つノード(ひいてはリンクとプレフィックス)の集合と定義する。問題は、BGPが複数の独立した「IGPドメイン」からノード/リンク/プレフィックス情報を受け取る可能性があり、それらを区別する必要があることである。さらに、ASごとに常に1つのIGPドメインが存在すると仮定することはできない。IGPの移行時に、2つの冗長IGPが配置する可能性がある。

さらに、BGP-LSが複数のASのトポロジを広告するために使用される展開では、異なるASから報告されたトポロジ情報を区別するために、自律システム番号(ASN)を使用する。

セクション5.2.1.4で説明したサブTLVセットとともに前述したように、識別子フィールドで伝送されるBGP-LSインスタンスIDは、NLRIのグローバルなユニークさが確保されるように、特定のノード/リンク情報に対する柔軟なキーの指定を可能にする。BGP-LSインスタンスIDはオペレータによって割り当てられるため、その割り当てスキームによって、複数ASネットワークであっても、各IGPドメインを一意に識別することを保証できる。

5.2.1.2. ローカル・ノード・ディスクリプタ

ローカル・ノード・ディスクリプタTLVは、リンクのローカル端を固定するノードのノード・ディスクリプタを含む。これは、3種類のNLRI(ノード、リンク、プレフィックス)すべてにおいて、必須のTLVである。タイプは256である。このTLVの長さは可変である。値はセクション5.2.1.4で定義された1つ以上のノード・ディスクリプタ・サブTLVを含む。

fig10
図10: ローカル・ノード・ディスクリプタのTLVフォーマット

5.2.1.3. リモート・ノード・ディスクリプタ

リモート・ノード・ディスクリプタTLVは、リンクのリモート端を固定するノードのノード・ディスクリプタを含む。これは、リンクNLRIの必須TLVである。タイプは257である。このTLVの長さは可変である。値はセクション5.2.1.4で定義された1つ以上のノード・ディスクリプタ・サブTLVを含む。

fig11
図11: リモート・ノード・ディスクリプタのTLVフォーマット

5.2.1.4. ノード・ディスクリプタのサブTLV

ノード・ディスクリプタのサブTLVタイプのコードポイントと長さを以下の表に示す。

サブTLV
コードポイント		 説明 長さ
512 自律システム 4
513 BGP-LS 識別子 (非推奨) 4
514 OSPF エリアID 4
515 IGPルータID 可変長

表3: ノード・ディスクリプタのサブTLV

ノード・ディスクリプタTLVのサブTLV値は以下のように定義される:

自律システム: Opaqueな値(32ビットのAS番号)。これはオプションのTLVである。この値は、リンクステート情報を発信するBGPプロセスに関連付けられたAS番号に設定する必要がある(SHOULD)。実装はBGP-LSプロデューサーに、例えばプライベートAS番号を使用する場合の衝突を避けるためなどに、異なる値を使用する設定オプションを提供してもよい(MAY)。

BGP-LS・ディスクリプタ: Opaqueな値(32ビットID)。これはオプションのTLVで、本文書では非推奨となっている(詳細は付録Aを参照のこと)。[RFC7752]の実装との互換性のために広告してもよい(MAY)。さらなる考慮事項と推奨されるデフォルト値については、このセクションの最後の段落を参照のこと。

OSPFエリアID: NLRIで広告される情報が属する32ビットのエリアを識別するために使用される。これは、エリアスコープLSAに由来する情報をOSPFから発信するときに必須のTLVである。OSPFエリア識別子は、同じルータの異なるNLRIをエリアごとに区別できる。ASスコープLSAから派生した情報を伝送する場合、その情報はエリアに関連付けられていないため、NLRIには使用されない。

IGPルータID: Opaqueな値。これは、IS-IS、OSPF、「直接」、または「静的設定」から情報を発信するときに必須のTLVである。IS-IS非擬似ノードの場合、6オクテットの ISOノードID(ISOシステムID)を含む。LANに対応するIS-IS擬似ノードでは、代表中間システム(DIS: Designated Intermediate System)の6オクテットのISOノードIDと、その後に続く1オクテットのゼロ以外のPSN識別子(合計7オクテット)を含む。OSPFv2またはOSPFv3の非擬似ノードの場合、4オクテットのRouter-IDを含む。LANを表すOSPFv2擬似ノードの場合、代表ルータ(DR: Designated Router)の4オクテットのルータIDと、それに続くLANへのDRのインタフェースの4オクテットのIPv4アドレスを含む(合計8オクテット)。同様に、OSPFv3擬似ノードでは、DRの4オクテットのルータIDと、それに続くLANへのDRのインタフェースの4オクテットのインタフェース識別子を含む(合計8オクテット)。TLVサイズとプロトコル識別子を組み合わせることで、デコーダはノードのタイプを判断できる。「直接」または「静的構成」の場合、値はノードに構成されたIPv4またはIPv6アドレス(ループバック・インタフェースなど)から取得する必要がある(SHOULD)。ノードがIGPプロトコルを実行している場合、実装は「直接」または「静的構成」にIGPルータIDを使用することを選択してもよい(MAY)。

ノード・ディスクリプタは、最大でも各サブTLVタイプのインスタンスが1つ存在しなければならない(MUST)。ノード・ディスクリプタ内のサブTLVは、サブTLVタイプ別に昇順に並べなければならない(MUST)。これは、実装で未知のサブTLVに遭遇した場合でも、NLRIを比較するために行う必要がある。安定した並べ替えを使用することで、実装はNLRIのバイナリ比較を行うことができ、その結果、新しいキーのサブTLVの増分展開できる。

BGP-LS識別子は[RFC7752]で導入され、その使用は本文書では非推奨である。実装は、[RFC7752]に準拠するBGP-LSプロデューサーの実装が存在する展開において、下位互換性のために、このサブTLVの広告をサポートし、リンクステート・オブジェクトのNLRI符号化の一貫性を確保する必要がある(SHOULD)。BGP-LSプロデューサーがBGP-LSに情報を発信するときにこのサブTLVを含める場合は、デフォルト値0を使用することが推奨される(RECOMMENDED)。実装は、下位互換性の理由から、この値を設定するオプションを提供する必要がある(SHOULD)。識別子フィールドで運ばれるBGP-LSインスタンスIDの使用は、BGP-LSで異なるIGPドメインのリンクステート・オブジェクトを分離する方法であることに留意する。

5.2.2. リンク・ディスクリプタ

リンク・ディスクリプタのフィールドは、タイプ/長さ/値(TLV)のトリプレットの集合である。各 TLVのフォーマットをセクション5.1に示す。リンク・ディスクリプタTLVは、アンカールータのペア間の複数の並列リンクの中でリンクをユニークに識別する。リンク・ディスクリプタTLVによって記述されるリンクは、実際には「ハーフリンク」、つまり論理リンクの一方向表現である。1つの論理リンクを完全に記述するには、2つのアンカールータがそれぞれハーフリンクを広告する。つまり、特定のポイントツーポイント・リンクに対して2つのリンクNLRIが広告される。

2つのノード間のリンクは、アンカーノードのペアからのハーフリンク表現に対応する2つのリンクNLRIによって記述されない限り、完全(または利用可能)とはみなされない。このチェックは、リンクステートIGPが実行する「双方向接続性チェック」に似ている。

実装は、リンクステートIGPからのハーフリンクに対応するリンクNLRIの広告を抑制してもよい(MAY)。ただし、そのリンクによって接続されている両方のノードによって、IS-IS LSPまたはOSPFルータLSAでそのリンクが報告されていることをIGPが検証した場合を除く。この「双方向接続チェック」は、リンクステートIGPが計算中に実行し、これらのIGPから報告されたハーフリンクの情報をBGP-LSに渡す前に活用することができる。これにより、確立されたリンクステートIGP隣接関係のみがリンクNLRIを介して報告されるようになる。このような「双方向接続性チェック」は、リモートノードの適切なリンク識別子を取得するために、特定のケース(OSPFなど)にも必要になる可能性がある。

ほとんどのリンク・ディスクリプタTLVの値フィールドの書式とセマンティクスは、[RFC5305]、[RFC5307]、[RFC6119]で定義されているIS-IS拡張IS到達性サブTLVの値フィールドの書式とセマンティクスに対応している。リンク・ディスクリプタTLVの符号化は元々IS-ISのために定義されたが、TLVはIS-ISまたはOSPFのどちらでもソースとするデータを伝送できる。

以下のTLVがリンクNLRIのリンク・ディスクリプタとして定義されている:

TLV
コード
ポイント		 説明 IS-IS TLV/
Sub-TLV		 参照先
258 リンクローカル/リモート識別子 22/4 [RFC5307]セクション1.1
259 IPv4インタフェース・アドレス 22/6 [RFC5305]セクション3.2
260 IPv4隣接アドレス 22/8 [RFC5305]セクション3.3
261 IPv6インタフェース・アドレス 22/12 [RFC6119]セクション4.2
262 IPv6隣接アドレス 22/13 [RFC6119]セクション4.3
263 マルチトポロジ識別子 ─ セクション 5.2.2.1

表4: リンク・ディスクリプタのTLV

リンクのローカルノードが発信したLSA/LSPに存在するリンクに関する情報は、リンクのリンク・ディスクリプタのTLVセットを決定する。

IPv4またはIPv6のインタフェース・アドレスと近隣アドレスが存在する場合、インタフェース/近隣アドレスTLVを含まなければならなず(MUST)、リンクローカル/リモート識別子TLVをリンク・ディスクリプタに含まれてはならない(MUST NOT)。リンクローカル/リモート識別子TLVは利用可能な場合、リンク属性に含めてもよい(MAY)。IPv4/IPv6のリンクローカル・アドレスは、ユニークとはみなされないため、リンク・ディスクリプタとして IPv4/IPv6インタフェース/近隣アドレスTLV(259/260/261/262)に伝送してはならない(MUST NOT)。

インタフェース・アドレスと近隣アドレスが存在せず、リンクローカル/リモート識別子が存在する場合、リンクローカル/リモート識別子TLVをリンク・ディスクリプタに含めなければならない(MUST)。リンクローカル/リモート識別子は、IPv6リンクローカル・アドレス指定のみを持つリンクの場合、リンク・ディスクリプタに含めなければならない(MUST)。

マルチトポロジ識別子TLVは、基礎となるIGPリンク・オブジェクトがデフォルト以外のトポロジに関連付けられている場合、リンク・ディスクリプタとして含めなければならない(MUST)。

インタフェース・アドレスおよび/またはローカル/リモート識別子に対応するTLV/サブTLVは、その広告が特別に有効になっていない限り、常にIGPで通知されるとは限らない。そのような場合、BGP-LSリンクのNLRIを、これらの識別子を使用せずに広告することは有効である。

5.2.2.1. マルチトポロジ識別子

マルチトポロジ識別子(MT-ID)TLVは、リンク、ノード、またはプレフィックスの1つ以上のIS-ISまたは OSPFマルチトポロジ識別子を伝送する。

IS-IS MT-IDのセマンティクスは、[RFC5120]のセクション7.1と7.2で定義されている。OSPF MT-IDのセマンティクスは、[RFC4915]のセクション3.7で定義されている。MT-ID TLVの値がOSPFに由来する場合、MT-IDフィールドの上位Rビットは0に設定されなければならず(MUST)、MT-IDには0～127の値のみが有効である。

MT-ID TLVのフォーマットを次図に示す。

fig12
図12: マルチトポロジ識別子のTLVフォーマット

タイプは263、長さは2*n、nはTLVで伝送されるMT-IDの数である。

MT-ID TLVは、リンク・ディスクリプタとして、プレフィックス・ディスクリプタとして、またはノードNLRIのBGP-LS属性に含めてもよい(MAY)。リンク・ディスクリプタまたはプレフィックス・ディスクリプタとして含まれる場合、リンクまたはプレフィックスが到達可能なトポロジのMT-IDを含む1つのMT-ID TLVのみが許可される。あるリンクまたはプレフィックス・ディスクリプタに対して複数のトポロジを広告したい場合は、各NLRIに1つのユニークなMT-IDが含まれる複数のNLRIを生成しなければならない(MUST)。IS-ISのリンク・ディスクリプタまたはプレフィックス・ディスクリプタとして使用される場合、ビットRは予約されており、発信時には0([RFC5120]のセクション7.2に従って)に設定され、受信時には無視されなければならない(MUST)。

ノードNLRIのBGP-LS属性では、ノードが到達可能なすべてのトポロジのMT-IDの配列を含む1つのMT-ID TLVが許可される。IS-ISのノード属性TLVで使用される場合、ビットRは[RFC5120]のセクション7.1に従って設定される。

5.2.3. プレフィックス・ディスクリプタ

プレフィックス・ディスクリプタ・フィールドは、タイプ/長さ/値(TLV)のトリプレット・セットである。プレフィックス・ディスクリプタTLVは、ノードが生成したIPv4またはIPv6プレフィックスをユニークに識別する。次のTLVは、IPv4/IPv6プレフィックスNLRIでプレフィックス・ディスクリプタとして定義されている:

TLV
コード
ポイント		 説明 長さ 参照先
263 マルチトポロジ識別子 可変長 セクション5.2.2.1
264 OSPF経路タイプ 1 セクション5.2.3.1
265 IP到達性情報 可変長 セクション5.2.3.2

表5: プレフィックス・ディスクリプタのTLV

マルチトポロジ識別子TLVは、基礎となるIGPプレフィックス・オブジェクトがデフォルト以外のトポロジと関連付けられている場合、 プレフィックス・ディスクリプタに含めなければならない(MUST)。

5.2.3.1. OSPF経路タイプ

OSPF経路タイプ TLVは、OSPFから発信されたプレフィックスNLRIに対応するオプションのTLVである。プレフィックスのOSPF経路タイプを識別するために使用される。OSPFプレフィックスは、複数の経路タイプでOSPFドメインに広告してもよい(MAY)。経路タイプTLVにより、これらの広告を区別できる。OSPF経路タイプTLVは、そのタイプが基となるLSAで明示的に通知されるか、明示的に通知されない場合(例えば、OSPFv2拡張プレフィックスOpaque LSA [RFC7684]の場合)に、同じプレフィックスに対する別のLSAを介して決定できる場合に、広告に含めなければならない(MUST)。OSPFv2拡張プレフィックスTLV([RFC7684]のセクション2.1)で広告される経路タイプは、AS外部経路とNot-So-Stubby Area(NSSA)外部経路のタイプ1と2を区別しない。この場合、プレフィックスのOSPFv2外部LSAまたはNSSA外部LSAをチェックすることで、BGP-LS広告で使用する経路タイプを決定できる。OSPFv2拡張プレフィックスTLVに経路タイプ値0が含まれている場合、ベースとなるOSPFv2 LSAについても同様のチェックを行い、使用する経路タイプを決定することができる。

OSPF経路タイプTLVの形式を次の図に示す。

fig13
図13: OSPF経路タイプのTLV形式

TLVのタイプ・フィールドと長さフィールドは、表5で定義されている。経路タイプ フィールドは、OSPFプロトコルで定義されている経路タイプに従い、以下のいずれかになる:

  • エリア内 (0x1)
  • エリア間 (0x2)
  • 外部1 (0x3)
  • 外部2 (0x4)
  • NSSA 1 (0x5)
  • NSSA 2 (0x6)
5.2.3.2. IP到達性情報

IP到達性情報TLVは、IPv4およびIPv6プレフィックスNLRIタイプの必須TLVである。TLVには、IGPトポロジで最初に広告された1つのIPアドレス・プレフィックス(IPv4またはIPv6)が含まれる。ルータは、BGPネクストホップごとにIPプレフィックスNLRIを広告する必要がある(SHOULD)。IP到達性情報TLVのフォーマットを次の図に示す:

fig14
図14: IP到達性情報のTLVフォーマット

TLVのタイプ・フィールドと長さフィールドは、表5に定義されている。以下の2つのフィールドは、アドレスファミリーの到達性情報を決定する。「プレフィックス長」フィールドはプレフィックスの長さをビット単位で含む。IPプレフィックス・フィールドは、IPアドレス・プレフィックスと、その後にフィールドの終わりがオクテット境界に収まるように必要な最小数の末尾ビットを含む。後続ビットはすべて0に設定しなければならない(MUST)。したがって、IPプレフィックス・フィールドには、プレフィックスの最上位オクテットが含まれる。すなわち、プレフィックス長1から8までの場合は1オクテット、プレフィックス長9から16までの場合は2オクテット、プレフィックス長17から24までの場合は3オクテット、プレフィックス長25から32までの場合は4オクテットなどである。

5.3. BGP-LS属性

BGP-LS属性(IANAによって値29が割り当てられた)は、リンク、ノード、プレフィックスのパラメータと属性を伝送するために使用される、オプションの非推移的BGP属性である。次のセクションで説明するように、タイプ/長さ/値(TLV)のトリプレット・セットとして定義される。この属性はリンクステートNLRIにのみ含めるべきである(SHOULD)。他のアドレスファミリーにこの属性を使用することは、本文書の範囲外である。

ノード属性TLV、リンク属性TLV、プレフィックス属性TLVは、それぞれノードNLRI、リンクNLRI、プレフィックス NLRIに関連付けられたBGP-LS属性で符号化される可能性があるTLVセットである。

BGP-LS属性のサイズは、1つのリンクステートNLRIに関連付けられたリンクステート情報の量に応じて、大きくなる可能性がある。BGP仕様[RFC4271]では、BGPメッセージの最大サイズを4096オクテットと定めている。BGP-LS属性内のより大きなサイズの情報に対応するために、実装がBGP[RFC8654]の拡張メッセージ・サイズをサポートすることが推奨される(RECOMMENDED)。BGP-LSプロデューサーは、BGP-LS属性に含まれるTLVが、1つのリンクステートNLRIに対するBGP UPDATEメッセージでBGPメッセージの最大制限を超えないようにしなければならない(MUST)。

実装は、BGP-LSコンシューマのアプリケーションの要件に基づいて、この問題を回避するメカニズムを採用してもよい(MAY)。このメカニズムは、本仕様の範囲外である。ただし、実装がBGP-LS属性からいくつかのTLVを除外することでこの問題を軽減することを選択した場合、この除外は、BGP-LSドメイン内のすべてのBGP-LSプロデューサーによって一貫して行われる必要がある(SHOULD)。BGP-LS属性からTLVを除外することに一貫性がない場合、BGP-LSプロパゲータのBGP決定プロセスに基づいて、BGP-LSコンシューマに伝播されるリンクステート・オブジェクトの属性セットが異なる結果となる。

BGP-LSプロパゲータが、他のBGP属性(AS_PATHなど)の追加や更新のために最大BGPメッセージ・サイズを超えていることに気付いた場合、そのBGP-LS属性を不正とみなし、「属性破棄(Attribute Discard)」エラー処理アプローチ[RFC7606]を適用し、セクション8.2.2で説明するように伝搬を処理しなければならない(MUST)。BGP-LSプロパゲータが、[RFC8654]のセクション4で規定されているように、 BGP UPDATEメッセージ・サイズを小さくするために「属性破棄」を実行する必要がある場合、セクション8.2.2に記載しているように、このエラー状態の検出と診断を可能にするために、最初にBGP-LS属性を破棄しなければならない(MUST)。これにより、4096オクテットを超えるBGP UPDATEメッセージ・サイズによるBGP-LS情報の一貫した伝播は、[RFC8654]の内容をすべてサポートするBGPスピーカーに沿ってのみ発生するという展開上の考慮事項がもたらされる。

5.3.1. ノード属性TLV

ノードNLRIに関連するBGP-LS属性には、以下のノード属性TLVが定義されている:

TLV
コード
ポイント		 説明 長さ 参照先
263 マルチトポロジ識別子 可変長 セクション5.2.2.1
1024 ノード・フラグ・ビット 1 セクション5.3.1.1
1025 Opaqueノード属性 可変長 セクション5.3.1.5
1026 ノード名 可変長 セクション5.3.1.3
1027 IS-ISエリア識別子 可変長 セクション5.3.1.2
1028 ローカル・ノードのIPv4ルータID 4 [RFC5305]セクション4.3
1029 ローカル・ノードのIPv6ルータID 16 [RFC6119]セクション4.1

表6: ノード属性TLV

5.3.1.1. ノード・フラグ・ビットTLV

ノード・フラグ・ビットTLVは、ノード属性を記述するビットマスクを運ぶ。値はフラグの1オクテット長のビット配列で、各ビットはノードの動作状態または属性を表す。

fig15
図15: ノード・フラグ・ビットのTLVフォーマット

ビットは以下のように定義されている:

ビット 説明 参照先
O オーバーロード・ビット [ISO10589]
A 付属ビット [ISO10589]
E 外部ビット [RFC2328]
B ABRビット [RFC2328]
R ルータ・ビット [RFC5340]
V V6ビット [RFC5340]

表7: ノード・フラグ・ビットの定義

定義されていないビットは、発信側で0に設定されなければならず(MUST)、受信側で無視されなければならない(MUST)。

5.3.1.2. IS-ISエリア識別子TLV

IS-ISノードは、1つのIS-ISエリアのみ属することができる。しかし、ノードは複数の同義のエリア・アドレスを持つことができる。これらの各エリア・アドレスは、IS-ISエリア識別子TLVで伝送される。複数のエリア・アドレスが存在する場合、それらを符号化するために複数のTLVを使用する。IS-ISエリア識別子TLVは、リンクステート・ノードNLRIで広告される場合にのみ、BGP-LS属性に存在する。

fig16
図16: IS-ISエリア識別子のTLVフォーマット

5.3.1.3. ノード名TLV

ノード名TLVはオプションである。ノード名の符号化セマンティクスは[RFC5301]から借用した。[値]フィールドは、ルータノードのシンボル名を識別する。このシンボリック名は、ルータの完全修飾ドメイン名(FQDN)、FQDNの部分文字列(ホスト名など)、またはオペレータがルータに使用したい任意の文字列にすることができる。FQDNまたはその部分文字列を使用することが強く推奨される(RECOMMENDED)。ノード名TLVの最大長は255オクテットである。

値フィールドは7ビットASCIIで符号化される。このフィールドを設定または表示するためのユーザ・インタフェースでUnicode文字を許可している場合、ユーザ・インタフェース、[RFC5890]で説明されているように、ToASCIIおよび/またはToUnicodeアルゴリズムを適用して、送信または表示に適した書式を実現する責任を負う。

[RFC5301]はIS-IS固有の拡張について説明しており、[RFC5642]はノード名TLVで符号化できるノード名の広告のためのOSPF拡張について説明している。

fig17
図17: ノード名の形式

5.3.1.4. ローカルIPv4/IPv6ルータID TLV

ローカルIPv4/IPv6ルータID TLVは、IGPが使用する可能性のある補助ルータIDを記述するために使用する。補助ルータIDは、例えば、異なるプロトコル間でノードIDを関連付けるなど、TEや移行の目的で使用される。特定のタイプの補助ルータIDが複数ある場合、それぞれが別個のTLVとして符号化される。

5.3.1.5. Opaqueノード属性TLV

Opaqueノード属性TLVは、ルータによって広告されるオプションのノード属性TLVを透過的に伝送するエンベロープである。発信元ルータは、NLRIヘッダのプロトコルIDフィールドで広告されたプロトコルに固有の情報、またはNLRIヘッダのプロトコルIDフィールドで広告されたプロトコルの新しいプロトコル拡張で、BGPリンクステートNLRIにプロトコル・ニュートラルな表現が存在しないものを符号化するために、この TLVを使用しなければならない。Opaqueノード属性TLVの主な用途は、新しいIGPリンクステート属性と、定義されているプロトコル・ニュートラルなBGP-LS拡張との間の文書化の遅れを橋渡しすることである。プロトコル・ニュートラルなBGP-LS拡張が定義された後も、BGP-LSの実装は、増分展開と移行のために、Opaque属性TLVと新しいTLV定義の両者で情報を広告する必要があるかも知れない。

OSPFの場合、このTLVは、OSPFルータ情報(RI)LSA[RFC7770]内のTLV以外のTLVを広告するために使用してはならない(MUST NOT)。

fig18
図18: Opaqueノード属性フォーマット

タイプは表6に指定されているとおりである。長さは可変である。

5.3.2. リンク属性TLV

リンク属性TLVは、リンクNLRIを使用してBGP-LS属性で符号化されるTLVである。各「リンク属性」は、セクション5.1で定義されているようにフォーマットされたタイプ/長さ/値(TLV)のトリプレットである。いくつかのリンク属性TLVの値フィールドの書式とセマンティクスは、[RFC5305]と[RFC5307]で定義されているIS-IS拡張IS到達性サブTLVの値フィールドの書式とセマンティクスに対応している。他のリンク属性TLVは本文書で定義されている。リンク属性TLVの符号化はもともとIS-IS用に定義されていたが、TLVはIS-ISまたはOSPFのいずれかをソースとするデータを伝送できる。

以下のリンク属性TLVは、リンクNLRIに関連付けられたBGP-LS属性に対して定義されている:

TLV
コード
ポイント		 説明 IS-IS TLV/
Sub-TLV		 参照先
1028 ローカル・ノードのIPv4ルータID 134/--- [RFC5305]セクション4.3
1029 ローカル・ノードのIPv6ルータID 140/--- [RFC6119]セクション4.1
1030 リモート・ノードのIPv4ルータID 134/--- [RFC5305]セクション4.3
1031 リモート・ノードのIPv6ルータID 140/--- [RFC6119]セクション4.1
1088 管理グループ (カラー) 22/3 [RFC5305]セクション3.1
1089 最大リンク帯域幅 22/9 [RFC5305]セクション3.4
1090 最大予約可能なリンク帯域幅 22/10 [RFC5305]セクション3.5
1091 予約されていない帯域幅 22/11 [RFC5305]セクション3.6
1092 TEデフォルト・メトリック 22/18 セクション5.3.2.3
1093 リンク保護タイプ 22/20 [RFC5307]セクション1.2
1094 MPLSプロトコル・マスク ─ セクション5.3.2.2
1095 IGPメトリック ─ セクション5.3.2.4
1096 共有リスク・リンク・グループ ─ セクション5.3.2.5
1097 Opaqueなリンク属性 ─ セクション5.3.2.6
1098 リンク名 ─ セクション5.3.2.7

表8: リンク属性TLV

5.3.2.1. IPv4/IPv6 ルータID TLV

ローカル/リモートIPv4/IPv6ルータID TLVは、IGPが TE目的などで使用するかも知れない補助ルータIDを記述するために使用される。ローカルノードとリモートノードのすべての補助ルータIDが、各リンクNLRIのリンク属性に含まなければならない(MUST)。あるタイプの補助ルータIDが複数ある場合、それらを符号化するために複数のTLVが使用される。

5.3.2.2. MPLSプロトコル・マスクTLV

MPLSプロトコル・マスクTLVは、どのMPLSシグナリング・プロトコルが有効かを記述するビットマスクを伝送する。このTLVの長さは1である。値は8つのフラグのビット配列で、各ビットはMPLSプロトコルの機能を表す。

MPLSプロトコル・マスクTLVの生成は、例えば、表2にあるようなプロトコルIDの「静的構成」や「直接」のような、ローカルリンクの洞察力を持つ発信者に対してのみ有効であり、その発信者に対してのみ使用する必要がある(SHOULD)。MPLSプロトコル・マスクTLVは、表2にリストされた他のプロトコルIDを持つNLRIに含めてはならない(MUST NOT)。

fig19
図19: MPLSプロトコル・マスクTLV

以下のビットが定義されており、予約ビットはゼロに設定しなければならず(MUST)、受信時に無視する必要がある(SHOULD)。

ビット 説明 参照先
L ラベル配布プロトコル (LDP) [RFC5036]
R トンネル用 RSVP の「R」拡張 (RSVP-TE) [RFC3209]

表9: MPLSプロトコル・マスクTLVコード

定義されていないビットは、発信者によって0に設定しなければならず(MUST)、受信者は無視しなければならない(MUST)。

5.3.2.3. TEのデフォルト・メトリックTLV

TEデフォルト・メトリックTLVは、このリンクのトラフィック・エンジニアリング・メトリックを伝送する。このTLVの長さは4オクテットに固定される。ソース・プロトコルが32ビット未満のメトリック幅を使用する場合、このフィールドの上位ビットはゼロでパディングしなければならない(MUST)。

fig20
図20: TEのデフォルト・メトリックTLVフォーマット

5.3.2.4. IGPメトリック TLV

IGPメトリックTLVは、このリンクのメトリックを伝送する。このTLVの長さは、基礎となるプロトコルのメトリック幅に応じて可変である。IS-ISの小さなメトリックのサイズは6ビットだが、1オクテット・フィールドで符号化される。したがって、フィールドの最上位2ビットは発信側で0に設定しなければならず、受信側では無視しなければならない。OSPFリンク・メトリックの長さは2オクテットである。IS-ISのワイド・メトリックの長さは3オクテットである。

fig21
図21: IGPメトリックTLVフォーマット

5.3.2.5. 共有リスク・リンク・グループTLV

共有リスク・リンク・グループ(SRLG)TLVは、共有リスク・リンク・グループ情報を伝送する([RFC4202]のセクション2.3(「共有リスク・リンク・グループ情報」)を参照)。図22に示すように、SRLG値の(変数)リストで構成されるデータ構造を含み、リストの各要素は4オクテットを持つ。このTLVの長さは4*(SRLG値の数)である。

fig22
図22: 共有リスク・リンク・グループのTLVフォーマット

OSPF-TEのSRLG TLVは[RFC4203]で定義されている。IS-ISでは、SRLG情報は、[RFC5307]で定義されたGMPLS-SRLG TLV(IPv4用)(タイプ138)と[RFC6119]で定義されたIPv6 SRLG TLV(タイプ139)の2つの異なるTLVで伝送される。IPv4とIPv6の両方のSRLG情報が1つのTLVで伝送される。

5.3.2.6. Opaqueリンク属性TLV

Opaqueリンク属性TLVは、ルータによって広告されるオプションのリンク属性TLVを透過的に伝送するエンベロープである。発信元ルータは、NLRIヘッダのプロトコルIDフィールドで広告されるプロトコルに固有の情報、またはBGPリンクステートNLRIにプロトコル・ニュートラルな表現がない、NRLIヘッダのプロトコルIDフィールドで広告されるプロトコルへの新しいプロトコル拡張を符号化するために、このTLVを使用しなければならない。Opaqueリンク属性TLVの主な用途は、新しいIGPリンクステート属性とその「プロトコル・ニュートラル」BGP-LS属性が定義される間の文書ラグをブリッジすることである。プロトコル・ニュートラルなBGP-LS拡張が定義された後も、BGP-LSの実装は、Opaque属性TLVと増分展開と移行のために、Opaque属性TLVと新しいTLV定義の両方で情報を広告する必要があるかも知れない。

OSPFv2の場合、このTLVは、OSPFv2拡張リンクOpaque LSA[RFC7684]以外のTLVを使って伝送される情報を広告するために使用してはならない(MUST NOT)。OSPFv3の場合、このTLVはOSPFv3 E-Router-LSAまたはE-Link-LSA[RFC8362]のTLV以外のTLVを広告するために使用してはならない(MUST NOT)。

fig23
図 23: Opaqueリンク属性のTLVフォーマット

5.3.2.7. リンク名TLV

リンク名TLVはオプションである。[値]フィールドは、ルータ・リンクのシンボリック名を識別する。このシンボリック名は、リンクのFQDN、FQDNの部分文字列、またはオペレータがリンクに使用する任意の文字列を指定できる。FQDNまたはその部分文字列の使用が強く推奨される(RECOMMENDED)。リンク名TLVの最大長は255オクテットである。

値フィールドは7ビットASCIIで符号化される。このフィールドを設定または表示するためのユーザ・インタフェースがUnicode文字を許可する場合、そのユーザ・インタフェースは、[RFC5890]で説明されているようにToASCIIおよび/またはToUnicodeアルゴリズムを適用して、送信または表示用のための正しいフォーマットを実現する責任を負う。

ルータがどのようなリンク名を導出し、注入するかは、本文書の範囲外である。

fig24
図 24: リンク名のTLV形式

5.3.3. プレフィックス属性TLV

プレフィックスは、 IGPトポロジ(IS-ISまたはOSPF)から IGP属性(メトリック、経路タグなど)セットで学習され、プレフィックスNLRIタイプ3および4を持つBGP-LS属性で広告される。

次のプレフィックス属性TLVは、プレフィックスNLRIに関連付けられたBGP-LS属性に対して定義されている:

TLV
コード
ポイント		 説明 長さ 参照先
1152 IGPフラグ 1 セクション5.3.3.1
1153 IGP経路タグ 4\times n [RFC5130]
1154 拡張経路タグ 8\times n [RFC5130]
1155 プレフィックス・メトリック 4 [RFC5305]
1156 OSPFフォワーディング・アドレス 4 [RFC2328]
1157 Opaqueプレフィックス属性変数 可変長 セクション5.3.3.6

表10: プレフィックス属性TLV

5.3.3.1. IGPフラグTLV

IGPフラグTLVは、元々プレフィックスに割り当てられていた1オクテットのIS-ISおよびOSPFのフラグとビットを含んでいる。IGPフラグTLVは次のように符号化される:

fig25
図25: IGPフラグTLVフォーマット

値フィールドは、以下の表に従って定義されたビットを含む:

ビット 説明 参照先
D IS-ISアップ/ダウン・ビット [RFC5305]
N OSPF「ユニキャストなし」ビット [RFC5340]
L OSPF「ローカル・アドレス」ビット [RFC5340]
P OSPF「NSSAの伝播」ビット [RFC5340]

表11: IGPフラグ・ビットの定義

定義されていないビットは、発信側で0に設定されなければならず(MUST)、受信側では無視しなければならない(MUST)。

5.3.3.2. IGP経路タグTLV

IGP経路タグTLVは、プレフィックスの元のIGPタグ(IS-IS[RFC5130]またはOSPF)を伝送し、次のように符号化される:

fig26
図26: IGP経路タグのTLVフォーマット

長さは4の倍数である。

値フィールドには、IGPトポロジで学習された1つ以上の経路タグを含む。

5.3.3.3. IGP拡張経路タグTLV

IGP拡張経路タグTLVは、プレフィックス[RFC5130]のIS-IS拡張経路タグを伝送し、以下のように符号化される:

fig27
図27: IGP拡張経路タグTLVフォーマット

長さは8の倍数である。

拡張経路タグ・フィールドは、IGPトポロジで学習された1つ以上の拡張経路タグを含む。

5.3.3.4. プレフィックス・メトリックTLV

プレフィックス・メトリックTLVはオプションの属性であり、一度だけ現れる。存在する場合、[RFC5305]のセクション4で記載しているように、IGPトポロジーで知られているプレフィックスのメトリックを伝送する(したがって、プレフィックスへの到達性コストを表す)。存在しない場合は、そのプレフィックスが到達性なしに広告されていることを意味する。

fig28
図28: プレフィックス・メトリックTLV形式

長さは4である。

5.3.3.5. OSPFフォワーディング・アドレスTLV

OSPFフォワーディング・アドレスTLV[RFC2328] [RFC5340]は、元のOSPF広告で知られているOSPFフォワーディング・アドレスを伝送する。フォワーディング・アドレスはIPv4またはIPv6のいずれかである。

fig29
図29: OSPFフォワーディング・アドレスTLV形式

長さは、IPv4フォワーディング・アドレスの場合は4、IPv6フォワーディング・アドレスの場合は16である。

5.3.3.6. Opaqueプレフィックス属性TLV

Opaqueプレフィックス属性TLVは、ルータが広告するオプションのプレフィックス属性TLVを透過的に伝送するエンベロープである。発信元ルータは、NLRIヘッダのプロトコルIDフィールドで広告されるプロトコルに固有の情報を符号化するためにこのTLVを使用するか、BGPリンクステートNLRIにニュートラルな表現がないNLRIヘッダのプロトコルIDフィールドで広告されるプロトコルの新しいプロトコル拡張を使用する。Opaqueプレフィックス属性TLVの主な用途は、新しいIGPリンクステート属性と、定義されているプロトコル・ニュートラルな BGP-LS拡張との間の文書ラグを橋渡しすることである。プロトコル・ニュートラルな BGP-LS拡張が定義された後も、BGP-LS実装は、増分展開と移行のために、Opaque属性TLVと新しいTLV定義の両方で情報を広告する必要があるかも知れない。

OSPFv2の場合、このTLVは、OSPFv2拡張プレフィックスOpaque LSA[RFC7684]に含まれるTLV以外のTLVを使用して伝送される情報を広告するために使用してはならない(MUST NOT)。OSPFv3の場合、このTLVは、OSPFv3 E-Inter-Area-Prefix-LSA、E-Intra-Area-Prefix-LSA、E-AS-External-LSA、および E-NSSA-LSA [RFC8362]以外のTLVを広告するために使用してはならない(MUST NOT)。

TLVのフォーマットは以下のとおりである:

fig30
図30: Opaqueプレフィックス属性のTLVフォーマット

タイプは表10に指定されているとおりである。長さは可変である。

5.4. プライベート使用

ベンダーのプライベート使用のためのTLVは、セクション7で示されているように予約されたコードポイント範囲を使ってサポートされる。NLRIまたはBGP-LS属性でこのようなTLVの使用する場合、セクション5.1で説明されているフォーマットを使用し、エンタープライズ・コードを伝える値の最初のフィールドとして4オクテットのフィールドを含まなければならない(MUST)。プライベート使用のNLRIタイプの場合、4オクテットのフィールドを、セクション5.2で説明されているリンクステートNLRIフォーマットのトータルNLR長フィールドの直後のNLRIの最初のフィールドとして含め、エンタープライズ・コード[ENTNUM]を伝送しなければならない(MUST)。これにより、ベンダ固有の拡張を競合することなく使用することができる。

プライベート使用TLVの複数のインスタンスがBGP-LS属性に現れてもよい (MAY)。

5.5. BGPネクストホップ情報

IPv4とIPv6ネットワークの両方のBGPリンクステート情報は、IPv4 BGPセッションまたはIPv6 BGPセッションのいずれかで伝送することができる。IPv4 BGPセッションを使用する場合、MP_REACH_NLRIのネクストホップはIPv4アドレスである必要がある(SHOULD)。同様に、IPv6 BGPセッションを使用する場合、MP_REACH_NLRIのネクストホップはIPv6アドレスである必要がある(SHOULD)。通常、ネクストホップはBGPセッションのローカル・エンドポイント・アドレスに設定される。ネクストホップ・アドレスは、[RFC4760]で説明されているように符号化しなければならない(MUST)。ネクストホップ・アドレスの長さフィールドは、ネクストホップ・アドレス・ファミリを指定する。ネクストホップの長さが4の場合、ネクストホップはIPv4アドレスである。ネクストホップの長さが16の場合、グローバルIPv6アドレスである。ネクストホップの長さが32の場合、グローバルIPv6アドレスが1つあり、その後にIPv6リンクローカル・アドレスが続く。IPv6リンクローカル・アドレスは、[RFC2545]の記述に従って使用する必要がある。VPN後続アドレスファミリー識別子 (SAFI)の場合、慣行に従って、すべてゼロに設定された8バイトの経路識別子がネクストホップの先頭に付加される。

BGPネクストホップは、各BGP-LSスピーカーが受信したNLRIを検証するために使用する。同一のNLRIが複数のBGP-LSプロデューサーから送信された場合、BGP ネクストホップは標準的なBGPパス決定プロセスに従って、タイブレークが行われる。この仕様は、BGPネクストホップの書き換えに関するルールを強制しない。

5.6. AS間リンク

TE情報の主なソースはIGPだが、AS間リンクではアクティブではない。場合によっては、IGPはAS間リンクの情報を持っていることがある[RFC5392] [RFC9346]。他のケースでは、実装はBGP-LSにAS間リンクを注入する手段を提供する必要がある(SHOULD)。AS間リンクを広告するために使用される正確なメカニズムは、本文書の範囲外である。

5.7. OSPF仮想リンクと擬似リンク

OSPF[RFC2328] [RFC5340]ネットワークでは、OSPF仮想リンクはバックボーンの物理的に別々のコンポーネントを接続して、バックボーン・エリアの連続性を確立/維持する役割を果たす。OSPF仮想リンクは、OSPFトポロジのポイントツーポイントの番号なしリンクとしてモデル化されているが、その特性と目的はOSPFトポロジの他のタイプのリンクとは異なる。これらは、OSPF LSAの個別の「仮想リンク」タイプを使って広告される。BGP-LSによるOSPF仮想リンクの広告メカニズムは、本文書の範囲外である。

OSPFネットワークでは、仮想(sham)リンク[RFC4577] [RFC6565]は、プロバイダ・エッジ(PE)ルータ上のVPN Routing and Forwarding (VRF)インスタンス間で、VPNプロバイダのネットワークを介したエリア内接続を提供するために使われる。これらのリンクは、ポイントツーポイントの番号なしリンクとしてOSPFで広告され、MPLSのようなカプセル化メカニズムを使ったサービス・プロバイダ・ネットワーク上の接続性を表す。そのため、OSPFの仮想リンクの広告メカニズムは、本文書で前述したように、他のポイントツーポイントの番号なしリンクと同じ手順に従う。

5.8. OSPFv2タイプ4サマリーLSAとOSPFv3エリア間ルータLSA

OSPFv2[RFC2328]はタイプ4サマリーLSAを定義し、OSPFv3[RFC5340]はエリア・ボーダー・ルータ(ABR)が、エリアの外部にありながら、まだ AS の内部にあるASボーダー・ルータ(ASBR)への到達性を広告するためのエリア間ルータLSAを定義している。このタイプのLSAを使用してOSPFが広告する情報の性質は、この文書で説明するように、ノード、リンク、プレフィックスのいずれにもマッピングされない。したがって、これらのLSAが伝送する情報の広告のメカニズムは、本文書の範囲外である。

5.9. 到達不能なIGPノードの処理

図31に示すようなOSPFネットワークを考える。ここで、R2とR3はBGP-LSプロデューサーであり、OSPFエリア・ボーダー・ルータ(ABR)でもある。R2とR3の間のリンクはエリア0にあり、他のリンクは、リンクに対してそれぞれa0とa1の参照で示されるように、エリア1にある。

BGP-LSコンシューマーは、BGPルート・リフレクタRR0と通信する。RR0は、BGP-LSプロデューサーR2とR3からのBGP-LSフィードを集約するBGP-LSプロパゲータである。ここで、R2とR3は、BGP-LSを介してRR0に冗長トポロジー・フィードを提供する。通常、RR0は、R2とR3の両方からすべてのリンクステートNLRIの2つの同じコピーを受信し、標準的なBGP決定プロセスに基づいてそのうちの1つ(例えばR2)を選択する。

fig31
図31: BGPパス選択による間違ったレポート

R5とR6間のリンクが失われる(それによってエリア1が分割される)シナリオを考え、R2とR3のOSPF LSDBへの影響を考える。

ここで、R5はそのルータLSAからリンクR5-R6を削除し、この更新されたLSAはR2で利用できる。R2は、R6のルータLSAの古いコピーを持っており、そこにはR6-R5のリンクがまだ残っている。R2は、LSDBのこのビューに基づき、R6の古くなったルータLSAから派生したハーフリンクR6-R5のみを広告する。

同時に、R6はそのルータLSAからリンクR6-R5を削除し、この更新されたLSAはR3で利用できる。同様に、R3はリンクR5-R6を含むR5のルータLSAの古くなったコピーを持っている。R3はLSDBに基づいて、R5の古くなったルータLSAから派生したハーフリンクR5-R6のみを広告する。

ここで、BGP-LSコンシューマは、R2とR3からRR0経由でハーフリンクに対応するリンクNLRIを両方受信する。これを一緒に見ると、BGP-LSコンシューマはエリア1が分割されていることに気付かない。また、R2がR4とR6のルータLSAの古くなったコピーに対応するノードとプレフィックスのNLRIを報告し続ける場合、RR0のBGP決定プロセスによって、R3から受信しているR4とR6の有効なノードとプレフィックスのNLRIよりも、RR0がそれらを優先する可能性がある。この結果、BGP-LSコンシューマは古く不正確なトポロジー情報を取得することになる。R2がR4とR6に対応するリンクステート情報を広告せず、R3がR1とR5についても同様に広告しなければ、この問題シナリオは回避される。

BGP-LSプロデューサーは、対応するLSP/LSAを発信したノードがIGPで到達不能になったと判断された場合、BGPで広告したすべてのリンクステート・オブジェクトを取り下げる必要がある(SHOULD)。実装は、BGP-LSコンシューマが完全なIGP LSDBビューに対応するトポロジー・フィードの受信に関心がある展開ユースケースにおいて、到達不能なノードに対応するリンクステート・オブジェクトの広告を継続してもよい(MAY)。このような展開では、BGP-LSプロデューサー・ノードと直接的なBGPピアリングを行うか、 RRを使用する場合は[RFC7911]に記載されているようなメカニズムを使用することに加え、BGP-LSコンシューマがこのようなトポロジー・フィードを適切に処理することで、上記の問題が軽減されることが期待される。これらのメカニズムの詳細は、本文書の範囲外である。

もし、BGP-LSプロデューサーが、あるIGPノードに対する到達性チェックの失敗に基づいて、そのIGPノードに関連するリンクステート・オブジェクトを撤回した場合、そのノードがIGPドメイン内で再び到達可能になった後に、それらのリンクステート・オブジェクトを再広告しなければならない(MUST)。

5.10. ルータIDアンカリングの例: ISO擬似ノード

IS-ISにおけるブロードキャストLANの符号化は、ルータIDがどのように符号化されるかを示す良い例となる。図32を考えてみよう。これは、ルータのペア間のブロードキャストLANを表している。「実際の」(非擬似ノード)ルータは、IPv4ルータIDとIS-ISノードIDの両方を持っている。擬似ノードにはIPv4ルータIDはない。Node1はLANのDISである。(Node1、Pseudonode1)と(Pseudonode1、Node2)の2つの1方向リンクが生成される。

(Node1, Pseudonode1)のリンクNLR 以下のように符号化される。ローカル・ノード・ディスクリプタのIGPルータID TLVは6オクテット長で、Node1のISO-ID、1920.0000.2001を含む。リモート・ノード・ディスクリプタのIGPルータID TLVは7オクテット長で、Pseudonode1のISO-ID、1920.0000.2001.02を含む。このリンクのBGP-LS属性は、Node1のIPv4ルータID192.0.2.1を含むローカルIPv4ルータID TLV(TLVタイプ1028)を1つ含む。

(Pseudonode1、Node2)のリンクNLRIは以下のように符号化される。ローカル・ノード・ディスクリプタのIGPルータID TLVは7オクテット長で、Pseudonode1のISO-ID、1920.0000.2001.02を含む。リモート・ノード・ディスクリプタのIGPルータID TLVは6オクテット長で、Node2のISO-ID、1920.0000.2002を含む。このリンクのBGP-LS属性は、Node2のIPv4ルータID 192.0.2.2を含むリモートIPv4ルータID TLV(TLVタイプ1030)を1つ含む。

fig32
図32: IS-IS擬似ノード

5.11. ルータIDアンカリングの例: OSPF擬似ノード

OSPFにおけるブロードキャストLANの符号化は、ルータIDとローカル・インタフェースIPがどのように符号化されるかを示す良い例となる。図33を考えてみる。これは、ペアのルータ間のブロードキャストLANを表している。「実際の」(非擬似ノード)ルータは、IPv4ルータIDとエリア識別子の両方を持っている。擬似ノードは、IPv4ルータID、IPv4インタフェース・アドレス(曖昧さ回避のため)、およびOSPFエリアを持っている。Node1はLANのDRであるため、そのローカルIPアドレス198.51.100.1が疑似ノード・キーのルータIDとインタフェースIPの両方として使用される。2つの単方向リンク(Node1、Pseudonode1)と(Pseudonode1、Node2)が生成される。

(Node1、Pseudonode1)のリンクNLRIは以下のように符号化される:

  • ローカル・ノード・ディスクリプタ
    TLV #515: IGPルータID: 192.0.2.1
    TLV #514: OSPFエリアID: ID:0.0.0.0
  • リモート・ノード・ディスクリプタ
    TLV #515: IGPルータID: 192.0.2.1:198.51.100.1
    TLV #514: OSPFエリアID: ID:0.0.0.0

(Pseudonode1、Node2)のリンクNLRIは以下のように符号化される:

  • ローカル・ノード・ディスクリプタ
    TLV #515: IGPルータID: 192.0.2.1:198.51.100.1
    TLV #514: OSPFエリアID: ID:0.0.0.0

  • リモート・ノード・ディスクリプタ
    TLV #515: IGPルータID: 192.0.2.2
    TLV #514: OSPFエリアID: ID:0.0.0.0

fig33
図33: OSPF擬似ノード

LANサブネット198.51.100.0/24は、Node1またはNode2のルータLSAには含まれていない。DR Node1が広告するこのLANのネットワークLSAには、DRアドレスとともにLANのサブネットマスクが含まれている。LANのサブネットに対応するプレフィックスNLRIは、ネットワークLSAのDRアドレスとサブネットマスクを使用して、ローカルノードとして使用されるPseudonode1が広告する。

5.12. ルータIDアンカーの例: OSPFv2からIS-ISへのマイグレーション

あるIGPから別のIGPへのグレースフルなマイグレーションでは、マイグレーション期間中の両方のプロトコルの協調動作させる必要がある。このような調整には、両方のIGPで特定の物理リンクを識別する必要がある。IPv4ルータIDは、OSPFリンクNLRIのノード・ディスクリプタとIS-ISリンクNLRIのリンク属性に存在する「接着剤(glue)」を提供する。

2台のルータAとB間のポイントツーポイント・リンクを考える。これらのルータは、最初はOSPFv2だけのルータだったが、その後IS-ISが有効になった。ノードAはIPv4ルータIDとISO-IDを持ち、ノードBは、IPv4ルータID、IPv6ルータID、ISO-IDを持つ。各プロトコルはリンク(A、B)に対して1つのリンクNLRIを生成し、その両方がBGP-LSによって伝送される。リンクに対するOSPFv2リンクNLRIは、ローカルおよびリモートのノード・ディスクリプタ内において、それぞれノードAおよびBのIPv4ルータIDで符号化される。リンクのIS-ISリンクNLRIは、ローカルおよびリモートのノード・ディスクリプタでそれぞれノードAおよびBのISO-IDで符号化される。さらに、IS-ISリンクNLRIのBGP-LS属性は、ノードAのIPv4ルータIDを含むTLVタイプ1028、ノードBのIPv4ルータIDを含むTLVタイプ1030、およびIPv6ルータIDを含むTLVタイプ1031が含まれている。この場合、IPv4ルータIDを使うことで、IS-ISプロトコルとOSPFプロトコルの両方でリンク(A、B)を識別することができる。

6. パス集約へのリンク

グローバル・インターネットで利用可能なすべてのリンクを伝播させることは確かに可能である。しかし、スケーリングやプライバシの観点からは望ましくない。したがって、実装はパス集約へのリンクをサポートしてもよい。ASBRは、ドメインのすべての個別のリンクを広告するのではなく、隣接しないノードのペア間の「集約リンク」を広告する場合がある。「集約リンク」は、隣接しないノードのペア間のリンク特性の集約セットを表す。パスの特性(帯域幅、メトリックなど)を計算する実際の方法は、本文書の範囲外である。すべての個別のリンクを広告するか、集約リンクを広告するかは、オペレータのポリシー選択で決まる。さまざまなレベルの危険性を強調するために、次の導入例を説明する。

6.1. 例: リンク集約なし

図34を考えてみる。AS1とAS2のオペレータは共にRSVP - 高速リルート(RSVP-FRR)LSPを使って、AS間{R1、R3}、{R2、R4}リンクを保護したいと考えている。R1がR3へのリンク保護LSPを計算したい場合は、R3への代替パスを「確認」する必要がある。したがって、AS2のオペレータはそのトポロジーを公開する。AS1内のすべてのBGP-TE対応ルータはAS2の完全なトポロジを「参照」することができ、したがって、バックアップ・パスを計算できる。計算処理ルータは、{R3, R4}間の直接リンクを使用するか、{R4, R5, R3}パスを使用するかを決定することに留意する。

fig34
図34: リンク集約なし

6.2. 例: ASBRからASBRへのパス集約

「リンク集約なし」の例と、この例の簡単な違いは、個別のリンクが露出していないことである。図35を考えてみる。AS2によって広告される唯一のリンクは、R3とR4の間の「集約」リンクである。AS1にバックアップ・パスがあることを伝えるには、これで十分である。しかし、実際に使用されているリンクはトポロジーから隠されている。

fig35
図35: ASBRのリンク集約

6.3. 例: マルチASのパス集約

複数のASを管理するサービス・プロバイダは、内部AS間リンクを露出しないことを決定する場合もある。図 36を考えてみる。AS3は、集約ドメインのボーダー・ルータに接続する1つのノードとしてモデル化されている。

fig36
図36: マルチAS集約

7. IANAに関する考慮事項

本文書は[RFC7752]と[RFC9029]を廃止するため、IANAはこれらの文書を参照するすべての登録情報を更新し、代わりに本文書を参照するようにした。

IANAは、「Address Family Numbers」レジストリにアドレス・ファミリー番号16388(BGP-LS)を割り当てた。

IANAは、「Subsequent Address Family Identifiers (SAFI) Parameters」レジストリ・グループの「SAFI Values」レジストリにSAFI値71(BGP-LS)と72(BGP-LS-VPN)を割り当てた。

IANAは、「ボーダー・ゲートウェイ・プロトコル(BGP)パラメータ」のレジストリ・グループの「BGPパス属性」レジストリに値29(BGP-LS属性)を割り当てた。

IANAは、「ボーダー・ゲートウェイ・プロトコル - リンクステート(BGP-LS)パラメータ」レジストリ・グループをhttps://www.iana.org/assignments/bgp-ls-parameters に作成した。

このセクションでは、[RFC9029]で導入された指定専門家向けのガイドラインと同様に、BGP-LS IANAレジストリ・グループの割り当て手順に対するすべての変更も組み込まれている。

7.1. BGP-LSレジストリ

以下のサブセクションに列挙されているすべてのレジストリはBGP-LSに固有であり、このレジストリの下でアクセスできる。

7.1.1. BGP-LS NLRIタイプ・レジストリ

「BGP-LS NLRI Types」レジストリは、BGP-LS NLRIタイプの2オクテット・サイズのコードポイントを割り当てるために設定され、以下に示す値が設定されている。

タイプ NLRIタイプ 参照先
0 予約済み RFC 9552
1 ノードNLRI RFC 9552
2 リンクNLRI RFC 9552
3 IPv4トポロジ・プレフィックスNLRI RFC 9552
4 IPv6トポロジ・プレフィックスNLRI RFC 9552
65000-65535 プライベート利用 RFC 9552

表12: BGP-LS NLRIタイプ

範囲はプライベート使用のために予約されている[RFC8126]。レジストリ内の他すべての割り当ては、「専門家レビュー」ポリシー[RFC8126]を使用して行われる。このポリシーでは、割り当て値の使用提案の文書化と、IESGが割り当てる代表専門家による承認を必要とする。

7.1.2. BGP-LSプロトコルIDレジストリ

「BGP-LS Protocol-IDs」レジストリは、BGP-LSプロトコルIDの1オクテット・サイズのコードポイントを割り当てるよう設定され、以下に示す値が設定されている。

プロトコルID NLRI情報ソース プロトコル 参照先
0 予約済み RFC 9552
1 IS-ISレベル1 RFC 9552
2 IS-ISレベル2 RFC 9552
3 OSPFv2 RFC 9552
4 直接 RFC 9552
5 静的構成 RFC 9552
6 OSPFv3 RFC 9552
200-255 プライベート利用 RFC 9552

表13: BGP-LSプロトコルID

範囲はプライベート使用のために予約されている[RFC8126]。レジストリ内の他のすべての割り当ては、「専門家レビュー」ポリシー[RFC8126]を使用して行われる。このポリシーでは、割り当てる値の使用提案の文書化と、IESGによって割り当てられた代表専門家による承認を必要とする。

7.1.3. BGP-LS Well-KnownインスタンスIDレジストリ

[RFC7752]で設定された「BGP-LS Well-Known Instance-IDs」レジストリは不要になった。IANAは、このレジストリを廃止済みとし、登録手続きを「registry closed」に変更した。

7.1.4. BGP-LSノード・フラグ・レジストリ

「BGP-LS Node Flag」レジストリは、ノード・フラグ・ビットTLV(1024)の1オクテット・サイズのフラグ・フィールド用に作成され、以下に示す初期値が設定されている:

ビット 説明 参照先
0 オーバーロード・ビット(Oビット) RFC 9552
1 付属ビット(Aビット) RFC 9552
2 外部ビット(Eビット) RFC 9552
3 ABRビット(Bビット) RFC 9552
4 ルータ・ビット(Rビット) RFC 9552
5 V6ビット(Vビット) RFC 9552
6-7 未割り当て

表14: BGP-LSノードのフラグ

レジストリ内の割り当ては、「専門家レビュー」ポリシー[RFC8126]を使用して行われる。このポリシーでは、割り当てる値の使用提案の文書化と、IESGによって割り当てられた指定専門家による承認を必要とする。

7.1.5. BGP-LS MPLSプロトコル・マスク・レジストリ

「BGP-LS MPLS Protocol Mask」レジストリは、MPLSプロトコル・マスクTLV(1094)の1オクテット・サイズのフラグ・フィールド用に作成され、以下に示す初期値が設定されている。

ビット 説明 参照先
0 ラベル配布プロトコル (Lビット) RFC 9552
1 LSPトンネル用RSVPの拡張 (Rビット) RFC 9552
2-7 未割り当て

表15: BGP-LS MPLSプロトコル・マスク

レジストリ内の割り当ては、「専門家レビュー」ポリシー[RFC8126]を使用して行われる。このポリシーでは、割り当てる値の使用提案の文書化と、IESGによって割り当てられた代表専門家による承認を必要とする。

7.1.6. BGP-LS IGP プレフィックス・フラグ・レジストリ

「BGP-LS IGP Prefix Flags」レジストリは、IGPフラグTLV (1152)の1オクテット・サイズのフラグ・フィールド用に作成され、以下に示す初期値が設定されている。

ビット 説明 参照先
0 IS-ISアップ/ダウン・ビット (Dビット) RFC 9552
1 「ユニキャストなし」ビット (Nビット) RFC 9552
2 「ローカル・アドレス」ビット (Lビット) RFC 9552
3 OSPF「NSSAの伝播」ビット (Pビット) RFC 9552
4-7 未割り当て

表16: BGP-LS IGP プレフィックス フラグ

レジストリ内の割り当ては、「専門家レビュー」ポリシー[RFC8126]を使用して行われる。このポリシーでは、割り当てる値の使用提案の文書化と、IESGによって割り当てられた指定専門家による承認を必要とする。

7.1.7. BGP-LS TLV レジストリ

「BGP-LSノード・ディスクリプタ、リンク・ディスクリプタ、プレフィックス・ディスクリプタ、属性TLV」レジストリは[RFC7752]を介して作成された。この文書により、IANAはそのレジストリの名前を「BGP-LS NLRI and Attribute TLVs」に変更し、「IS-IS TLV/Sub-TLV」の列を削除した。登録手続きは以下のとおりである。

TLV
コードポイント		 登録プロセス
0 ～ 255 予約済み (割り当てられません)
256-64999 専門家レビュー
65000-65535 プライベート利用

表17: BGP-LS TLVの登録プロセス

範囲はプライベート使用のために予約されている[RFC8126]。レジストリ内の他のすべての割り当ては、「専門家レビュー」ポリシー[RFC8126]を使用して行われる。このポリシーでは、割り当てる値の使用提案の文書化と、IESGによって割り当てられた代表専門家による承認を必要とする。

レジストリは、表18に示す値で事前に設定され、各割り当ての参照先は、本文書と、それらのTLVが指定されている各セクションに変更された。

7.2. 代表専門家に対するガイダンス

ここで説明する代表専門家(designated expert)によるレビューのすべてのケースにおいて、代表専門家は、要求されたコードポイントの目的と使用の明確性をチェックすることが期待されている。本文書で説明するレジストリには以下の点が適用される:

  1. コードポイントの割り当ての申請は、いつでも指定された専門家に対して行うことができ、コードポイントの用途を説明した技術文書を添付しなければならない(MUST)。そのような文書は、インターネット・ドラフトの形式で提示することが望ましい(SHOULD)が、査読者間でレビューし、交換することができる任意の形式で提供してもよい(MAY)。
  2. 代表専門家は、適切に設立されたワーキング・グループが存在しない場合、既にワーキング・グループの文書として受理されている、またはADスポンサード文書としての進行が計画されているたインターネット・ドラフトから生じるリクエストのみを考慮すべきである(SHOULD)。
  3. ワーキング・グループ文書の場合、代表専門家は、この時点で割り当てを行うワーキング・グループ内の合意があることをワーキング・グループの議長に確認しなければならない(MUST)。ADが後援する文書の場合、代表専門家は、この時点で割り当ての承認をADに確認しなければならない(MUST)。
  4. 文書がIDRワーキング・グループ(またはその後継)によって採用されない場合、指名された専門家はIDRメーリングリスト(またはその後継)にその要求を通知し、文書へのアクセスを提供しなければならない。代表専門家は、回答に2週間の猶予を与えなければならない。受け取ったコメントはすべて、代表専門家が次のステップの一部として考慮しなければならない。
  5. その後、代表専門家は、割り当て要求を技術的なメリットに基づいてを検討しなければならない(MUST)。代表専門家は、割り当てが行われる前に、さらなる検討のために、著者およびIDR(または後継者)メーリングリスト上で、割り当て要求に関連する問題を提起してもよい(MAY)。
  6. 代表専門家は、コードポイントの要求が、IETF内で進行中の作業またはすでに公開されている作業と衝突しないことを保証しなければならない(MUST)。
  7. 代表専門家が承認した後、IANAは割り当てられたコードポイントに関連文書への参照を付すことで、レジストリを更新する。
  8. その文書がワーキング・グループの文書であるか、ADがスポンサーとなっている文書で、RFCとしての公開に進めなかった場合、ワーキング・グループの議長またはADは、IANAに連絡して、そのコードポイントを非推奨(deprecated)としてマークすることについて調整する必要がある(SHOULD)。非推奨のコードポイントは、使用するために割り当てられたとマークされず、将来の文書に割り当てることはできない。WG議長は、レジストリに未割り当てのコードポイントが不足する場合、非推奨のコードポイントが非推奨になった後、いつでも完全に割り当てを解除する(つまり、新しい割り当てに使用できる)ことをIANAに通知することができる。

8. 管理性に関する考慮事項

このセクションは、[RFC5706]で推奨されている構成になっている。

8.1. 運用上の考慮事項

8.1.1. 運用

既存のBGP運用手順が適用される。本文書では新しい運用手順は定義されていない。本文書に記載されているNLRI情報は、BGPが計算した対応するフォワーディング状態に直接的な影響を与えない、純粋にアプリケーション・レベルのデータを伝送するものであることに留意する。そのため、到達性情報の変化は、ルータ全体のフォワーディング状態を変更する必要がある通常のBGPアップデートとは異なる影響を与える。BGP-LS NLRIの配布は、異なるBGPアドレス・ファミリー間で一定レベルの分離と障害封じ込めを提供するほとんどの展開において、専用のルート・リフレクタによって処理するべきである(SHOULD)。専用のルート・リフレクタが使用できない場合は、BGPインスタンスの分離や、リンクステート情報配布のための個別のBGPセッション(ピアリングに異なるアドレスを使用するなど)など、他の代替メカニズムを使用する必要がある(SHOULD)。

BGP-LSを導入する事業者は、BGP-LSへのリンクステート情報の発信に冗長性を持たせるために、IGPフラッディング・ドメインごとに2つ以上のBGP-LSプロデューサーを有効にすることが推奨される。また、事業者は、BGPアップデートの伝播パスの冗長性を確保するBGPピアリング設計(例えば、少なくとも1組のルート・リフレクタを使用する)を行い、BGP-LSコンシューマが少なくとも2台のBGP-LSスピーカーから、確実にトポロジー情報を受信していることを確認することも推奨される(RECOMMENDED)。

マルチドメインIGPネットワークでは、マルチドメインのリンクステート・トポロジーを一貫して報告するには、BGP-LSプロデューサー上でBGP-LSインスタンスIDを正しくプロビジョニングする必要がある。詳細は、セクション5.2を参照のこと。

8.1.2. インストールと初期設定

セクション8.2.3で定義されている設定パラメータは、以下のデフォルト値に初期化する必要がある(SHOULD)。

リンクステートNLRIケイパビリティは、すべてのネイバーに対してオフにする。リンクステートNLRIが隣接ノードから広告または撤回される最大レートは、1 秒あたり200アップデートに設定する。

8.1.3. マイグレーション・パス

提案された拡張は、ケイパビリティ・ネゴシエーション後にBGPピア間でのみ有効化される。さらに、拡張は個々のピアごとにオン/オフを切り替えることができるため(セクション8.2.3を参照)、拡張をネットワーク内で段階的に展開することができる。

8.1.4. 他のプロトコルや機能コンポーネントの要件

本文書で定義されているプロトコル拡張は、他のプロトコルや機能コンポーネントに新たな要件を課すものではない。

8.1.5. ネットワーク運用への影響

リンクステートNLRIのアップデート頻度は、通常のBGPプレフィックス配布を妨げる可能性がある。ネットワーク・オペレータは、セクション8.1.1で説明しているように、専用ルート・リフレクタのインフラを使用してリンクステートNLRIを配布する必要がある。

リンクステートNLRIの配布は、1つのASまたは複数のAS内の複数のエリアで構成される単一の管理ドメインに限定すべきである(SHOULD)。

8.1.6. 正しい動作の確認

既存のBGP手順が適用される。さらに、実装はオペレータが以下のことが行えるようにする必要がある(SHOULD)。

スピーカーがリンクステートNLRIを交換しているネイバーをリストする。

8.2. 管理上の考慮事項

8.2.1. 管理情報

IDRワーキング・グループは、BGPスピーカーとその間のセッションを管理・監視するための管理情報ベースとYANGモデルの一部を文書化し、現在も文書化し続けている。現在のところ、BGP-LSを実行するBGPセッションは、他のBGPセッションと実質的な違いはなく、同じデータ・モデルを使って管理できると考えられている。

8.2.2. 障害管理

このセクションでは、[RFC7606]に説明しているように、BGP-LSのBGP UPDATEメッセージの処理で実行される障害管理の動作について説明する。

セクション5.1および5.2で説明しているように、TLVの包含/除外やTLVフィールドの内容(つまり、セマンティック・エラー)に基づいて、リンクステート NLRIを不正または無効とみなしてはならない(MUST NOT)。

BGP-LSスピーカーは、リンクステートNLRIが不正な形式かどうかを判断するために、以下の構文検証を行わなければならない(MUST)。

  • BGP MP_REACH_NLRI属性で見つかったすべてのTLV長の合計は、BGP MP_REACH_NLRIの長さに対応する。
  • BGP MP_UNREACH_NLRI属性で見つかったすべてのTLV長の合計は、BGP MP_UNREACH_NLRIの長さに対応する。
  • リンクステートNLRIで見つかったすべてのTLV長の合計は、そのすべてのディスクリプタの合計NLRI長フィールドに対応する。
  • TLVの長さ、およびTLVが認識される場合、NLRI内のサブTLVの長さは有効である。
  • NLRIフィールドの構文の正しさは[RFC7606]に従って検証されている。
  • TLVの順序に関するルールは、セクション5.1で説明されているとおりである。
  • ローカルまたはリモート・ノード・ディスクリプタTLVのいずれかを伝送するNLRIの場合、サブTLVのインスタンスが1以上存在することはない。

判定されたエラーによって、ルータが不正な形式のNLRIをスキップしてBGP UPDATEメッセージの残りの部分の処理を続行できる場合(例えば、TLV順序付けルールに違反している場合)、ルータはそのような不正なNLRIを「NLRI破棄」 として処理しなければならない(MUST)(つまり、[RFC7606]のセクション5.4で説明しているものと同様の処理)。その他ケースで、NLRI符号化のエラーによって、BGP UPDATEメッセージが処理できない場合(例えば、長さに関連する符号化エラー)、ルータは、BGP-LS以外のAFI/SAFIが同じセッション上で広告されている場合、そのような不正なNLRIを「AFI/SAFI無効」として処理する必要がある(SHOULD)。代わりに、セッションが、BGP-LSにのみ使用されている場合、または「AFI/SAFI無効」アクションが不可能な場合、ルータは「セッション・リセット」を実行しなければならない(MUST)。

BGP-LS属性は、セクション5.1と5.3で説明しているように、TLVの包含/除外またはTLVフィールドの内容(つまり、セマンティック・エラー)に基づいて、不正または無効とみなしてはならない(MUST NOT)。

BGP-LSスピーカーは、BGP-LS属性の不正形式かどうかを判断するために、以下の構文検証を行わなければならない(MUST)。

  • BGP-LS属性に含まれるすべてのTLV長の合計が、BGP-LS属性の長さに相当する。
  • 属性(BGP-LS属性を含む)の構文の正しさは[RFC7606]に従って検証されている。
  • 各TLVの長さと、TLVが認識される場合、BGP-LS属性内のサブTLVの長さが有効である。

エラーと判断された場合、ルータが不正な形式のBGP-LS属性をスキップし、BGP UPDATEメッセージの残りの部分の処理を続行できる(例えば、BGP-LS属性の長さとパス属性の長さの合計が正しいが、BGP-LS属性内のTLV/サブTLVの長さが無効の場合)、ルータはそのような不正なBGP-LS属性を「属性破棄」として処理しなければならない(MUST)。その他のケースで、BGP-LS属性の符号化エラーによって、BGP UPDATEメッセージを処理できない場合、その処理は上記の不正なNLRIと同じように処理される。

「属性破棄」アクションは、BGP-LS属性内のすべてのTLVを失うものであり、特定の不正なTLVを削除するものではないことに留意する。特定の不正なTLVを削除すると、BGP-LSコンシューマに、その特定の情報が削除された、または利用できないことを誤った示す可能性がある。

BGPスピーカーが、MP_REACH_NLRIにリンクステートNLRIが含まれ、BGP-LS属性が含まれないUPDATEメッセージを受信した場合、そのメッセージに先行するBGPスピーカーが「属性破棄」の障害処理を実行したことを示している可能性が高い。実装は、BGP-LSコンシューマがそのオブジェクトのリンクステート情報の喪失を検出でき、その削除/撤回を想定しないように、ローカル・ポリシーで拒否されない限り、リンクステートNLRIをそのようなUPDATEメッセージで保持し、伝播する必要がある(SHOULD)。これにより、ネットワーク・オペレータは、BGP-LS属性の障害を検出したBGP-LSプロパゲータを追跡することができる。

実装は、さらなる分析のために、構文検証中に見つかったエラーのメッセージをログに記録すべきである(SHOULD)。

BGP-LSプロパゲータは、同じノード上にBGP-LSコンシューマが共存している場合でも、リンクステートNLRIやBGP-LS属性のセマンティック検証を行わず、形式が不正であるか無効であるかを判断すべきではない。BGP-LSプロパゲータが行ってはいけないセマンティック検証はタイプは以下のとおりである(これは完全なリストとはみなされない)。

  • 必須TLVの存在
  • 固定長TLVの長さが正しいか、可変長TLVの長さが有効または許容される
  • TLVフィールドの値が有効または許容される
  • 特定のリンクステートNLRIタイプを持つTLV/サブTLVの包含と使用は有効である

各TLVは、セマンティック検証のためにBGP-LSコンシューマのみが使用できる、有効で許容される値とそのセマンティックスを示すことができる。ただし、エラーの処理は特定のアプリケーションに固有の場合があり、本文書の範囲外である。

8.2.3. 構成管理

実装は、リンクステートNLRIが広告され、リンクステートNLRIがアクセスされるネイバーをオペレータが指定できるようにすべきである(SHOULD)。

実装は、リンクステートNLRIが近隣ノードから広告/撤回される最大レートを、オペレータが指定できるようにすべきである(SHOULD)。

実装は、ルータのルーティング情報ベース(RIB)に格納されるリンクステートNLRIの最大数を、オペレータが指定できるようにすべきである(SHOULD)。

実装は、オペレータが近隣に広告される抽象化されたトポロジを作成し、異なる近隣に対して異なる抽象化を作成できるようにすべきである(SHOULD)。

実装は、オペレータが8オクテットのBGP-LSインスタンスIDを設定できるようにしなければならない(MUST)。BGP-LSインスタンスIDの設定に関するオペレータへのガイダンスについては、セクション5.2を参照のこと。

実装は、オペレータが自律システム番号(ASN)とBGP-LS識別子を設定できるようにすべきである(セクション5.2.1.4を参照)。

実装は、BGP-LSプロデューサのBGP-LS UPDATEメッセージのサイズ制限を4096バイトに設定することをオペレータに許可すべきか、すべてのBGP-LSスピーカーが拡張メッセージ・サイズ[RFC8654]をサポートしていることが分かっている場合は、より大きな値を許可すべきである(SHOULD)。

8.2.4. アカウント管理

該当しない。

8.2.5. パフォーマンス管理

実装は以下の統計を提供すべきである(SHOULD)。

  • 送受信されたリンクステートNLRIアップデートの総数
  • ネイバーごとに送受信されたリンクステートNLRIアップデートの数
  • ネイバーごとの、受信エラーが発生したリンクステートNLRIアップデートの数
  • ローカルに発信されたリンクステートNLRIの総数

これらの統計は、システムまたはセッションの開始時間以降の絶対数として記録すべきである。実装はまた、それぞれのケースで1秒あたりのピーク数を記録することで、この情報を強化してもよい(MAY)。

8.2.6. セキュリティ管理

オペレータは、インバウンド・アップデートを制限するインポート・ポリシーを以下のように定義しなければならない(MUST):

  • BGP-LSコンシューマーにのみサービスを提供していないピアからのアップデートをすべてドロップする。

実装は、インバウンド・アップデートを制限する手段を持たなければならない(MUST)。

9. TLV/Sub-TLV コードポイントの概要

このセクションには、本文書で定義されているすべてのTLV/サブTLVのグローバル・テーブルが含まれる。

TLV
コードポイント		 説明 参照先セクション
256 ローカル・ノード・ディスクリプタ セクション5.2.1.2
257 リモート・ノード・ディスクリプタ セクション5.2.1.3
258 リンク・ローカル/リモート識別子 セクション5.2.2
259 IPv4インタフェース・アドレス セクション5.2.2
260 IPv4隣接アドレス セクション5.2.2
261 IPv6インタフェース・アドレス セクション5.2.2
262 IPv6隣接アドレス セクション5.2.2
263 マルチトポロジ識別子 セクション5.2.2.1
264 OSPF経路タイプ セクション5.2.3.1
265 IP到達性情報 セクション5.2.3.2
512 自律システム セクション5.2.1.4
513 BGP-LS 識別子 (非推奨) セクション5.2.1.4
514 OSPFエリアID セクション5.2.1.4
515 IGPルータID セクション5.2.1.4
1024 ノード・フラグ・ビット セクション5.3.1.1
1025 Opaqueノード属性 セクション5.3.1.5
1026 ノード名 セクション5.3.1.3
1027 IS-ISエリア識別子 セクション5.3.1.2
1028 ローカル・ノードのIPv4ルータID セクション5.3.1.4、5.3.2.1
1029 ローカル・ノードのIPv6ルータID セクション5.3.1.4、5.3.2.1
1030 リモート・ノードのIPv4ルータID セクション5.3.2.1
1031 リモート・ノードのIPv6ルータID セクション5.3.2.1
1088 管理グループ (カラー) セクション5.3.2
1089 最大リンク帯域幅 セクション5.3.2
1090 最大予約可能なリンク帯域幅 セクション5.3.2
1091 予約されていない帯域幅 セクション5.3.2
1092 TE デフォルト メトリック セクション5.3.2.3
1093 リンク保護タイプ セクション5.3.2
1094 MPLSプロトコル・マスク セクション5.3.2.2
1095 IGPメトリック セクション5.3.2.4
1096 共有リスク・リンク・グループ セクション5.3.2.5
1097 Opaqueリンク属性 セクション5.3.2.6
1098 リンク名 セクション5.3.2.7
1152 IGPフラグ セクション5.3.3.1
1153 IGP経路タグ セクション5.3.3.2
1154 IGP拡張経路タグ セクション5.3.3.3
1155 プレフィックス・メトリック セクション5.3.3.4
1156 OSPFフォワーディング・アドレス セクション5.3.3.5
1157 Opaqueプレフィックス属性 セクション5.3.3.6

表18: TLV/Sub-TLVコードポイントの要約表

10. セキュリティに関する考慮事項

本文書で定義されている手順やプロトコル拡張は、BGPセキュリティ・モデルには影響しない。BGPのセキュリティについては、[RFC4271]の「セキュリティに関する考慮事項」セクションを参照のこと。また、BGPのセキュリティ問題の分析については、[RFC4272]と[RFC6952]を参照のこと。

オペレータは、セクション8.2.3と8.2.6で説明するポリシー設定オプションを使用して、BGP-LSスピーカがBGP-LSコンシューマにしか情報を提供しないピアからのUPDATEメッセージを 受け入れないようにする必要がある。一般的に、オペレータはBGP-LSスピーカの役割とリンクステート・ピアリングを認識している。そのため、オペレータはBGP-LS スピーカを、誤った情報、フィードバック・ループ、または誤った入力を示す可能性のあるアップデートを送信するピアから保護することができる。

BGP-LSに発信され、BGP-LSコンシューマ・アプリケーションで使用するためにネットワークを経由して伝播するリンクステート情報にエラーや改ざんがあると、それらのアプリケーションが誤動作する可能性がある。そのようなリスクの例としては、BGP-LSプロデューサーのIGP LSDBに存在しない、または整合性のない不正確な情報の発信、NLRIのTLVの順序付けの誤り、複数のBGP-LSプロデューサーからの一貫性のない発信、伝播中のNLRIまたはBGP-LS属性の更新(エラーによる破棄を含む)などがある。これらは、BGPプロトコルの観点からは新しいリスクではない。ただし、BGP-LSの場合、影響はBGPルーティング機能ではなく、コンシューマ・アプリケーションに反映される。

さらに、本文書で説明されているリンクステートおよびTE情報のエクスポートは、ネットワークに関するミッション・クリティカルな情報または商業上の機密情報の機密性に対するリスクを構成するとみなされる可能性がある。BGPピアリングは自動ではないため、設定が必要である。したがって、信頼できるBGPスピーカーのみがそのような情報を受信するように設定されていることを確認するのは、ネットワーク・オペレータの責任である。同様のセキュリティ上の考慮事項は、BGPスピーカーとBGP-LSコンシューマ間のインタフェースでも生じるが、それらの説明は本文書の範囲外である。

11. 参考文献

11.1. 引用規格

[ENTNUM] IANA, "Private Enterprise Numbers (PENs)", https://www.iana.org/assignments/enterprise-numbers/.

[ISO10589] ISO, "Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, November 2002.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, https://www.rfc-editor.org/info/rfc2328.

[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, https://www.rfc-editor.org/info/rfc2545.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, https://www.rfc-editor.org/info/rfc3209.

[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, https://www.rfc-editor.org/info/rfc4202.

[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, https://www.rfc-editor.org/info/rfc4203.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, https://www.rfc-editor.org/info/rfc4271.

[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, June 2006, https://www.rfc-editor.org/info/rfc4577.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, https://www.rfc-editor.org/info/rfc4760.

[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, https://www.rfc-editor.org/info/rfc4915.

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, https://www.rfc-editor.org/info/rfc5036.

[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, https://www.rfc-editor.org/info/rfc5120.

[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 2008, https://www.rfc-editor.org/info/rfc5130.

[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, October 2008, https://www.rfc-editor.org/info/rfc5301.

[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, https://www.rfc-editor.org/info/rfc5305.

[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, https://www.rfc-editor.org/info/rfc5307.

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, https://www.rfc-editor.org/info/rfc5340.

[RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, "Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642, DOI 10.17487/RFC5642, August 2009, https://www.rfc-editor.org/info/rfc5642.

[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, https://www.rfc-editor.org/info/rfc5890.

[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, https://www.rfc-editor.org/info/rfc6119.

[RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, June 2012, https://www.rfc-editor.org/info/rfc6565.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, https://www.rfc-editor.org/info/rfc7606.

[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, https://www.rfc-editor.org/info/rfc7684.

[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, https://www.rfc-editor.org/info/rfc7770.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, https://www.rfc-editor.org/info/rfc8126.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, https://www.rfc-editor.org/info/rfc8362.

[RFC8654] Bush, R., Patel, K., and D. Ward, "Extended Message Support for BGP", RFC 8654, DOI 10.17487/RFC8654, October 2019, https://www.rfc-editor.org/info/rfc8654.

11.2. 参考規格

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, https://www.rfc-editor.org/info/rfc1918.

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, https://www.rfc-editor.org/info/rfc4272.

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, https://www.rfc-editor.org/info/rfc4364.

[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, https://www.rfc-editor.org/info/rfc4655.

[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, https://www.rfc-editor.org/info/rfc5152.

[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, https://www.rfc-editor.org/info/rfc5392.

[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, https://www.rfc-editor.org/info/rfc5693.

[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, https://www.rfc-editor.org/info/rfc5706.

[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, https://www.rfc-editor.org/info/rfc6549.

[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, https://www.rfc-editor.org/info/rfc6952.

[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, https://www.rfc-editor.org/info/rfc7285.

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, https://www.rfc-editor.org/info/rfc7752.

[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, https://www.rfc-editor.org/info/rfc7911.

[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017, https://www.rfc-editor.org/info/rfc8202.

[RFC9029] Farrel, A., "Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries", RFC 9029, DOI 10.17487/RFC9029, June 2021, https://www.rfc-editor.org/info/rfc9029.

[RFC9346] Chen, M., Ginsberg, L., Previdi, S., and D. Xiaodong, "IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 9346, DOI 10.17487/RFC9346, February 2023, https://www.rfc-editor.org/info/rfc9346.

付録 A. RFC 7752からの変更点

このセクションでは、RFC 7752からの大まかな変更点をリスト化し、それらが導入されている文書のセクションへの参照を提供する。

  1. セクション1の図1を更新し、セクション3を追加して、リンクステート情報の伝達におけるBGP実装のさまざまな役割を説明した。
  2. セクション4で、IGPからBGP-LSへのリンクステート情報の広告に関連する側面を明確にした。
  3. セクション5.1では、NLRI部分とBGP-LS属性部分の両方に適用されるTLVの処理と、NLRI部分にのみ適用される処理を明確にした。実装は、未知のTLVの処理に関する部分が抜け落ちていた可能性があるため、[RFC7606]のガイドラインに基づいて、未知のNLRIタイプを破棄する可能性がある。この点については、セクション5.2で明確に説明している。また、BGP-LS属性のうち、順序付けされていないTLVは、不正な形式とはみなされない。
  4. NLRIとBGP-LS属性部分の両方で、必須およびオプションのTLVを文書全体で明確化した。
  5. セクション5.3では、BGP-LS情報の増加に伴う大きなサイズのBGP-LS属性の取り扱いと、それに起因するエラーの軽減について説明している。
  6. 本文書では、指定されたプロトコルとNLRIタイプのためのNLRIディスクリプタTLVを説明し、将来のBGP-LS拡張では、他のプロトコルとNLRIタイプを導入する場合にも同じように説明しなければならないことを明確にした。
  7. セクション5.2で、リンクステートNLRIの識別子フィールドの使用を明確にした。これは、単一リンク上のマルチ・インスタンスIGPのみを参照すると曖昧に定義されていたが、ルータ上の複数のIGPプロトコル・インスタンスにも使用できる。これに伴い、IANAレジストリは削除される。
  8. ノード・ディスクリプタのBGP-LS識別子TLVは非推奨となった。その使用法は [RFC7752]で明確に規定されておらず、複数のIGPルーティング・プロトコルのインスタンスを実行する場合、BGP-LSインスタンスIDを含む識別子フィールドを使用するのに対して、IGPドメインを識別するためのBGP-LS識別子の使用について、実装者間である程度の混乱があった。BGP-LS識別子の本来の目的は、ASNと組み合わせてBGP-LSドメインを一意に識別し、ASNとBGP-LS IDの組み合わせがグローバルに一意になることだった。ただし、NLRIの固定部分の識別子フィールドで伝送されるBGP-LSインスタンスIDも同様の機能を提供する。したがって、BGP-LS識別子TLVを含める必要はない。広告される場合、IGPフラッディング・セット(LSP/LSAがフラッディングされるIGPノード・セット)内のすべてのBGP-LSスピーカーは同じ(ASN、BGP-LS ID)タプルを使用しなければならなず、IGPドメインが複数のフラッディング・セットで構成される場合、IGPドメイン内のすべてのBGP-LSスピーカーは同じ(ASN、BGP-LS ID)タプルを使用しなければならない。
  9. ASスコープのLSAから情報を取得する場合を除き、OSPFからの情報の発信するノード・ディスクリプタにはエリアID TLVが必須であり、このTLV が適用されないことを明確にした。また、IS-ISエリアとエリア・アドレスも明確にした。
  10. MT-ID TLVはノード・ディスクリプタのサブTLVではないため、ノード・ディスクリプタのセクションからリンク・ディスクリプタのセクションの下に移動した。このTLVにおけるOSPF MT-IDの符号化の曖昧さを修正した。IS-IS仕様の参照セクションを更新し、MT-ID TLVがリンク・ディスクリプタTLVおよびプレフィックス属性TLVとして使用される場合のRフラグの適用可能性の違いを説明した。MT-ID TLVの使用は、基盤となるIGPで有効になっている場合、SHOULDに昇格した。
  11. IPv6リンク・ローカル・アドレスはリンク・ディスクリプタTLVで広告されず、代わりにローカル/リモート識別子がIPv6リンク・ローカル・アドレスを持つリンクにのみ使用されることを明確にした。
  12. セクション5.2.3.1でOSPF経路タイプTLVの使用法を更新し、OSPFプレフィックスの使用を義務付けた。これは、あるノード(ループバックなど)に到達するために使用されるエリア内プレフィックスと、他のタイプのエリア間および外部プレフィックスを分離するために必要なためである。
  13. ノード、リンク、プレフィックスのOpaque属性TLVで使用する特定のOSPFv2およびOSPFv3プロトコルTLV空間を明確にした。
  14. ノード・フラグ・ビットとIGPフラグTLVの長さを1オクテットとすることを明確にした。
  15. セクション5.3.1.3のノード名TLVをOSPF仕様に合わせて更新した。
  16. IGPメトリックTLVを介したIS-ISナロー・メトリック広告のサイズと未使用ビットの処理を明確にした。
  17. セクション5.11のOSPFネットワークにおけるLANセグメントに対応するプレフィックスの広告を明確にした。
  18. セクション5.7と5.8で、仮想リンク、擬似リンク、タイプ4 LSAなどのOSPF固有の概念の広告とサポートを明確にした。
  19. セクション5.4で、プライベート使用TLVのコードポイント空間を導入し、その符号化を規定した。
  20. セクション5.9では、IGPリンクステートの報告の一貫性に関する問題とその解決策が紹介した。
  21. BGP-LSのエラーや障害が通常のBGPルーティングに影響するのを回避するため、BGP-LSセッションを他のBGP経路交換から分離するための推奨事項を追加した。
  22. BGP-LS情報伝播フローにおけるBGPスピーカーの役割に基づく詳細なルールを追加し、「障害管理」セクションを更新した。
  23. BGP-LSのIANAレジストリの管理を「仕様必須」から「専門家レビュー」に変更し、指名された専門家向けのガイドラインを更新した。より具体的には、[RFC9029]によって導入された変更のうち、本文書によって廃止された変更を含めた。
  24. さまざまなTLVのフラグ・フィールドに対する「専門家レビュー」ポリシーが抜けていたため、BGP-LSのIANAレジストリを追加した。BGP-LS TLVレジストリの名前を変更し、「IS-IS TLV/サブTLV」の列を削除した。

謝辞

BGP-LS仕様[RFC7752]に対する本文書の更新は、IDRワーキング・グループでの議論からのフィードバックとインプットの結果である。また、BGP-LSの実装と展開の経験に基づく特定の詳細と明確化も組み込まれている。

チェンギズ・アラエッティノグルとパラグ・アムリットカルは、OSPFのLANサブネットの広告を明確にする必要性を提起した。

バラジ・ラジャゴパラン、スリハリ・サングリ、シュラダ・ヘグデ、アンドリュー・ストーン、ジェフ・タンツーラ、エース・リンデム、レス・ピンズバーグ、ジエ・ドン、アイジュン・ワン、ナンダン・サハ、ジョエル・ハルパーン、ギャン・ミシュラらの本文書のレビューとフィードバックに感謝する。IANAの考慮事項セクションに関するレビューとコメントをくれたトム・ペッチに感謝する。また、文書を改善するための詳細な羊飼いレビューと意見を提供してくれたジェフリー・ハースにも感謝する。

アルバロ・レタナによる詳細なADレビューと彼の提案により、本文書は大幅な改善された。

[RFC7752]に多大な貢献をしてくれたロバート・ヴァルガに感謝する。

ニシャル・シェス、アリア・アトラス、デヴィッド・ウォード、デレク・ヨン、ムルトゥーザ・ライトワラ、ジョン・スカダー、カリラジ・ヴィラヴァッカライ、レス・ピンズバーグ、リエム・グエン、マニッシュ・バールドワージ、マット・ミラー、マイク・シャンド、ピーター・プセナク、レックス・フェルナンド、リチャード・ワウンディ、スティーブン・ルオン、タマス・モンダル、ワカス・アラム、ヴィピン・クマール、シェン・ナイミン、カルロス・ピニャータロ、バラジ・ラジャゴパラン、ヤコフ・レクター、アルバロ・レタナ、バリー・レイバ、ベン・キャンベルらの[RFC7752]に関するコメントに感謝する。

貢献者

以下の人物は、[RFC7752]および本文書に重要な文章を寄稿した。彼らは共著者とみなされるべきである。

ハネス・グレドラー
Rtbrick
メール: hannes@rtbrick.com

ヤン・メドベド
Cisco Systems Inc.
アメリカ合衆国
メール: jmedved@cisco.com

ステファノ・プレヴィディ
Huawei Technologies
イタリア
メール: stefano@previdi.net

エイドリアン・ファレル
Old Dog Consulting
メール: adrian@olddog.co.uk

サイカット・レイ
個人
アメリカ合衆国
メール：raysaikat@gmail.com

著者のアドレス

ケタン・タラウリカー (編集者)
Cisco Systems
インド
メール: ketant.ietf@gmail.com

更新履歴

  • 2024.5.3
  • 2024.5.10
GitHubで編集を提案

Discussion