Zenn
🍩

RFC 7854: BGPモニタリング・プロトコル(BMP)

2024/07/03に公開
RFC
bgp
tech

要旨

本文書では、BGPセッションを監視するために使用できるBGPモニタリング・プロトコル(BMP)を定義する。BMPは、経路ビューを取得するための便利なインタフェースを提供することを目的としている。BMPが導入される前は、このようなビューを取得するために、スクリーン・スクレイピングが最も一般的に使われていた。BMPの設計目標は、シンプルで、便利で、実装が簡単で、サービスへの影響を最小限に抑えることである。BMPはルーティング・プロトコルとしての使用には適さない。

本文書の位置付け

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

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、<http://www.rfc-editor.org/info/rfc7854>で入手できる。

著作権表示

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

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

本文書には、2008年11月10日以前に公開または利用可能になったIETF文書またはIETF貢献の資料が含まれている場合がある。このような資料の著作権を管理する者は、IETF標準化過程外での変更を許可する権利をIETFトラストに付与していない可能性がある。このような資料の著作権を管理する人物から適切なライセンスを取得しない限り、この文書はIETF標準化過程外で変更することはできない。また、RFCとして公開するためにフォーマットしたり、英語以外の言語に翻訳する場合を除き、本文書の派生物をIETF標準化過程外で作成してはならない。

1. はじめに

多くの研究者やネットワーク・オペレータが、ルータのBGPルーティング情報ベース(RIB)の内容や、ルータが受信しているプロトコル・アップデートのビューにアクセスすることを望んでいる。この監視タスクは、標準的なプロトコル・メカニズムでは実現できない。BMPが導入される以前は、このデータはスクリーン・スクレイピングによってしか取得できなかった。

⚠️ 従来とBMPによる監視の違い

従来は、ベストパスのみを監視するため、すべてのピアからの経路を監視できなかった。
bgpmon-trad
BMPの場合、すべてのピアからの経路を監視できる。
bgpmon-bmp

BMPは、継続的にピアのAdj-RIB-Inにアクセスし、監視ステーションがさらなる分析に使用できる特定の統計情報の定期的なダンプを提供する。ざっくり言うと、BMPはさまざまな監視対象BGPセッションで受信したメッセージを多重化した結果と考えることができる。

⚠️ BMPの監視ポイント

Adj-RIBs-Inのフィルタ適用前後、Adj-RIBs-Outのフィルタ適用前後、Loc-RIBとBGPのすべてが監視対象になる。
bgpmon-trad

1.1. 要件言語

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119[RFC2119]の記述にしたがって解釈する。

2. 定義

  • Adj-RIB-In: [RFC4271]で定義しているように、「Adj-RIBs-Inは、ピアからローカルBGPスピーカーに広告された未処理のルーティング情報が含む」。本文書では、ポリシー前Adj-RIB-Inとも呼ばれる。

  • ポリシー後Adj-RIB-In: Adj-RIB-Inにインバウンド・ポリシーを適用した結果だが、Loc-RIBを形成するための、経路選択適用前のもの。

3. BMPの運用概要

3.1. BMPメッセージ

BMPが提供するメッセージを以下に示す:

  • 経路モニタリング (RM): ピアから受信したすべての経路の初期ダンプを提供するために使用し、ピアが広告し、撤回した増分経路をモニタリング・ステーションに送信する継続的なメカニズムにも使われる。

  • Peer Down通知: ピアリング・セッションがダウンしたことを示すため、セッション切断の理由を示す情報と共に送信されるメッセージ。

  • 統計レポート(SR): ルータで起こっているアクティビティの大まかな指標として、モニタリング・ステーションが使用できる統計情報の継続的なダンプ。

  • Peer Up通知: ピアリング・セッションが開始されたことを示すために送信されるメッセージ。このメッセージには、OPENメッセージにおいてピア間で交換されたデータに関する情報と、ピアリングTCPセッション自体に関する情報が含まれる。ピアがEstablished状態に遷移するたびに送信されることに加え、BMPセッション自体が立ち上がると、Established状態の各ピアに対してPeer Up通知が送信する。

  • 開始: 監視対象ルータがベンダ、ソフトウェア・バージョンなどを監視ステーションに通知する手段。

  • 終了: 監視対象ルータがBMPセッションを終了する理由を監視ステーションに通知する手段。

  • 経路ミラーリング: 監視対象ルータが受信したメッセージの複製をそのまま送信する手段。監視対象のBGPセッションを正確にミラーリングするために使用できる。また、不正なBGPプロトコル・データ・ユニット(PDU)を報告するためにも使用できる。

3.2. 接続の確立と終了

BMPはTCP上で動作する。すべてのオプションは、監視対象ルータの設定によって制御される。監視ステーションは監視対象ルータにBMPメッセージを送信することはない。監視対象ルータは、監視ステーションがデータを送信しないようにする(例えば、TCPセッションを半分閉じるか、ウィンドウ・サイズを0に設定する)措置を取ってもよいし、監視ステーションから送信されたデータを黙って破棄してもよい(MAY)。

ルータは、1つ以上の監視ステーションによって監視される。各(ルータと監視ステーション)ペアに関して、一方のパーティはTCPセッションの確立に関してアクティブで、もう一方のパーティがパッシブである。どちらの当事者がアクティブで、どちらがパッシブかは、設定によって制御される。

パッシブ・パーティは特定のTCPポートをリッスンするように設定され、アクティブ・パーティはそのポートへの接続を確立するように設定される。アクティブ・パーティがパッシブ・パーティに接続できない場合、アクティブ・パーティは定期的に接続を再試行する。再試行は、何らかのバックオフに従わなければならない(MUST)。デフォルトの初期バックオフは30秒で、最大720秒の指数バックオフを推奨する。

ルータは、接続を受け入れるIPアドレス・セットを制限してもよい(MAY)。ルータは、特定のIPアドレスからの同時接続数を制限する必要がある(SHOULD)。この制限のデフォルト値は1にする必要がある(SHOULD)が、実装は設定でこの制限を無効にしてもよい(MAY)。ルータは、セッションを確立できるレートも制限しなければなならない(MUST)。推奨されるデフォルトの確立レートは、1分あたり2セッションである。

