Zenn
⛳

RFC 9107: BGP最適ルート・リフレクション (BGP ORR)

2024/04/19に公開
RFC
bgp
tech

要旨

本文書は、BGPルート・リフレクタの拡張機能を定義する。ルート・リフレクタにおいて、BGP経路選択はルート・リフレクタ自体の見方からではなく、クライアントの見方から最適経路を選択するように変更する。スケーリングと正確さの要件に応じて、経路選択は1つのクライアントに特化することも、クライアント・セットに一致することも、ルート・リフレクタのすべてのクライアントに一致することもできる。このソリューションは、ルート・リフレクタのIGPの位置に基づく最適経路を選択する集中型ルート・リフレクタを使用する展開に特に適用可能である。これにより、例えば、「最適出口点」ポリシー (「ホットポテト・ルーティング」)が容易になる。

このソリューションは、すべてのルート・リフレクタが検討対象とするすべてのパスを学習することに依存している。BGP経路選択は、リンクステート型IGPで設定された場所からのIGPコストに基づいてルート・リフレクタ内で実行される。

本文書の位置付け

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

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

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

著作権表示

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

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

1. はじめに

現在、自律システム(AS)内でのBGP展開には、フルメッシュ、コンフェデレーション、ルート・リフレクションの3つのタイプがある。BGPルート・リフレクション[RFC4456]は、同じASに属するBGPスピーカー間でBGP経路を配布する最も一般的な方法である。しかし、状況によっては、この手法はパス選択が最適にならない点に悩まされる。

[RFC4456]は、ネットワーク内のあるポイントへのIGPコストはルータ間で異なるため、「ルート・リフレクション手法は、フルIBGPメッシュ手法と同じ経路選択結果にならない可能性がある」と明言している。(「IBGP」は「内部BGP」の略。) この事実の実際の意味は、ルート・リフレクションの導入により、「ホットポテト・ルーティング」を実現する能力が妨げられる可能性があるということである。ホットポテト・ルーティングは、より優先度の高いポリシーで指示がない場合に、最も近いAS出口点にトラフィックを誘導しようとする。ルート・リフレクション方式の結果として、ルート・リフレクタとそのクライアントの出口点の選択は、ルート・リフレクタにとって最適な出口点となるが、そのクライアントにとって必ずしも最適な出口点とは限らない。

⚠️ ホットポテト・ルーティング

ホットポテト・ルーティングは、複数の場所で相互接続しているAS間のルーティングにおいて、トラフィックをできるだけ早く対向ASに渡し、そのネットワークを広域トランジットに使う方法をいう。ついでに言えば、コールドポテト・ルーティングはその逆で、発信元ASがパケットを宛先にできるだけ近くなるまで内部ネットワークで運ぶ。

ホットポテト・ルーティングは、ほとんどのISPで一般に採用されている通常の動作である。パケットの送信元は、自ネットワークの負担を最小限に抑えるため、できるだけ早くパケットを対向ASに渡そうとする。ホットポテト・ルーティングでは、受信EBGP経路に付加されたMEDは破棄され、代わりに自AS内のIGPコストを使用する。

hot-potato

[RFC4456]のセクション11では、ルート・リフレクションの展開が、満たされた場合の、IBGPフルメッシュ手法と同じ結果をもたらす展開手法と一連の制約について説明している。この展開手法は、ルート・リフレクションをホットポテト・ルーティング・ポリシーの適用に適合させる。これらの設計ルールに従って、ルート・リフレクタは多くの場合、フォワーディング・パスに配備され、ポイント・オブ・プレゼンス(POP)とネットワーク・コアの境界に注意深く配置されてきた。

ドメイン内ネットワーク設計の進化モデルにより、フォワーディング・パスの外側にルート・リフレクタを配備できるようになった。当初、このモデルは、IP VPN[RFC4364]などの新しいサービスにのみ採用されていたが、IPv4やIPv6インターネットなど、他のBGPサービスにも徐々に拡張されきた。このような環境では、ホットポテト・ルーティング・ポリシーが引き続き望ましい。

フォワーディング・パスの外側にあるルート・リフレクタは、POPとネットワーク・コアの境界に配備できるが、大規模なネットワークのコア内の任意の場所に配置されることが多い。

このような展開には、BGP経路選択の文脈で重大な欠点がある。特定の経路の複数のパスを認識しているルート・リフレクタでも、通常、最適パスを選択し、その最適パスのみをクライアントに広告する。IGPのタイブレークに基づいて経路の最適パスが選択された場合、広告されるパスはルート・リフレクタに最も近い出口点になる。ただし、クライアントは、ルート・リフレクタとはネットワーク・トポロジ的に異なる場所にいる。ルート・リフレクタがフォワーディング・パス上にないネットワークでは、この違いはさらに深刻になる。

