[要約] RFC 7747は、データプレーンの収束に関する基本的なBGP収束ベンチマーキング手法を提供しています。このRFCの目的は、BGPルータの収束性能を評価するための一貫した方法論を提供することです。
Internet Engineering Task Force (IETF) R. Papneja
Request for Comments: 7747 Huawei Technologies
Category: Informational B. Parise
ISSN: 2070-1721 Skyport Systems
S. Hares
Huawei Technologies
D. Lee
IXIA
I. Varlashkin
Google
April 2016
Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence
データプレーンコンバージェンスの基本的なBGPコンバージェンスベンチマーク手法
Abstract
概要
BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098.
BGPは、デフォルトのAS間（自律システム）ルーティングプロトコルとして、いくつかのサービスプロバイダーによって広く展開および使用されています。 BGPピアまたはBGPピアのダウンストリームリンクに障害が発生した場合、代替パスが迅速に使用され、これらの代替パスを介したルートがインストールされるようにすることが最も重要です。このドキュメントでは、RFC 4098で定義されている既存のBGPコンバージェンス用語を使用した基本的なBGPベンチマーク手法について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7747.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7747で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Benchmarking Definitions . . . . . . . . . . . . . . . . 4
1.2. Purpose of BGP FIB (Data-Plane) Convergence . . . . . . . 4
1.3. Control-Plane Convergence . . . . . . . . . . . . . . . . 5
1.4. Benchmarking Testing . . . . . . . . . . . . . . . . . . 5
2. Existing Definitions and Requirements . . . . . . . . . . . . 5
3. Test Topologies . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. General Reference Topologies . . . . . . . . . . . . . . 7
4. Test Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. Number of Peers . . . . . . . . . . . . . . . . . . . . . 9
4.2. Number of Routes per Peer . . . . . . . . . . . . . . . . 9
4.3. Policy Processing/Reconfiguration . . . . . . . . . . . . 9
4.4. Configured Parameters (Timers, etc.) . . . . . . . . . . 9
4.5. Interface Types . . . . . . . . . . . . . . . . . . . . . 11
4.6. Measurement Accuracy . . . . . . . . . . . . . . . . . . 11
4.7. Measurement Statistics . . . . . . . . . . . . . . . . . 11
4.8. Authentication . . . . . . . . . . . . . . . . . . . . . 11
4.9. Convergence Events . . . . . . . . . . . . . . . . . . . 12
4.10. High Availability . . . . . . . . . . . . . . . . . . . . 12
5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Basic Convergence Tests . . . . . . . . . . . . . . . . . 13
5.1.1. RIB-IN Convergence . . . . . . . . . . . . . . . . . 13
5.1.2. RIB-OUT Convergence . . . . . . . . . . . . . . . . . 15
5.1.3. eBGP Convergence . . . . . . . . . . . . . . . . . . 16
5.1.4. iBGP Convergence . . . . . . . . . . . . . . . . . . 16
5.1.5. eBGP Multihop Convergence . . . . . . . . . . . . . . 17
5.2. BGP Failure/Convergence Events . . . . . . . . . . . . . 18
5.2.1. Physical Link Failure on DUT End . . . . . . . . . . 18
5.2.2. Physical Link Failure on Remote/Emulator End . . . . 19
5.2.3. ECMP Link Failure on DUT End . . . . . . . . . . . . 20
5.3. BGP Adjacency Failure (Non-Physical Link Failure) on
Emulator . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4. BGP Hard Reset Test Cases . . . . . . . . . . . . . . . . 21
5.4.1. BGP Non-Recovering Hard Reset Event on DUT . . . . . 21
5.5. BGP Soft Reset . . . . . . . . . . . . . . . . . . . . . 22
5.6. BGP Route Withdrawal Convergence Time . . . . . . . . . . 24
5.7. BGP Path Attribute Change Convergence Time . . . . . . . 26
5.8. BGP Graceful Restart Convergence Time . . . . . . . . . . 27
6. Reporting Format . . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
This document defines the methodology for benchmarking data-plane Forwarding Information Base (FIB) convergence performance of BGP in routers and switches using topologies of three or four nodes. The methodology proposed in this document applies to both IPv4 and IPv6, and if a particular test is unique to one version, it is marked accordingly. For IPv6 benchmarking, the Device Under Test (DUT) will require the support of Multiprotocol BGP (MP-BGP) [RFC4760] [RFC2545]. Similarly, both Internal BGP (iBGP) and External BGP (eBGP) are covered in the tests as applicable.
このドキュメントでは、3つまたは4つのノードのトポロジを使用して、ルーターおよびスイッチにおけるBGPのデータプレーン転送情報ベース（FIB）収束パフォーマンスをベンチマークする方法を定義します。このドキュメントで提案されている方法論はIPv4とIPv6の両方に適用され、特定のテストが1つのバージョンに固有の場合は、それに応じてマークされます。 IPv6ベンチマークの場合、テスト対象デバイス（DUT）はマルチプロトコルBGP（MP-BGP）[RFC4760] [RFC2545]のサポートを必要とします。同様に、内部BGP（iBGP）と外部BGP（eBGP）の両方が、必要に応じてテストでカバーされています。
The scope of this document is to provide methodology for BGP FIB convergence measurements with BGP functionality limited to IPv4 and IPv6 as defined in [RFC4271] and MP-BGP [RFC4760] [RFC2545]. Other BGP extensions to support Layer 2 and Layer 3 Virtual Private Networks (VPNs) are outside the scope of this document. Interaction with IGPs (IGP interworking) is outside the scope of this document.
このドキュメントの範囲は、[RFC4271]およびMP-BGP [RFC4760] [RFC2545]で定義されているIPv4およびIPv6に制限されたBGP機能を使用して、BGP FIB収束測定の方法を提供することです。レイヤ2およびレイヤ3の仮想プライベートネットワーク（VPN）をサポートする他のBGP拡張機能は、このドキュメントの範囲外です。 IGPとの相互作用（IGPインターワーキング）は、このドキュメントの範囲外です。
The terminology used in this document is defined in [RFC4098]. One additional term is defined in this document as follows.
このドキュメントで使用される用語は、[RFC4098]で定義されています。このドキュメントでは、次のように1つの追加の用語を定義しています。
FIB (data-plane) convergence is defined as the completion of all FIB changes so that all forwarded traffic then takes the newly proposed route. RFC 4098 defines the terms 'BGP device', 'FIB', and 'forwarded traffic'. Data-plane convergence is different than control-plane convergence within a node.
FIB（データプレーン）コンバージェンスは、すべての転送されたトラフィックが新しく提案されたルートをたどるように、すべてのFIB変更の完了として定義されます。 RFC 4098は、「BGPデバイス」、「FIB」、および「転送トラフィック」という用語を定義しています。データプレーンの収束は、ノード内のコントロールプレーンの収束とは異なります。
This document defines methodology to test
このドキュメントでは、テストする方法を定義します
o data-plane convergence on a single BGP device that supports the BGP functionality with a scope as outlined above; and
o 上記の範囲でBGP機能をサポートする単一のBGPデバイスでのデータプレーンコンバージェンス。そして
o using test topology of three or four nodes that are sufficient to recreate the convergence events used in the various tests of this document.
o このドキュメントのさまざまなテストで使用される収束イベントを再現するのに十分な3つまたは4つのノードのテストトポロジを使用する。
In the current Internet architecture, the inter-AS transit is primarily available through BGP. To maintain reliable connectivity within intra-domains or across inter-domains, fast recovery from failures remains most critical. To ensure minimal traffic losses, many service providers are requiring BGP implementations to converge the entire Internet routing table within sub-seconds at FIB level.
現在のインターネットアーキテクチャでは、AS間トランジットは主にBGPを介して利用できます。ドメイン内またはドメイン間で信頼性の高い接続を維持するには、障害からの迅速な回復が最も重要です。トラフィックの損失を最小限に抑えるために、多くのサービスプロバイダーは、BGP実装にFIBレベルで数秒以内にインターネットルーティングテーブル全体を収束させることを要求しています。
Furthermore, to compare these numbers amongst various devices, service providers are also looking at ways to standardize the convergence measurement methods. This document offers test methods for simple topologies. These simple tests will provide a quick high-level check of BGP data-plane convergence across multiple implementations from different vendors.
さらに、さまざまなデバイス間でこれらの数値を比較するために、サービスプロバイダーは収束測定方法を標準化する方法も検討しています。このドキュメントでは、単純なトポロジのテスト方法について説明します。これらの簡単なテストは、さまざまなベンダーの複数の実装にわたるBGPデータプレーンコンバージェンスの迅速で高レベルのチェックを提供します。
The convergence of BGP occurs at two levels: Routing Information Base (RIB) and FIB convergence. RFC 4098 defines terms for BGP control-plane convergence. Methodologies that test control-plane convergence are out of scope for this document.
BGPの収束は、ルーティング情報ベース（RIB）とFIB収束の2つのレベルで発生します。 RFC 4098は、BGPコントロールプレーンコンバージェンスの用語を定義しています。コントロールプレーンの収束をテストする方法論は、このドキュメントの範囲外です。
In order to ensure that the results obtained in tests are repeatable, careful setup of initial conditions and exact steps are required.
テストで得られた結果を再現性のあるものにするために、初期条件と正確な手順を注意深く設定する必要があります。
This document proposes these initial conditions, test steps, and result checking. To ensure uniformity of the results, all optional parameters SHOULD be disabled and all settings SHOULD be changed to default; these may include BGP timers as well.
このドキュメントでは、これらの初期条件、テストステップ、および結果チェックを提案します。結果の均一性を確保するために、すべてのオプションのパラメーターを無効にし（SHOULD）、すべての設定をデフォルトに変更する必要があります（SHOULD）。これらにはBGPタイマーも含まれる場合があります。
"Benchmarking Terminology for Network Interconnect Devices" [RFC1242] and "Benchmarking Terminology for LAN Switching Devices" [RFC2285] SHOULD be reviewed in conjunction with this document. WLAN-specific terms and definitions are also provided in Clauses 3 and 4 of the IEEE 802.11 standard [IEEE.802.11]. Commonly used terms may also be found in RFC 1983 [RFC1983].
「ネットワーク相互接続デバイスのベンチマーク用語」[RFC1242]および「LANスイッチングデバイスのベンチマーク用語」[RFC2285]は、このドキュメントと併せて検討する必要があります。 WLAN固有の用語と定義は、IEEE 802.11標準[IEEE.802.11]の3節と4節にも記載されています。一般的に使用される用語は、RFC 1983 [RFC1983]にも記載されています。
For the sake of clarity and continuity, this document adopts the general template for benchmarking terminology set out in Section 2 of [RFC1242]. Definitions are organized in alphabetical order and grouped into sections for ease of reference. The following terms are assumed to be taken as defined in RFC 1242 [RFC1242]: Throughput, Latency, Constant Load, Frame Loss Rate, and Overhead Behavior. In addition, the following terms are taken as defined in [RFC2285]: Forwarding Rates, Maximum Forwarding Rate, Loads, Device Under Test (DUT), and System Under Test (SUT).
明確さと継続性のために、このドキュメントでは、[RFC1242]のセクション2に記載されているベンチマーク用語の一般的なテンプレートを採用しています。定義はアルファベット順に整理され、参照しやすいようにセクションにグループ化されています。次の用語は、RFC 1242 [RFC1242]で定義されているものと見なされます。スループット、遅延、一定の負荷、フレーム損失率、およびオーバーヘッドの動作。さらに、[RFC2285]で定義されている次の用語が使用されます：転送レート、最大転送レート、負荷、テスト中のデバイス（DUT）、およびテスト中のシステム（SUT）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This section describes the test setups for use in BGP benchmarking tests measuring convergence of the FIB (data-plane) after BGP updates have been received.
このセクションでは、BGPアップデートが受信された後にFIB（データプレーン）の収束を測定するBGPベンチマークテストで使用するテストセットアップについて説明します。
These test setups have three or four nodes with the following configuration:
これらのテストセットアップには、次の構成の3つまたは4つのノードがあります。
1. Basic test setup
1. 基本的なテスト設定
2. Three-node setup for iBGP or eBGP convergence
2. iBGPまたはeBGPコンバージェンスのための3ノードのセットアップ
3. Setup for eBGP multihop test Scenario
3. eBGPマルチホップテストシナリオのセットアップ
4. Four-node setup for iBGP or eBGP convergence
4. iBGPまたはeBGPコンバージェンスのための4ノードのセットアップ
Individual tests refer to these topologies.
個々のテストはこれらのトポロジーを参照します。
Figures 1 through 4 use the following conventions:
図1〜4では、次の表記法を使用しています。
o AS-X: Autonomous System X
o AS-X：自律システムX
o Loopback Int: Loopback interface on a BGP-enabled device
o Loopback Int：BGP対応デバイスのループバックインターフェイス
o HLP, HLP1, HLP2: Helper routers running the same version of BGP as the DUT
o HLP、HLP1、HLP2：DUTと同じバージョンのBGPを実行するヘルパールーター
o All devices MUST be synchronized using NTP or some other clock synchronization mechanism
o すべてのデバイスは、NTPまたはその他のクロック同期メカニズムを使用して同期する必要があります
Emulator acts as one or more BGP peers for different test cases.
エミュレータは、さまざまなテストケースで1つ以上のBGPピアとして機能します。
+----------+ +------------+
| | Traffic Interfaces | |
| |-----------------------1---- | tx |
| |-----------------------2---- | tr1 |
| |-----------------------3-----| tr2 |
| DUT | | Emulator |
| | Routing Interfaces | |
| Dp1 |--------------------------- |Emp1 |
| | BGP Peering | |
| Dp2 |---------------------------- |Emp2 |
| | BGP Peering | |
+----------+ +------------+
Figure 1: Basic Test Setup
図1：基本的なテストのセットアップ
+------------+ +-----------+ +-----------+
| | | | | |
| | | | | |
| HLP | | DUT | | Emulator |
| (AS-X) |--------| (AS-Y) |-----------| (AS-Z) |
| | | | | |
| | | | | |
| | | | | |
+------------+ +-----------+ +-----------+
| |
| |
+--------------------------------------------+
Figure 2: Three-Node Setup for eBGP and iBGP Convergence
図2：eBGPおよびiBGPコンバージェンスの3ノードのセットアップ
+----------------------------------------------+
| |
| |
+------------+ +-----------+ +-----------+
| | | | | |
| | | | | |
| HLP | | DUT | | Emulator |
| (AS-X) |--------| (AS-Y) |-----------| (AS-Z) |
| | | | | |
| | | | | |
| | | | | |
+------------+ +-----------+ +-----------+
|Loopback-Int |Loopback-Int
| |
+ +
Figure 3: BGP Convergence for eBGP Multihop Scenario
図3：eBGPマルチホップシナリオのBGPコンバージェンス
+---------+ +--------+ +--------+ +---------+
| | | | | | | |
| | | | | | | |
| HLP1 | | DUT | | HLP2 | |Emulator |
| (AS-X) |-----| (AS-X) |-----| (AS-Y) |-----| (AS-Z) |
| | | | | | | |
| | | | | | | |
| | | | | | | |
+---------+ +--------+ +--------+ +---------+
| |
| |
+---------------------------------------------+
Figure 4: Four-Node Setup for eBGP and iBGP Convergence
図4：eBGPおよびiBGPコンバージェンスの4ノードのセットアップ
The test cases for measuring convergence for iBGP and eBGP are different. Both iBGP and eBGP use different mechanisms to advertise, install, and learn the routes. Typically, an iBGP route on the DUT is installed and exported when the next hop is valid. For eBGP, the route is installed on the DUT with the remote interface address as the next hop, with the exception of the multihop test case (as specified in the test).
iBGPとeBGPの収束を測定するためのテストケースは異なります。 iBGPとeBGPはどちらも異なるメカニズムを使用して、ルートをアドバタイズ、インストール、および学習します。通常、DUT上のiBGPルートは、ネクストホップが有効なときにインストールおよびエクスポートされます。 eBGPの場合、ルートはリモートインターフェースアドレスをネクストホップとしてDUTにインストールされますが、マルチホップテストケース（テストで指定されている）は例外です。
"Number of Peers" is defined as the number of BGP neighbors or sessions the DUT has at the beginning of the test. The peers are established before the tests begin. The relationship could be either iBGP or eBGP peering depending upon the test case requirement.
「ピアの数」は、テストの開始時にDUTが持つBGPネイバーまたはセッションの数として定義されます。ピアはテストが始まる前に確立されます。関係は、テストケースの要件に応じて、iBGPまたはeBGPピアリングのいずれかになります。
The DUT establishes one or more BGP peer sessions with one or more emulated routers or Helper Nodes. Additional peers can be added based on the testing requirements. The number of peers enabled during the testing should be well documented in the report matrix.
DUTは、1つ以上のエミュレートされたルーターまたはヘルパーノードとの1つ以上のBGPピアセッションを確立します。テスト要件に基づいて、ピアを追加できます。テスト中に有効にされたピアの数は、レポートマトリックスに十分に文書化されている必要があります。
"Number of Routes per Peer" is defined as the number of routes advertised or learned by the DUT per session or through a neighbor relationship with an emulator or Helper Node. The Tester, emulating as a BGP neighbor, MUST advertise at least one route per BGP peer.
「ピアごとのルート数」は、セッションごとに、またはエミュレータまたはヘルパーノードとのネイバー関係を介してDUTによってアドバタイズまたは学習されたルートの数として定義されます。テスターは、BGPネイバーとしてエミュレートし、BGPピアごとに少なくとも1つのルートをアドバタイズする必要があります。
Each test run must identify the route stream in terms of route packing, route mixture, and number of routes. This route stream must be well documented in the reporting stream. RFC 4098 defines these terms.
各テスト実行では、ルートパッキング、ルートの混合、およびルートの数の観点からルートストリームを識別する必要があります。このルートストリームは、レポートストリームで十分に文書化されている必要があります。 RFC 4098はこれらの用語を定義しています。
It is RECOMMENDED that the user consider advertising the entire current Internet routing table per peering session using an Internet route mixture with unique or non-unique routes. If multiple peers are used, it is important to precisely document the timing sequence between the peer sending routes (as defined in RFC 4098).
一意のルートまたは一意でないルートと混合したインターネットルートを使用して、ピアリングセッションごとに現在のインターネットルーティングテーブル全体をアドバタイズすることを検討することをお勧めします。複数のピアが使用されている場合、ピア送信ルート間のタイミングシーケンスを正確に文書化することが重要です（RFC 4098で定義されています）。
The DUT MUST run one baseline test where policy is the Minimal policy as defined in RFC 4098. Additional runs may be done with the policy that was set up before the tests began. Exact policy settings MUST be documented as part of the test.
DUTは、ポリシーがRFC 4098で定義されている最小限のポリシーである1つのベースラインテストを実行する必要があります。追加の実行は、テストが始まる前に設定されたポリシーで実行できます。正確なポリシー設定は、テストの一部として文書化する必要があります。
There are configured parameters and timers that may impact the measured BGP convergence times.
測定されたBGPコンバージェンス時間に影響を与える可能性のある設定済みのパラメータとタイマーがあります。
The benchmark metrics MAY be measured at any fixed values for these configured parameters.
ベンチマーク指標は、これらの構成されたパラメーターの固定値で測定される場合があります。
It is RECOMMENDED these configure parameters have the following settings: a) default values specified by the respective RFC, b) platform-specific default parameters, and c) values as expected in the operational network. All optional BGP settings MUST be kept consistent across iterations of any specific tests
これらの構成パラメーターには次の設定があることをお勧めします：a）それぞれのRFCによって指定されたデフォルト値、b）プラットフォーム固有のデフォルトパラメーター、およびc）運用ネットワークで期待される値。すべてのオプションのBGP設定は、特定のテストの反復全体で一貫している必要があります
Examples of the configured parameters that may impact measured BGP convergence time include, but are not limited to:
測定されたBGPコンバージェンス時間に影響を与える可能性のある構成済みパラメーターの例には、以下が含まれますが、これらに限定されません。
1. Interface failure detection timer
1. インターフェイス障害検出タイマー
2. BGP keepalive timer
2. BGPキープアライブタイマー
3. BGP holdtime
3. BGPホールドタイム
4. BGP update delay timer
4. BGP更新遅延タイマー
5. ConnectRetry timer
5. ConnectRetryタイマー
6. TCP segment size
6. TCPセグメントサイズ
7. Minimum Route Advertisement Interval (MRAI)
7. 最小ルートアドバタイズメントインターバル（MRAI）
8. MinASOriginationInterval (MAOI)
8. みなそりぎなちおにんてｒゔぁｌ （まおい）
9. Route flap damping parameters
9. ルートフラップダンピングパラメータ
10. TCP Authentication Option (TCP AO or TCP MD5)
10. TCP認証オプション（TCP AOまたはTCP MD5）
11. Maximum TCP window size
11. 最大TCPウィンドウサイズ
12. MTU
12. MTU
The basic-test settings for the parameters should be:
パラメータの基本テスト設定は次のようになります。
1. Interface failure detection timer (0 ms)
1. インターフェイス障害検出タイマー（0 ms）
2. BGP keepalive timer (1 min)
2. BGPキープアライブタイマー（1分）
3. BGP holdtime (3 min)
3. BGPホールドタイム（3分）
4. BGP update delay timer (0 s)
4. BGP更新遅延タイマー（0秒）
5. ConnectRetry timer (1 s)
5. ConnectRetryタイマー（1秒）
6. TCP segment size (4096 bytes)
6. TCPセグメントサイズ（4096バイト）
7. Minimum Route Advertisement Interval (MRAI) (0 s) 8. MinASOriginationInterval (MAOI) (0 s)
７。 みにむｍ ろうて あｄゔぇｒちせめんｔ いんてｒゔぁｌ （Ｍらい） （０ ｓ） ８。 みなそりぎなちおにんてｒゔぁｌ （まおい） （０ ｓ）
9. Route flap damping parameters (off)
9. ルートフラップダンピングパラメータ（オフ）
10. TCP Authentication Option (off)
10. TCP認証オプション（オフ）
The type of media dictates which test cases may be executed; each interface type has a unique mechanism for detecting link failures, and the speed at which that mechanism operates will influence the measurement results. All interfaces MUST be of the same media and throughput for all iterations of each test case.
メディアの種類によって、実行できるテストケースが決まります。各インターフェイスタイプには、リンク障害を検出するための独自のメカニズムがあり、そのメカニズムの動作速度が測定結果に影響します。すべてのインターフェイスは、各テストケースのすべての反復で同じメディアとスループットである必要があります。
Since observed packet loss is used to measure the route convergence time, the time between two successive packets offered to each individual route is the highest possible accuracy of any packet-loss-based measurement. When packet jitter is much less than the convergence time, it is a negligible source of error, and hence, it will be treated as within tolerance.
観測されたパケット損失はルート収束時間の測定に使用されるため、個々のルートに提供される2つの連続するパケット間の時間は、パケット損失ベースの測定の可能な限り最高の精度です。パケットジッタがコンバージェンス時間よりもはるかに短い場合、それはエラーの無視できるソースであるため、許容範囲内として扱われます。
Other options to measure convergence are the Time-Based Loss Method (TBLM) and Timestamp-Based Method (TBM) [RFC6414].
収束を測定する他のオプションは、時間ベースの損失法（TBLM）とタイムスタンプベースの方法（TBM）[RFC6414]です。
An exterior measurement on the input media (such as Ethernet) is defined by this specification.
入力メディア（イーサネットなど）の外部測定は、この仕様で定義されています。
The benchmark measurements may vary for each trial due to the statistical nature of timer expirations, CPU scheduling, etc. It is recommended to repeat the test multiple times. Evaluation of the test data must be done with an understanding of generally accepted testing practices regarding repeatability, variance, and statistical significance of a small number of trials.
ベンチマークの測定値は、タイマーの有効期限、CPUスケジューリングなどの統計的な性質により、試行ごとに異なる場合があります。テストを複数回繰り返すことをお勧めします。テストデータの評価は、少数の試行の再現性、分散、および統計的有意性に関する一般的に受け入れられているテスト方法を理解して行う必要があります。
For any repeated tests that are averaged to remove variance, all parameters MUST remain the same.
分散を除去するために平均化される繰り返しテストでは、すべてのパラメーターを同じままにする必要があります。
Authentication in BGP is done using the TCP Authentication Option [RFC5925]. (In some legacy situations, the authentication may still be with TCP MD5). The processing of the authentication hash, particularly in devices with a large number of BGP peers and a large amount of update traffic, can have an impact on the control plane of the device. If authentication is enabled, it MUST be documented correctly in the reporting format.
BGPでの認証は、TCP認証オプション[RFC5925]を使用して行われます。 （一部のレガシー状況では、認証はまだTCP MD5で行われる場合があります）。特に多数のBGPピアと大量の更新トラフィックがあるデバイスでの認証ハッシュの処理は、デバイスのコントロールプレーンに影響を与える可能性があります。認証が有効になっている場合は、レポート形式で正しく文書化する必要があります。
Also, it is recommended that trials MUST be with the same Secure Inter-Domain Routing (SIDR) features [RFC7115] [BGPsec]. The best convergence tests would be with no SIDR features and then to repeat the convergence tests with the same SIDR features.
また、トライアルは同じセキュアドメイン間ルーティング（SIDR）機能[RFC7115] [BGPsec]を使用する必要があることをお勧めします。最良の収束テストは、SIDR機能を使用せず、同じSIDR機能を使用して収束テストを繰り返すことです。
Convergence events or triggers are defined as abnormal occurrences in the network, which initiate route flapping in the network and hence forces the reconvergence of a steady state network. In a real network, a series of convergence events may cause convergence latency operators desire to test.
コンバージェンスイベントまたはトリガーは、ネットワーク内のルートフラッピングを開始し、したがって定常状態ネットワークの再コンバージェンスを強制する、ネットワーク内の異常発生として定義されます。実際のネットワークでは、一連の収束イベントにより、オペレーターがテストしたい収束待ち時間が発生する場合があります。
These convergence events must be defined in terms of the sequences defined in RFC 4098. This basic document begins all tests with a router initial setup. Additional documents will define BGP data-plane convergence based on peer initialization.
これらの収束イベントは、RFC 4098で定義されているシーケンスの観点から定義する必要があります。この基本的なドキュメントは、すべてのテストをルーターの初期セットアップで開始します。追加のドキュメントでは、ピアの初期化に基づいてBGPデータプレーンの収束を定義します。
The convergence events may or may not be tied to the actual failure. A soft reset [RFC4098] does not clear the RIB or FIB tables. A hard reset clears BGP peer sessions, RIB tables, and FIB tables.
収束イベントは、実際の障害に関連付けられている場合と関連付けられていない場合があります。ソフトリセット[RFC4098]は、RIBまたはFIBテーブルをクリアしません。ハードリセットは、BGPピアセッション、RIBテーブル、およびFIBテーブルをクリアします。
Due to the different Non-Stop-Routing (sometimes referred to High-Availability) solutions available from different vendors, it is RECOMMENDED that any redundancy available in the routing processors should be disabled during the convergence measurements. For cases where the redundancy cannot be disabled, the results are no longer comparable and the level of impact on the measurements is out of scope of this document.
さまざまなベンダーから提供されているさまざまなノンストップルーティング（高可用性と呼ばれることもある）ソリューションがあるため、収束測定中はルーティングプロセッサで使用できる冗長性を無効にすることをお勧めします。冗長性を無効にできない場合、結果は比較できなくなり、測定への影響のレベルはこのドキュメントの範囲外になります。
All tests defined under this section assume the following:
このセクションで定義されているすべてのテストは、次のことを前提としています。
a. BGP peers are in Established state.
a. BGPピアはEstablished状態です。
b. BGP state should be cleared from Established state to Idle prior to each test. This is recommended to ensure that all tests start with BGP peers being forced back to Idle state and databases flushed.
b. 各テストの前に、BGP状態を確立済み状態からアイドルにクリアする必要があります。これは、すべてのテストがBGPピアが強制的にアイドル状態に戻され、データベースがフラッシュされることで確実に開始するために推奨されます。
c. Furthermore, the traffic generation and routing should be verified in the topology to ensure there is no packet loss observed on any advertised routes.
c. さらに、トポロジでトラフィックの生成とルーティングを検証して、アドバタイズされたルートでパケット損失が観察されないようにする必要があります。
d. The arrival timestamp of advertised routes can be measured by installing an inline monitoring device between the emulator and the DUT or by using the span port of the DUT connected with an external analyzer. The time base of such an inline monitor or external analyzer needs to be synchronized with the protocol and traffic emulator. Some modern emulators may have the capability to capture and timestamp every NLRI packet leaving and arriving at the emulator ports. The timestamps of these NLRI packets will be almost identical to the arrival time at the DUT if the cable distance between the emulator and DUT is relatively short.
d. アドバタイズされたルートの到着タイムスタンプは、エミュレータとDUTの間にインラインモニタリングデバイスを設置するか、外部アナライザに接続されたDUTのスパンポートを使用して測定できます。このようなインラインモニターまたは外部アナライザーのタイムベースは、プロトコルおよびトラフィックエミュレーターと同期する必要があります。最近のエミュレーターの中には、エミュレーターポートに出入りするすべてのNLRIパケットをキャプチャしてタイムスタンプを付ける機能を備えているものがあります。エミュレータとDUT間のケーブル距離が比較的短い場合、これらのNLRIパケットのタイムスタンプは、DUTへの到着時間とほぼ同じになります。
These test cases measure characteristics of a BGP implementation in non-failure scenarios like:
これらのテストケースは、以下のような非障害シナリオでのBGP実装の特性を測定します。
1. RIB-IN Convergence
1. RIB-INコンバージェンス
2. RIB-OUT Convergence
2. RIB-OUTコンバージェンス
3. eBGP Convergence
3. eBGPコンバージェンス
4. iBGP Convergence
4. iBGPコンバージェンス
Objective:
目的：
This test measures the convergence time taken to receive and install a route in RIB using BGP.
このテストでは、BGPを使用してRIBでルートを受信してインストールするのにかかるコンバージェンス時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 1
このテストでは、図1に示すセットアップを使用します。
Procedure:
手順：
A. All variables affecting convergence should be set to a basic test state (as defined in Section 4.4).
A.収束に影響するすべての変数は、基本的なテスト状態に設定する必要があります（セクション4.4で定義）。
B. Establish BGP adjacency between the DUT and one peer of the emulator, Emp1.
B. DUTとエミュレータの1つのピアであるEmp1の間にBGP隣接関係を確立します。
C. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test.
C.隣接関係を確実に確立するには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するまで待ってから、残りのテストに進みます。
D. Start the traffic from the emulator tx towards the DUT targeted at a route specified in the route mixture (e.g., routeA). Initially, no traffic SHOULD be observed on the egress interface as routeA is not installed in the forwarding database of the DUT.
D.エミュレータtxから、ルート混合で指定されたルート（routeAなど）をターゲットとするDUTに向けてトラフィックを開始します。最初は、routeAがDUTの転送データベースにインストールされていないため、出力インターフェイスでトラフィックを監視する必要はありません。
E. Advertise routeA from the peer (Emp1) to the DUT and record the time.
E.ピア（Emp1）からDUTにrouteSをアドバタイズし、時間を記録します。
This is Tup(Emp1,Rt-A), also named XMT-Rt-time(Rt-A).
これはTup（Emp1、Rt-A）で、XMT-Rt-time（Rt-A）とも呼ばれます。
F. Record the time when routeA from Emp1 is received at the DUT.
F. Emp1からのrouteAがDUTで受信された時刻を記録します。
This is Tup(DUT,Rt-A), also named RCV-Rt-time(Rt-A).
これはTup（DUT、Rt-A）で、RCV-Rt-time（Rt-A）とも呼ばれます。
G. Record the time when the traffic targeted towards routeA is received by the emulator on the appropriate traffic egress interface.
G. routeA宛てのトラフィックがエミュレーターによって適切なトラフィック出力インターフェイスで受信された時間を記録します。
This is TR(TDr,Rt-A), also named DUT-XMT-Data-Time(Rt-A).
これはTR（TDr、Rt-A）で、DUT-XMT-Data-Time（Rt-A）とも呼ばれます。
H. The difference between the Tup(DUT,RT-A) and traffic received time (TR (TDr, Rt-A) is the FIB convergence time for routeA in the route mixture. A full convergence for the route update is the measurement between the first route (Rt-A) and the last route (Rt-last).
H. Tup（DUT、RT-A）とトラフィック受信時間（TR（TDr、Rt-A）の差は、ルート混合におけるrouteAのFIBコンバージェンス時間です。ルート更新の完全なコンバージェンスは、最初のルート（Rt-A）と最後のルート（Rt-last）。
Route update convergence is
ルート更新の収束は
TR(TDr, Rt-last)- Tup(DUT, Rt-A), or
TR（TDr、Rt-last）-Tup（DUT、Rt-A）、または
(DUT-XMT-Data-Time - RCV-Rt-Time)(Rt-A).
（DUT-XMT-Data-Time-RCV-Rt-Time）（Rt-A）。
Note: It is recommended that a single test with the same route mixture be repeated several times. A report should provide the standard deviation and the average of all tests.
注：同じ経路を混合した単一のテストを数回繰り返すことをお勧めします。レポートは、標準偏差とすべてのテストの平均を提供する必要があります。
Running tests with a varying number of routes and route mixtures is important to get a full characterization of a single peer.
さまざまな数のルートとルートの混合でテストを実行することは、単一のピアの完全な特性を取得するために重要です。
Objective:
目的：
This test measures the convergence time taken by an implementation to receive, install, and advertise a route using BGP.
このテストでは、実装がBGPを使用してルートを受信、インストール、およびアドバタイズするのにかかるコンバージェンス時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 2.
このテストでは、図2に示すようなセットアップを使用します。
Procedure:
手順：
A. The Helper Node (HLP) MUST run same version of BGP as the DUT.
A.ヘルパーノード（HLP）は、DUTと同じバージョンのBGPを実行する必要があります。
B. All devices MUST be synchronized using NTP or some local reference clock.
B.すべてのデバイスは、NTPまたはローカルの基準クロックを使用して同期する必要があります。
C. All configuration variables for the Helper Node, DUT, and emulator SHOULD be set to the same values. These values MAY be basic test or a unique set completely described in the test setup.
C.ヘルパーノード、DUT、およびエミュレーターのすべての構成変数を同じ値に設定する必要があります（SHOULD）。これらの値は、基本的なテストまたはテストセットアップで完全に記述された一意のセットである場合があります。
D. Establish BGP adjacency between the DUT and the emulator.
D. DUTとエミュレーターの間にBGP隣接関係を確立します。
E. Establish BGP adjacency between the DUT and the Helper Node.
E. DUTとヘルパーノードの間にBGP隣接関係を確立します。
F. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test.
F.隣接関係を確立するには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するまで待ってから、残りのテストに進みます。
G. Start the traffic from the emulator towards the Helper Node targeted at a specific route (e.g., routeA). Initially, no traffic SHOULD be observed on the egress interface as routeA is not installed in the forwarding database of the DUT.
G.エミュレータから、特定のルート（routeAなど）をターゲットとするヘルパーノードに向けてトラフィックを開始します。最初は、routeAがDUTの転送データベースにインストールされていないため、出力インターフェイスでトラフィックを監視する必要はありません。
H. Advertise routeA from the emulator to the DUT and note the time.
H.エミュレータからDUTにルートをアドバタイズし、時間を書き留めます。
This is Tup(EMx, Rt-A), also named EM-XMT-Data-Time(Rt-A).
これはTup（EMx、Rt-A）で、EM-XMT-Data-Time（Rt-A）とも呼ばれます。
I. Record when routeA is received by the DUT.
I. routeAがDUTによって受信されたときを記録します。
This is Tup(DUTr, Rt-A), also named DUT-RCV-Rt-Time(Rt-A).
これはTup（DUTr、Rt-A）で、DUT-RCV-Rt-Time（Rt-A）とも呼ばれます。
J. Record the time when routeA is forwarded by the DUT towards the Helper Node.
J. routeAがDUTによってヘルパーノードに転送される時間を記録します。
This is Tup(DUTx, Rt-A), also named DUT-XMT-Rt-Time(Rt-A).
これはTup（DUTx、Rt-A）で、DUT-XMT-Rt-Time（Rt-A）とも呼ばれます。
K. Record the time when the traffic targeted towards routeA is received on the Route Egress Interface. This is TR(EMr, Rt-A), also named DUT-XMT-Data Time(Rt-A).
K. routeA宛てのトラフィックがRoute Egress Interfaceで受信された時間を記録します。これはTR（EMr、Rt-A）で、DUT-XMT-Data Time（Rt-A）とも呼ばれます。
FIB convergence = (DUT-XMT-Data-Time -DUT-RCV-Rt-Time)(Rt-A)
RIB convergence = (DUT-XMT-Rt-Time - DUT-RCV-Rt-Time)(Rt-A)
Convergence for a route stream is characterized by
ルートストリームの収束は、
a) individual route convergence for FIB and RIB, and
a) FIBとRIBの個々のルート収束、および
b) all route convergence of
b) すべてのルート収束
FIB-convergence = DUT-XMT-Data-Time(last) - DUT-RCV-Rt-
Time(first), and
RIB-convergence = DUT-XMT-Rt-Time(last) - DUT-RCV-Rt-Time(first).
RIB-convergence = DUT-XMT-Rt-Time（last）-DUT-RCV-Rt-Time（first）。
Objective:
目的：
This test measures the convergence time taken by an implementation to receive, install, and advertise a route in an eBGP Scenario.
このテストは、eBGPシナリオでルートを受信、インストール、およびアドバタイズするために実装によって使用された収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 2, and the scenarios described in RIB-IN and RIB-OUT are applicable to this test case.
このテストでは、図2に示すセットアップを使用します。RIB-INおよびRIB-OUTで説明されているシナリオは、このテストケースに適用できます。
Objective:
目的：
This test measures the convergence time taken by an implementation to receive, install, and advertise a route in an iBGP Scenario.
このテストは、実装がiBGPシナリオでルートを受信、インストール、およびアドバタイズするために要する収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 2, and the scenarios described in RIB-IN and RIB-OUT are applicable to this test case.
このテストでは、図2に示すセットアップを使用します。RIB-INおよびRIB-OUTで説明されているシナリオは、このテストケースに適用できます。
Objective:
目的：
This test measures the convergence time taken by an implementation to receive, install, and advertise a route in an eBGP Multihop Scenario.
このテストでは、eBGPマルチホップシナリオでルートを受信、インストール、およびアドバタイズするために実装によって使用された収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 3. The DUT is used along with a Helper Node.
このテストでは、図3に示すようなセットアップを使用します。DUTはヘルパーノードと共に使用されます。
Procedure:
手順：
A. The Helper Node MUST run the same version of BGP as the DUT.
A.ヘルパーノードは、DUTと同じバージョンのBGPを実行する必要があります。
B. All devices MUST be synchronized using NTP or some local reference clock.
B.すべてのデバイスは、NTPまたはローカルの基準クロックを使用して同期する必要があります。
C. All variables affecting convergence, like authentication, policies, and timers, SHOULD be set to basic settings.
C.認証、ポリシー、タイマーなど、収束に影響を与えるすべての変数は、基本設定に設定する必要があります（SHOULD）。
D. All three devices, the DUT, emulator, and Helper Node, are configured with different ASs.
D. DUT、エミュレーター、ヘルパーノードの3つのデバイスはすべて、異なるASで構成されています。
E. Loopback interfaces are configured on the DUT and Helper Node, and connectivity is established between them using any config options available on the DUT.
E.ループバックインターフェイスはDUTとヘルパーノードで構成され、DUTで使用可能な構成オプションを使用して、それらの間の接続が確立されます。
F. Establish BGP adjacency between the DUT and the emulator.
F. DUTとエミュレータの間でBGP隣接関係を確立します。
G. Establish BGP adjacency between the DUT and the Helper Node.
G. DUTとヘルパーノードの間にBGP隣接関係を確立します。
H. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test
H.隣接関係を確実に確立するには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するまで待ってから、残りのテストに進みます。
I. Start the traffic from the emulator towards the DUT targeted at a specific route (e.g., routeA).
I.エミュレータから、特定のルート（routeAなど）をターゲットとするDUTへのトラフィックを開始します。
J. Initially, no traffic SHOULD be observed on the egress interface as routeA is not installed in the forwarding database of the DUT.
J.最初は、routeAがDUTの転送データベースにインストールされていないため、出力インターフェイスでトラフィックを監視する必要はありません。
K. Advertise routeA from the emulator to the DUT and note the time (Tup(EMx,RouteA), also named Route-Tx-time(Rt-A).
K.エミュレータからDUTにrouteSをアドバタイズし、時間（Tup（EMx、RouteS）、Route-Tx-time（Rt-A）とも呼ばれます）をメモします。
L. Record the time when the route is received by the DUT. This is Tup(EMr,DUT), also named Route-Rcv-time(Rt-A).
L. DUTがルートを受信した時刻を記録します。これはTup（EMr、DUT）で、Route-Rcv-time（Rt-A）とも呼ばれます。
M. Record the time when the traffic targeted towards routeA is received from the egress interface of the DUT on the emulator. This is Tup(EMd,DUT) named Data-Rcv-time(Rt-A)
M. routeA宛てのトラフィックがエミュレータ上のDUTの出力インターフェイスから受信された時間を記録します。これは、Data-Rcv-time（Rt-A）という名前のTup（EMd、DUT）です。
N. Record the time when routeA is forwarded by the DUT towards the Helper Node. This is Tup(EMf,DUT), also named Route-Fwd-time(Rt-A).
N. routeAがDUTによってヘルパーノードに転送される時間を記録します。これはTup（EMf、DUT）で、Route-Fwd-time（Rt-A）とも呼ばれます。
FIB Convergence = (Data-Rcv-time - Route-Rcv-time)(Rt-A)
RIB Convergence = (Route-Fwd-time - Route-Rcv-time)(Rt-A)
Note: It is recommended that the test be repeated with a varying number of routes and route mixtures. With each set route mixture, the test should be repeated multiple times. The results should record the average, mean, standard deviation.
注：異なる数のルートとルートの混合でテストを繰り返すことをお勧めします。設定されたルートの混合ごとに、テストを複数回繰り返す必要があります。結果には、平均、平均、標準偏差が記録されます。
Objective:
目的：
This test measures the route convergence time due to a local link failure event at the DUT's Local Interface.
このテストでは、DUTのローカルインターフェースでのローカルリンク障害イベントによるルート収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 1. The shutdown event is defined as an administrative shutdown event on the DUT.
このテストでは、図1に示すセットアップを使用します。シャットダウンイベントは、DUTの管理シャットダウンイベントとして定義されます。
Procedure:
手順：
A. All variables affecting convergence, like authentication, policies, and timers, should be set to basic-test policy.
A.認証、ポリシー、タイマーなど、収束に影響を与えるすべての変数は、基本テストポリシーに設定する必要があります。
B. Establish two BGP adjacencies from the DUT to the emulator, one over the peer interface and the other using a second peer interface.
B. DUTからエミュレータへの2つのBGP隣接関係を確立します。1つはピアインターフェイスを介し、もう1つは2番目のピアインターフェイスを使用します。
C. Advertise the same route, routeA, over both adjacencies with preferences so that the Best Egress Interface for the preferred next hop is (Emp1) interface.
C.優先順位のある両方の隣接で同じルートrouteAをアドバタイズして、優先されるネクストホップの最適な出力インターフェイスが（Emp1）インターフェイスになるようにします。
D. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test.
D.隣接関係を確立するには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するまで待ってから、残りのテストに進みます。
E. Start the traffic from the emulator towards the DUT targeted at a specific route (e.g., routeA). Initially, traffic would be observed on the best egress route, Emp1, instead of Emp2.
E.エミュレータから、特定のルート（routeAなど）をターゲットとするDUTへのトラフィックを開始します。最初、トラフィックはEmp2ではなくEmp1の最適な出力ルートで監視されます。
F. Trigger the shutdown event of Best Egress Interface on the DUT (Dp1). This time is called Shutdown time.
F. DUT（Dp1）のBest Egress Interfaceのシャットダウンイベントをトリガーします。この時間はシャットダウン時間と呼ばれます。
G. Measure the convergence time for the event to be detected and traffic to be forwarded to Next-Best Egress Interface (Dp2).
G.検出されるイベントとNext-Best Egress Interface（Dp2）に転送されるトラフィックの収束時間を測定します。
Time = Data-detect(Emp2) - Shutdown time
H. Stop the offered load and wait for the queues to drain. Restart the data flow.
H.提示された負荷を停止し、キューが空になるのを待ちます。データフローを再開します。
I. Bring up the link on the DUT's Best Egress Interface.
I. DUTのBest Egress Interfaceにリンクを表示します。
J. Measure the convergence time taken for the traffic to be rerouted from Dp2 to Best Egress Interface, Dp1.
J.トラフィックがDp2から最適な出力インターフェイスであるDp1に再ルーティングされるまでにかかるコンバージェンス時間を測定します。
Time = Data-detect(Emp1) - Bring Up time
K. It is recommended that the test be repeated with a varying number of routes and route mixtures or with a number of routes and route mixtures closer to what is deployed in operational networks.
K.さまざまな数のルートとルートの混合、または運用ネットワークで展開されているものにより近いルートとルートの混合でテストを繰り返すことをお勧めします。
Objective:
目的：
This test measures the route convergence time due to a local link failure event at the Tester's Local Interface.
このテストは、テスターのローカルインターフェースでのローカルリンク障害イベントによるルート収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 1. The shutdown event is defined as a shutdown of the local interface of the Tester via a logical shutdown event. The procedure used in Section 5.2.1 is used for the termination.
このテストでは、図1に示すセットアップを使用します。シャットダウンイベントは、論理シャットダウンイベントによるテスターのローカルインターフェースのシャットダウンとして定義されます。 5.2.1項で使用した手順が終了に使用されます。
Objective:
目的：
This test measures the route convergence time due to a local link failure event at the ECMP member. The FIB configuration and BGP are set to allow two ECMP routes to be installed. However, policy directs the routes to be sent only over one of the paths.
このテストでは、ECMPメンバーでのローカルリンク障害イベントによるルート収束時間を測定します。 FIB設定とBGPは、2つのECMPルートをインストールできるように設定されています。ただし、ポリシーは、経路の1つだけを介して送信されるようにルートを指示します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 1, and the procedure used in Section 5.2.1.
このテストでは、図1に示す設定と、セクション5.2.1で使用した手順を使用します。
Objective:
目的：
This test measures the route convergence time due to BGP Adjacency Failure on the emulator.
このテストでは、エミュレータでのBGP隣接障害によるルート収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 1.
このテストでは、図1に示すようなセットアップを使用します。
Procedure:
手順：
A. All variables affecting convergence, like authentication, policies, and timers, should be set to basic-policy.
A.認証、ポリシー、タイマーなど、収束に影響を与えるすべての変数をbasic-policyに設定する必要があります。
B. Establish two BGP adjacencies from the DUT to the emulator: one over the Best Egress Interface and the other using the Next-Best Egress Interface.
B. DUTからエミュレータまでの2つのBGP隣接関係を確立します。1つは最高の出力インターフェイスを介して、もう1つは次善の出力インターフェイスを使用して確立します。
C. Advertise the same route, routeA, over both adjacencies with preferences so that the Best Egress Interface for the preferred next hop is (Emp1) interface.
C.優先順位のある両方の隣接で同じルートrouteAをアドバタイズして、優先されるネクストホップの最適な出力インターフェイスが（Emp1）インターフェイスになるようにします。
D. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test.
D.隣接関係を確立するには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するまで待ってから、残りのテストに進みます。
E. Start the traffic from the emulator towards the DUT targeted at a specific route (e.g., routeA). Initially, traffic would be observed on the Best Egress Interface.
E.エミュレータから、特定のルート（routeAなど）をターゲットとするDUTへのトラフィックを開始します。最初は、トラフィックは最適な出力インターフェイスで監視されます。
F. Remove BGP adjacency via a software adjacency down on the emulator on the Best Egress Interface. This time is called BGPadj-down-time, also termed BGPpeer-down.
F. Best Egress Interfaceのエミュレーターでソフトウェア隣接を介してBGP隣接を削除します。この時間はBGPadj-down-timeと呼ばれ、BGPpeer-downとも呼ばれます。
G. Measure the convergence time for the event to be detected and traffic to be forwarded to Next-Best Egress Interface. This time is Tr-rr2, also called TR2-traffic-on.
G.イベントが検出され、トラフィックがNext-Best Egress Interfaceに転送されるまでの収束時間を測定します。今回はTr-rr2で、TR2-traffic-onとも呼ばれます。
Convergence = TR2-traffic-on - BGPpeer-down
H. Stop the offered load and wait for the queues to drain and restart the data flow.
H.提供された負荷を停止し、キューが排出してデータフローを再開するのを待ちます。
I. Bring up BGP adjacency on the emulator over the Best Egress Interface. This time is BGP-adj-up, also called BGPpeer-up.
I.最良の出力インターフェイスを介してエミュレータでBGP隣接関係を始動します。今回はBGP-adj-upで、BGPpeer-upとも呼ばれます。
J. Measure the convergence time taken for the traffic to be rerouted to the Best Egress Interface. This time is Tr-rr1, also called TR1-traffic-on.
J.トラフィックが最適な出力インターフェイスに再ルーティングされるまでにかかるコンバージェンス時間を測定します。今回はTr-rr1で、TR1-traffic-onとも呼ばれます。
Convergence = TR1-traffic-on - BGPpeer-up
Objective:
目的：
This test measures the route convergence time due to a hard reset on the DUT.
このテストでは、DUTのハードリセットによるルート収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 1.
このテストでは、図1に示すようなセットアップを使用します。
Procedure:
手順：
A. The requirement for this test case is that the hard reset event should be non-recovering and should affect only the adjacency between the DUT and the emulator on the Best Egress Interface.
A.このテストケースの要件は、ハードリセットイベントが回復不能であり、DUTとBest Egress Interface上のエミュレーター間の隣接のみに影響することです。
B. All variables affecting the test SHOULD be set to basic-test values.
B.テストに影響を与えるすべての変数は、基本テスト値に設定する必要があります。
C. Establish two BGP adjacencies from the DUT to the emulator: one over the Best Egress Interface and the other using the Next-Best Egress Interface.
C. DUTからエミュレーターへの2つのBGP隣接を確立します。1つは最良の出力インターフェースを介して、もう1つは次善の出力インターフェースを使用して確立します。
D. Advertise the same route, routeA, over both adjacencies with preferences so that the Best Egress Interface for the preferred next hop is (Emp1) interface.
D.優先ネクストホップの最良の出力インターフェイスが（Emp1）インターフェイスになるように、両方の隣接を介して同じルートrouteAを優先的にアドバタイズします。
E. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test.
E.隣接関係が確立されるようにするには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するまで待ってから、残りのテストに進みます。
F. Start the traffic from the emulator towards the DUT targeted at a specific route (e.g., routeA). Initially, traffic would be observed on the Best Egress Interface.
F.エミュレータから、特定のルート（routeAなど）をターゲットとするDUTに向けてトラフィックを開始します。最初は、トラフィックは最適な出力インターフェイスで監視されます。
G. Trigger the hard reset event of the Best Egress Interface on the DUT. This time is called time reset.
G. DUTのベストイグレスインターフェイスのハードリセットイベントをトリガーします。この時間を時間リセットと呼びます。
H. This event is detected and traffic is forwarded to the Next-Best Egress Interface. This time is called time-traffic flow.
H.このイベントが検出され、トラフィックはNext-Best Egress Interfaceに転送されます。この時間は、時間トラフィックフローと呼ばれます。
I. Measure the convergence time for the event to be detected and traffic to be forwarded to Next-Best Egress Interface.
I.イベントが検出され、トラフィックがNext-Best Egress Interfaceに転送されるまでの収束時間を測定します。
Time of convergence = time-traffic flow - time-reset
収束時間=時間トラフィックフロー-時間リセット
J. Stop the offered load and wait for the queues to drain and restart.
J.提供された負荷を停止し、キューが排出されて再起動するのを待ちます。
K. It is recommended that the test be repeated with a varying number of routes and route mixtures or with a number of routes and route mixtures closer to what is deployed in operational networks.
K.さまざまな数のルートとルートの混合、または運用ネットワークで展開されているものにより近いルートとルートの混合でテストを繰り返すことをお勧めします。
L. When varying number of routes are used, convergence time is measured using the Loss-Derived method [RFC6412].
L.さまざまな数のルートが使用されている場合、コンバージェンス時間は損失導出法[RFC6412]を使用して測定されます。
M. Convergence time in this scenario is influenced by failure detection time on the Tester, BGP keepalive time and routing, and forwarding table update time.
M.このシナリオの収束時間は、テスターの障害検出時間、BGPキープアライブ時間とルーティング、および転送テーブルの更新時間の影響を受けます。
Objective:
目的：
This test measures the route convergence time taken by an implementation to service a BGP Route Refresh message and advertise a route.
このテストは、BGPルートリフレッシュメッセージを処理し、ルートをアドバタイズするために実装で使用されたルート収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 2.
このテストでは、図2に示すようなセットアップを使用します。
Procedure:
手順：
A. The BGP implementation on the DUT and Helper Node needs to support BGP Route Refresh Capability [RFC2918].
A. DUTおよびヘルパーノードのBGP実装は、BGPルートリフレッシュ機能[RFC2918]をサポートする必要があります。
B. All devices MUST be synchronized using NTP or some local reference clock.
B.すべてのデバイスは、NTPまたはローカルの基準クロックを使用して同期する必要があります。
C. All variables affecting convergence, like authentication, policies, and timers, should be set to basic-test defaults.
C.認証、ポリシー、タイマーなど、収束に影響を与えるすべての変数は、基本テストのデフォルトに設定する必要があります。
D. The DUT and the Helper Node are configured in the same AS, whereas the emulator is configured under a different AS.
D. DUTとヘルパーノードは同じASで構成されていますが、エミュレータは別のASで構成されています。
E. Establish BGP adjacency between the DUT and the emulator.
E. DUTとエミュレータの間でBGP隣接関係を確立します。
F. Establish BGP adjacency between the DUT and the Helper Node.
F. Establish BGP adjacency between the DUT and the Helper Node.
G. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test.
G.隣接関係を確立するには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するまで待ってから、残りのテストに進みます。
H. Configure a policy under the BGP on the Helper Node to deny routes received from the DUT.
H. DUTから受信したルートを拒否するように、ヘルパーノードのBGPでポリシーを構成します。
I. Advertise routeA from the emulator to the DUT.
I.エミュレータからDUTにルートをアドバタイズします。
J. The DUT will try to advertise the route to the Helper Node; it will be denied.
J. DUTはルートをヘルパーノードにアドバタイズしようとします。拒否されます。
K. Wait for three keepalives.
K. 3つのキープアライブを待ちます。
L. Start the traffic from the emulator towards the Helper Node targeted at a specific route, say routeA. Initially, no traffic would be observed on the egress interface, as routeA is not present.
L.エミュレータから、特定のルート（routeAなど）をターゲットとするヘルパーノードへのトラフィックを開始します。最初は、routeAが存在しないため、出力インターフェイスでトラフィックは観察されません。
M. Remove the policy on the Helper Node and issue a route refresh request towards the DUT. Note the timestamp of this event. This is the RefreshTime.
M.ヘルパーノードのポリシーを削除し、DUTに向けてルート更新リクエストを発行します。このイベントのタイムスタンプに注意してください。これはRefreshTimeです。
N. Record the time when the traffic targeted towards routeA is received on the egress interface. This is RecTime.
N. routeA宛てのトラフィックが出力インターフェイスで受信された時間を記録します。これはRecTimeです。
O. The following equation represents the Route Refresh Convergence Time per route.
O.次の方程式は、ルートごとのルートリフレッシュ収束時間を表しています。
Route Refresh Convergence Time = (RecTime - RefreshTime)
Objective:
目的：
This test measures the route convergence time taken by an implementation to service a BGP withdraw message and advertise the withdraw.
このテストでは、実装がBGP withdrawメッセージを処理し、withdrawをアドバタイズするのにかかるルート収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 2.
このテストでは、図2に示すようなセットアップを使用します。
Procedure:
手順：
A. This test consists of two steps to determine the Total Withdraw Processing Time.
A.このテストは、合計引き出し処理時間を決定する2つのステップで構成されています。
B. Step 1:
B.ステップ1：
(1) All devices MUST be synchronized using NTP or some local reference clock.
（1）すべてのデバイスは、NTPまたはローカルの基準クロックを使用して同期する必要があります。
(2) All variables should be set to basic-test parameters.
（2）すべての変数は、基本テストパラメーターに設定する必要があります。
(3) The DUT and Helper Node are configured in the same AS, whereas the emulator is configured under a different AS.
（3）DUTとヘルパーノードは同じASで構成されますが、エミュレータは別のASで構成されます。
(4) Establish BGP adjacency between the DUT and the emulator.
（4）DUTとエミュレータの間にBGP隣接関係を確立します。
(5) To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test.
（5）隣接関係が確立されるようにするには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するまで待ってから、残りのテストに進みます。
(6) Start the traffic from the emulator towards the DUT targeted at a specific route (e.g., routeA). Initially, no traffic would be observed on the egress interface as routeA is not present on the DUT.
（6）エミュレータから、特定のルート（routeAなど）をターゲットとするDUTに向けてトラフィックを開始します。最初は、routeAがDUTに存在しないため、出力インターフェイスでトラフィックは観察されません。
(7) Advertise routeA from the emulator to the DUT.
（7）エミュレータからDUTにルートをアドバタイズします。
(8) The traffic targeted towards routeA is received on the egress interface.
（8）routeA宛てのトラフィックは、出力インターフェイスで受信されます。
(9) Now the Tester sends a request to withdraw routeA to the DUT. TRx(Awith) is also called WdrawTime1(Rt-A).
（9）これで、テスターはrouteAを撤回する要求をDUTに送信します。 TRx（Awith）はWdrawTime1（Rt-A）とも呼ばれます。
(10) Record the time when no traffic is observed as determined by the emulator. This is the RouteRemoveTime1(Rt-A).
（10）エミュレーターによって決定された、トラフィックが観察されない時間を記録します。これはRouteRemoveTime1（Rt-A）です。
(11) The difference between the RouteRemoveTime1 and WdrawTime1 is the WdrawConvTime1.
（11）RouteRemoveTime1とWdrawTime1の違いは、WdrawConvTime1です。
WdrawConvTime1(Rt-A) = RouteRemoveTime1(Rt-A) -
WdrawTime1(Rt-A)
C. Step 2:
C. Step 2:
(1) Continuing from Step 1, re-advertise routeA back to the DUT from the Tester.
（1）ステップ1から続けて、テスターからrouteAをDUTに再アドバタイズします。
(2) The DUT will try to advertise routeA to the Helper Node (this assumes there exists a session between the DUT and Helper Node).
（2）DUTはルートをヘルパーノードにアドバタイズしようとします（これはDUTとヘルパーノードの間にセッションが存在することを前提としています）。
(3) Start the traffic from the emulator towards the Helper Node targeted at a specific route (e.g., routeA). Traffic would be observed on the egress interface after routeA is received by the Helper Node.
（3）エミュレータから、特定のルート（routeAなど）をターゲットとするヘルパーノードに向けてトラフィックを開始します。 routeAがヘルパーノードによって受信された後、トラフィックは出力インターフェイスで監視されます。
WATime=time traffic first flows
WATime =トラフィックが最初に流れる時間
(4) Now the Tester sends a request to withdraw routeA to DUT. This is the WdrawTime2(Rt-A).
（4）これで、テスターはrouteAを撤回する要求をDUTに送信します。これはWdrawTime2（Rt-A）です。
WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A)
(5) DUT processes the withdraw and sends it to the Helper Node.
（5）DUTがwithdrawを処理し、ヘルパーノードに送信します。
(6) Record the time when no traffic is observed as determined by the emulator. This is:
(6) Record the time when no traffic is observed as determined by the emulator. This is:
TR-WAW(DUT,RouteA) = RouteRemoveTime2(Rt-A)
(7) Total Withdraw Processing Time is:
（7）合計引き出し処理時間は次のとおりです。
TotalWdrawTime(Rt-A) = ((RouteRemoveTime2(Rt-A) -
WdrawTime2(Rt-A)) - WdrawConvTime1(Rt-A))
Objective:
目的：
This test measures the convergence time taken by an implementation to service a BGP Path Attribute Change.
このテストは、BGPパス属性の変更を処理するために実装が取る収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 1.
このテストでは、図1に示すようなセットアップを使用します。
Procedure:
手順：
A. This test only applies to Well-Known Mandatory Attributes like origin, AS path, and next hop.
A.このテストは、オリジン、ASパス、ネクストホップなどの既知の必須属性にのみ適用されます。
B. In each iteration of the test, only one of these mandatory attributes need to be varied whereas the others remain the same.
B.テストの反復ごとに、これらの必須属性の1つだけを変更する必要があるのに対し、他は同じままです。
C. All devices MUST be synchronized using NTP or some local reference clock.
C.すべてのデバイスは、NTPまたはローカルの基準クロックを使用して同期する必要があります。
D. All variables should be set to basic-test parameters.
D.すべての変数は、基本テストパラメーターに設定する必要があります。
E. Advertise the same route, routeA, over both adjacencies with preferences so that the Best Egress Interface for the preferred next hop is (Emp1) interface.
E. Advertise the same route, routeA, over both adjacencies with preferences so that the Best Egress Interface for the preferred next hop is (Emp1) interface.
F. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test.
F.隣接関係を確立するには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するまで待ってから、残りのテストに進みます。
G. Start the traffic from the emulator towards the DUT targeted at the specific route (e.g., routeA). Initially, traffic would be observed on the Best Egress Interface.
G.エミュレータから、特定のルート（routeAなど）をターゲットとするDUTに向けてトラフィックを開始します。最初は、トラフィックは最適な出力インターフェイスで監視されます。
H. Now advertise the same route, routeA, on the Next-Best Egress Interface but by varying one of the well-known mandatory attributes to have a preferred value over that interface. We call this Tbetter. The other values need to be the same as what was advertised on the Best-Egress adjacency.
H.次に、Next-Best Egressインターフェイスで同じルートrouteAをアドバタイズしますが、既知の必須属性の1つを変更して、そのインターフェイスよりも優先される値にします。これをTbetterと呼びます。その他の値は、Best-Egress隣接でアドバタイズされたものと同じである必要があります。
TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A)
I. Measure the convergence time for the event to be detected and traffic to be forwarded to Next-Best Egress Interface.
I.イベントが検出され、トラフィックがNext-Best Egress Interfaceに転送されるまでの収束時間を測定します。
DUT(Path-Change, Rt-A) = Path-switch time(Rt-A)
Convergence = Path-switch time(Rt-A) - Path Change Event
Time(Rt-A)
J. Stop the offered load and wait for the queues to drain and restart.
J.提供された負荷を停止し、キューが排出されて再起動するのを待ちます。
K. Repeat the test for various attributes.
K.さまざまな属性についてテストを繰り返します。
Objective:
目的：
This test measures the route convergence time taken by an implementation during a Graceful Restart Event as detailed in the terminology document [RFC4098].
このテストでは、用語のドキュメント[RFC4098]で詳しく説明されているように、グレースフルリスタートイベント中に実装が取るルート収束時間を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test uses the setup as shown in Figure 4.
このテストでは、図4に示すセットアップを使用します。
Procedure:
手順：
A. It measures the time taken by an implementation to service a BGP Graceful Restart Event and advertise a route.
A. It measures the time taken by an implementation to service a BGP Graceful Restart Event and advertise a route.
B. The Helper Nodes are the same model as the DUT and run the same BGP implementation as the DUT.
B.ヘルパーノードはDUTと同じモデルであり、DUTと同じBGP実装を実行します。
C. The BGP implementation on the DUT and Helper Node needs to support the BGP Graceful Restart Mechanism [RFC4724].
C. DUTとヘルパーノードのBGP実装は、BGPグレースフルリスタートメカニズム[RFC4724]をサポートする必要があります。
D. All devices MUST be synchronized using NTP or some local reference clock.
D.すべてのデバイスは、NTPまたはローカルの基準クロックを使用して同期する必要があります。
E. All variables are set to basic-test values.
E.すべての変数が基本テスト値に設定されます。
F. The DUT and Helper Node 1 (HLP1) are configured in the same AS, whereas the emulator and Helper Node 2 (HLP2) are configured under different ASs.
F. DUTとヘルパーノード1（HLP1）は同じASで構成されていますが、エミュレーターとヘルパーノード2（HLP2）は異なるASで構成されています。
G. Establish BGP adjacency between the DUT and Helper Nodes.
G. DUTとヘルパーノードの間にBGP隣接関係を確立します。
H. Establish BGP adjacency between the Helper Node 2 and the emulator.
H.ヘルパーノード2とエミュレーターの間にBGP隣接関係を確立します。
I. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test.
I.隣接関係を確実に確立するには、DUTから3つのキープアライブが受信されるか、構成可能な遅延が発生するのを待ってから、残りのテストに進みます。
J. Configure a policy under the BGP on Helper Node 1 to deny routes received from the DUT.
J. Configure a policy under the BGP on Helper Node 1 to deny routes received from the DUT.
K. Advertise routeA from the emulator to Helper Node 2.
K. routeSをエミュレータからヘルパーノード2にアドバタイズします。
L. Helper Node 2 advertises the route to the DUT and the DUT will try to advertise the route to Helper Node 1, which will be denied.
L.ヘルパーノード2はルートをDUTにアドバタイズし、DUTはルートをヘルパーノード1にアドバタイズしようとしますが、拒否されます。
M. Wait for three keepalives.
M. 3つのキープアライブを待ちます。
N. Start the traffic from the emulator towards the Helper Node 1 targeted at the specific route (e.g., routeA). Initially, no traffic would be observed on the egress interface as routeA is not present.
N.エミュレータから、特定のルート（routeAなど）をターゲットとするヘルパーノード1へのトラフィックを開始します。最初は、routeAが存在しないため、出力インターフェイスでトラフィックは観察されません。
O. Perform a Graceful Restart Trigger Event on the DUT and note the time. This is the GREventTime.
O. DUTでグレースフルリスタートトリガーイベントを実行し、時間を記録します。これはGREventTimeです。
P. Remove the policy on Helper Node 1.
P.ヘルパーノード1のポリシーを削除します。
Q. Record the time when the traffic targeted towards routeA is received on the egress interface.
Q. routeA宛てのトラフィックが出力インターフェイスで受信された時間を記録します。
This is TRr(DUT, routeA), also called RecTime(Rt-A).
これは、RecTime（Rt-A）とも呼ばれるTRr（DUT、routeA）です。
R. The following equation represents the Graceful Restart Convergence Time.
R.次の方程式は、グレースフルリスタートの収束時間を表しています。
Graceful Restart Convergence Time(Rt-A) = ((RecTime(Rt-A) -
GREventTime) - RIB-IN)
S. It is assumed in this test case that after a switchover is triggered on the DUT, it will not have any cycles to process the BGP Refresh messages. The reason for this assumption is that there is a narrow window of time where after switchover, when we remove the policy from Helper Node 1, implementations might generate Route Refresh automatically and this request might be serviced before the DUT actually switches over and re-establishes BGP adjacencies with the peers.
S.このテストケースでは、DUTでスイッチオーバーがトリガーされた後、BGPリフレッシュメッセージを処理するサイクルがないことが想定されています。この想定の理由は、ヘルパーノード1からポリシーを削除すると、スイッチオーバー後にルートリフレッシュが自動的に生成され、DUTが実際にスイッチオーバーして再確立する前にこのリクエストが処理される可能性があるという狭い時間枠があるためです。ピアとのBGP隣接。
For each test case, it is recommended that the reporting tables below are completed, and all time values SHOULD be reported with resolution as specified in [RFC4098].
For each test case, it is recommended that the reporting tables below are completed, and all time values SHOULD be reported with resolution as specified in [RFC4098].
Parameter Units or Description
=========================== ==========================
Test case Test case number
Test topology 1, 2, 3, or 4
テストトポロジ1、2、3、または4
Parallel links Number of parallel links
並列リンク並列リンクの数
Interface type Gigabit Ethernet (GigE), Packet over SONET (POS), ATM, other
インターフェイスの種類ギガビットイーサネット（GigE）、Packet over SONET（POS）、ATM、その他
Convergence Event Hard reset, soft reset, link failure, or other defined
収束イベントハードリセット、ソフトリセット、リンク障害、またはその他の定義済み
eBGP sessions Number of eBGP sessions
eBGPセッションeBGPセッションの数
iBGP sessions Number of iBGP sessions
iBGP sessions Number of iBGP sessions
eBGP neighbor Number of eBGP neighbors
eBGP neighbor Number of eBGP neighbors
iBGP neighbor Number of iBGP neighbors
iBGPネイバーiBGPネイバーの数
Routes per peer Number of routes
ピアごとのルートルート数
Total unique routes Number of routes
一意のルートの総数ルートの数
Total non-unique routes Number of routes
一意でないルートの総数ルートの数
IGP configured IS-IS, OSPF, static, or other
IGP構成のIS-IS、OSPF、静的、またはその他
Route mixture Description of route mixture
ルートの混合ルートの混合の説明
Route packing Number of routes included in an update
Route packing Number of routes included in an update
Policy configured Yes, No
構成されたポリシーはい、いいえ
SIDR origin authentication Yes, No [RFC7115]
SIDRオリジン認証はい、いいえ[RFC7115]
bgp-sec [BGPsec] Yes, No
bgp-sec [BGPsec]はい、いいえ
Packet size offered Bytes to the DUT
パケットサイズはバイトをDUTに提供しました
Offered load Packets per second
1秒あたりの提供負荷パケット
Packet sampling interval Seconds on Tester
テスターのパケットサンプリング間隔秒
Forwarding delay threshold Seconds
転送遅延しきい値秒
Timer values configured on DUT
DUTで構成されたタイマー値
Interface failure Seconds indication delay Hold time Seconds MinRouteAdvertisementInterval Seconds (MRAI) MinASOriginationInterval Seconds (MAOI) Keepalive time Seconds ConnectRetry Seconds
インターフェース障害秒数表示の遅延保持時間秒数MinRouteAdvertisementInterval秒数（MRAI）MinASOriginationInterval秒数（MAOI）キープアライブ時間秒数ConnectRetry秒数
TCP parameters for DUT and Tester Maximum Segment Size (MSS) Bytes Slow start threshold Bytes Maximum window size Bytes
DUTおよびテスターのTCPパラメータ最大セグメントサイズ（MSS）バイトスロースタートしきい値バイト最大ウィンドウサイズバイト
Test Details:
Test Details:
a. If the Offered Load matches a subset of routes, describe how this subset is selected.
a. If the Offered Load matches a subset of routes, describe how this subset is selected.
b. Describe how the convergence event is applied; does it cause instantaneous traffic loss or not?
b. 収束イベントがどのように適用されるかを説明します。それは瞬間的なトラフィックの損失を引き起こすかどうか？
c. If there is any policy configured, describe the configured policy.
c. ポリシーが構成されている場合は、構成されているポリシーについて説明します。
Complete the table below for the initial convergence event and the reversion convergence event.
最初の収束イベントと復帰収束イベントについて、以下の表に記入してください。
Parameter Unit
=========================== ==========================
Convergence Event Initial or reversion
Traffic Forwarding Metrics Total number of packets Number of packets offered to the DUT Total number of packets Number of packets forwarded by the DUT Connectivity packet loss Number of packets Convergence packet loss Number of packets Out-of-order packets Number of packets Duplicate packets Number of packets
トラフィック転送メトリクスパケットの合計数DUTに提供されたパケットの数パケットの合計数DUTによって転送されたパケットの数接続パケットの損失パケットの数収束パケットの損失パケットの数順不同のパケットパケットの数重複パケットの数パケット
Convergence Benchmarks
収束ベンチマーク
Rate-Derived Method [RFC6412]: First route convergence Seconds time Full convergence time Seconds
レート導出法[RFC6412]：最初のルートの収束秒数完全な収束時間秒
Loss-Derived Method [RFC6412]: Loss-Derived convergence Seconds time
損失導出法[RFC6412]：損失導出収束秒数
Route-Specific (R-S) Loss-Derived Method: Minimum R-S convergence Seconds time Maximum R-S convergence Seconds time Median R-S convergence Seconds time Average R-S convergence Seconds time
Route-Specific (R-S) Loss-Derived Method: Minimum R-S convergence Seconds time Maximum R-S convergence Seconds time Median R-S convergence Seconds time Average R-S convergence Seconds time
Loss of Connectivity (LoC) Benchmarks
接続喪失（LoC）ベンチマーク
Loss-Derived Method: Loss-Derived loss of Seconds connectivity period
損失に基づく方法：損失に基づく秒単位の接続期間の損失
Route-Specific Loss-Derived Method: Minimum LoC period [n] Array of seconds Minimum Route LoC period Seconds Maximum Route LoC period Seconds Median Route LoC period Seconds Average Route LoC period Seconds
ルート固有の損失に基づく方法：最小LoC期間[n]秒の配列最小ルートLoC期間秒最大ルートLoC期間秒中央ルートLoC期間秒平均ルートLoC期間秒
Benchmarking activities as described in this memo are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
このメモに記載されているベンチマーク活動は、専用のアドレススペースと上記のセクションで指定された制約を使用して、実験環境で制御された刺激を使用した技術の特性評価に限定されます。
The benchmarking network topology is an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
ベンチマークネットワークトポロジは独立したテストセットアップであり、テストトラフィックを実稼働ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤ってルーティングする可能性のあるデバイスに接続してはなりません。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable and external to the DUT/SUT.
さらに、ベンチマークは「ブラックボックス」ベースで実行され、DUT / SUTの外部で観測可能な測定にのみ依存します。
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
[IEEE.802.11] IEEE, "IEEE Standard for Information technology -- Telecommunications and information exchange between systems Local and metropolitan area networks -- Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April 2012, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6178209>.
[IEEE.802.11] IEEE、 "IEEE Standard for Information technology-Telecommunications and information exchange between system Local and metropolitan area network-Specific requirements Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications"、 IEEE 802.11-2012、DOI 10.1109 / ieeestd.2012.6178212、2012年4月、<http://ieeexplore.ieee.org/servlet/ opac？punumber = 6178209>。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, <http://www.rfc-editor.org/info/rfc2918>.
[RFC2918]チェンE。、「BGP-4のルートリフレッシュ機能」、RFC 2918、DOI 10.17487 / RFC2918、2000年9月、<http://www.rfc-editor.org/info/rfc2918>。
[RFC4098] Berkowitz, H., Davies, E., Ed., Hares, S., Krishnaswamy, P., and M. Lepp, "Terminology for Benchmarking BGP Device Convergence in the Control Plane", RFC 4098, DOI 10.17487/RFC4098, June 2005, <http://www.rfc-editor.org/info/rfc4098>.
[RFC4098] Berkowitz、H.、Davies、E.、Ed。、Hares、S.、Krishnaswamy、P。、およびM. Lepp、「Control PlaneでBGPデバイスの収束をベンチマークするための用語」、RFC 4098、DOI 10.17487 / RFC4098、2005年6月、<http://www.rfc-editor.org/info/rfc4098>。
[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>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<http://www.rfc-editor.org/info/rfc4271>。
[RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence", RFC 6412, DOI 10.17487/RFC6412, November 2011, <http://www.rfc-editor.org/info/rfc6412>.
[RFC6412] Poretsky、S.、Imhoff、B。、およびK. Michielsen、「ベンチマークリンクステートIGPデータプレーンルートコンバージェンスの用語」、RFC 6412、DOI 10.17487 / RFC6412、2011年11月、<http：// www .rfc-editor.org / info / rfc6412>。
[BGPsec] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", Work in Progress, draft-ietf-sidr-bgpsec-protocol-15, March 2016.
[BGPsec] Lepinski、M。およびK. Sriram、「BGPsec Protocol Specification」、Work in Progress、draft-ietf-sidr-bgpsec-protocol-15、March 2016。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <http://www.rfc-editor.org/info/rfc1242>.
[RFC1242] Bradner、S。、「ネットワーク相互接続デバイスのベンチマーク用語」、RFC 1242、DOI 10.17487 / RFC1242、1991年7月、<http://www.rfc-editor.org/info/rfc1242>。
[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18, RFC 1983, DOI 10.17487/RFC1983, August 1996, <http://www.rfc-editor.org/info/rfc1983>.
[RFC1983] Malkin、G.、Ed。、「Internet Users 'Glossary」、FY18、RFC 1983、DOI 10.17487 / RFC1983、1996年8月、<http://www.rfc-editor.org/info/rfc1983>。
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, DOI 10.17487/RFC2285, February 1998, <http://www.rfc-editor.org/info/rfc2285>.
[RFC2285] Mandeville、R。、「Benchmarking Terminology for LAN Switching Devices」、RFC 2285、DOI 10.17487 / RFC2285、February 1998、<http://www.rfc-editor.org/info/rfc2285>。
[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, <http://www.rfc-editor.org/info/rfc2545>.
[RFC2545] Marques、P。およびF. Dupont、「Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing」、RFC 2545、DOI 10.17487 / RFC2545、1999年3月、<http：//www.rfc-editor。 org / info / rfc2545>。
[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>.
[RFC4724] Sangli、S.、Chen、E.、Fernando、R.、Scudder、J。、およびY. Rekhter、「BGPのグレースフルリスタートメカニズム」、RFC 4724、DOI 10.17487 / RFC4724、2007年1月、<http： //www.rfc-editor.org/info/rfc4724>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<http：// www。 rfc-editor.org/info/rfc4760>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<http://www.rfc-editor.org/info / rfc5925>。
[RFC6414] Poretsky, S., Papneja, R., Karthik, J., and S. Vapiwala, "Benchmarking Terminology for Protection Performance", RFC 6414, DOI 10.17487/RFC6414, November 2011, <http://www.rfc-editor.org/info/rfc6414>.
[RFC6414] Poretsky、S.、Papneja、R.、Karthik、J.、and S. Vapiwala、 "Benchmarking Terminology for Protection Performance"、RFC 6414、DOI 10.17487 / RFC6414、November 2011、<http：//www.rfc -editor.org/info/rfc6414>。
[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, <http://www.rfc-editor.org/info/rfc7115>.
[RFC7115]ブッシュR.、「リソース公開鍵基盤（RPKI）に基づく元の検証操作」、BCP 185、RFC 7115、DOI 10.17487 / RFC7115、2014年1月、<http://www.rfc-editor.org / info / rfc7115>。
Acknowledgements
謝辞
We would like to thank Anil Tandon, Arvind Pandey, Mohan Nanduri, Jay Karthik, and Eric Brendel for their input and discussions on various sections in the document. We also like to acknowledge Will Liu, Hubert Gee, Semion Lisyansky, and Faisal Shah for their review and feedback on the document.
このドキュメントのさまざまなセクションに関する意見や議論を提供してくれたAnil Tandon、Arvind Pandey、Mohan Nanduri、Jay Karthik、およびEric Brendelに感謝します。また、Will Liu、Hubert Gee、Semion Lisyansky、Faisal Shahのレビューとドキュメントへのフィードバックを歓迎します。
Authors' Addresses
著者のアドレス
Rajiv Papneja Huawei Technologies
Rajeev Papaneja Huawei Technologies
Email: rajiv.papneja@huawei.com
Bhavani Parise Skyport Systems
Bhavani Parise Skyport Systems
Email: bparise@skyportsystems.com
Susan Hares Huawei Technologies
スーザンハレスファーウェイテクノロジー
Email: shares@ndzh.com
Dean Lee IXIA
ディーン・リーIXIA
Email: dlee@ixiacom.com
Ilya Varlashkin Google
イリヤバラシュキングーグル
Email: ilya@nobulus.com