ルータ(または管理ステーション)は、両パーティがアクティブに設定されている場合に発生するかもしれない冗長接続を検出するロジックを実装し(MAY)、冗長接続の終了を選択してもよい(MAY)。この目的のために終了理由コードを定義している。

接続が確立されると、ルータはその接続上でメッセージを送信する。初期化やハンドシェイクのフェーズはなく、接続が確立されるとすぐにメッセージを送信する。

監視ステーションがBMP処理を終了または再開する場合は、単に接続を切断する。

3.3. BMPセッションのライフサイクル

ルータは、1つ以上の監視ステーションにBMPで通信するように設定する。BGPピアのサブセットに対してのみ監視情報を送信するように設定してもよい(MAY)。それ以外の場合、すべてのBGPピアが監視対象と見なされる。

BMPセッションは、アクティブ・パーティ(設定によって決定されるルータまたは管理ステーションのいずれか)がTCPセッション(「BMPセッション」)を正常に開いたときに始まる。セッションが起動すると、ルータはBMPメッセージの送信を開始する。開始するには、開始メッセージを送信しなければならない(MUST)。その後、Established状態にある監視対象のBGPピアごとに、BMPセッションを介してPeer Upメッセージを送信する。続いて、経路モニタリング・メッセージにカプセル化されたAdj-RIBs-In(ポリシー前、ポリシー後、あるいはその両方、セクション5を参照)のコンテンツを送信する。あるピアのすべての経路を送信したら、そのピアのEnd-of-RIBメッセージを送信しなければならない(MUST)。監視対象の各ピアのEnd-of-RIBを送信したら、最初のテーブル・ダンプが完了する。(テーブル・ダンプを収集したいだけの監視ステーションは、各Peer Upメッセージに対応するEnd-of-RIBまたはPeer Downメッセージを収集したら、接続を閉じることができる。)

⚠️ BMPセッション

bmp-sessionr

初期のテーブル・ダンプの後、ルータは経路モニタリング・メッセージでカプセル化された増分更新を送信する。設定に応じて、定期的に統計レポートまたは新しい開始メッセージを送信してもよい(MAY)。新しい監視対象のBGPピアがEstablished状態になると、対応するPeer Upメッセージを送信する。Peer Upメッセージが送信されたBGPピアがEstablished状態から移行すると、対応するPeer Downメッセージを送信する。

BMPセッションは、そのセッションを伝送するTCPセッションが何らかの理由で閉じられると終了する。ルータは、セッションを閉じる前に終了メッセージを送信してもよい(MAY)。

4. BMPメッセージ・フォーマット

4.1. 共通ヘッダ

以下の共通ヘッダは、すべてのBMPメッセージに現れる。BMPメッセージの残りのデータは、共通ヘッダのメッセージ・タイプ・フィールドに依存する。

common-header

  • バージョン(1バイト): BMPのバージョンを示す。この仕様で定義されているすべてのメッセージでは、「3」に設定する。(「1」と「2」は、本文書のドラフト版で使用していた。) バージョン0は予約済みで、送信してはならない(MUST NOT)。

  • メッセージ長(4バイト): バイト単位のメッセージの長さ(ヘッダ、データ、カプセル化されたメッセージがあればそれを含む)。

  • メッセージ・タイプ(1バイト): これはBMPメッセージのタイプを識別する。BMP実装は、受信時に認識できないメッセージ・タイプを無視しなければならない(MUST)。

    • タイプ = 0: 経路監視
    • タイプ = 1: 統計レポート
    • タイプ = 2: Peer Down通知
    • タイプ = 3: Peer Up通知
    • タイプ = 4: 開始メッセージ
    • タイプ = 5: 終了メッセージ
    • タイプ = 6: 経路ミラーリング・メッセージ

4.2. Per Peerヘッダ

Per Peerヘッダは、ほとんどのBMPメッセージの共通ヘッダに続く。BMPメッセージの残りのデータは、共通ヘッダのメッセージ・タイプ・フィールドに依存する。