さらに、サービス・プロバイダが、トラフィックの種類やトラフィック負荷など、他の要因に基づいて、クライアントの出口点を選択する際、より多くの制御権を持ちたいと考える展開シナリオもある。これにより、問題がさらに複雑になり、ルート・リフレクタがクライアントの視点から最適パスを選択する可能性が低くなる。その結果、ルート・リフレクタによって選択される最適パスは、クライアントがルート・リフレクタと同じ候補パスの集合を考慮した場合、クライアントによって選択されるパスと必ずしも同じではない。

⚠️ 通常のルートリフレクタと最適ルートリフレクタ(ORR)の違い

通常のルートリフレクタ構成では、BGP経路選択において、IGPコストを使う場合に必ずしも最適パスが選ばれるとは限らない。RRクライアントに広告される経路のIGPコストは、RRからみたものとなるため、そのRRクライアントにとって最短コストにはならない。下例の場合、AS65002との出口点はR3とR2で、R1から見たAS65002の経路は、(ネクストホップとなる)出口点へのIGPコストで選択される。この場合、R3とR2のIGPコストの比較となるが、RRクライアントであるR1から見たBGP経路は、実際にはRRから見たBGP経路なので、R2の方がIGPコスト的に近いにも関わらず、R3が選択されてしまう。

rr-fig

一方、ORRになると、RRクライアントからみたIGPコストを計算するため、R1はR3ではなく、R2を選択する。また、ORRは物理的場所に制限を受けなくなり、ルートリフレクタ専用機(ルータやサーバ)の設置ができる。

orr-fig

👀 IBGPのベストパス選択条件 (一般的なケース)

  1. LOCAL_PREFが大きい
  2. AS-PATH長が短い
  3. ORIGIN属性が小さい(igp > egp > incomplete)
  4. MED値が小さい
  5. ネクストホップへのIGPメトリックが小さい
  6. (続く)

2. 用語

本文書は、[RFC4271]および[RFC4456]で定義された用語を使用する。

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

3. BGP経路選択の変更

このソリューションの中核は、ルート・リフレクタがネクストホップまでの内部コストを計算するIGP位置をオペレータが指定できる機能である。IGP位置は、IGPトポロジ内のノードとして定義され、このノードのIPアドレス(ループバック・アドレスなど)によって識別され、ルート・リフレクタ単位、クライアントのセット単位、 またはクライアント単位に構成することができる。このような構成により、ルート・リフレクタは、選択されたIGP位置の位置からネクストホップまでの距離が最短経路を選択し、所定のクライアントに配布できる。これにより、ルート・リフレクタの物理的な位置に関する自由度が得られ、IPトランジットに影響を与えることなく、このネットワーク・コントロール・プレーン機能を任意の場所に一時的または恒久的に移行することができる。

具体的な粒度(ルート・リフレクタ、クライアント・セット、またはクライアント)の選択は、ネットワーク・オペレータによって設定される。実装は、そのようなグループ化カテゴリを少なくとも1つサポートしていれば、その実装は本文書に準拠しているとみなされる。

⚠️ 粒度(granularity)とは

ここでいう粒度(granularity)とは、クラスタをどのように細分化するかと言うことだろう。

経路選択の目的上、クライアントの視点はルート・リフレクタや他のクライアントの視点とは、2つ異なる点がある:

  • IGPトポロジの中で位置が異なる。

  • 異なるルーティング・ポリシーを持つ可能性がある。

これらの要素は、前述の問題に対応する。

本文書では、BGPルート・リフレクタ[RFC4456]について、BGP経路選択アルゴリズムへの2つの変更を定義する:

  • セクション3.1で導入された最初の変更は、BGP決定プロセスにおけるBGPネクストホップへのIGPコストに関連するものである。この変更は、ルート・リフレクタ自体とは異なるIGPの位置でIGPコストを使用することから構成される。

  • セクション3.2で導入された2つ目の変更は、BGP決定プロセスの粒度を拡張し、異なる視点やポリシーを使用して複数の決定プロセスを実行できるようにする。

ルート・リフレクタは、クライアントが同じ候補パスを与えられたときに、クライアント自身が選択したであろう最適パスをクライアントのために選択できるようにするために、上記修正のいずれかまたは両方を実装することができる。

これらの手法の大きな利点は、ルート・リフレクタのクライアントを変更する必要がないことである。

