[要約] RFC 4098は、BGPデバイスの制御プレーンでの収束性をベンチマークするための用語を定義しています。その目的は、BGPネットワークのパフォーマンスを評価し、改善するための基準を提供することです。
Network Working Group H. Berkowitz
Request for Comments: 4098 Gett Communications & CCI Training
Category: Informational E. Davies, Ed.
Folly Consulting
S. Hares
Nexthop Technologies
P. Krishnaswamy
SAIC
M. Lepp
Consultant
June 2005
Terminology for Benchmarking BGP Device Convergence in the Control Plane
コントロールプレーンのベンチマークBGPデバイスの収束のための用語
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant.
このドキュメントは、単一のBGPデバイスの制御面でのEBGP収束を測定するためのベンチマーク方法論の説明を標準化するための用語を確立します。将来のドキュメントでは、IBGPの収束、収束したコントロールプレーン情報と複数の相互作用するBGPデバイスに基づく転送の開始について説明します。この用語は、IPv4とIPv6の両方に適用できます。関連する場合は、各バージョンの実例が含まれています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview and Road Map ......................................4
1.2. Definition Format ..........................................5
2. Components and Characteristics of Routing Information ...........5
2.1. (Network) Prefix ...........................................5
2.2. Network Prefix Length ......................................6
2.3. Route ......................................................6
2.4. BGP Route ..................................................7
2.5. Network Level Reachability Information (NLRI) ..............7
2.6. BGP UPDATE Message .........................................8
3. Routing Data Structures and Route Categories ....................8
3.1. Routing Information Base (RIB) .............................8
3.1.1. Adj-RIB-In and Adj-RIB-Out ..........................8
3.1.2. Loc-RIB .............................................9
3.2. Prefix Filtering ...........................................9
3.3. Routing Policy ............................................10
3.4. Routing Policy Information Base ...........................10
3.5. Forwarding Information Base (FIB) .........................11
3.6. BGP Instance ..............................................12
3.7. BGP Device ................................................12
3.8. BGP Session ...............................................13
3.9. Active BGP Session ........................................13
3.10. BGP Peer .................................................13
3.11. BGP Neighbor .............................................14
3.12. MinRouteAdvertisementInterval (MRAI) .....................14
3.13. MinASOriginationInterval (MAOI) ..........................15
3.14. Active Route .............................................15
3.15. Unique Route .............................................15
3.16. Non-Unique Route .........................................16
3.17. Route Instance ...........................................16
4. Constituent Elements of a Router or Network of Routers .........17
4.1. Default Route, Default-Free Table, and Full Table .........17
4.1.1. Default Route ......................................17
4.1.2. Default-Free Routing Table .........................18
4.1.3. Full Default-Free Table ............................18
4.1.4. Default-Free Zone ..................................19
4.1.5. Full Provider-Internal Table .......................19
4.2. Classes of BGP-Speaking Routers ...........................19
4.2.1. Provider Edge Router ...............................20
4.2.2. Subscriber Edge Router .............................20
4.2.3. Inter-provider Border Router .......................21
4.2.4. Core Router ........................................21
5. Characterization of Sets of Update Messages ....................22
5.1. Route Packing .............................................22
5.2. Route Mixture .............................................23
5.3. Update Train ..............................................24
5.4. Randomness in Update Trains ...............................24
5.5. Route Flap ................................................25
6. Route Changes and Convergence ..................................25
6.1. Route Change Events .......................................25
6.2. Device Convergence in the Control Plane ...................27
7. BGP Operation Events ...........................................28
7.1. Hard Reset ................................................28
7.2. Soft Reset ................................................29
8. Factors That Impact the Performance of the Convergence
Process ........................................................29
8.1. General Factors Affecting Device Convergence ..............29
8.1.1. Number of Peers ....................................29
8.1.2. Number of Routes per Peer ..........................30
8.1.3. Policy Processing/Reconfiguration ..................30
8.1.4. Interactions with Other Protocols ..................30
8.1.5. Flap Damping .......................................30
8.1.6. Churn ..............................................31
8.2. Implementation-Specific and Other Factors Affecting BGP ...31
8.2.1. Forwarded Traffic ..................................31
8.2.2. Timers .............................................32
8.2.3. TCP Parameters Underlying BGP Transport ............32
8.2.4. Authentication .....................................32
9. Security Considerations ........................................32
10. Acknowledgements ..............................................32
11. References ....................................................33
11.1. Normative References ....................................33
11.2. Informative References ..................................34
This document defines terminology for use in characterizing the convergence performance of BGP processes in routers or other devices that instantiate BGP functionality. (See 'A Border Gateway Protocol 4 (BGP-4)' [RFC1771], referred to as RFC 1771 in the remainder of the document.) It is the first part of a two-document series, of which the subsequent document will contain the associated tests and methodology. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. However, this document is primarily targeted for BGP-4 in IPv4 networks. IPv6 will require the use of MP-BGP [RFC2858], as described in RFC 2545 [RFC2545], but this document will not address terminology or issues specific to these extensions of BGP-4. Also terminology and issues specific to the extensions of BGP that support VPNs as described in RFC 2547 [RFC2547] are out of scope for this document.
このドキュメントでは、ルーターまたはBGP機能をインスタンス化する他のデバイスのBGPプロセスの収束性能を特徴付ける際に使用する用語を定義しています。（「A Border Gateway Protocol 4（BGP-4）」[RFC1771]を参照してください。これは、文書の残りでRFC 1771と呼ばれます。）これは、2ドキュメントシリーズの最初の部分です。関連するテストと方法論。この用語は、IPv4とIPv6の両方に適用できます。関連する場合は、各バージョンの実例が含まれています。ただし、このドキュメントは、主にIPv4ネットワークのBGP-4を対象としています。IPv6は、RFC 2545 [RFC2545]に記載されているように、MP-BGP [RFC2858]の使用を必要としますが、この文書は、BGP-4のこれらの拡張に固有の用語または問題に対処しません。また、RFC 2547 [RFC2547]で説明されているようにVPNをサポートするBGPの拡張に固有の用語と問題は、このドキュメントの範囲外です。
The following observations underlie the approach adopted in this document, and in the companion document:
次の観察結果は、この文書およびコンパニオンドキュメントで採用されたアプローチの根底にあります。
o The principal objective is to derive methodologies that standardize conducting and reporting convergence-related measurements for BGP.
o 主な目的は、BGPのコンクバージェンス関連の測定値を標準化する方法論を導き出すことです。
o It is necessary to remove ambiguity from many frequently used terms that arise in the context of these measurements.
o これらの測定のコンテキストで発生する多くの頻繁に使用される用語から曖昧さを削除する必要があります。
o As convergence characterization is a complex process, it is desirable to restrict the initial focus in this set of documents to specifying how to take basic control-plane measurements as a first step in characterizing BGP convergence.
o 収束の特性評価は複雑なプロセスであるため、BGP収束を特徴付けるための最初のステップとして基本的なコントロールプレーン測定を行う方法を指定するために、この一連のドキュメントの最初の焦点を制限することが望ましいです。
For path-vector protocols, such as BGP, the primary initial focus will therefore be on network and system control-plane [RFC3654] activity consisting of the arrival, processing, and propagation of routing information.
したがって、BGPなどのパスベクトルプロトコルの場合、主要な初期焦点は、ルーティング情報の到着、処理、伝播で構成されるネットワークおよびシステムコントロールプレーン[RFC3654]アクティビティにあります。
We note that for testing purposes, all optional parameters SHOULD be turned off. All variable parameters SHOULD be at their default setting unless the test specifies otherwise.
テストのために、すべてのオプションのパラメーターをオフにする必要があることに注意してください。すべての変数パラメーターは、テストが特に指定しない限り、デフォルト設定である必要があります。
Subsequent documents will explore the more intricate aspects of convergence measurement, such as the impacts of the presence of Multiprotocol Extensions for BGP-4, policy processing, simultaneous traffic on the control and data paths within the Device Under Test (DUT), and other realistic performance modifiers. Convergence of Interior Gateway Protocols (IGPs) will also be considered in separate documents.
後続のドキュメントでは、BGP-4のマルチプロトコル拡張機能の存在、ポリシー処理、テスト対象のデバイス内のコントロールの同時トラフィック、およびその他の現実的なデータパスの存在の影響など、収束測定のより複雑な側面を調査します。パフォーマンス修飾子。インテリアゲートウェイプロトコル（IGPS）の収束も、個別のドキュメントで考慮されます。
Characterizations of the BGP convergence performance of a device must-take into account all distinct stages and aspects of BGP. functionality. This requires that the relevant terms and metrics be as specifically defined as possible. Such definition is the goal of this document.
BGPのキャラクタ化デバイスの収束性能は、BGPのすべての異なる段階と側面を考慮に入れておく必要があります。機能。これには、関連する用語とメトリックが可能な限り具体的に定義される必要があります。このような定義は、このドキュメントの目標です。
The necessary definitions are classified into separate categories:
必要な定義は、別々のカテゴリに分類されます。
o Components and characteristics of routing information
o ルーティング情報のコンポーネントと特性
o Routing data structures and route categories
o データ構造とルートカテゴリをルーティングします
o Descriptions of the constituent elements of a network or a router that is undergoing convergence
o ネットワークの構成要素または収束を受けているルーターの説明
o Characterization of sets of update messages, types of route-change events, as well as some events specific to BGP operation
o 更新メッセージのセット、ルート変更イベントの種類、およびBGP操作に固有のいくつかのイベントの特性評価
o Descriptions of factors that impact the performance of convergence processes
o 収束プロセスのパフォーマンスに影響を与える要因の説明
The definition format is equivalent to that defined in 'Requirements for IP Version 4 Routers' [RFC1812], and is repeated here for convenience:
定義形式は、「IPバージョン4ルーターの要件」[RFC1812]で定義されているものと同等であり、便利なためにここで繰り返されます。
X.x Term to be defined (e.g., Latency).
x.x定義される用語（例：レイテンシ）。
Definition: One or more sentences forming the body of the definition.
定義：定義の本体を形成する1つ以上の文。
Discussion: A brief discussion of the term, its application, and any restrictions that there might be on measurement procedures.
議論：用語、その適用、および測定手順にある可能性のある制限に関する簡単な議論。
Measurement units: The units used to report measurements of this term. This item may not be applicable (N.A.).
測定単位：この用語の測定を報告するために使用される単位。このアイテムは適用できない場合があります（N.A.）。
Issues: List of issues or conditions that could affect this term.
問題：この用語に影響を与える可能性のある問題または条件のリスト。
See also: List of related terms that are relevant to the definition or discussion of this term.
参照：この用語の定義または議論に関連する関連する用語のリスト。
Definition: "A network prefix is a contiguous set of bits at the more significant end of the address that collectively designates the set of systems within a network; host numbers select among those systems." (This definition is taken directly from section 2.2.5.2, "Classless Inter Domain Routing (CIDR)", of RFC 1812.)
定義：「ネットワークプレフィックスは、ネットワーク内のシステムのセットを集合的に指定するアドレスのより重要な端にある隣接するビットのセットです。ホスト番号は、これらのシステムで選択されます。」（この定義は、RFC 1812のセクション2.2.5.2「クラスレスインタードメインルーティング（CIDR）」から直接取得しています。）
Discussion: In the CIDR context, the network prefix is the network component of an IP address. In IPv4 systems, the network component of a complete address is known as the 'network part', and the remaining part of the address is known as the 'host part'. In IPv6 systems, the network component of a complete address is known as the 'subnet prefix', and the remaining part is known as the 'interface identifier'.
ディスカッション：CIDRコンテキストでは、ネットワークプレフィックスはIPアドレスのネットワークコンポーネントです。IPv4システムでは、完全なアドレスのネットワークコンポーネントは「ネットワークパーツ」として知られており、アドレスの残りの部分は「ホストパーツ」として知られています。IPv6システムでは、完全なアドレスのネットワークコンポーネントは「サブネットプレフィックス」として知られており、残りの部分は「インターフェイス識別子」として知られています。
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also:
参照：
Definition: The network prefix length is the number of bits, out of the total constituting the address field, that define the network prefix portion of the address.
定義：ネットワークプレフィックスの長さは、アドレスフィールドを構成する合計のうち、アドレスのネットワークプレフィックス部分を定義するビット数です。
Discussion: A common alternative to using a bit-wise mask to communicate this component is the use of slash (/) notation. This binds the notion of network prefix length in bits to an IP address. For example, 141.184.128.0/17 indicates that the network component of this IPv4 address is 17 bits wide. Similar notation is used for IPv6 network prefixes; e.g., 2001:db8:719f::/48. When referring to groups of addresses, the network prefix length is often used as a means of describing groups of addresses as an equivalence class. For example, 'one hundred /16 addresses' refers to 100 addresses whose network prefix length is 16 bits.
ディスカッション：このコンポーネントを通信するためにビットワイズマスクを使用する一般的な代替手段は、スラッシュ（/）表記の使用です。これにより、ビットのネットワークプレフィックスの長さの概念がIPアドレスに結合します。たとえば、141.184.128.0/17は、このIPv4アドレスのネットワークコンポーネントが幅17ビットであることを示しています。同様の表記は、IPv6ネットワークプレフィックスに使用されます。例：2001：DB8：719f ::/48。アドレスのグループを参照する場合、ネットワークプレフィックスの長さは、アドレスのグループを等価クラスとして記述する手段としてよく使用されます。たとえば、「100 /16アドレス」とは、ネットワークのプレフィックスの長さが16ビットの100アドレスを指します。
Measurement units: Bits.
測定単位：ビット。
Issues:
問題：
See also: Network Prefix.
参照：ネットワークプレフィックス。
Definition: In general, a 'route' is the n-tuple <prefix, nexthop [, other routing or non-routing protocol attributes]>. A route is not end-to-end, but is defined with respect to a specific next hop that should take packets on the next step toward their destination as defined by the prefix. In this usage, a route is the basic unit of information about a target destination distilled from routing protocols.
定義：一般に、「ルート」はn-tuple <prefix、nexthop [、他のルーティングまたは非ルーティングプロトコル属性]>です。ルートはエンドツーエンドではありませんが、プレフィックスで定義されているように、目的地に向かって次のステップでパケットを取得する特定の次のホップに関して定義されます。この使用法では、ルートは、ルーティングプロトコルから蒸留されたターゲット宛先に関する情報の基本単位です。
Discussion: This term refers to the concept of a route common to all routing protocols. With reference to the definition above, typical non-routing-protocol attributes would be associated with diffserv or traffic engineering.
議論：この用語は、すべてのルーティングプロトコルに共通するルートの概念を指します。上記の定義を参照すると、典型的な非ルーティングプロトコル属性は、DiffServまたはトラフィックエンジニアリングに関連付けられます。
Measurement units: N.A.
測定単位：N.A。
Issues: None.
問題：なし。
See also: BGP Route.
参照：BGPルート。
Definition: A BGP route is an n-tuple <prefix, nexthop, ASpath [, other BGP attributes]>.
定義：BGPルートは、n-tuple <prefix、nexthop、aspath [、他のBGP属性]>です。
Discussion: BGP Attributes, such as Nexthop or AS path, are defined in RFC 1771, where they are known as Path Attributes, and they are the qualifying data that define the route. From RFC 1771: "For purposes of this protocol a route is defined as a unit of information that pairs a destination with the attributes of a path to that destination."
議論：NexthopやPathなどのBGP属性は、パス属性として知られているRFC 1771で定義されており、ルートを定義する適格なデータです。RFC 1771から：「このプロトコルの目的のために、ルートは、目的地をその目的地へのパスの属性とペアリングする情報の単位として定義されます。」
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also: Route, Prefix, Adj-RIB-In, Network Level Reachability Information (NLRI)
参照：ルート、プレフィックス、adj-rib-in、ネットワークレベルの到達可能性情報（NLRI）
Definition: The NLRI consists of one or more network prefixes with the same set of path attributes.
定義：NLRIは、同じパス属性セットを持つ1つ以上のネットワークプレフィックスで構成されています。
Discussion: Each prefix in the NLRI is combined with the (common) path attributes to form a BGP route. The NLRI encapsulates a set of destinations to which packets can be routed (from this point in the network) along a common route described by the path attributes.
ディスカッション：NLRIの各プレフィックスは、（共通の）パス属性と組み合わされてBGPルートを形成します。NLRIは、パス属性によって記述された一般的なルートに沿って（ネットワークのこの時点から）パケットをルーティングできる一連の宛先をカプセル化します。
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also: Route Packing, Network Prefix, BGP Route, NLRI.
参照：ルートパッキング、ネットワークプレフィックス、BGPルート、NLRI。
Definition: An UPDATE message contains an advertisement of a single NLRI field, possibly containing multiple prefixes, and multiple withdrawals of unfeasible routes. See RFC 1771 for details.
定義：更新メッセージには、おそらく複数のプレフィックスが含まれている可能性のある単一のNLRIフィールドの広告と、実行不可能なルートの複数の引き出しが含まれています。詳細については、RFC 1771を参照してください。
Discussion: From RFC 1771: "A variable length sequence of path attributes is present in every UPDATE. Each path attribute is a triple <attribute type, attribute length, attribute value> of variable length."
ディスカッション：RFC 1771から：「すべての更新にパス属性の変数長シーケンスが存在します。各パス属性は、変数長のトリプル<属性タイプ、属性長、属性値>です。」
Measurement units: N.A.
測定単位：N.A。
See also:
参照：
The RIB collectively consists of a set of logically (not necessarily physically) distinct databases, each of which is enumerated below. The RIB contains all destination prefixes to which the router may forward, and one or more currently reachable next hop addresses for them.
リブは、論理的に（必ずしも物理的にではない）異なるデータベースのセットで構成されており、それぞれが以下に列挙されています。リブには、ルーターが転送できるすべての宛先プレフィックスが含まれており、現在1つ以上の1つ以上の次のホップアドレスが到達します。
Routes included in this set potentially have been selected from several sources of information, including hardware status, interior routing protocols, and exterior routing protocols. RFC 1812 contains a basic set of route selection criteria relevant in an all-source context. Many implementations impose additional criteria. A common implementation-specific criterion is the preference given to different routing information sources.
このセットに含まれるルートは、ハードウェアステータス、インテリアルーティングプロトコル、外部ルーティングプロトコルなど、いくつかの情報源から選択されています。RFC 1812には、オールソースのコンテキストに関連するルート選択基準の基本セットが含まれています。多くの実装が追加の基準を課しています。一般的な実装固有の基準は、さまざまなルーティング情報源に与えられる好みです。
Definition: Adj-RIB-In and Adj-RIB-Out are "views" of routing information from the perspective of individual peer routers. The Adj-RIB-In contains information advertised to the DUT by a specific peer.
定義：adj-rib-inおよびadj-rib-outは、個々のピアルーターの観点からルーティング情報の「ビュー」です。adj-rib-inには、特定のピアによってDUTに宣伝されている情報が含まれています。
The Adj-RIB-Out contains the information the DUT will advertise to the peer. See RFC 1771.
adj-rib-outには、DUTがピアに宣伝する情報が含まれています。RFC 1771を参照してください。
Discussion:
議論：
Issues:
問題：
Measurement units: Number of route instances.
測定単位：ルートインスタンスの数。
See also: Route, BGP Route, Route Instance, Loc-RIB, FIB.
参照：ルート、BGPルート、ルートインスタンス、loc-rib、fib。
Definition: The Loc-RIB contains the set of best routes selected from the various Adj-RIBs, after applying local policies and the BGP route selection algorithm.
定義：LOC-RIBには、ローカルポリシーとBGPルート選択アルゴリズムを適用した後、さまざまなadj-RIBから選択された最高のルートのセットが含まれています。
Discussion: The separation implied among the various RIBs is logical. It does not necessarily follow that these RIBs are distinct and separate entities in any given implementation. Types of routes that need to be considered include internal BGP, external BGP, interface, static, and IGP routes.
議論：さまざまなrib骨の間で暗示される分離は論理的です。これらのリブが特定の実装において明確で別々のエンティティであることは必ずしも従いません。考慮する必要があるルートの種類には、内部BGP、外部BGP、インターフェイス、静的、IGPルートが含まれます。
Issues:
問題：
Measurement units: Number of routes.
測定単位：ルート数。
See also: Route, BGP Route, Route Instance, Adj-RIB-In, Adj-RIB-Out, FIB.
参照：ルート、BGPルート、ルートインスタンス、adj-rib-in、adj-rib-out、fib。
Definition: Prefix Filtering is a technique for eliminating routes from consideration as candidates for entry into a RIB by matching the network prefix in a BGP Route against a list of network prefixes.
定義：プレフィックスフィルタリングは、BGPルート内のネットワークプレフィックスのリストにネットワークプレフィックスを一致させることにより、リブへの参入候補としての候補としてルートを排除するための手法です。
Discussion: A BGP Route is eliminated if, for any filter prefix from the list, the Route prefix length is equal to or longer than the filter prefix length and the most significant bits of the two prefixes match over the length of the filter prefix. See 'Cooperative Route Filtering Capability for BGP-4' [BGP-4] for examples of usage.
ディスカッション：リストからのフィルタープレフィックスについて、ルートのプレフィックスの長さがフィルタープレフィックスの長さ以下であり、2つのプレフィックスの中で最も重要なビットがフィルタープレフィックスの長さで一致する場合、BGPルートが削除されます。使用の例については、「BGP-4の協同ルートフィルタリング機能」[BGP-4]を参照してください。
Measurement units: Number of filter prefixes; lengths of prefixes.
測定単位：フィルタープレフィックスの数。プレフィックスの長さ。
Issues:
問題：
See also: BGP Route, Network Prefix, Network Prefix Length, Routing Policy, Routing Policy Information Base.
参照：BGPルート、ネットワークプレフィックス、ネットワークプレフィックスの長さ、ルーティングポリシー、ルーティングポリシー情報ベース。
Definition: Routing Policy is "the ability to define conditions for accepting, rejecting, and modifying routes received in advertisements" [GLSSRY].
定義：ルーティングポリシーは、「広告で受け取ったルートを受け入れ、拒否し、変更するための条件を定義する能力」[Glssry]です。
Discussion: RFC 1771 further constrains policy to be within the hop-by-hop routing paradigm. Policy is implemented using filters and associated policy actions such as Prefix Filtering. Many ASes formulate and document their policies using the Routing Policy Specification Language (RPSL) [RFC2622] and then automatically generate configurations for the BGP processes in their routers from the RPSL specifications.
ディスカッション：RFC 1771は、ポリシーがホップバイホップルーティングパラダイム内にあることをさらに制約します。ポリシーは、フィルターとプレフィックスフィルタリングなどの関連するポリシーアクションを使用して実装されます。多くのASEは、ルーティングポリシー仕様言語（RPSL）[RFC2622]を使用してポリシーを策定および文書化し、RPSL仕様からルーターのBGPプロセスの構成を自動的に生成します。
Measurement units: Number of policies; length of policies.
測定単位：ポリシーの数。ポリシーの長さ。
Issues:
問題：
See also: Routing Policy Information Base, Prefix Filtering.
参照：ルーティングポリシー情報ベース、プレフィックスフィルタリング。
Definition: A routing policy information base is the set of incoming and outgoing policies.
定義：ルーティングポリシー情報ベースは、受信ポリシーと発信ポリシーのセットです。
Discussion: All references to the phase of the BGP selection process below are made with respect to RFC 1771 definition of these phases. Incoming policies are applied in Phase 1 of the BGP selection process to the Adj-RIB-In routes to set the metric for the Phase 2 decision process. Outgoing Policies are applied in Phase 3 of the BGP process to the Adj-RIB-Out routes preceding route (prefix and path attribute tuple) announcements to a specific peer. Policies in the Policy Information Base have matching and action conditions. Common information to match includes route prefixes, AS paths, communities, etc. The action on match may be to drop the update and not to pass it to the Loc-RIB, or to modify the update in some way, such as changing local preference (on input) or MED (on output), adding or deleting communities, prepending the current AS in the AS path, etc. The amount of policy processing (both in terms of route maps and filter/access lists) will impact the convergence time and properties of the distributed BGP algorithm. The amount of policy processing may vary from a simple policy that accepts all routes and sends them according to a complex policy with a substantial fraction of the prefixes being filtered by filter/access lists.
議論：以下のBGP選択プロセスのフェーズへのすべての言及は、これらのフェーズのRFC 1771定義に関して行われます。着信ポリシーは、BGP選択プロセスのフェーズ1にAdj-Rib-inルートに適用され、フェーズ2の決定プロセスのメトリックを設定します。発信ポリシーは、BGPプロセスのフェーズ3に、特定のピアにアナウンスされるルート（プレフィックスおよびパス属性タプル）のアナウンスに先行するadj-rib-outルートに適用されます。ポリシー情報ベースのポリシーには、マッチング条件とアクション条件があります。一致する一般的な情報には、パス、コミュニティなどのルートプレフィックスが含まれます。一致するアクションは、更新をドロップし、それをloc-ribに渡さないか、現地の好みの変更など、何らかの方法で更新を変更することです。（入力時）またはMED（出力時）、コミュニティの追加または削除、ASパスのように電流の準備など。ポリシー処理の量（ルートマップとフィルター/アクセスリストの両方）は、収束時間に影響を与えます分散BGPアルゴリズムのプロパティ。ポリシー処理の量は、すべてのルートを受け入れ、複雑なポリシーに従ってそれらを送信する単純なポリシーから異なる場合があります。
Measurement units: Number and length of policies.
測定単位：ポリシーの数と長さ。
Issues:
問題：
See also:
参照：
Definition: According to the definition in Appendix B of RIPE-37 [RIPE37]: "The table containing the information necessary to forward IP Datagrams is called the Forwarding Information Base. At minimum, this contains the interface identifier and next hop information for each reachable destination network prefix."
定義：RIPE-37 [Ripe37]の付録Bの定義によると、「転送に必要な情報を含むテーブルは転送情報ベースと呼ばれます。宛先ネットワークプレフィックス。」
Discussion: The forwarding information base describes a database indexing network prefixes versus router port identifiers. The forwarding information base is distinct from the "routing table" (the Routing Information Base or RIB), which holds all routing information received from routing peers. It is a data plane construct and is used for the forwarding of each packet. The Forwarding Information Base is generated from the RIB. For the purposes of this document, the FIB is effectively the subset of the RIB used by the forwarding plane to make per-packet forwarding decisions. Most current implementations have full, non-cached FIBs per router interface. All the route computation and convergence occurs before entries are downloaded into a FIB.
ディスカッション：転送情報ベースでは、データベースインデックスネットワークのプレフィックスとルーターポート識別子について説明します。転送情報ベースは、「ルーティングテーブル」（ルーティング情報ベースまたはリブ）とは異なり、ルーティングピアから受け取ったすべてのルーティング情報を保持します。これはデータプレーンコンストラクトであり、各パケットの転送に使用されます。転送情報ベースはrib骨から生成されます。このドキュメントの目的のために、FIBは事実上、パケットごとの転送決定を行うために転送面で使用されるリブのサブセットです。現在のほとんどの実装には、ルーターインターフェイスごとに完全な非キャッシュされたFIBがあります。すべてのルート計算と収束は、エントリがFIBにダウンロードされる前に発生します。
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also: Route, RIB.
参照：ルート、リブ。
Definition: A BGP instance is a process with a single Loc-RIB.
定義：BGPインスタンスは、単一のloc-ribを使用したプロセスです。
Discussion: For example, a BGP instance would run in routers or test equipment. A test generator acting as multiple peers will typically run more than one instance of BGP. A router would typically run a single instance.
ディスカッション：たとえば、BGPインスタンスはルーターまたはテスト機器で実行されます。複数のピアとして機能するテストジェネレーターは、通常、BGPの複数のインスタンスを実行します。ルーターは通常、単一のインスタンスを実行します。
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also:
参照：
Definition: A BGP device is a system that has one or more BGP instances running on it, each of which is responsible for executing the BGP state machine.
定義：BGPデバイスは、1つ以上のBGPインスタンスを実行しているシステムであり、それぞれがBGPステートマシンの実行を担当しています。
Discussion: We have chosen to use "device" as the general case, to deal with the understood (e.g., [GLSSRY]) and yet-to-be-invented cases where the control processing may be separate from forwarding [RFC2918]. A BGP device may be a traditional router, a route server, a BGP-aware traffic steering device, or a non-forwarding route reflector. BGP instances such as route reflectors or servers, for example, never forward traffic, so forwarding-based measurements would be meaningless for them.
議論：「デバイス」を一般的なケースとして使用して、理解されている（例えば[glssry]）、および制御処理が転送から分離されている可能性があるまだ発明されていない場合に対処することを選択しました[RFC2918]。BGPデバイスは、従来のルーター、ルートサーバー、BGPを認識しているトラフィックステアリングデバイス、または非軌道ルートリフレクターです。たとえば、ルートリフレクターやサーバーなどのBGPインスタンスは、トラフィックを転送することはないため、転送ベースの測定は無意味です。
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also:
参照：
Definition: A BGP session is a session between two BGP instances.
定義：BGPセッションは、2つのBGPインスタンス間のセッションです。
Discussion:
議論：
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also:
参照：
Definition: An active BGP session is one that is in the established state. (See RFC 1771.)
定義：アクティブなBGPセッションは、確立された状態にあるものです。（RFC 1771を参照してください。）
Discussion:
議論：
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also:
参照：
Definition: A BGP peer is another BGP instance to which the DUT is in the Established state. (See RFC 1771.)
定義：BGPピアは、DUTが確立された状態にある別のBGPインスタンスです。（RFC 1771を参照してください。）
Discussion: In the test scenarios for the methodology discussion that will follow this document, peers send BGP advertisements to the DUT and receive DUT-originated advertisements. We recommend that the peering relation be established before tests begin. It might also be interesting to measure the time required to reach the established state. This is a protocol-specific definition, not to be confused with another frequent usage, which refers to the business/economic definition for the exchange of routes without financial compensation. It is worth noting that a BGP peer, by this definition, is associated with a BGP peering session, and there may be more than one such active session on a router or on a tester. The peering sessions referred to here may exist between various classes of BGP routers (see Section 4.2).
ディスカッション：このドキュメントに従う方法論ディスカッションのテストシナリオで、ピアはBGP広告をDUTに送信し、DUTに起因する広告を受け取ります。テストを開始する前に、ピアリング関係を確立することをお勧めします。また、確立された状態に到達するのに必要な時間を測定することも興味深いかもしれません。これはプロトコル固有の定義であり、別の頻繁な使用法と混同しないでください。これは、金融補償なしのルート交換のビジネス/経済的定義を指します。この定義により、BGPピアはBGPピアリングセッションに関連付けられており、ルーターまたはテスターに複数のアクティブセッションがある可能性があることは注目に値します。ここで言及されているピアリングセッションは、BGPルーターのさまざまなクラスの間に存在する場合があります（セクション4.2を参照）。
Measurement units: Number of BGP peers.
測定単位：BGPピア数。
Issues:
問題：
See also:
参照：
Definition: A BGP neighbor is a device that can be configured as a BGP peer.
定義：BGP隣接は、BGPピアとして構成できるデバイスです。
Discussion:
議論：
Measurement units:
測定単位：
Issues:
問題：
See also:
参照：
Definition: (Paraphrased from RFC 1771) The MRAI timer determines the minimum time between advertisements of routes to a particular destination (prefix) from a single BGP device. The timer is applied on a pre-prefix basis, although the timer is set on a per-BGP device basis.
定義：（ RFC 1771からの言い換え）MRAIタイマーは、単一のBGPデバイスから特定の宛先（プレフィックス）へのルートの広告間の最小時間を決定します。タイマーはプレフィックス前ベースで適用されますが、タイマーはBGPごとのデバイスベースで設定されています。
Discussion: Given that a BGP instance may manage in excess of 100,000 routes, RFC 1771 allows for a degree of optimization in order to limit the number of timers needed. The MRAI does not apply to routes received from BGP speakers in the same AS or to explicit withdrawals. RFC 1771 also recommends that random jitter is applied to MRAI in an attempt to avoid synchronization effects between the BGP instances in a network. In this document, we define routing plane convergence by measuring from the time an NLRI is advertised to the DUT to the time it is advertised from the DUT. Clearly any delay inserted by the MRAI will have a significant effect on this measurement.
議論：BGPインスタンスが100,000を超えるルートを管理できることを考えると、RFC 1771は、必要なタイマーの数を制限するためにある程度の最適化を可能にします。MRAIは、BGPスピーカーから受け取ったルートには、明示的な引き出しと同じで、または明示的な撤退には適用されません。RFC 1771は、ネットワーク内のBGPインスタンス間の同期効果を回避するために、ランダムジッターがMRAIに適用されることを推奨しています。このドキュメントでは、NLRIがDUTに宣伝されている時間からDUTから宣伝されている時間から測定することにより、ルーティングプレーンの収束を定義します。明らかに、MRAIによって挿入された遅延は、この測定に大きな影響を及ぼします。
Measurement units: Seconds.
測定単位：秒。
Issues:
問題：
See also: NLRI, BGP Route.
参照：NLRI、BGPルート。
Definition: The MAOI specifies the minimum interval between advertisements of locally originated routes from this BGP instance.
定義：MAOIは、このBGPインスタンスからのローカル発信ルートの広告間の最小間隔を指定します。
Discussion: Random jitter is applied to MAOI in an attempt to avoid synchronization effects between BGP instances in a network.
ディスカッション：ネットワーク内のBGPインスタンス間の同期効果を回避するために、ランダムジッターがMAOIに適用されます。
Measurement units: Seconds.
測定単位：秒。
Issues: It is not known what, if any, relationship exists between the settings of MRAI and MAOI.
問題：MRAIとMAOIの設定の間に関係がある場合は、もしあれば、何があるとしても不明です。
See also: MRAI, BGP Route.
参照：MRAI、BGPルート。
Definition: Route for which there is a FIB entry corresponding to a RIB entry.
定義：rib骨のエントリに対応するFIBエントリがあるルート。
Discussion:
議論：
Measurement units: Number of routes.
測定単位：ルート数。
Issues:
問題：
See also: RIB.
参照：リブ。
Definition: A unique route is a prefix for which there is just one route instance across all Adj-Ribs-In.
定義：一意のルートは、すべてのadj-ribs-inに1つのルートインスタンスのみがあるプレフィックスです。
Discussion:
議論：
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also: Route, Route Instance.
参照：ルート、ルートインスタンス。
Definition: A non-unique route is a prefix for which there is at least one other route in a set including more than one Adj-RIB-In.
定義：非ユニークルートは、複数のadj-rib-inを含むセットに少なくとも1つの他のルートがあるプレフィックスです。
Discussion:
議論：
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also: Route, Route Instance, Unique Active Route.
参照：ルート、ルートインスタンス、一意のアクティブルート。
Definition: A route instance is one of several possible occurrences of a route for a particular prefix.
定義：ルートインスタンスは、特定のプレフィックスのルートのいくつかの可能な発生の1つです。
Discussion: When a router has multiple peers from which it accepts routes, routes to the same prefix may be received from several peers. This is then an example of multiple route instances. Each route instance is associated with a specific peer. The BGP algorithm that arbitrates between the available candidate route instances may reject a specific route instance due to local policy.
ディスカッション：ルーターにルートを受け入れる複数のピアがある場合、同じプレフィックスへのルートが複数のピアから受信される場合があります。これは、複数のルートインスタンスの例です。各ルートインスタンスは、特定のピアに関連付けられています。利用可能な候補ルートインスタンス間で仲裁するBGPアルゴリズムは、ローカルポリシーのために特定のルートインスタンスを拒否する場合があります。
Measurement units: Number of route instances.
測定単位：ルートインスタンスの数。
Issues: The number of route instances in the Adj-RIB-In bases will vary based on the function to be performed by a router. An inter-provider border router, located in the default-free zone (see Section 4.1.4), will likely receive more route instances than a provider edge router, located closer to the end-users of the network.
問題：adj-rib-inベースのルートインスタンスの数は、ルーターによって実行される関数によって異なります。デフォルトのフリーゾーンにあるプロバイダー間のボーダールーター（セクション4.1.4を参照）は、ネットワークのエンドユーザーに近いプロバイダーエッジルーターよりも多くのルートインスタンスを受信する可能性があります。
See also:
参照：
Many terms included in this list of definitions were originally described in previous standards or papers. They are included here because of their pertinence to this discussion. Where relevant, reference is made to these sources. An effort has been made to keep this list complete with regard to the necessary concepts without over-definition.
この定義のリストに含まれる多くの用語は、もともと以前の標準または論文で説明されていました。彼らはこの議論に適しているため、ここに含まれています。関連する場合、これらのソースに参照が行われます。過剰定義なしに必要な概念に関して、このリストを完全に保つ努力がなされました。
An individual router's routing table may not necessarily contain a default route. Not having a default route, however, is not synonymous with having a full default-free table (DFT). Also, a router that has a full set of routes as in a DFT, but that also has a 'discard' rule for a default route would not be considered default free.
個々のルーターのルーティングテーブルには、必ずしもデフォルトのルートが含まれているとは限りません。ただし、デフォルトのルートを持たないことは、完全なデフォルトのテーブル（DFT）を持つことと同義ではありません。また、DFTのようにルートの完全なセットを備えたルーターもありますが、デフォルトルートの「破棄」ルールもあるルーターは、デフォルトの無料とは見なされません。
Note that in this section the references to number of routes are to routes installed in the loc-RIB, which are therefore unique routes, not route instances. Also note that the total number of route instances may be 4 to 10 times the number of routes.
このセクションでは、ルートの数への参照は、loc-ribにインストールされているルートに対するものであることに注意してください。したがって、ルートインスタンスではなく、一意のルートであることに注意してください。また、ルートインスタンスの総数はルートの4〜10倍である可能性があることに注意してください。
Definition: A default route can match any destination address. If a router does not have a more specific route for a particular packet's destination address, it forwards this packet to the next hop in the default route entry, provided that its Forwarding Table (Forwarding Information Base, or FIB, contains one). The notation for a default route for IPv4 is 0.0.0.0/0 and for IPv6 it is 0:0:0:0:0:0:0:0 or ::/0.
定義：デフォルトのルートは、任意の宛先アドレスと一致させることができます。ルーターに特定のパケットの宛先アドレスに対してより具体的なルートがない場合、その転送テーブル（転送情報ベース、またはFIBが含まれている）を条件に、デフォルトルートエントリの次のホップにこのパケットを転送します。IPv4のデフォルトルートの表記は0.0.0.0/0であり、IPv6の場合は0：0：0：0：0：0：0または::/0です。
Discussion:
議論：
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also: Default-Free Routing Table, Route, Route Instance.
参照：デフォルトのフリールーティングテーブル、ルート、ルートインスタンス。
Definition: A default-free routing table has no default routes and is typically seen in routers in the core or top tier of routers in the network.
定義：デフォルトのないルーティングテーブルにはデフォルトのルートがなく、通常、ネットワーク内のルーターのコアまたは上層のルーターに表示されます。
Discussion: The term originates from the concept that routers at the core or top tier of the Internet will not be configured with a default route (Notation in IPv4 0.0.0.0/0 and in IPv6 0:0:0:0:0:0:0:0 or ::/0). Thus they will forward every packet to a specific next hop based on the longest match between the destination IP address and the routes in the forwarding table.
ディスカッション：この用語は、インターネットのコアまたはトップ層のルーターがデフォルトのルート（IPv4 0.0.0.0.0/0およびIPv6 0：0：0：0：0：0の表記）で構成されないという概念に由来します。：0：0または::/0）。したがって、宛先IPアドレスと転送テーブルのルートとの間の最長の一致に基づいて、すべてのパケットを特定の次のホップに転送します。
Default-free routing table size is commonly used as an indicator of the magnitude of reachable Internet address space. However, default-free routing tables may also include routes internal to the router's AS.
デフォルトのないルーティングテーブルサイズは、一般に、到達可能なインターネットアドレススペースの大きさのインジケーターとして使用されます。ただし、デフォルトのないルーティングテーブルには、ルーターのASの内部ルートも含まれます。
Measurement units: The number of routes.
測定単位：ルート数。
See also: Full Default-Free Table, Default Route.
参照：完全なデフォルトのないテーブル、デフォルトルート。
Definition: A full default-free table is the union of all sets of BGP routes taken from all the default-free BGP routing tables collectively announced by the complete set of autonomous systems making up the public Internet. Due to the dynamic nature of the Internet, the exact size and composition of this table may vary slightly depending on where and when it is observed.
定義：完全なデフォルトのないテーブルは、パブリックインターネットを構成する自律システムの完全なセットによって総称されたすべてのデフォルトのないBGPルーティングテーブルから取られたすべてのBGPルートのセットの結合です。インターネットの動的な性質により、このテーブルの正確なサイズと構成は、どこで、いつ観測されるかによってわずかに異なる場合があります。
Discussion: It is generally accepted that a full table, in this usage, does not contain the infrastructure routes or individual sub-aggregates of routes that are otherwise aggregated by the provider before announcement to other autonomous systems.
議論：この使用法では、フルテーブルには、他の自律システムに発表される前にプロバイダーによって集約されているルートのインフラストラクチャルートまたは個々のサブ凝集体が含まれていないことが一般的に認められています。
Measurement units: Number of routes.
測定単位：ルート数。
Issues: The full default-free routing table is not the same as the union of all reachable unicast addresses. The table simply does not contain the default prefix (0/0) and does contain the union of all sets of BGP routes from default-free BGP routing tables.
問題：完全なデフォルトのないルーティングテーブルは、すべての到達可能なユニキャストアドレスの結合と同じではありません。テーブルには、デフォルトのプレフィックス（0/0）が含まれておらず、デフォルトのないBGPルーティングテーブルからのすべてのセットのBGPルートの結合が含まれています。
See also: Routes, Route Instances, Default Route.
参照：ルート、ルートインスタンス、デフォルトルート。
Definition: The default-free zone is the part of the Internet backbone that does not have a default route.
定義：デフォルトのフリーゾーンは、デフォルトのルートがないインターネットバックボーンの一部です。
Discussion:
議論：
Measurement units:
測定単位：
Issues:
問題：
See also: Default Route.
参照：デフォルトルート。
Definition: A full provider-internal table is a superset of the full routing table that contains infrastructure and non-aggregated routes.
定義：完全なプロバイダー内部テーブルは、インフラストラクチャと非凝集ルートを含むフルルーティングテーブルのスーパーセットです。
Discussion: Experience has shown that this table might contain 1.3 to 1.5 times the number of routes in the externally visible full table. Tables of this size, therefore, are a real-world requirement for key internal provider routers.
ディスカッション：経験によると、このテーブルには、外部から見えるフルテーブルのルートの数の1.3〜1.5倍が含まれている可能性があります。したがって、このサイズの表は、主要な内部プロバイダールーターの実際の要件です。
Measurement units: Number of routes.
測定単位：ルート数。
Issues:
問題：
See also: Routes, Route Instances, Default Route.
参照：ルート、ルートインスタンス、デフォルトルート。
A given router may perform more than one of the following functions, based on its logical location in the network.
特定のルーターは、ネットワーク内の論理的な場所に基づいて、次の関数のうち複数を実行できます。
Definition: A provider edge router is a router at the edge of a provider's network that speaks eBGP to a BGP speaker in another AS.
定義：プロバイダーエッジルーターは、プロバイダーのネットワークの端にあるルーターであり、EBGPを別のASでBGPスピーカーに話すことです。
Discussion: The traffic that transits this router may be destined to or may originate from non-adjacent autonomous systems. In particular, the MED values used in the Provider Edge Router would not be visible in the non-adjacent autonomous systems. Such a router will always speak eBGP and may speak iBGP.
議論：このルーターを通過するトラフィックは、隣接していない自律システムに運命づけられているか、または由来する可能性があります。特に、プロバイダーのエッジルーターで使用されるMED値は、隣接していない自律システムでは見えません。このようなルーターは常にEBGPを話し、IBGPを話すかもしれません。
Measurement units:
測定単位：
Issues:
問題：
See also:
参照：
Definition: A subscriber edge router is router at the edge of the subscriber's network that speaks eBGP to its provider's AS(s).
定義：サブスクライバーエッジルーターは、サブスクライバーのネットワークの端にあるルーターであり、そのプロバイダーのASにEBGPを話すことです。
Discussion: The router belongs to an end user organization that may be multi-homed, and that carries traffic only to and from that end user AS. Such a router will always speak eBGP and may speak iBGP.
ディスカッション：ルーターは、マルチホームである可能性のあるエンドユーザー組織に属し、そのエンドユーザーとの間でのみトラフィックを運ぶ可能性があります。このようなルーターは常にEBGPを話し、IBGPを話すかもしれません。
Measurement units:
測定単位：
Issues: This definition of an enterprise border router (which is what most Subscriber Edge Routers are) is practical rather than rigorous. It is meant to draw attention to the reality that many enterprises may need a BGP speaker that advertises their own routes and accepts either default alone or partial routes. In such cases, they may be interested in benchmarks that use a partial routing table, to see whether a smaller control plane processor will meet their needs.
問題：エンタープライズボーダールーターのこの定義（ほとんどのサブスクライバーエッジルーターがあります）は、厳密ではなく実用的です。多くの企業が自分のルートを宣伝し、デフォルトのみまたは部分的なルートを受け入れるBGPスピーカーを必要とする可能性があるという現実に注意を向けることを目的としています。そのような場合、彼らは部分的なルーティングテーブルを使用するベンチマークに関心があるかもしれません。より小さなコントロールプレーンプロセッサがニーズを満たすかどうかを確認します。
See also:
参照：
Definition: An inter-provider border router is a BGP speaking router that maintains BGP sessions with other BGP speaking routers in other providers' ASes.
定義：プロバイダー間ボーダールーターは、他のプロバイダーのASEで他のBGPスピーキングルーターとBGPセッションを維持するBGPスピーキングルーターです。
Discussion: Traffic transiting this router may be originated in or destined for another AS that has no direct connectivity with this provider's AS. Such a router will always speak eBGP and may speak iBGP.
ディスカッション：このルーターを通過するトラフィックは、このプロバイダーのASとの直接的な接続がないため、別のルーターに由来するか、運命づけられる場合があります。このようなルーターは常にEBGPを話し、IBGPを話すかもしれません。
Measurement units:
測定単位：
Issues:
問題：
See also:
参照：
Definition: An core router is a provider router internal to the provider's net, speaking iBGP to that provider's edge routers, other intra-provider core routers, or the provider's inter-provider border routers.
定義：コアルーターは、プロバイダーのネットの内部のプロバイダールーターであり、そのプロバイダーのエッジルーター、その他のプロバイダー内コアルーター、またはプロバイダーのプロバイダー間ボーダールーターにIBGPを話します。
Discussion: Such a router will always speak iBGP and may speak eBGP.
ディスカッション：このようなルーターは常にIBGPを話し、EBGPを話す可能性があります。
Measurement units:
測定単位：
Issues: By this definition, the DUTs that are eBGP routers aren't core routers.
問題：この定義により、EBGPルーターであるDUTはコアルーターではありません。
See also:
参照：
This section contains a sequence of definitions that build up to the definition of an update train. The packet train concept was originally introduced by Jain and Routhier [PKTTRAIN]. It is here adapted to refer to a train of packets of interest in BGP performance testing.
このセクションには、更新列車の定義に合わせて構築する一連の定義が含まれています。パケットトレインのコンセプトは、もともとJainとRouthier [Pkttrain]によって導入されました。ここでは、BGPパフォーマンステストに関心のある一連のパケットを参照するように適合しています。
This is a formalization of the sort of test stimulus that is expected as input to a DUT running BGP. This data could be a well-characterized, ordered, and timed set of hand-crafted BGP UPDATE packets. It could just as well be a set of BGP UPDATE packets that have been captured from a live router.
これは、BGPを実行しているDUTへの入力として予想される一種のテスト刺激の形式化です。このデータは、手作りされたBGPアップデートパケットの適切に特徴付けられ、順序付けられ、時限セットである可能性があります。ライブルーターからキャプチャされたBGP更新パケットのセットでもあります。
Characterization of route mixtures and update trains is an open area of research. The particular question of interest for this work is the identification of suitable update trains, modeled on or taken from live traces that reflect realistic sequences of UPDATEs and their contents.
ルート混合物と更新列車の特性評価は、研究のオープンエリアです。この作業に興味のある特定の問題は、アップデートの現実的なシーケンスとその内容を反映したライブトレースでモデル化または採取された適切な更新列車の識別です。
Definition: Route packing is the number of route prefixes accommodated in a single Routing Protocol UPDATE Message, either as updates (additions or modifications) or as withdrawals.
定義：ルートパッキングは、更新（追加または変更）または引き出しとして、単一のルーティングプロトコル更新メッセージに収容されるルートプレフィックスの数です。
Discussion: In general, a routing protocol update may contain more than one prefix. In BGP, a single UPDATE may contain two sets of multiple network prefixes: one set of additions and updates with identical attributes (the NLRI) and one set of unfeasible routes to be withdrawn.
説明：一般に、ルーティングプロトコルの更新には複数のプレフィックスが含まれる場合があります。BGPでは、単一の更新には、2つのセットの複数のネットワークプレフィックスが含まれている場合があります。1つの追加属性（NLRI）を使用した1つのセットと更新と、撤回する実行不可能なルートのセット。
Measurement units:
測定単位：
Number of prefixes.
プレフィックスの数。
Issues:
問題：
See also: Route, BGP Route, Route Instance, Update Train, NLRI.
参照：ルート、BGPルート、ルートインスタンス、更新トレイン、NLRI。
Definition: A route mixture is the demographics of a set of routes.
定義：ルート混合物は、ルートのセットの人口統計です。
Discussion: A route mixture is the input data for the benchmark. The particular route mixture used as input must be selected to suit the question being asked of the benchmark. Data containing simple route mixtures might be suitable to test the performance limits of the BGP device. Using live data or input that simulates live data will improve understanding of how the BGP device will operate in a live network. The data for this kind of test must be route mixtures that model the patterns of arriving control traffic in the live Internet. To accomplish this kind of modeling, it is necessary to identify the key parameters that characterize a live Internet route mixture. The parameters and how they interact is an open research problem. However, we identify the following as affecting the route mixture:
ディスカッション：ルート混合物は、ベンチマークの入力データです。入力として使用される特定のルート混合物は、ベンチマークについて尋ねられている質問に合わせて選択する必要があります。単純なルート混合物を含むデータは、BGPデバイスのパフォーマンス限界をテストするのに適している場合があります。ライブデータまたはライブデータをシミュレートする入力を使用すると、BGPデバイスがライブネットワークでどのように動作するかの理解が向上します。この種のテストのデータは、ライブインターネットに到着するコントロールトラフィックのパターンをモデル化するルート混合物でなければなりません。この種のモデリングを達成するには、ライブインターネットルートの混合物を特徴付ける重要なパラメーターを特定する必要があります。パラメーターとそれらがどのように相互作用するかは、オープンな研究問題です。ただし、ルート混合物に影響を与えるものとして以下を特定します。
* Path length distribution
* パス長分布
* Attribute distribution
* 属性分布
* Prefix length distribution
* プレフィックスの長さ分布
* Packet packing
* パケットパッキング
* Probability density function of inter-arrival times of UPDATES
* 更新の到着時間間の確率密度関数
Each of the items above is more complex than a single number. For example, one could consider the distribution of prefixes by AS or by length.
上記の各アイテムは、単一の数字よりも複雑です。たとえば、ASまたは長さによる接頭辞の分布を考慮することができます。
Measurement units: Probability density functions.
測定単位：確率密度関数。
Issues:
問題：
See also: NLRI, RIB.
参照：NLRI、RIB。
Definition: An update train is a set of Routing Protocol UPDATE messages sent by a router to a BGP peer.
定義：更新列車は、ルーターからBGPピアに送信されるルーティングプロトコル更新メッセージのセットです。
Discussion: The arrival pattern of UPDATEs can be influenced by many things, including TCP parameters, hold-down timers, upstream processing, a peer coming up, or multiple peers sending at the same time. Network conditions such as a local or remote peer flapping a link can also affect the arrival pattern.
ディスカッション：更新の到着パターンは、TCPパラメーター、ホールドダウンタイマー、上流の処理、ピアの登場、または同時に送信する複数のピアなど、多くのことに影響を与える可能性があります。ローカルまたはリモートピアなどのネットワーク条件は、到着パターンに影響を与える可能性があります。
Measurement units: Probability density function for the inter-arrival times of UPDATE packets in the train.
測定単位：列車内の更新パケットの到着間時間の確率密度関数。
Issues: Characterizing the profiles of real-world UPDATE trains is a matter for future research. In order to generate realistic UPDATE trains as test stimuli, a formal mathematical scheme or a proven heuristic is needed to drive the selection of prefixes. Whatever mechanism is selected, it must generate update trains that have similar characteristics to those measured in live networks.
問題：現実世界の更新列車のプロファイルを特徴付けることは、将来の研究の問題です。テスト刺激として現実的な更新列車を生成するには、接頭辞の選択を駆動するために、正式な数学スキームまたは実証済みのヒューリスティックが必要です。どんなメカニズムが選択されているとしても、ライブネットワークで測定されたものと同様の特性を持つ更新列車を生成する必要があります。
See also: Route Mixture, MRAI, MAOI.
参照：ルート混合物、MRAI、MAOI。
As we have seen from the previous sections, an update train used as a test stimulus has a considerable number of parameters that can be varied, to a greater or lesser extent, randomly and independently.
前のセクションから見たように、テスト刺激として使用される更新列車には、かなりの数のパラメーターがあり、それは多かれ少なかれ、ランダムに、そして独立して変化させることができます。
A random update train will contain a route mixture randomized across:
ランダムアップデートトレインには、ランダム化されたルート混合物が含まれます。
* NLRIs
* nlris
* updates and withdrawals
* 更新と引き出し
* prefixes
* プレフィックス
* inter-arrival times of the UPDATEs and possibly across other variables.
* 更新の到着時間と、場合によっては他の変数全体で到着します。
This is intended to simulate the unpredictable asynchronous nature of the network, whereby UPDATE packets may have arbitrary contents and be delivered at random times.
これは、ネットワークの予測不可能な非同期性をシミュレートすることを目的としています。これにより、更新パケットには任意の内容があり、ランダムな時間に配信される場合があります。
It is important that the data set be randomized sufficiently to avoid favoring one vendor's implementation over another's. Specifically, the distribution of prefixes could be structured to favor the internal organization of the routes in a particular vendor's databases. This is to be avoided.
あるベンダーの実装を他のベンダーの実装に支持しないように、データセットを十分にランダム化することが重要です。具体的には、プレフィックスの分布は、特定のベンダーのデータベース内のルートの内部組織を支持するように構成できます。これは避けるべきです。
Definition: A route flap is a change of state (withdrawal, announcement, attribute change) for a route.
定義：ルートフラップは、ルートの状態（撤退、発表、属性の変更）の変化です。
Discussion: Route flapping can be considered a special and pathological case of update trains. A practical interpretation of what may be considered excessively rapid is the RIPE 229 [RIPE229], which contains current guidelines on flap-damping parameters.
ディスカッション：ルートフラッピングは、更新列車の特別で病理学的なケースと見なすことができます。過度に迅速に考えられるものの実際的な解釈は、フラップダンプパラメーターに関する現在のガイドラインを含むRIPE 229 [Ripe229]です。
Measurement units: Flapping events per unit time.
測定単位：単位時間あたりのフラッピングイベント。
Issues: Specific Flap events can be found in Section 6.1. A bench-marker SHOULD use a mixture of different route change events in testing.
問題：特定のフラップイベントは、セクション6.1に記載されています。ベンチマーカーは、テストで異なるルート変更イベントの混合物を使用する必要があります。
See also: Route Change Events, Flap Damping, Packet Train
参照：ルート変更イベント、フラップダンピング、パケットトレイン
The following two definitions are central to the benchmarking of external routing convergence and are therefore singled out for more extensive discussion.
次の2つの定義は、外部ルーティングの収束のベンチマークの中心であるため、より広範な議論のために選ばれます。
A taxonomy characterizing routing information changes seen in operational networks is proposed in RIPE-37 [RIPE37] and Labovitz et al [INSTBLTY]. These papers describe BGP protocol-centric events and event sequences in the course of an analysis of network behavior. The terminology in the two papers categorizes similar but slightly different behaviors with some overlap. We would like to apply these taxonomies to categorize the tests under definition where possible, because these tests must tie in to phenomena that arise in actual networks. We avail ourselves of, or may extend, this terminology as necessary for this purpose.
運用ネットワークで見られるルーティング情報の変更を特徴付ける分類法は、Ripe-37 [Ripe37]およびLabovitz et al [instblty]で提案されています。これらの論文は、ネットワーク動作の分析の過程でのBGPプロトコル中心のイベントとイベントシーケンスについて説明します。2つの論文の用語は、類似しているがわずかに異なる動作を分類して、ある程度の重複を分類します。これらのテストは、可能であれば定義の下でテストを分類するためにこれらの分類法を適用したいと考えています。これらのテストは、実際のネットワークで発生する現象に結びつける必要があるからです。この目的のために必要に応じて、この用語を利用するか、または拡張するかもしれません。
A route can be changed implicitly by replacing it with another route or explicitly by withdrawal followed by the introduction of a new route. In either case, the change may be an actual change, no change, or a duplicate. The notation and definition of individual categorizable route change events is adopted from [INSTBLTY] and given below.
ルートは、別のルートに置き換えるか、新しいルートの導入により撤退して明示的に交換することにより、暗黙的に変更できます。どちらの場合でも、変更は実際の変更、変更なし、または複製である可能性があります。個々の分類可能なルート変更イベントの表記と定義は、[instblty]から採用され、以下に示されています。
1. AADiff: Implicit withdrawal of a route and replacement by a route different in some path attribute.
1. Aadiff：ルートの暗黙的な撤回と、一部のパス属性が異なるルートに置き換えます。
2. AADup: Implicit withdrawal of a route and replacement by route that is identical in all path attributes.
2. Aadup：ルートの暗黙的な撤回と、すべてのパス属性で同一のルートに置き換えられます。
3. WADiff: Explicit withdrawal of a route and replacement by a different route.
3. WADIFF：ルートの明示的な撤回と別のルートに置き換えられます。
4. WADup: Explicit withdrawal of a route and replacement by a route that is identical in all path attributes.
4. WADUP：ルートの明示的な撤回と、すべてのパス属性で同一のルートに置き換えられます。
To apply this taxonomy in the benchmarking context, we need terms to describe the sequence of events from the update train perspective, as listed above, and event indications in the time domain in order to measure activity from the perspective of the DUT. With this in mind, we incorporate and extend the definitions of [INSTBLTY] to the following:
この分類法をベンチマークのコンテキストで適用するには、上記のアップデート列車の観点からの一連のイベントを説明する用語が必要です。上記のように、DUTの観点からアクティビティを測定するために、時間領域でのイベントの表示が必要です。これを念頭に置いて、[instblty]の定義を以下に組み込み、拡張します。
1. Tup (TDx): Route advertised to the DUT by Test Device x
1. Tup（TDX）：テストデバイスxによってDUTに宣伝されたルート
2. Tdown(TDx): Route being withdrawn by Device x
2. TDown（TDX）：デバイスXによって引き出されるルート
3. Tupinit(TDx): The initial announcement of a route to a unique prefix
3. Tupinit（TDX）：一意のプレフィックスへのルートの最初の発表
4. TWF(TDx): Route fail over after an explicit withdrawal.
4. TWF（TDX）：明示的な撤回後にルートが失敗します。
But we need to take this a step further. Each of these events can involve a single route, a "short" packet train, or a "full" routing table. We further extend the notation to indicate how many routes are conveyed by the events above:
しかし、これをさらに一歩進める必要があります。これらの各イベントには、単一のルート、「短い」パケットトレイン、または「フル」ルーティングテーブルが含まれます。さらに、表記を拡張して、上記のイベントで伝えられるルートの数を示します。
1. Tup(1,TDx) means Device x sends 1 route
1. tup（1、tdx）は、デバイスxが1つのルートを送信することを意味します
2. Tup(S,TDx) means Device x sends a train, S, of routes
2. tup（s、tdx）は、デバイスxがルートの列車を送ることを意味します
3. Tup(DFT,TDx) means Device x sends an approximation of a full default-free table.
3. tup（dft、tdx）は、デバイスxが完全なデフォルトのないテーブルの近似を送信することを意味します。
The basic criterion for selecting a "better" route is the final tiebreaker defined in RFC 1771, the router ID. As a consequence, this memorandum uses the following descriptor events, which are routes selected by the BGP selection process rather than simple updates:
「より良い」ルートを選択するための基本的な基準は、RFC 1771であるルーターIDで定義されている最終的なタイブレーカーです。結果として、この覚書は、単純な更新ではなく、BGP選択プロセスによって選択されるルートである次の記述子イベントを使用します。
1. Tbest -- The current best path.
1. TBEST-現在の最高のパス。
2. Tbetter -- Advertise a path that is better than Tbest.
2. tbetter- tbestよりも優れたパスを宣伝します。
3. Tworse -- Advertise a path that is worse than Tbest.
3. Tworse- Tbestよりも悪いパスを宣伝します。
Definition: A routing device is said to have converged at the point in time when the DUT has performed all actions in the control plane needed to react to changes in topology in the context of the test condition.
定義：ルーティングデバイスは、テスト条件のコンテキストでトポロジの変化に反応するために必要な制御プレーンのすべてのアクションを実行した時点で収束したと言われています。
Discussion: For example, when considering BGP convergence, the convergence resulting from a change that alters the best route instance for a single prefix at a router would be deemed to have occurred when this route is advertised to its downstream peers. By way of contrast, OSPF convergence concludes when SPF calculations have been performed and the required link states are advertised onward. The convergence process, in general, can be subdivided into three distinct phases:
議論：たとえば、BGPの収束を考慮すると、ルーターでの単一のプレフィックスの最適なルートインスタンスを変更する変更に起因する収束は、このルートが下流のピアに宣伝されたときに発生したとみなされます。対照的に、OSPFの収束は、SPF計算が実行され、必要なリンク状態が宣伝されたときに終了します。一般に、収束プロセスは3つの異なるフェーズに細分化できます。
* convergence across the entire Internet,
* インターネット全体を横切る収束、
* convergence within an Autonomous System,
* 自律システム内の収束、
* convergence with respect to a single device.
* 単一のデバイスに関する収束。
Convergence with respect to a single device can be
単一のデバイスに関する収束があります
* convergence with regard to data forwarding process(es)
* データ転送プロセスに関する収束（es）
* convergence with regard to the routing process(es), the focus of this document.
* このドキュメントの焦点であるルーティングプロセスに関する収束。
It is the latter that we describe herein and in the methodology documents. Because we are trying to benchmark the routing protocol performance, which is only a part of the device overall, this definition is intended (as far as is possible) to exclude any additional time needed to download and install the forwarding information base in the data plane. This definition is usable for different families of protocols.
後者は、ここで、方法論文書で説明します。デバイス全体の一部であるルーティングプロトコルのパフォーマンスをベンチマークしようとしているため、この定義は（可能な限り）データプレーンの転送情報ベースをダウンロードしてインストールするために必要な追加時間を除外することを意図しています。。この定義は、プロトコルのさまざまなファミリに使用できます。
It is of key importance to benchmark the performance of each phase of convergence separately before proceeding to a composite characterization of routing convergence, where implementation-specific dependencies are allowed to interact. Care also needs to be taken to ensure that the convergence time is not influenced by policy processing on downstream peers. The time resolution needed to measure the device convergence depends to some extent on the types of the interfaces on the router. For modern routers with gigabit or faster interfaces, an individual UPDATE may be processed and re-advertised in very much less than a millisecond so that time measurements must be made to a resolution of hundreds to tens of microseconds or better.
実装固有の依存関係が相互作用することが許可されているルーティング収束の複合特性に進む前に、収束の各フェーズのパフォーマンスを個別にベンチマークすることが非常に重要です。また、収束時間が下流のピアの政策処理の影響を受けないようにするためにも注意を払う必要があります。デバイスの収束を測定するために必要な時間分解能は、ルーター上のインターフェイスのタイプにある程度依存します。ギガビットまたはより高速なインターフェイスを備えた最新のルーターの場合、個々の更新を1ミリ秒未満で処理および再承認することができるため、数百から数十マイクロ秒以上の解像度で時間測定を行う必要があります。
Measurement units:
測定単位：
Time period.
期間。
Issues:
問題：
See also:
参照：
The BGP process(es) in a device might restart because operator intervention or a power failure caused a complete shutdown. In this case, a hard reset is needed. A peering session could be lost, for example, because of action on the part of the peer or a dropped TCP session. A device can reestablish its peers and re-advertise all relevant routes in a hard reset. However, if a peer is lost, but the BGP process has not failed, BGP has mechanisms for a "soft reset."
オペレーターの介入または停電が完全なシャットダウンを引き起こしたため、デバイス内のBGPプロセス（ES）は再起動する可能性があります。この場合、ハードリセットが必要です。たとえば、ピア側でのアクションやドロップされたTCPセッションのために、ピアリングセッションが失われる可能性があります。デバイスは仲間を再確立し、ハードリセットで関連するすべてのルートを再承認できます。ただし、ピアが失われたが、BGPプロセスが失敗していない場合、BGPには「ソフトリセット」のメカニズムがあります。
Definition: An event that triggers a complete re-initialization of the routing tables on one or more BGP sessions, resulting in exchange of a full routing table on one or more links to the router.
定義：1つまたは複数のBGPセッションでルーティングテーブルの完全な再イベントをトリガーするイベントにより、ルーターへの1つまたは複数のリンクで完全なルーティングテーブルを交換します。
Discussion:
議論：
Measurement units: N.A.
測定単位：N.A。
Issues: See also:
問題：参照：
Definition: A soft reset is performed on a per-neighbor basis; it does not clear the BGP session while re-establishing the peering relation and does not stop the flow of traffic.
定義：ソフトリセットは、隣人ごとに実行されます。ピアリング関係を再確立しながらBGPセッションをクリアせず、トラフィックの流れを止めません。
Discussion: There are two methods of performing a soft reset: (1) graceful restart [GRMBGP], wherein the BGP device that has lost a peer continues to forward traffic for a period of time before tearing down the peer's routes and (2) soft refresh [RFC2918], wherein a BGP device can request a peer's Adj-RIB-Out.
ディスカッション：ソフトリセットを実行するには2つの方法があります：（1）優雅な再起動[GRMBGP]。ピアを失ったBGPデバイスは、ピアのルートを引き裂く前にトラフィックを一定期間転送し続け、（2）ソフト[RFC2918]を更新し、BGPデバイスがピアのadj-rib-outを要求できます。
Measurement units: N.A.
測定単位：N.A。
Issues:
問題：
See also:
参照：
Although this is not a complete list, all the items discussed below have a significant effect on BGP convergence. Not all of them can be addressed in the baseline measurements described in this document.
これは完全なリストではありませんが、以下で説明するすべての項目は、BGPの収束に大きな影響を及ぼします。それらのすべてが、このドキュメントで説明されているベースライン測定で対処できるわけではありません。
These factors are conditions of testing external to the router Device Under Test (DUT).
これらの要因は、テスト中のルーターデバイスの外部にテストする条件（DUT）です。
As the number of peers increases, the BGP route selection algorithm is increasingly exercised. In addition, the phasing and frequency of updates from the various peers will have an increasingly marked effect on the convergence process on a router as the number of peers grows, depending on the quantity of updates generated by each additional peer. Increasing the number of peers also increases the processing workload for TCP and BGP keepalives.
ピアの数が増えると、BGPルート選択アルゴリズムがますます行使されます。さらに、さまざまなピアからの更新のフェージングと頻度は、各追加ピアによって生成される更新の量に応じて、ピア数が増加するにつれて、ルーターに対する収束プロセスにますます顕著な影響を与えます。ピア数を増やすと、TCPおよびBGPのキープライブの処理ワークロードも増加します。
The number of routes per BGP peer is an obvious stressor to the convergence process. The number and relative proportion of multiple route instances and distinct routes being added or withdrawn by each peer will affect the convergence process, as will the mix of overlapping route instances and IGP routes.
BGPピアあたりのルート数は、収束プロセスの明らかなストレッサーです。複数のルートインスタンスの数と相対的な割合と、各ピアによって追加または撤回される異なるルートは、重複するルートインスタンスとIGPルートの混合と同様に、収束プロセスに影響します。
The number of routes and attributes being filtered and set as a fraction of the target route table size is another parameter that will affect BGP convergence.
フィルタリングされ、ターゲットルートテーブルサイズの一部として設定されているルートと属性の数は、BGP収束に影響する別のパラメーターです。
The following are extreme examples:
以下は極端な例です。
o Minimal policy: receive all, send all.
o 最小限のポリシー：すべてを受け取り、すべてを送信します。
o Extensive policy: up to 100% of the total routes have applicable policy.
o 広範なポリシー：合計ルートの最大100％が適用可能なポリシーを持っています。
There are interactions in the form of precedence, synchronization, duplication, and the addition of timers and route selection criteria. Ultimately, understanding BGP4 convergence must include an understanding of the interactions with both the IGPs and the protocols associated with the physical media, such as Ethernet, SONET, and DWDM.
優先順位、同期、重複、およびタイマーとルート選択基準の追加の形式の相互作用があります。最終的に、BGP4の収束を理解するには、イーサネット、SONET、DWDMなどの物理メディアに関連するプロトコルの両方との相互作用の理解を含める必要があります。
A router can use flap damping to respond to route flapping. Use of flap damping is not mandatory, so the decision to enable the feature, and to change parameters associated with it, can be considered a matter of routing policy.
ルーターは、フラップダンピングを使用して、ルートフラッピングに応答できます。フラップ減衰の使用は必須ではないため、機能を有効にし、それに関連するパラメーターを変更するという決定は、ルーティングポリシーの問題と見なすことができます。
The timers are defined by RFC 2439 [RFC2439] and discussed in RIPE-229 [RIPE229]. If this feature is in effect, it requires that the device keep additional state to carry out the damping, which can have a direct impact on the control plane due to increased processing. In addition, flap damping may delay the arrival of real changes in a route and affect convergence times.
タイマーはRFC 2439 [RFC2439]で定義され、RIPE-229 [Ripe229]で説明されています。この機能が有効な場合、デバイスは減衰を実行するために追加の状態を維持する必要があります。これは、処理の増加によりコントロールプレーンに直接影響を与える可能性があります。さらに、フラップ減衰は、ルートへの実際の変化の到着を遅らせ、収束時間に影響を与える可能性があります。
In theory, a BGP device could receive a set of updates that completely define the Internet and could remain in a steady state, only sending appropriate keepalives. In practice, the Internet will always be changing.
理論的には、BGPデバイスは、インターネットを完全に定義し、定常状態にとどまる可能性があり、適切なキープライブのみを送信する一連の更新を受信できます。実際には、インターネットは常に変化します。
Churn refers to control-plane processor activity caused by announcements received and sent by the router. It does not include keepalives and TCP processing.
チャーンとは、ルーターが受け取って送信した発表によって引き起こされるコントロールプレーンプロセッサアクティビティを指します。KeepaliveとTCP処理は含まれません。
Churn is caused by both normal and pathological events. For example, if an interface of the local router goes down and the associated prefix is withdrawn, that withdrawal is a normal activity, although it contributes to churn. If the local device receives a withdrawal of a route it already advertises, or an announcement of a route it did not previously know, and it re-advertises this information, these are normal constituents of churn. Routine updates can range from single announcements or withdrawals, to announcements of an entire default-free table. The latter is completely reasonable as an initialization condition.
解約は、正常イベントと病理学的イベントの両方によって引き起こされます。たとえば、ローカルルーターのインターフェイスがダウンして関連するプレフィックスが撤回された場合、その撤回は通常のアクティビティですが、チャーンに寄与します。ローカルデバイスが既に宣伝しているルートの撤回、または以前は知らなかったルートの発表を受信した場合、この情報を再承認すると、これらは通常のチャーンの構成要素です。ルーチンの更新は、単一のアナウンスまたは引き出しから、デフォルトのないテーブル全体の発表までの範囲です。後者は、初期化条件として完全に合理的です。
Flapping routes are a pathological contributor to churn, as is MED oscillation [RFC3345]. The goal of flap damping is to reduce the contribution of flapping to churn.
羽ばたきルートは、薬物振動[RFC3345]と同様に、チャーンの病理学的貢献者です。フラップ減衰の目標は、羽ばたきの寄与を解約することです。
The effect of churn on overall convergence depends on the processing power available to the control plane, and on whether the same processor(s) are used for forwarding and control.
全体的な収束に対するチャーンの効果は、コントロールプレーンが利用できる処理能力、および同じプロセッサが転送と制御に使用されるかどうかに依存します。
These factors are conditions of testing internal to the Device Under Test (DUT), although they may affect its interactions with test devices.
これらの要因は、テスト中のデバイスの内部テスト条件（DUT）ですが、テストデバイスとの相互作用に影響を与える可能性があります。
The presence of actual traffic in the device may stress the control path in some fashion if both the offered load (due to data) and the control traffic (FIB updates and downloads as a consequence of flaps) are excessive. The addition of data traffic presents a more accurate reflection of realistic operating scenarios than would be presented if only control traffic were present.
デバイス内の実際のトラフィックが存在すると、提供された負荷（データによる）と制御トラフィック（FIBの更新とフラップの結果としてのダウンロード）の両方が過剰な場合、何らかの方法で制御パスを強調する可能性があります。データトラフィックの追加は、制御トラフィックのみが存在する場合に提示されるよりも、現実的な操作シナリオをより正確に反映しています。
Settings of delay and hold-down timers at the link level, as well as for BGP4, can introduce or ameliorate delays. As part of a test report, all relevant timers MUST be reported if they use non-default values.
リンクレベルでの遅延およびホールドダウンタイマーの設定、およびBGP4の場合、遅延を導入または改善することができます。テストレポートの一環として、非デフォルト値を使用する場合は、すべての関連するタイマーを報告する必要があります。
Because all BGP traffic and interactions occur over TCP, all relevant parameters characterizing the TCP sessions MUST be provided; e.g., slow start, max window size, maximum segment size, or timers.
すべてのBGPトラフィックと相互作用はTCPで発生するため、TCPセッションを特徴付けるすべての関連パラメーターを提供する必要があります。たとえば、スロースタート、最大ウィンドウサイズ、最大セグメントサイズ、またはタイマー。
Authentication in BGP is currently done using the TCP MD5 Signature Option [RFC2385]. The processing of the MD5 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.
BGPの認証は現在、TCP MD5署名オプション[RFC2385]を使用して行われます。MD5ハッシュの処理、特に多数のBGPピアと大量の更新トラフィックを備えたデバイスでは、デバイスの制御面に影響を与える可能性があります。
The document explicitly considers authentication as a performance-affecting feature, but does not consider the overall security of the routing system.
ドキュメントは、認証をパフォーマンスに影響を与える機能と明示的に考慮していますが、ルーティングシステムの全体的なセキュリティを考慮していません。
Thanks to Francis Ovenden for review and Abha Ahuja for encouragement. Much appreciation to Jeff Haas, Matt Richardson, and Shane Wright at Nexthop for comments and input. Debby Stopp and Nick Ambrose contributed the concept of route packing.
レビューをしてくれたフランシス・オヴェンデンと励ましのアバ・アフジャに感謝します。コメントとインプットについて、NexthopのJeff Haas、Matt Richardson、およびShane Wrightに感謝します。デビー・ストップとニック・アンブローズは、ルートパッキングの概念に貢献しました。
Alvaro Retana was a key member of the team that developed this document, and made significant technical contributions regarding route mixes. The team thanks him and regards him as a co-author in spirit.
Alvaro Retanaは、このドキュメントを開発したチームの重要なメンバーであり、ルートミックスに関して重要な技術的貢献をしました。チームは彼に感謝し、彼を精神の共著者と見なします。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、Chandra、R。、およびR. Govindan、「BGP Route Flap Damping」、RFC 2439、1998年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RIPE37] Ahuja, A., Jahanian, F., Bose, A., and C. Labovitz, "An Experimental Study of Delayed Internet Routing Convergence", RIPE-37 Presentation to Routing WG, November 2000, <http://www.ripe.net/ripe/meetings/archive/ ripe-37/presentations/RIPE-37-convergence/> . [INSTBLTY] Labovitz, C., Malan, G., and F. Jahanian, "Origins of Internet Routing Instability", Infocom 99, August 1999.
[Ripe37] Ahuja、A.、Jahanian、F.、Bose、A.、およびC. Labovitz、「遅延インターネットルーティングの収束の実験的研究」、Ripe-37ルーティングWGへのプレゼンテーション、2000年11月、<http：//www.ripe.net/ripe/meetings/archive/ ripe-37/presentations/ripe-37-convergence/>。[Instblty] Labovitz、C.、Malan、G。、およびF. Jahanian、「インターネットルーティング不安定性の起源」、1999年8月。
[RFC2622] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra, M., and C. Villamizar, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.
[RFC2622] Alaettinoglu、C.、Bates、T.、Gerich、E.、Karrenberg、D.、Meyer、D.、Terpsstra、M.、およびC. Villamizar、「ルーティングポリシー仕様言語（RPSL）」、RFC 22800、1998年1月。
[RIPE229] Panigl, C., Schmitz, J., Smith, P., and C. Vistoli, "RIPE Routing-WG Recommendation for coordinated route-flap damping parameters, version 2", RIPE 229, October 2001.
[Ripe229] Panigl、C.、Schmitz、J.、Smith、P。、およびC. Vistoli、「調整されたルートフラップダンピングパラメーターのRipe Routing-WG推奨、バージョン2」、Ripe 229、2001年10月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[GLSSRY] Juniper Networks, "Junos(tm) Internet Software Configuration Guide Routing and Routing Protocols, Release 4.2", Junos 4.2 and other releases, September 2000, <http://www.juniper.net/techpubs/software/junos/junos42/ swcmdref42/html/glossary.html> . [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[Glssry]ジュニパーネットワーク、「Junos（TM）インターネットソフトウェア構成ガイドルーティングおよびルーティングプロトコル、リリース4.2 "、Junos 4.2およびその他のリリース、2000年9月、<http://www.juniper.net/techpubs/software/junos/junos42/swcmdref42/html/glossary.html>。[RFC2547] Rosen、E。およびY. Rekhter、「BGP/MPLS VPNS」、RFC 2547、1999年3月。
[PKTTRAIN] Jain, R. and S. Routhier, "Packet trains -- measurement and a new model for computer network traffic", IEEE Journal on Selected Areas in Communication 4(6), September 1986.
[Pkttrain] Jain、R。and S. Routhier、「パケットトレイン - 測定とコンピューターネットワークトラフィックの新しいモデル」、IEEEジャーナルCommunication 4（6）、1986年9月。
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[RFC2918] Chen、E。、「BGP-4のルートリフレッシュ機能」、RFC 2918、2000年9月。
[GRMBGP] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, June 2004.
[Grmbgp] Sangli、S.、Rekhter、Y.、Fernando、R.、Scudder、J。、およびE. Chen、「BGPの優雅な再起動メカニズム」、2004年6月の作業。
[BGP-4] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, March 2004.
[BGP-4] Chen、E。およびY. Rekhter、「BGP-4の協同ルートフィルタリング機能」、2004年3月、進行中の作業。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3654] Khosravi、H。およびT. Anderson、「IPコントロールと転送の分離の要件」、RFC 3654、2003年11月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345] McPherson、D.、Gill、V.、Walton、D。、およびA. Retana、「Border Gateway Protocol（BGP）持続ルート振動条件」、RFC 3345、2002年8月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC2858] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545] Marques、P。and F. Dupont、「IPv6インタードメインルーティングのBGP-4マルチプロトコル拡張の使用」、RFC 2545、1999年3月。
Authors' Addresses
著者のアドレス
Howard Berkowitz Gett Communications & CCI Training 5012 S. 25th St Arlington, VA 22206 USA
ハワードバーコウィッツゲットコミュニケーション＆CCIトレーニング5012 S. 25th St Arlington、VA 22206 USA
Phone: +1 703 998-5819
Fax: +1 703 998-5058
EMail: hcb@gettcomm.com
Elwyn B. Davies Folly Consulting The Folly Soham Cambs, CB7 5AW UK
エルウィン・B・デイビス・フォリー・コンサルティング・トゥ・ザ・フォリー・ソム・キャンブス、CB7 5AW UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Susan Hares Nexthop Technologies 825 Victors Way Ann Arbor, MI 48108 USA
スーザン・ヘールズ・ネクソップ・テクノロジーズ825ビクターズ・ウェイ・アン・アーバー、ミシガン州48108 USA
Phone: +1 734 222-1610
EMail: skh@nexthop.com
Padma Krishnaswamy SAIC 331 Newman Springs Road Red Bank, New Jersey 07701 USA
Padma Krishnaswamy Saic 331 Newman Springs Road Red Bank、ニュージャージー07701 USA
EMail: padma.krishnaswamy@saic.com
Marianne Lepp Consultant
Marianne Leppコンサルタント
EMail: mlepp@lepp.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。