perpeer-header

  • ピア・タイプ (1バイト): ピアのタイプを識別する。現在、3種類のピアを識別する:

    • ピア・タイプ = 0: グローバル・インスタンス・ピア
    • ピア・タイプ = 1: RDインスタンス・ピア
    • ピア・タイプ = 2: ローカル・インスタンス・ピア

  • ピア・フラグ (1バイト): これらのフラグは、ピアに関する詳細情報を提供する。フラグは以下のように定義されている:
    perpeer-flag

    • Vフラグは、ピア・アドレスがIPv6アドレスであることを示す。IPv4ピアの場合、Vフラグを0に設定する。

    • Lフラグが1の場合、メッセージがポリシー後のAdj-RIB-Inを反映していることを示す(つまり、パス属性はインバウンド・ポリシーの適用を反映している)。メッセージがポリシー前のAdj-RIB-Inを反映している場合、0に設定する。ローカルに発信された経路は、Lフラグが1を持つ。詳細については、セクション5を参照のこと。このフラグは、経路ミラーリング・メッセージ(セクション4.7)で使用する場合、意味を持たない。

    • Aフラグが1の場合、メッセージが従来の2バイトAS_PATH形式でフォーマットされていることを示す。0の場合、メッセージは4バイトのAS_PATH形式[RFC6793]を使用してフォーマットする。BMPスピーカーは、ピアから受信したAS_PATH情報をそのまま伝播することを選択してもよい(MAY)。また、ピアから受信した方法に関係なく、すべてのAS_PATH情報を4バイト形式に再フォーマットすることを選択してもよい(MAY)。後者の場合、AS4_PATHまたはAS4_AGGREGATORパス属性をBMP UPDATEメッセージで送るべきではない(SHOULD NOT)。このフラグは、経路ミラーリング・メッセージ(セクション4.7)で使用される場合は意味を持たない。

    • 残りのビットは将来の使用のために予約されている。これらは0として送信しなければならず(MUST)、受信時にその値を無視しなければならない(MUST)。

  • ピア識別子(8バイト): 現在のルータは複数のインスタンスを持つことができる(例えば、レイヤ3仮想プライベート・ネットワーク(L3VPN) [RFC4364])。このフィールドは、1 つのアドレス・ドメインに属するピアを他のアドレス・ドメインと区別するために存在する。

    ピアが「グローバル・インスタンス・ピア」の場合、このフィールドはゼロで埋められる。ピアが「RDインスタンス・ピア」の場合、このフィールドはピアが属する特定のインスタンスの経路識別子が設定される。ピアが「ローカル・インスタンス・ピア」の場合、このフィールドはローカルで定義された一意の値を設定する。いずれの場合も、ピア・タイプとピア識別子の組み合わせは、他の識別情報が重複する可能性のあるピアの曖昧さをなくすのに十分である。

  • ピア・アドレス: カプセル化されたPDUを受信したTCPセッションに関連付けられたリモートIPアドレス。このフィールドにIPv4アドレスが含まれている場合は4バイト長(上位12バイトはゼロで埋められる)、このフィールドにIPv6アドレスが格納されている場合は16バイト長である。

  • ピアAS: カプセル化されたPDUを受信したピアの自律システム番号。このフィールドに16ビットのAS番号が格納されている場合[RFC6793]、上位16ビットにゼロを埋める必要がある。

  • ピアBGP ID: カプセル化されたPDUを受信したピアのBGP識別子。

  • タイムスタンプ: カプセル化された経路を受信した時刻(Adj-RIB-Inにインストールされた時刻と考えることもできる)。1970年1月1日(UTC)の真夜中(0時)からの秒とマイクロ秒数で表される。ゼロの場合、時刻は利用できない。タイムスタンプの精度は実装に依存する。

4.3. 開始メッセージ

開始メッセージは、監視対象ルータが、ベンダ、ソフトウェア・バージョンなどを監視ステーションに通知する手段を提供する。開始メッセージは、TCPセッションが起動した後の最初のメッセージとして送信しなければならない(MUST)。開始メッセージは、監視対象ルータに変更があった場合、その後いつでも送信してよい(MAY)。

開始メッセージは、共通のBMPヘッダと、それに続く監視対象ルータに関する情報を含む2つ以上の情報TLV(セクション4.4)で構成する。sysDescrとsysName情報TLVは送信しなければならない(MUST)が、他の情報は任意である。文字列TLVは複数回含めてよい(MAY)。

⚠️ 開始メッセージ(パケット)

bmp-init-msg

4.4. 情報TLV

情報TLV は、開始(セクション4.3) 及びPeer Up(セクション4.10)メッセージで使用する。

information-tlv

  • 情報タイプ (2 バイト): 提供される情報のタイプ。定義しているタイプは以下のとおり:

    • タイプ = 0: 文字列。情報フィールドは情報長フィールドで長さを指定した自由形式のUTF-8文字列を含む。この値は管理上割り当てられる。文字列をNull(または他の特定の)文字で終了する必要はない ─ 情報長フィールドがその終了を指定する。複数の文字列が含まれる場合、報告時にそれらの順序を保持しなければならない(MUST)。

    • タイプ = 1: sysDescr。情報フィールドには、sysDescr MIB-II [RFC1213]オブジェクトの値と同じ値に設定しなければならない(MUST)ASCII文字列を含む。

    • タイプ = 2: sysName。情報フィールドには、sysName MIB-II [RFC1213]オブジェクトの値と同じ値に設定しなければならない(MUST)ASCII文字列を含む。

  • 情報長(2バイト): 続く情報フィールドのバイト単位の長さ。

  • 情報(可変): タイプに応じた、監視対象ルータに関する情報。

4.5. 終了メッセージ

終了メッセージは、監視対象ルータがセッションを終了する理由を示す方法を提供する。このメッセージの使用を推奨する(RECOMMENDED)が、監視ステーションは、メッセージなしでセッションが終了することを常に想定していなければならない(MUST)。ルータが終了メッセージを送信したら、それ以上メッセージを送信せずにTCPセッションを閉じなければならない(MUST)。同様に、監視ステーションは終了メッセージを受信した後、TCPセッションを閉じなければならない(MUST)。

終了メッセージは、以下のように、共通のBMPヘッダに続き、終了理由に関する情報を含む1つ以上のTLVで構成される。

termination-tlv

  • 情報タイプ(2バイト): 提供される情報のタイプ。定義されているタイプは以下のとおりである:

    • タイプ = 0: 文字列。情報フィールドは、情報長フィールドによって長さが指定された自由形式のUTF-8文字列を含む。このTLVを含めるかどうかは任意である。定義した理由のいずれかについて、さらに詳細を提供するために使用しても良い(MAY)。メッセージには複数の文字列TLVを含めてもよい(MAY)。

    • タイプ = 1: 理由。情報フィールドは、接続が終了した理由を示す2バイトのコードを含む。理由によっては、さらにTLVを持つ場合がある。このTLVを含めることは必須である。定義している理由は以下のとおりである:

      • 理由 = 0: セッションが管理上終了した。セッションは再開される可能性がある。
      • 理由 = 1: 特定の理由はない。
      • 理由 = 2: リソース不足。ルータがBMPセッションに使用できるリソースを使い果たした。
      • 理由 = 3: 冗長接続。ルータは、この接続が別の接続と冗長と判断した。
      • 理由 = 4: セッションは永久に管理上クローズされ、再開されることはない。監視ステーションは、監視対象ルータへの再接続を試みるレートを下げる必要がある(場合によっては0まで)。

  • 情報長(2バイト): これに続く情報フィールドの長さ(バイト単位)。

  • 情報(可変): タイプに応じた監視対象ルータに関する情報。

4.6. 経路監視

経路監視メッセージは、Adj-RIBs-Inの初期同期に使用する。また、Adj-RIB-In状態を継続的な監視するためにも使用する。経路監視メッセージは状態圧縮されている。これについては、セクション5で詳しく説明する。