3.1. さまざまなIGP位置からの経路選択

この手法では、「最適」とは、[RFC4271]のセクション9.1.2.2(「ブレイキング・タイ(フェーズ2)」) の「ステップe)」で経路の内部コストが決定される場合の「決定」を指す。他のポリシーステップや規定に基づくパス選択の優先設定には適用されない。

[RFC4456]のセクション9で規定されている変更に加えて、[RFC4271]のセクション9.1.2.2のステップe)の文章は以下のように修正される。

RFC 4271 には次のように書かれている:

e) 優先度の低い内部コストを持つ経路を検討から外す。経路の内部コストは、ルーティング・テーブルを使って経路のNEXT_HOPまでのメトリックを計算することで決定する。

本文書では、この文章を以下のように変更する:

e) 優先度の低い内部コストを持つ経路を検討から外す。経路の内部コストは、選択されたIGPの位置をルート(root)とする最短IGPパス木を使用して、選択したIGPの位置から経路のNEXT_HOPまでのメトリックを計算することで決定する。

⚠️ [RFC4271]のセクション9.1.2.2のステップe)

優先度の低い内部コストを持つ経路を検討から外す。経路の内部コストは、ルーティング・テーブルを使って経路のNEXT_HOPまでのメトリックを計算することで決定する。経路のNEXT_HOPホップに到達できるが、コストを決定できない場合、このステップをスキップする必要がある(すべての経路のコストは等しいとみなす)。

これについては、以下の手順でも説明する。

for m = まだ検討中のすべての経路
     for n = まだ検討中のすべての経路
         if (コスト(n)がコスト(m)より低い)
             mを検討から外す

上記の疑似コードで、cost(n)とは経路のNEXT_HOP属性で与えられたアドレスへのパスのコスト(内部距離)を返す関数である。

選択されたIGP位置をルートとする最短パス木を計算できるようにするには、それらの各位置を含むエリア/レベルのIGPトポロジーの知識が必要である。この知識は、IS-IS[ISO10589]やOSPF[RFC2328] [RFC5340]などのリンクステートIGPを使用するか、ボーダー・ゲートウェイ・プロトコル - リンク・ステート(BGP-LS)[RFC7752]を介して取得することができる。クライアント・グループのルート・リフレクタの論理的な場所を指定するとき、冗長性のために1つ以上のバックアップIGPの場所を指定できるようにする必要がある(SHOULD)。導入に関するさらなる考慮事項についてはセクション4で説明する。

⚠️ エリア/レベルが複数ある場合

エリア/レベルが複数ある場合は、エリア/レベル間では詳細なリンクステート情報ではなく集約した情報を交換するため、RRは直接参加していないエリア/レベルのIGPの詳細情報を知ることができない。エリア/レベルをまたがって、IGPの詳細なリンクステート情報を知るため、BGP-LSを用いる。

bgp-ls

3.1.1. BGPのネクストホップがBGP経路の場合の制限事項

BGPのネクストホップがBGP経路自体である状況において、解決に使用される経路のIGPメトリックは、当該ネクストホップに到達するための最終的なIGPコストである必要がある(SHOULD)。再帰的なネクストホップへの最終的なIGPメトリックをBGPに通知できない実装は、ネクストホップ・メトリックの比較の際に、当該パスを最も優先度が低いと扱わなければならない(MUST)。しかし、そのようなパスはBGPフェーズ2の経路選択ではまだ有効であると見なされなければならない(MUST)。

3.2. 複数の経路選択

[RFC4456]に従ったBGPルート・リフレクタは、1つのBGP決定プロセスを実行する。BGP最適ルート・リフレクション(BGP ORR)は、異なるクライアント・セットに対して異なるIGPの位置またはBGPポリシーを考慮するため、複数のBGP決定プロセスまたは決定プロセスのサブセットを必要とするかも知れない。これは、[RFC7947]セクション2.3.2.1で定義されているものと非常に似ている。

⚠️ RFC7947のセクション2.3.2.1

パスの隠匿を発生させずにクライアントごとのポリシー制御を可能にする最も移植性の高い方法は、ルートサーバのBGP実装を使用することである。この実装では、プレフィックスへのパスごとにクライアント単位の最適パスの計算を実行する。この計算は、ルートサーバのクライアント・ポリシーが考慮されている。これは、クライアントごとのLoc-RIBを使用し、Adj-RIB-InとクライアントごとのLoc-RIBの間にパス・フィルタリングを実装することで実装できる。実装では、グローバルLoc-RIB内のフィルタリング・ポリシーの対象外のパスを保持し、クライアントごとのLoc-RIBをその差分として保存することで、これを最適化できる。

