[要約] RFC 8671は、BGPモニタリングプロトコル（BMP）でのAdj-RIB-Outのサポートに関するものです。このRFCの目的は、BMPセッションを介してBGPのAdj-RIB-Out情報を収集するための仕組みを提供することです。
Internet Engineering Task Force (IETF) T. Evens
Request for Comments: 8671 S. Bayraktar
Updates: 7854 Cisco Systems
Category: Standards Track P. Lucente
ISSN: 2070-1721 NTT Communications
P. Mi
Tencent
S. Zhuang
Huawei
November 2019
Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)
BGP監視プロトコル（BMP）でのAdj-RIB-Outのサポート
Abstract
概要
The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.
BGP監視プロトコル（BMP）は、Adj-RIB-Inルーティング情報ベース（RIB）へのアクセスのみを定義します。このドキュメントでは、Adj-RIB-Out RIBへのアクセスを追加することにより、BMP（RFC 7854）を更新します。また、Adj-RIB-InとAdj-RIB-Outを区別するために、ピアヘッダーに新しいフラグを追加します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8671.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8671で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Definitions
4. Per-Peer Header
5. Adj-RIB-Out
5.1. Post-policy
5.2. Pre-policy
6. BMP Messages
6.1. Route Monitoring and Route Mirroring
6.2. Statistics Report
6.3. Peer Up and Down Notifications
6.3.1. Peer Up Information
7. Other Considerations
7.1. Peer and Update Groups
7.2. Changes to Existing BMP Session
8. Security Considerations
9. IANA Considerations
9.1. Addition to BMP Peer Flags Registry
9.2. Additions to BMP Statistics Types Registry
9.3. Addition to BMP Initiation Message TLVs Registry
10. Normative References
Acknowledgements
Contributors
Authors' Addresses
The BGP Monitoring Protocol (BMP) defines monitoring of the received (e.g., Adj-RIB-In) Routing Information Bases (RIBs) per peer. The pre-policy Adj-RIB-In conveys to a BMP receiver all RIB data before any policy has been applied. The post-policy Adj-RIB-In conveys to a BMP receiver all RIB data after policy filters and/or modifications have been applied. An example of pre-policy versus post-policy is when an inbound policy applies attribute modification or filters. Pre-policy would contain information prior to the inbound policy changes or filters of data. Post-policy would convey the changed data or would not contain the filtered data.
BGPモニタリングプロトコル（BMP）は、ピアごとに受信した（Adj-RIB-Inなどの）ルーティング情報ベース（RIB）のモニタリングを定義します。ポリシー前のAdj-RIB-Inは、ポリシーが適用される前にすべてのRIBデータをBMPレシーバーに伝達します。ポリシー後のAdj-RIB-Inは、ポリシーフィルターや変更が適用された後、すべてのRIBデータをBMPレシーバーに伝達します。事前ポリシーと事後ポリシーの例は、インバウンドポリシーが属性の変更またはフィルターを適用する場合です。事前ポリシーには、受信ポリシーの変更またはデータのフィルターの前の情報が含まれます。ポストポリシーは、変更されたデータを伝達するか、フィルタリングされたデータを含みません。
Monitoring the received updates that the router received before any policy has been applied is the primary level of monitoring for most use cases. Inbound policy validation and auditing are the primary use cases for enabling post-policy monitoring.
ポリシーが適用される前にルーターが受信した更新を監視することは、ほとんどのユースケースで監視する主要なレベルです。受信ポリシーの検証と監査は、ポリシー後の監視を有効にするための主な使用例です。
In order for a BMP receiver to receive any BGP data, the BMP sender (e.g., router) needs to have an established BGP peering session and actively be receiving updates for an Adj-RIB-In.
BMP受信者がBGPデータを受信するには、BMP送信者（ルーターなど）がBGPピアリングセッションを確立し、Adj-RIB-Inの更新をアクティブに受信している必要があります。
Being able to only monitor the Adj-RIB-In puts a restriction on what data is available to BMP receivers via BMP senders (e.g., routers). This is an issue when the receiving end of the BGP peer is not enabled for BMP or when it is not accessible for administrative reasons. For example, a service provider advertises prefixes to a customer, but the service provider cannot see what it advertises via BMP. Asking the customer to enable BMP and monitoring of the Adj-RIB-In are not feasible.
Adj-RIB-Inのみを監視できるため、BMP送信者（ルーターなど）を介してBMP受信者が使用できるデータに制限が生じます。これは、BGPピアの受信側でBMPが有効になっていない場合、または管理上の理由でアクセスできない場合の問題です。たとえば、サービスプロバイダーはプレフィックスを顧客にアドバタイズしますが、サービスプロバイダーはBMPを介してアドバタイズするものを見ることができません。 BMPを有効にするよう顧客に依頼し、Adj-RIB-Inを監視することはできません。
BMP [RFC7854] only defines Adj-RIB-In being sent to BMP receivers. This document updates the per-peer header defined in Section 4.2 of [RFC7854] by adding a new flag to distinguish between Adj-RIB-In and Adj-RIB-Out. BMP senders use the new flag to send either Adj-RIB-In or Adj-RIB-Out.
BMP [RFC7854]は、BMP受信者に送信されるAdj-RIB-Inのみを定義します。このドキュメントでは、[RFC7854]のセクション4.2で定義されているピアごとのヘッダーを更新して、Adj-RIB-InとAdj-RIB-Outを区別する新しいフラグを追加します。 BMP送信者は、新しいフラグを使用してAdj-RIB-InまたはAdj-RIB-Outを送信します。
Adding Adj-RIB-Out provides the ability for a BMP sender to send to BMP receivers what it advertises to BGP peers, which can be used for outbound policy validation and to monitor routes that were advertised.
Adj-RIB-Outを追加すると、BMP送信者がBGPピアにアドバタイズするものをBMPレシーバーに送信する機能が提供されます。これは、アウトバウンドポリシーの検証や、アドバタイズされたルートの監視に使用できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Adj-RIB-Out As defined in [RFC4271], "The Adj-RIBs-Out contains the routes for advertisement to specific peers by means of the local speaker's UPDATE messages."
Adj-RIB-Out [RFC4271]で定義されているように、「Adj-RIBs-Outには、ローカルスピーカーのUPDATEメッセージによる特定のピアへのアドバタイズメントのルートが含まれています。」
Pre-policy Adj-RIB-Out The result before applying the outbound policy to an Adj-RIB-Out. This normally would match what is in the local RIB.
Pre-policy Adj-RIB-Out発信ポリシーをAdj-RIB-Outに適用する前の結果。これは通常、ローカルRIBの内容と一致します。
Post-policy Adj-RIB-Out The result of applying outbound policy to an Adj-RIB-Out. This MUST convey to the BMP receiver what is actually transmitted to the peer.
ポリシー後のAdj-RIB-Out発信ポリシーをAdj-RIB-Outに適用した結果。これは、実際にピアに送信されるものをBMPレシーバーに伝達する必要があります。
The per-peer header has the same structure and flags as defined in Section 4.2 of [RFC7854] with the addition of the O flag as shown here:
ピアごとのヘッダーの構造とフラグは、[RFC7854]のセクション4.2で定義されているものと同じですが、次に示すようにOフラグが追加されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|L|A|O| Resv |
+-+-+-+-+-+-+-+-+
* The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set to 1.
* Oフラグは、0に設定されている場合はAdj-RIB-In、1に設定されている場合はAdj-RIB-Outを示します。
The existing flags are defined in Section 4.2 of [RFC7854], and the remaining bits are reserved for future use. They MUST be transmitted as 0, and their values MUST be ignored on receipt.
既存のフラグは[RFC7854]のセクション4.2で定義されており、残りのビットは将来の使用のために予約されています。これらは0として送信する必要があり、それらの値は受信時に無視する必要があります。
When the O flag is set to 1, the following fields in the per-peer header are redefined:
Oフラグを1に設定すると、ピアごとのヘッダーの次のフィールドが再定義されます。
* Peer Address: The remote IP address associated with the TCP session over which the encapsulated Protocol Data Unit (PDU) is sent.
* ピアアドレス：カプセル化されたプロトコルデータユニット（PDU）が送信されるTCPセッションに関連付けられたリモートIPアドレス。
* Peer AS: The Autonomous System number of the peer to which the encapsulated PDU is sent.
* ピアAS：カプセル化されたPDUが送信されるピアの自律システム番号。
* Peer BGP ID: The BGP Identifier of the peer to which the encapsulated PDU is sent.
* ピアBGP ID：カプセル化されたPDUの送信先となるピアのBGP ID。
* Timestamp: The time when the encapsulated routes were advertised (one may also think of this as the time when they were installed in the Adj-RIB-Out), expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC). If zero, the time is unavailable. Precision of the timestamp is implementation-dependent.
* タイムスタンプ：カプセル化されたルートがアドバタイズされた時間（Adj-RIB-Outにインストールされた時間と考えることもできます）。1970年1月1日の午前0時（ゼロ時間）からの秒とマイクロ秒で表されます（ UTC）。ゼロの場合、時間は利用できません。タイムスタンプの精度は実装に依存します。
The primary use case in monitoring Adj-RIB-Out is to monitor the updates transmitted to a BGP peer after outbound policy has been applied. These updates reflect the result after modifications and filters have been applied (e.g., post-policy Adj-RIB-Out). Some attributes are set when the BGP message is transmitted, such as next hop. Post-policy Adj-RIB-Out MUST convey to the BMP receiver what is actually transmitted to the peer.
Adj-RIB-Outの監視の主な使用例は、送信ポリシーが適用された後にBGPピアに送信される更新を監視することです。これらの更新は、変更とフィルターが適用された後の結果を反映します（例：ポリシー後のAdj-RIB-Out）。一部の属性は、ネクストホップなど、BGPメッセージが送信されるときに設定されます。ポリシー後のAdj-RIB-Outは、実際にピアに送信されるものをBMPレシーバーに伝達する必要があります。
The L flag MUST be set to 1 to indicate post-policy.
事後ポリシーを示すには、Lフラグを1に設定する必要があります。
Similar to Adj-RIB-In policy validation, pre-policy Adj-RIB-Out can be used to validate and audit outbound policies. For example, a comparison between pre-policy and post-policy can be used to validate the outbound policy.
Adj-RIB-Inポリシー検証と同様に、事前ポリシーのAdj-RIB-Outを使用して、発信ポリシーを検証および監査できます。たとえば、事前ポリシーと事後ポリシーの比較を使用して、発信ポリシーを検証できます。
Depending on the BGP peering session type -- Internal BGP (IBGP), IBGP route reflector client, External BGP (EBGP), BGP confederations, route server client -- the candidate routes that make up the pre-policy Adj-RIB-Out do not contain all local RIB routes. Pre-policy Adj-RIB-Out conveys only routes that are available based on the peering type. Post-policy represents the filtered/changed routes from the available routes.
BGPピアリングセッションタイプに応じて-内部BGP（IBGP）、IBGPルートリフレクタークライアント、外部BGP（EBGP）、BGPコンフェデレーション、ルートサーバークライアント-プレポリシーAdj-RIB-Outを構成する候補ルートすべてのローカルRIBルートが含まれているわけではありません。事前ポリシーAdj-RIB-Outは、ピアリングタイプに基づいて使用可能なルートのみを伝達します。事後ポリシーは、使用可能なルートからのフィルタリング/変更されたルートを表します。
Some attributes are set only during transmission of the BGP message, i.e., post-policy. It is common that the next hop may be null, loopback, or similar during the pre-policy phase. All mandatory attributes, such as next hop, MUST be either zero or have an empty length if they are unknown at the pre-policy phase completion. The BMP receiver will treat zero or empty mandatory attributes as self-originated.
一部の属性は、BGPメッセージの送信中にのみ設定されます（つまり、ポリシー後）。ポリシー前フェーズでは、ネクストホップがヌル、ループバック、または類似することがよくあります。ネクストホップなどのすべての必須属性は、ポリシー前フェーズの完了時に不明である場合、ゼロであるか空の長さである必要があります。 BMPレシーバーは、ゼロまたは空の必須属性を自己生成として扱います。
The L flag MUST be set to 0 to indicate pre-policy.
事前ポリシーを示すには、Lフラグを0に設定する必要があります。
Many BMP messages have a per-peer header, but some are not applicable to Adj-RIB-In or Adj-RIB-Out monitoring, such as Peer Up and Down Notifications. Unless otherwise defined, the O flag should be set to 0 in the per-peer header in BMP messages.
多くのBMPメッセージにはピアごとのヘッダーがありますが、ピアアップ通知やダウン通知など、Adj-RIB-InまたはAdj-RIB-Outモニタリングには適用できないものもあります。特に定義されていない限り、BMPメッセージのピアごとのヘッダーでOフラグを0に設定する必要があります。
The O flag MUST be set accordingly to indicate if the route monitor or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out.
ルートモニターまたはルートミラーリングメッセージがAdj-RIB-InまたはAdj-RIB-Outを伝えるかどうかを示すために、それに応じてOフラグを設定する必要があります。
The Statistics Report message has a Stat Type field to indicate the statistic carried in the Stat Data field. Statistics report messages are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O flag set to zero. The O flag SHOULD be ignored by the BMP receiver.
統計レポートメッセージには、Stat Dataフィールドに含まれる統計を示すStat Typeフィールドがあります。統計レポートメッセージはAdj-RIB-InまたはAdj-RIB-Outに固有のものではなく、Oフラグをゼロに設定する必要があります。 BMPレシーバーはOフラグを無視する必要があります（SHOULD）。
This document defines the following new statistics types:
このドキュメントでは、次の新しい統計タイプを定義しています。
* Stat Type = 14: Number of routes in pre-policy Adj-RIB-Out. This statistics type is 64-bit Gauge.
* 統計タイプ= 14：ポリシー前のAdj-RIB-Outのルート数。この統計タイプは64ビットゲージです。
* Stat Type = 15: Number of routes in post-policy Adj-RIB-Out. This statistics type is 64-bit Gauge.
* 統計タイプ= 15：ポリシー後のAdj-RIB-Outのルート数。この統計タイプは64ビットゲージです。
* Stat Type = 16: Number of routes in per-AFI/SAFI pre-policy Adj-RIB-Out. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
* Stat Type = 16：AFI / SAFIプレポリシーごとのルートの数Adj-RIB-Out。値は、2バイトのアドレスファミリ識別子（AFI）、1バイトの後続アドレスファミリ識別子（SAFI）、それに続く64ビットゲージのように構成されています。
* Stat Type = 17: Number of routes in per-AFI/SAFI post-policy Adj-RIB-Out. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
* Stat Type = 17：AFI / SAFIポストポリシーAdj-RIB-Outごとのルート数。値は、2バイトのアドレスファミリ識別子（AFI）、1バイトの後続アドレスファミリ識別子（SAFI）、それに続く64ビットゲージのように構成されています。
Peer Up and Down Notifications convey BGP peering session state to BMP receivers. The state is independent of whether or not route monitoring or route mirroring messages will be sent for Adj-RIB-In, Adj-RIB-Out, or both. BMP receiver implementations SHOULD ignore the O flag in Peer Up and Down Notifications.
ピアアップおよびダウン通知は、BGPピアリングセッション状態をBMPレシーバーに伝えます。状態は、Adj-RIB-In、Adj-RIB-Out、またはその両方に対してルートモニタリングメッセージまたはルートミラーリングメッセージが送信されるかどうかには依存しません。 BMPレシーバーの実装は、ピアのアップおよびダウン通知のOフラグを無視する必要があります（SHOULD）。
This document defines the following Peer Up Information TLV type:
このドキュメントでは、次のピアアップ情報TLVタイプを定義しています。
* Type = 4: Admin Label. The Information field contains a free-form UTF-8 string whose byte length is given by the Information Length field. The value is administratively assigned. There is no requirement to terminate the string with null or any other character.
* タイプ= 4：管理ラベル。 Informationフィールドには、バイト長がInformation Lengthフィールドで指定される自由形式のUTF-8文字列が含まれています。値は管理上割り当てられます。文字列をnullまたはその他の文字で終了する必要はありません。
Multiple Admin Labels can be included in the Peer Up Notification. When multiple Admin Labels are included, the BMP receiver MUST preserve their order.
ピアアップ通知には複数の管理ラベルを含めることができます。複数の管理ラベルが含まれている場合、BMPレシーバーはそれらの順序を保持する必要があります。
The Admin Label is optional.
管理ラベルはオプションです。
Peer and update groups are used to group updates shared by many peers. This is a level of efficiency in implementations, not a true representation of what is conveyed to a peer in either pre-policy or post-policy.
ピアおよび更新グループは、多くのピアによって共有される更新をグループ化するために使用されます。これは実装の効率レベルであり、事前ポリシーまたは事後ポリシーのいずれかでピアに伝達されるものの真の表現ではありません。
One of the use cases to monitor post-policy Adj-RIB-Out is to validate and continually ensure the egress updates match what is expected. For example, wholesale peers should never have routes with community X:Y sent to them. In this use case, there may be hundreds of wholesale peers, but a single peer could have represented the group.
ポリシー後のAdj-RIB-Outを監視する使用例の1つは、出力の更新を検証し、期待されるものと一致していることを継続的に確認することです。たとえば、ホールセールピアには、コミュニティX：Yのルートを送信しないでください。このユースケースでは、何百ものピアが存在する可能性がありますが、1つのピアがグループを表すこともできます。
From a BMP perspective, it should be simple to include a group name in the Peer Up, but it is more complex than that. BGP implementations have evolved to provide comprehensive and structured policy grouping, such as session, AFI/SAFI, and template-based group policy inheritances.
BMPの観点からは、グループ名をピアアップに含めるのは簡単ですが、それよりも複雑です。 BGPの実装は、セッション、AFI / SAFI、テンプレートベースのグループポリシーの継承など、包括的で構造化されたポリシーグループを提供するように進化しています。
This level of structure and inheritance of polices does not provide a simple peer group name or ID, such as wholesale peer.
このレベルの構造とポリシーの継承では、ホールセールピアなどの単純なピアグループ名やIDは提供されません。
This document defines a new Admin Label type for Peer Up Information TLVs (Section 6.3.1) that can be used instead of requiring a group name. These labels have administrative scope relevance. For example, labels "type=wholesale" and "region=west" could be used to monitor expected policies.
このドキュメントでは、グループ名を要求する代わりに使用できるピアアップ情報TLV（セクション6.3.1）の新しい管理ラベルタイプを定義します。これらのラベルには、管理スコープの関連性があります。たとえば、ラベル「type = wholesale」および「region = west」を使用して、予想されるポリシーを監視できます。
Configuration and assignment of labels to peers are BGP implementation-specific.
ピアへのラベルの設定と割り当ては、BGP実装固有です。
In case of any change that results in the alteration of behavior of an existing BMP session (i.e., changes to filtering and table names), the session MUST be bounced with a Peer Down/Peer Up sequence.
既存のBMPセッションの動作の変更につながる変更（つまり、フィルタリングとテーブル名の変更）が発生した場合、セッションはピアダウン/ピアアップシーケンスでバウンスする必要があります。
The considerations in Section 11 of [RFC7854] apply to this document. Implementations of this protocol SHOULD require establishing sessions with authorized and trusted monitoring devices. It is also believed that this document does not add any additional security considerations.
[RFC7854]のセクション11の考慮事項がこのドキュメントに適用されます。このプロトコルの実装では、承認済みの信頼できる監視デバイスとのセッションを確立する必要があります（SHOULD）。また、このドキュメントはセキュリティに関する追加の考慮事項を追加しないと考えられています。
IANA has assigned the following new parameters to the "BGP Monitoring Protocol (BMP) Parameters" registry (https://www.iana.org/assignments/bmp-parameters/).
IANAは、「BGP監視プロトコル（BMP）パラメーター」レジストリ（https://www.iana.org/assignments/bmp-parameters/）に次の新しいパラメーターを割り当てました。
IANA has made the following assignment for the per-peer header flag defined in Section 4 of this document:
IANAは、このドキュメントのセクション4で定義されているピアごとのヘッダーフラグに次の割り当てを行いました。
+------+-------------+-----------+
| Flag | Description | Reference |
+======+=============+===========+
| 3 | O flag | RFC 8671 |
+------+-------------+-----------+
Table 1: Addition to the "BMP Peer Flags" Registry
表1：「BMPピアフラグ」レジストリへの追加
IANA has made the following assignment for the four statistics types defined in Section 6.2 of this document:
IANAは、このドキュメントのセクション6.2で定義されている4つの統計タイプに次の割り当てを行いました。
+-----------+------------------------------+-----------+
| Stat Type | Description | Reference |
+===========+==============================+===========+
| 14 | Number of routes in pre- | RFC 8671 |
| | policy Adj-RIB-Out | |
+-----------+------------------------------+-----------+
| 15 | Number of routes in post- | RFC 8671 |
| | policy Adj-RIB-Out | |
+-----------+------------------------------+-----------+
| 16 | Number of routes in per-AFI/ | RFC 8671 |
| | SAFI pre-policy Adj-RIB-Out | |
+-----------+------------------------------+-----------+
| 17 | Number of routes in per-AFI/ | RFC 8671 |
| | SAFI post-policy Adj-RIB-Out | |
+-----------+------------------------------+-----------+
Table 2: Additions to the "BMP Statistics Types" Registry
表2：「BMP統計タイプ」レジストリへの追加
IANA has made the following assignment per Section 6.3.1 of this document:
IANAは、このドキュメントのセクション6.3.1に従って次の割り当てを行いました。
+------+-------------+-----------+
| Type | Description | Reference |
+======+=============+===========+
| 4 | Admin Label | RFC 8671 |
+------+-------------+-----------+
Table 3: Addition to the "BMP Initiation Message TLVs" Registry
表3：「BMP開始メッセージTLV」レジストリへの追加
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, <https://www.rfc-editor.org/info/rfc7854>.
[RFC7854] Scudder、J.、Ed。、Fernando、R。、およびS. Stuart、「BGP Monitoring Protocol（BMP）」、RFC 7854、DOI 10.17487 / RFC7854、2016年6月、<https：//www.rfc- editor.org/info/rfc7854>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
Acknowledgements
謝辞
The authors would like to thank John Scudder and Mukul Srivastava for their valuable input.
著者は、貴重な情報を提供してくれたJohn ScudderとMukul Srivastavaに感謝します。
Contributors
貢献者
The following individuals contributed to this document:
以下の個人がこの文書に貢献しました：
* Manish Bhardwaj, Cisco Systems
* マニッシュ・バードワージ、シスコシステムズ
* Xianyu Zheng, Tencent
* X Ian Yu Zheng、Tencent
* Wei Guo, Tencent
* Wei GU O、Tencent
* Shugang Cheng, H3C
* Shu Gang Cheng、H3C
Authors' Addresses
著者のアドレス
Tim Evens Cisco Systems 2901 Third Avenue, Suite 600 Seattle, WA 98121 United States of America
Tim Evens Cisco Systems 2901 Third Avenue、Suite 600 Seattle、WA 98121アメリカ合衆国
Email: tievens@cisco.com
Serpil Bayraktar Cisco Systems 3700 Cisco Way San Jose, CA 95134 United States of America
Serpil Bayraktar Cisco Systems 3700 Cisco Way San Jose、CA 95134アメリカ合衆国
Email: serpil@cisco.com
Paolo Lucente NTT Communications Siriusdreef 70-72 2132 Hoofddorp Netherlands
Paolo Lucente NTT Communications Siriusdreef 70-72 2132 Hoofddorp Netherlands
Email: paolo@ntt.net
Penghui Mi China 200233 Shanghai Tengyun Building, Tower A, No. 397 Tianlin Road Tencent
Penghui Mi China 200233 Shanghai Tengyun Building、Tower A、No. 397 Tianlin Road Tencent
Email: Penghui.Mi@gmail.com
Shunwan Zhuang China 100095 Beijing Huawei Building, No.156 Beiqing Rd. Huawei
Shu N万Z黄中国100095北京hu Aが建設中、no.156 be i青RD。hu Aが建設中
Email: zhuangshunwan@huawei.com