共通BMPヘッダとPer Peerヘッダの後に、BGP UPDATE PDUが続く。

⚠️ 経路監視メッセージ(パケット)

bmp-init-msg

4.7. 経路ミラーリング

経路ミラーリング・メッセージは、受信したメッセージをそのまま複製するために使用する。ミラーリングの可能な用途は、監視対象の1つ以上のBGPセッションを状態圧縮なしで正確にミラーリングすることである。もう1つの用途は、デバッグ目的で、Treat-as-withdrawの対象となったメッセージ[RFC7606]をミラーリングすることである。ミラーリングされたメッセージは、サンプリングされる場合もあれば、ロスレスの場合もある。メッセージ損失情報コードは、損失を示すために用意されている。セクション6で詳細を説明する。

共通BMPヘッダとPer Peerヘッダに続くのは、メッセージやメッセージ・セットに関する情報を含むTLVセットが続く。各TLVは、2バイトのタイプ・コード、2バイトの長さフィールド、及び可変長の値で構成される。特定のTLVを含めることはオプションだが、少なくとも1つのTLVを含める必要がある(SHOULD)。そうでなければ、メッセージを送信する意味がない。定義されているTLVは以下のとおりである。

  • タイプ = 0: BGPメッセージ。BGP PDU。このPDUはUPDATEメッセージであってもなくてもよい。BGPメッセージTLVが経路ミラーリング・メッセージ内にある場合、TLVリストの最後になければならない(MUST)。

  • タイプ = 1: 情報。ミラーリングされたメッセージまたはメッセージ・ストリームに関する情報を提供する2バイト・コード。定義されるコードは以下のとおりである。

    • コード = 0: エラーのあるPDU。含まれたメッセージに何らかのエラーがあり、使用できないため、撤回として扱われる[RFC7606]。BGPメッセージTLVもTLVリストに含まれなければならない(MUST)。

    • コード = 1: メッセージが失われた。1つ以上のメッセージが失われた可能性がある。これは例えば、実装がミラーリング・メッセージをキューに入れるための利用可能なバッファ領域が不足した場合に発生する可能性がある。

経路ミラーリング・メッセージは、経路監視メッセージを送信できる場合はいつでも送信できる。

4.8. 統計レポート

これらのメッセージには、監視ステーションがルータで発生する興味深いイベントを観察するために使用できる情報が含まれている。

SRメッセージの送信は、タイマー・トリガまたはイベント・ドリブン(例えば、重要なイベントが発生した時やしきい値に達した時)である。本仕様では、これらのレポートがいつ、どのイベントで送信されなければならないかについて、いかなるタイミング制限も課していない。送信タイミングを決定するのは実装に任されているが、タイマーやしきい値の設定制御を提供する必要がある。本文書はSRメッセージの形式と内容のみを規定する。

共通のBMPヘッダとPer Peerヘッダに続いて、統計メッセージ内のカウンタの数を示す4バイトのフィールドがある。各カウンタはTLVとして符号化される。

stats-count

各カウンタは次のように符号化される。

stats-data

  • 統計タイプ(2バイト): 統計データ・フィールドに格納される統計のタイプを定義する。

  • 統計長さ(2バイト): 統計データ・フィールドの長さを定義する。

この仕様は以下の統計を定義する。BMP実装は、受信時に認識できない統計タイプを無視しなければならず(MUST)、同様に統計データ・フィールドの予期しないデータも無視しなければならない(MUST)。

統計情報はカウンタまたはゲージのいずれかで、[RFC1155]のセクション3.2.3.3と[RFC2856]のセクション4の例に従って以下のように定義される:

32ビット・カウンタ: 最大値に達するまで単調に増加する非負の整数。最大値に達すると、再び0 から増加し始める。最大値は2^{32}-1(10進数で4294967295)である。

64ビット・ゲージ: 増加または減少する非負の整数だが、最大値を超えることも最小値を下回ることもない。最大値は2^{64}-1(10進数で18446744073709551615)より大きくすることはできない、最小値は0より小さくすることはできない。この値は、モデル化される情報が最大値以上の場合は常に最大値となり、モデル化される情報が最小値以下の場合は常に最小値となる。その後、モデル化される情報が最大値を下回る(または最小値を上回る)と、64ビット・ゲージも減少(または増加)する。

  • 統計タイプ = 0: (32ビット・カウンタ) インバウンド・ポリシーによって拒否されたプレフィックスの数。
  • 統計タイプ = 1: (32ビット・カウンタ) (既知の)重複プレフィックス広告の数。
  • 統計タイプ = 2: (32ビット・カウンタ) (既知の)重複撤回の数。
  • 統計タイプ = 3: (32ビット・カウンタ) CLUSTER_LISTループにより無効になったUPDATEの数。
  • 統計タイプ = 4: (32ビット・カウンタ) AS_PATHループにより無効になったUPDATEの数。
  • 統計タイプ = 5: (32ビット・カウンタ) ORIGINATOR_IDにより無効になったUPDATEの数。
  • 統計タイプ = 6: (32ビット・カウンタ) AS_CONFEDループにより無効になったUPDATEの数。
  • 統計タイプ = 7: (64ビット・ゲージ) Adj-RIBs-In内の経路の数。
  • 統計タイプ = 8: (64ビット・ゲージ) Loc-RIB内の経路の数。
  • 統計タイプ = 9: AFI/SAFごとのAdj-RIB-Inの経路の数。値は、2バイトのアドレス・ファミリ識別子(AFI)、1バイトの後続アドレス・ファミリー識別子(SAFI)、それに続く64ビットのゲージで構成される。
  • 統計タイプ = 10: AFI/SAFIごとのLoc-RIB内の経路の数。値は、2バイトのAFI、1バイトのSAFI、それに続く64ビットのゲージで構成される。
  • 統計タイプ = 11: (32ビット・カウンタ) Treat-as-withdraw処理の対象となったUPDATEの数[RFC7606]。
  • 統計タイプ = 12: (32ビット・カウンタ) Treat-as-withdraw処理の対象となったプレフィックスの数 [RFC7606]。
  • 統計タイプ = 13: (32ビット・カウンタ) 受信した重複UPDATEメッセージの数。