この実装は、ルートサーバ・クライアントの機能を前提としないため、移植性が高い。

必要なルーティング最適化がBGPネクストホップまでのIGPコストに限定される場合、[RFC4271]セクション9.1.2.2で定義されているステップe)とそれ以降のステップのみを複数回実行する必要がある。

ルーティングの最適化のために、異なるクライアント・セットに対して異なるBGPポリシーを使用する必要がある場合、[RFC4271]のセクション 9.1で定義されている決定プロセス全体の、決定プロセスの大部分を複数回実行する必要がある。例えば、フェーズ1でさまざまな優先度を計算するために、さまざまなポリシーを使用する必要がある場合が該当する。これは、トラフィック・エンジニアリングや、特定のクライアント向けに特定の出口点を充てる場合を含むユースケースに必要である。後者の場合、ユーザはクライアント・セットに対してルート・リフレクタ上で一般ポリシーを指定し、適用することができる。次に、セクション3.1に従って、クライアント・セットに対するIGPパースペクティブを含む通常のパス選択が候補パスに適用され、クライアントに広告する最終パスが選択される。

4. 展開に関する考慮事項

BGP ORRは、クライアントの視点をルート・リフレクタのBGP経路選択決定プロセスに統合するモデルを提供する。具体的には、BGPパスの選択には、(ルート・リフレクタからネクストホップまでのIGPコストではなく)クライアントとネクストホップ間のIGPコスト、あるいはユーザが設定した他のポリシーが考慮される。

異なるクラスタのクライアント間で最適なルーティングを実現するには、すべてのルート・リフレクタが検討対象となるすべてのパスを学習する必要がある。この要件を満たすためには、ルート・リフレクタ間にBGP ADD-PATH[RFC7911]を導入する必要がある。

⚠️ ADD-PATHの必要性について

クラスタのRR間はIBGPフルメッシュ化されるが、IBGPは最適経路しか広告しないため、最適化前の経路を含めて広告するには、BGP ADD-PATHが必要という意味だろう。

このソリューションは、エンドツーエンドのトンネル環境だけでなく、ホップバイホップ転送ネットワークにも展開できる。複数のルート・リフレクタとカプセル化なしのホップバイホップ転送を持つネットワークでのルーティング・ループを回避するためには、ルート・リフレクション・トポロジを設計する際にネットワーク・トポロジを慎重に考慮することが不可欠である([RFC4456]のセクション11も参照)。

[RFC4456]のセクション11で述べられているように、BGPルート・リフレクタのIGPの位置は重要であり、ルーティングに影響を与える。これは、最適なルート・リフレクタに設定されたIGPの位置の選択にも同様に当てはまる。バックアップの位置が提供されている場合、プライマリIGPの位置がIGPから消えたとき(つまり、障害が発生した場合)に使用される。ルート・リフレクタ[RFC4456]の障害と同様に、経路選択され、クライアントに広告されるパスが変更される可能性があり、一般的に、障害後のパスは最適ではなくなることが予想される。これは、IGPトポロジと、プライマリIGPの位置とバックアップIGPの位置との間のIGP距離に依存する。距離が小さいほど、潜在的な影響は小さくなる。

N個の適切なIGPの位置を選択した後、オペレータはルート・リフレクタのすべてまたはサブセット上で、それらすべての経路選択を有効にすることを選択できる。オペレータは代わりに、IGPの位置ごとに1つまたは複数のルート・リフレクタ(バックアップ・ケース)を配備するか、その中間の設計を作成することもできる。この選択は、運用モデル(集中型か地域ごとか)、障害発生時の許容範囲(爆発半径)、ルート・リフレクタ間のメッシュのIBGPセッション数、パフォーマンス、機器の構成粒度によって異なる。

この手法を使用すると、ルート・リフレクションがフォワーディング・プレーンの外に移動し、ホップバイホップ転送がエンドツーエンドのMPLSまたはIPカプセル化に置き換えられても、ISPはホットポテト・ルーティング・ポリシーを適用できる。すべてのルータにADD-PATHを展開する場合と比較して、BGP ORRは、ホットポテト・ルーティングを実行するためにネットワークのエッジにプッシュする必要がある状態の量を削減する。

BGP ORRのIGP位置を変更しても、BGP決定プロセスのIGPタイブレーク([RFC4271]、セクション9.1.2.2のステップe)の前に適用されるポリシーを妨げない。