現在の仕様では、「統計データ」として4バイトのカウンタと8バイトのゲージのみが規定されているが、これは将来のバージョンでより複雑なTLVタイプの「統計データ」(例えば、プレフィックス固有のデータを伝送できるもの)を組み込むことを妨げるものではない。SRメッセージはオプションである。しかし、SRメッセージが伝送される場合、少なくとも1つの統計量を伝送しなければならない(MUST)。

⚠️ 統計レポート(パケット)

statistics-repo

4.9. Peer Down通知

このメッセージは、ピアリング・セッションが終了したことを示すために使用される。

peerdown-notification

理由は、セッションがクローズした理由を示す。定義している値は以下のとおり:

  • 理由1: ローカルシステムがセッションをクローズした。理由の後には、ピアに送信されるはずだったBGP NOTIFICATIONメッセージを含むBGP PDUが続く。

  • 理由2: ローカルシステムはセッションをクローズした。通知メッセージは送信されなかった。理由コードの後には、システムがセッションをクローズする原因となった有限状態マシン(FSM)イベントに対応するコードを含む2バイトのフィールドが続く([RFC4271]のセクション8.1参照)。両方とも0に設定された2バイトは、関連するイベントコードが定義されていないことを示すために使用する。

  • 理由3: リモートシステムは通知メッセージでセッションをクローズした。理由の後には、ピアから受信したBGP NOTIFICATIONメッセージを含むBGP PDUが続く。

  • 理由4: リモートシステムは通知メッセージなしでセッションをクローズした。これには予期しないトランスポート・セッションの終了が含まれるため、場合によっては、ローカルシステムとリモートシステムの両方でこれが適用されると考えるかもしれない。

  • 理由5: このピアの情報は、 設定上の理由で監視ステーションに送信されなくなる。これは厳密に言えば、ピアがダウンしたことを示すものではないが、監視ステーションがピアのUPDATEを受信していないことを示す。

Peer Downメッセージは、暗黙のうちに、問題のピアに関連付けられたすべての経路を撤回する。BMP実装は、そのような経路に対する明示的な撤回の送信を省略してもよい(MAY)。

4.10. Peer Up通知

Peer Upメッセージは、ピアリング・セッションが起動した(つまり、Established状態に移行した)ことを示すために使用する。共通BMPヘッダとPer Peerヘッダの後に以下の内容が続く:

peerup-notification

  • ローカルアドレス: ピアリングTCPセッションに関連付けられたローカルIPアドレス。このフィールドにIPv4アドレスが含まれる場合は4バイト長で、Vフラグによって決定する(上位12バイトはゼロで埋められる)。このフィールドにIPv6アドレスが含まれる場合は16バイト長である。

  • ローカルポート: ピアリングTCPセッションに関連付けられたローカルポート番号。TCPセッションが実際に存在しない場合は0である(セクション8.2参照)。

  • リモートポート: ピアリングTCPセッションに関連付けられたリモートポート番号。TCPセッションが実際に存在しない場合は0である(セクション8.2参照)。(リモートアドレスは、固定ヘッダのピア・アドレス・フィールドで確認できる。)

  • 送信OPENメッセージ: 監視対象ルータがそのピアに送信した完全なOPENメッセージ。

  • 受信OPENメッセージ: 監視対象ルータがそのピアから受信した完全なOPENメッセージ。

  • 情報: 情報TLV(セクション4.4)のフォーマットを使用したピアに関する情報。この文脈では文字列型のみが定義され、繰り返し使用できる。情報フィールドを含めるかどうかはオプション(OPTIONAL)である。情報フィールドの有無は、共通ヘッダのメッセージ長を調べることで推測できる。

⚠️ Peer Up通知(パケット)

bmp-peerup-notification

5. 経路監視

BMPの通常の動作モードでは、BMPセッションが起動した後、経路監視メッセージを使用して、各監視対象ピアのAdj-RIB-Inのスナップショットを提供する。これは、経路監視メッセージにカプセル化された標準BGPアップデート・メッセージを使用して、それらのピアのAdj-RIB-Inに格納されているすべての経路を送信することによって行われる。ピアダンプ内のメッセージの順序に関する要件はない。あるピアの初期ダンプが完了したら、そのピアのEnd-of-RIBマーカーを(BMPカプセル化ヘッダを付加し、[RFC4724]のセクション2で規定されているように)送信し、これを示さなければならない(MUST)。セクション9も参照のこと。

BMPスピーカーは、ポリシー前の経路、ポリシー後の経路、またはその両方を送信することができる。その選択は実装上の制約によるかもしれない(例えば、BGPの実装が、ポリシーによってフィルタリングされた経路を保存しない可能性がある)。ポリシー前の経路はBMPヘッダでLフラグをクリアしなければならない(MUST)(セクション4を参照)。ポリシー後の経路はLフラグを設定しなければならない(MUST)。実装がポリシー前の経路とポリシー後の経路の両方を送信することを選択した場合、それは事実上、2つのアップデート・ストリームをBMPセッションに多重化することになる。ストリームはLフラグで区別される。

実装が、経路の受信時期に関する情報を提供できる場合、BMPタイムスタンプ・フィールドでそのような情報を提供してもよい(MAY)。それ以外の場合、BMPタイムスタンプ・フィールドには、時間が利用できないことを示す0を設定しなければならない(MUST)。

継続的な監視は、BGPアップデートPDUで経路変更を伝播し、そのPDUを監視ステーションに転送することで実現する。この場合もRMメッセージを使用する。属性変更など、経路に変更が発生すると、ルータは新しい属性で監視ステーションを更新しなければならない。前述のように、LフラグをクリアしたUPDATE、LフラグをセットしたUPDATE、またはLフラグをクリアしたUPDATEとLフラグを設定したUPDATEの2つのUPDATEを生成してもよい(MAY)。ピアによって経路が撤回されたとき、対応する撤回が監視ステーションに送られる。その撤回は、前のアナウンスと同じようにLフラグが設定しなければならない(MUST)。問題の経路が前にLフラグがクリアとセットの両方でアナウンスしていた場合、撤回は同様にLフラグがクリアとセットで2回送らなければならない(MUST)。複数の変更した経路は、標準のBGPプロトコルとまったく同じように、実行可能な場合は1つのBGP UPDATE PDUにまとめてよい(MAY)。

RMメッセージはピアから受信したメッセージを複製するものではないことに留意することが重要である(必要な場合は経路ミラーリング(セクション6)が提供される)。ルータはUPDATEを迅速に生成するよう試みるべきだが、UPDATEの受信、RMメッセージの生成、監視ステーションへの送信の間に経過する可能性のある時間は有限である。そのプレフィックスの中間で状態の変更があった場合、ルータがそのプレフィックスの最終状態を監視ステーションに生成することが許容される。これは、「状態圧縮」と呼ばれることがある。例えば、異なる実装がパス属性をどのようにフォーマットするかの違いにより、実際に生成されたステーションに送信されるPDUは、ピアから受信した正確なPDUと異なるかもしれない。

6. 経路ミラーリング

経路ミラーリング・メッセージは主に2つの理由で提供する。1つ目は、実装が、状態圧縮なしで、ピアから受信したすべてのメッセージを完全に忠実に表示するモードで動作できるようにするためである。セクション5で述べたように、BMPの通常の動作モードでは、このような機能は提供できない。実装者は、状態圧縮がなければ、ミラーリングのためにキューに入れられたメッセージをバッファリングするために、実装が無限のストレージを必要とする可能性があることを強く警告する。経路ミラーリングは、従来のルータでの実装には適しているとは考えにくく、実装者がトレードオフを慎重に検討した場合を除き、その使用は推奨しない(NOT RECOMMENDED)。これらのトレードオフには、ルータのリソースの枯渇、BGP UPDATEメッセージの送信または受信を妨げる可能性、ルーティングの収束を遅らせることがなどがある。

経路ミラーリングの2つ目の用途は、エラー報告と診断である。BGP UPDATE メッセージの改訂版エラー処理[RFC7606]を使用している場合、ルータはBGPセッションをリセットすることなく、エラーが含まれていると判断されたBGPメッセージを処理することができる。そのようなメッセージはミラーリングしてもよい(MAY)。そのようなミラーリングに使用されるバッファリングは制限する必要がある(SHOULD)。エラーになったメッセージがバッファを使い果たしたためにミラーリングできない場合、そのことを示すために「メッセージ損失」コードを含むメッセージを送信する必要がある(SHOULD)。(これは、この用途のためにバッファを予約する必要があることを意味する。)

7. 統計レポート

上で要点を説明したように、SRメッセージは監視対象ルータ上の特定のイベントとカウンタを監視するために使用される。監視の1つのタイプは、監視対象ルータ上で過度の数の経路広告と撤回が発生しているかどうか(チャーン) を確認することである。別の指標は、ルータ上のループしたAS_PATHの数を評価することである。

本文書では、まず少数のカウンタを提案しているが、著者は、BMPスタイルの監視を必要とする新しいアプリケーションによって、将来的にこのリストが拡大する可能性があると考えている。

8. その他の考慮事項

8.1. 複数のインスタンス

ルータによっては、例えば「論理ルータ」として、または他の機能によって、BGPプロトコルの複数のインスタンスをサポートする場合がある。BMPプロトコルは、BGP の単一のインスタンスに関連する。したがって、ルータが複数のBGPインスタンスをサポートする場合、複数のBMPインスタンス(BGPインスタンスごとに1つ)もサポートする必要がある。異なるBMPインスタンスは、例えば、識別可能なsysNameを使用するか、文字列TLVにインスタンス識別情報を含めるなどして、互いに異なる開始メッセージを生成する必要がある(SHOULD)。

8.2. ローカルで生成された経路

他のプロトコルからの再配布の結果か、他の理由かにかかわらず、ローカルルータがBGPに生成された経路については、何らかの考慮が必要である。

そのような経路は、ルータ自身のアドレスがヘッダのピア・アドレス・フィールドに置くことで、ルータが自分自身に送信したものとしてモデル化できる。これを行う場合、ルータはBMPセッションのローカル・アドレスとして使用したものと同じアドレスを使用することを推奨する(RECOMMENDED)。この場合、実際にはトランスポート・セッションは存在しないため、Peer Upメッセージのローカルポート・フィールドとリモートポート・フィールドは0に設定しなければならない(MUST)。明らかに、Peer UpメッセージのOPENメッセージ・フィールドは、物理的に送信されないに等しいが、ローカル・ルータの関連能力を表す必要がある。

また、セクション4.2を参照して、Lフラグはローカルにソースルートを示すために使用されることを思い出してほしい。

9. BMPの使用

BMPセッションが確立されると、経路監視は現在のスナップショットと増分変更を同時にダンプし始める。

これらの操作を同時に実行しても問題ない。最初のダンプが経路にアクセスし、その後に撤回を受信した場合、これは監視ステーションに転送され、その経路の削除を内部状態で相関させて反映する必要がある。これは、監視ステーションが必ずサポートする必要がある操作である。

ピアダンプ手順がそのプレフィックスにアクセスする前であっても、ルータがそのプレフィックスの撤回を受信した場合、ルータは内部状態からその経路をクリーンアップし、監視ステーションに転送しない。この場合、監視ステーションは、安全に無視できる偽の撤回を受信する可能性がある。

⚠️ BMPの実装
カテゴリ 実装 URL
BMPをサポートするルータ・ソフトウェア Cisco IOS-XR、IOS-XE、Juniper Junos、Nokia SR-OS、GoBGP、BIRD
BMPコレクタ OpenBMP
pmacct
OpenDayLight		 <https://www.openbmp.org>
<http://www.pmacct.net/>
<https://www.opendaylight.org>
監視ステーション SNAS (Streaming Network Analytics System) <https://github.com/SNAS/>