さまざまなIGPの位置を持つ経路を計算するには、複数のショーテスト・パス・ファースト (SPF)の計算と複数の(サブセットの)BGP決定プロセスが必要になる。このシナリオでは、より多くのコンピューティング・リソースが必要になる。本文書では、ルート・リフレクタごと、またはクライアント・セットごと、またはクライアントごとに1つの決定プロセスなど、さまざまな粒度を許容する。よりきめ細かな粒度、すなわち、より多くコンピューティング・パワーのコストで、最適なホットポテト・ルーティングに変換できるかもしれない。クライアントごとにIGP位置を設定することは、各クライアントを理想的な(独自の)IGPの位置に関連付けることができるため、最も精度が高くなる。ただし、これを行うと、(上で説明したように)パフォーマンスに影響が出る可能性がある。クライアント・セットごとにIGPの位置を使用すると、精度は低下するが、ルート・リフレクタのパフォーマンスへの影響は軽減される。同様に、IGPの位置がルーティング・インスタンス全体に対して選択される場合、精度は最低になるが、パフォーマンスへの影響は最小限に抑えられる。最後の動作モード(IGPの位置が、ルーティング・インスタンス全体に対して選択される場合)では、[RFC4456]で説明しているように、精度とパフォーマンスの両方の指標がルート・リフレクションと同等になる。きめ細かな計算を実行できるかどうかは、導入しているプラットフォーム/ハードウェア、クライアント数、BGP経路数、IGPトポロジのサイズに依存する。要するに、サイジングに関する考慮事項は、BGPルート・リフレクタの展開に似ている。

⚠️ ベンダーの実装について
ベンダ BGP-ORR (RFC 9107) BGP-LS (RFC 7752) ADD-PATH (RFC 7911)
Cisco IOS-XE ? ? ◯
Cisco IOS-XR ◯ (OSPF/ISIS) ◯ ◯
Juniper Junos ◯ (OSPF/ISIS) ◯ ◯
Nokia SR-OS ◯ (OSPF/ISIS) ◯ ◯
OpenBGPD X X ◯
BIRD X X ◯
FRRouting X X ◯

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

本文書で規定されている拡張機能は、BGPルート・リフレクタの経路を計算するための追加情報を使用して、新しいメトリック値を提供する。不適切に使用されたメトリック値がネットワークのレジリエンスに影響を与える可能性はあるが、この拡張機能は[RFC4456]にある既存のIBGPに内在する根本的なセキュリティ問題を変更するものではない。

本文書は、新たな保護手段の要件を導入するものではない。

6. IANA に関する考慮事項

本文書にIANAのアクションはない。

7. 参考文献

7.1. 引用規格

[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>.

[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>.

[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <https://www.rfc-editor.org/info/rfc4456>.

[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>.

[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>.

7.2. 参考規格

[ISO10589] International Organization for Standardization, "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, Second Edition, November 2002.

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

[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>.

[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>.

[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>.

[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, <https://www.rfc-editor.org/info/rfc7947>.

謝辞

キール・パテル、エリック・ローゼン、クラレンス・フィルスフィルス、ウリ・ボーンハウザー、ラス・ホワイト、ヤコブ・ハイツ、マイク・シャンド、ジョン・ミッチェル、ジョン・スカダー、ジェフ・ハース、マーティン・ジャーネス、ダニエレ・チェッカレッリに感謝する。キーラン・ミルン、ジョブ・スナイデルス、ランディ・ブッシュ、アルバロ・レタナ、フランチェスカ・パロンビーニ、ベンジャミン・カドゥク、ザヘドゥザマン・サルカー、ラース・エガート、マレー・クチェラウィ、トム・ペッチ、ニック・ヒリアードらの貴重な意見に感謝する。

貢献者

以下の人物が現在の文書形式に多大な貢献をした。

ステファン・リトコウスキー
Cisco Systems
メール:slitkows.ietf@gmail.com

アダム・チャペル
GTT Communications, Inc.
Aspira Business Centre
Bucharova 2928/14a
158 00 Prague 13 Stodůlky
チェコ共和国
メール: adam.chappell@gtt.net

著者のアドレス

ロバート・ラズク (編集者)
NTT Network Innovations
メール: robert@raszuk.net

ブルーノ・デクレーン (編集者)
Orange
メール: bruno.decraene@orange.com

クリスチャン・カサール
電子メール: cassar.christian@gmail.com

エリック・オーマン
メール: erik.aman@aman.se

ケビン・ワン
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
アメリカ合衆国
メール: kfwang@juniper.net

更新履歴

  • 2024.4.13
GitHubで編集を提案

Discussion