JUNOSの設定例:

routing-options bmp {
	  traceoptions {
	      file bmp.log size 10m;
	      flag all;
	  }
	  station bmpserver1 {
	      connection-mode active;
	      monitor enable;
	      route-monitoring {
	          post-policy;
	      }
	      station-address 192.168.1.1;
	      station-port 11019;
	      statistics-timeout 15;
	  }
}

Cisco IOS-XRの設定例:

router bgp 65000
  address-family ipv4 unicast
  !
  neighbor 1.1.1.1
    remote-as 64500
    bmp-activate server 1
    address-family ipv4 unicast
!
bmp
  bmp server 1
    host 192.168.1.1 port 11019
    update-source Loopback 0
    initial-delay 30activate
    stats-reporting-period 50
    route-monitoring inbound post-policy
  !

10. IANAの考慮事項

IANAは、以下のBMPパラメータのレジストリを作成し、新しいグループ「BGP Monitoring Protocol (BMP) Parameters」に整理した。

10.1. BMPメッセージ・タイプ

本文書では、連携システム間でBGPメッセージを転送するための7つのメッセージ・タイプを定義している(セクション4):

  • タイプ 0: 経路監視
  • タイプ 1: 統計レポート
  • タイプ 2: Peer Down通知
  • タイプ 3: Peer Up通知
  • タイプ 4: 開始
  • タイプ 5: 終了
  • タイプ 6: 経路ミラーリング

タイプ値0から127は「標準アクション」ポリシーを使用して割り当てる必要があり、値128から250は[RFC5226]で定義されている「仕様必須」ポリシーを使用して割り当てなければならない(MUST)。値251から254は実験的であり、値255は予約済みである。

10.2. BMPピアのタイプ

本文書では、ピア識別子フィールド(セクション4.2)を解釈するために、3種類のピアを定義する。

  • ピア・タイプ = 0: グローバル・インスタンス・ピア
  • ピア・タイプ = 1: RDインスタンス・ピア
  • ピア・タイプ = 2: ローカル・インスタンス・ピア

[RFC5226]で定義されている通り、ピアタイプ値0から127は、「標準アクション」ポリシーを使用して割り当てる必要があり、値128から250は「仕様必須」ポリシーを使用して割り当てる必要がある。値251から254は実験的であり、値255は予約済みである。

⚠️ 本文書公開後に追加されたもの
  • ピア・タイプ = 3: Loc-RIBインスタンス・ピア (RFC 9069)

10.3. BMPピア・フラグ

本文書では、Per Peerヘッダのピアフラグ・フィールドの3ビットフラグを定義する(セクション4.2)。ビットは0(最上位、つまり左端のビット)から7(最下位、つまり右端のビット)まで番号が振られている。

  • フラグ0: Vフラグ
  • フラグ1: Lフラグ
  • フラグ2: Aフラグ

フラグ3から7は未割り当てである。レジストリの登録手順は「標準アクション」である。

⚠️ 本文書公開後に追加されたもの
  • フラグ3: Oフラグ (RFC 8671)

10.4. BMP統計タイプ

本文書では、統計レポートのための14種類の統計タイプを定義している(セクション4.8):

  • 統計タイプ = 0: 受信ポリシーによって拒否されたプレフィックスの数
  • 統計タイプ = 1: (既知の) 重複プレフィックス広告の数
  • 統計タイプ = 2: (既知の) 重複撤回の数
  • 統計タイプ = 3: CLUSTER_LISTループによって無効になっアップデートの数
  • 統計タイプ = 4: AS_PATH ループによって無効になったアップデートの数
  • 統計タイプ = 5: ORIGINATOR_ID によって無効になったアップデートの数
  • 統計タイプ = 6: AS_CONFED_SEQUENCEまたはAS_CONFED_SETで見つかったループにより無効になったアップデートの数
  • 統計タイプ = 7: Adj-RIBs-In内の経路の数
  • 統計タイプ = 8: Loc-RIB内の経路の数
  • 統計タイプ = 9: AFI/SAFIごとの内のAdj-RIB-Inの経路の数
  • 統計タイプ = 10: AFI/SAFIごとのLoc-RIBの経路の数
  • 統計タイプ = 11: Treat-as-withdraw処理の対象となったアップデートの数
  • 統計タイプ = 12: Treat-as-withdraw処理の対象となったプレフィックスの数
  • 統計タイプ = 13: 受信した重複するアップデート・メッセージの数

統計タイプの値0から32767は、「標準アクション」ポリシーを使用して割り当てる必要があり、値32768から65530は[RFC5226]で定義されている「仕様必須」ポリシーを使用して割り当てる必要がある。値 65531から65534は実験的であり、値65535は予約済みである。

⚠️ 本文書公開後に追加されたもの
  • 統計タイプ = 14: ポリシー前のAdj-RIB-Outの経路数 (RFC 8671)
  • 統計タイプ = 15: ポリシー後のAdj-RIB-Outの経路数 (RFC 8671)
  • 統計タイプ = 16: AFI/SAFIごとのポリシー前のAdj-RIB-Outの経路数 (RFC 8671)
  • 統計タイプ = 17: AFI/SAFIごとのポリシー後のAdj-RIB-Outの経路数 (RFC 8671)

10.5. BMP開始メッセージTLV

本文書では、開始メッセージで伝送される情報の3つのタイプを定義している(セクション4.3):

  • タイプ = 0: 文字列
  • タイプ = 1: sysDescr
  • タイプ = 2: sysName

情報タイプ値0から32767は「標準アクション」ポリシーを使用して割り当てる必要があり、値 32768から65530は[RFC5226]で定義されている「仕様必須」ポリシーを使用して割り当てる必要がある。値65531から65534は実験的であり、値65535は予約済みである。

⚠️ 本文書公開後に追加されたもの
  • タイプ = 3: VRF/テーブル名 (RFC 9069)
  • タイプ = 4: 管理ラベル (RFC 8671)

10.6. BMP 終了メッセージTLV

本文書では、終了メッセージで伝送される情報の2つのタイプを定義している(セクション4.5):

  • タイプ = 0: 文字列
  • タイプ = 1: 理由

情報タイプ値 0から32767は「標準アクション」ポリシーを使用して割り当てる必要があり、値 32768から65530は [RFC5226]で定義されている「仕様必須」ポリシーを使用して割り当てる必要がある。値 65531から65534は実験的であり、値65535は予約済みです。

10.7. BMP終了メッセージの理由コード

本文書では、終了メッセージ(セクション 4.5)の理由コードで伝送される情報の5つのタイプを定義している:

  • タイプ = 0: 管理上クローズされた
  • タイプ = 1: 特定できない理由
  • タイプ = 2: リソース不足
  • タイプ = 3: 冗長接続
  • タイプ = 4: 管理上、永久にクローズされた

情報タイプの値0から32767は、「標準アクション」ポリシーを使用して割り当てる必要がある。また、値 32768から65530は、[RFC5226]で定義されている「仕様が必要」ポリシーを使用して割り当てる必要がある。値65531から65534は実験的であり、値65535は予約済みである。

10.8. BMP Peer Down理由コード

本文書では、Peer Down通知(セクション4.9)の理由コードで伝送される情報の5つのタイプを定義している(さらに1つのタイプを予約する):

  • タイプ = 0: 予約済み
  • タイプ = 1: ローカルシステムが終了し、NOTIFICATION PDUが続く
  • タイプ = 2: ローカルシステムが終了し、FSMイベントが続く
  • タイプ = 3: リモートシステムが終了し、NOTIFICATION PDUが続く
  • タイプ = 4: リモートシステムが終了し、データなし
  • タイプ = 5: ピアの構成解除

情報タイプ値0から32767は、[RFC5226]で定義されている「標準アクション」ポリシーで、値 32768から65530は 「仕様必須」ポリシーを使用して割り当てなければならない(MUST)。値65531から65534は実験的であり、値0と65535は予約済みである。

⚠️ 本文書公開後に追加されたもの
  • タイプ = 6: ローカル・システムが終了し、TLVデータが続く (RFC 9069)

10.9. 経路ミラーリングTLV

本文書では、経路ミラーリング・メッセージ(セクション4.7)で伝送される情報の2つのタイプを定義している:

  • タイプ = 0: BGP メッセージ
  • タイプ = 1: 情報

情報タイプ値0から32767は「標準アクション」ポリシーを使用して割り当てる必要があり、値 32768から65530は [RFC5226]で定義されている「仕様必須」ポリシーを使用して割り当てる必要がある。値65531から65534は実験的であり、値65535は予約済みである。

10.10. BMP経路ミラーリング情報コード

本文書では、経路ミラーリング情報(セクション 4.7)コードで伝送される情報について、2つのタイプを定義している。

  • タイプ = 0: エラーのあるPDU
  • タイプ = 1: メッセージが失われた

情報タイプ値0から32767は「標準アクション」ポリシーを使用して割り当てる必要があり、値 32768から65530は[RFC5226]で定義されている「仕様必須」ポリシーを使用して割り当てる必要がある。値65531から65534は実験的であり、値65535は予約済みである。

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

本文書では、BGPスピーカーのBGP経路(受信したBGPメッセージを含む)の完全なダンプを取得または継続的に監視するメカニズムを定義する。この機能を使うことで、外部の関係者が他の方法では取得できない情報を取得できる。例えば、パブリック・インターネットのBGP経路の内容を機密情報と見なすことは考えにくいが、BGPはプライベートな状況でも使用される(例えば、L3VPN[RFC4364])。別の例として、巧妙な攻撃者は、BMPによって公開されたポリシー前の経路とBGPでエクスポートされたポリシー後の経路を比較することで、監視対象ルータのインポート・ポリシーの内容を推測できるかもしれない。

このプロトコルの実装は、監視対象デバイスと監視デバイスの手動設定すべきである(SHOULD)。

相互認証を提供するトランスポートを使用しない限り、攻撃者は監視対象ルータになりすまして監視ステーションを騙して偽の情報を受け入れさせたり、監視ステーションになりすまして BMPデータに不正アクセスすることができる。機密性を提供するトランスポートが使用されない限り、受動的または能動的な攻撃者は、送信中のBMPデータにアクセスしたり、改ざんしたりする可能性がある。

上記のセキュリティ上の考慮事項を懸念する場合、このプロトコルのユーザは、事前共有鍵を使用したトンネルモードでIPsec[RFC4303]を使用する必要がある。

12. 参考文献

12.1. 引用規格

[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, <http://www.rfc-editor.org/info/rfc1213>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://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, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <http://www.rfc-editor.org/info/rfc4724>.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.

[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, <http://www.rfc-editor.org/info/rfc7606>.

12.2. Informative References

[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, <http://www.rfc-editor.org/info/rfc1155>.

[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, DOI 10.17487/RFC2856, June 2000, <http://www.rfc-editor.org/info/rfc2856>.

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.

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

謝辞

エッベン・アリエス、マイケル・アクセルロッド、セルピル・ベイラクタル、ティム・エヴァンス、ピエール・フランソワ、ジェフリー・ハース、ジョン・イオアニディス、ジョン・ケンプ、マック・マクブライド、ダニー・マクファーソン、デビッド・マイヤー、ディミトリ・パパディミトリオウ、トム・ペッチ、ロバート・ラズスク、エリック・ロミーン、ピーター・シェーンメーカー、及びGROWワーキング・グループのメンバーのコメントに感謝する。

著者のアドレス

ジョン・スカダー (編集者)
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
米国
メール: jgs@juniper.net

レックス・フェルナンド
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
米国
メール: rex@cisco.com

スティーブン・スチュアート
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
米国
メール: sstuart@google.com

更新履歴

  • 2024.7.2
GitHubで編集を提案

Discussion