Network Working Group D. McPherson
Request for Comments: 4451 Arbor Networks, Inc.
Category: Informational V. Gill
AOL
March 2006
BGP MULTI_EXIT_DISC (MED) Considerations
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.
BGP MULTI_EXIT_DISC（MED）属性は、BGPスピーカは、ローカルASに最適なエントリポイントとして隣接して搬送するための機構を提供します。 BGPののMEDは、多くのシナリオでは正しく機能しますが、動的または複雑なトポロジーでのMEDを利用する場合、多くの問題が生じる可能性があります。
This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar.
この文書では、BGPのMEDについての実装と展開の考慮事項について説明し、実装し、ネットワークオペレータはおなじみておくべき情報を提供します。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
2.1. About the MULTI_EXIT_DISC (MED) Attribute ..................3
2.2. MEDs and Potatoes ..........................................5
3. Implementation and Protocol Considerations ......................6
3.1. MULTI_EXIT_DISC Is an Optional Non-Transitive Attribute ....6
3.2. MED Values and Preferences .................................6
3.3. Comparing MEDs between Different Autonomous Systems ........7
3.4. MEDs, Route Reflection, and AS Confederations for BGP ......7
3.5. Route Flap Damping and MED Churn ...........................8
3.6. Effects of MEDs on Update Packing Efficiency ...............9
3.7. Temporal Route Selection ...................................9
4. Deployment Considerations ......................................10
4.1. Comparing MEDs between Different Autonomous Systems .......10
4.2. Effects of Aggregation on MEDs ............................11
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
The BGP MED attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.
BGP MED属性は、BGPスピーカは、ローカルASに最適なエントリーポイントとして隣接に伝えられるようにするための機構を提供します。 BGPののMEDは、多くのシナリオでは正しく機能しますが、動的または複雑なトポロジーでのMEDを利用する場合、多くの問題が生じる可能性があります。
While reading this document, note that the goal is to discuss both implementation and deployment considerations regarding BGP MEDs. In addition, the intention is to provide guidance that both implementors and network operators should be familiar with. In some instances, implementation advice varies from deployment advice.
この文書を読んでいる間、目標はBGPののMEDについての両方の実装と展開の考慮を議論することであることに注意してください。また、意図は、実装者とネットワークオペレータの両方が精通している必要がありガイダンスを提供することです。いくつかの例では、実装のアドバイスは、展開のアドバイスによって異なります。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The BGP MULTI_EXIT_DISC (MED) attribute, formerly known as the INTER_AS_METRIC, is currently defined in section 5.1.4 of [BGP4], as follows:
次のように以前INTER_AS_METRICとして知られているBGP MULTI_EXIT_DISC（MED）属性は、現在、[BGP4]のセクション5.1.4で定義されています。
The MULTI_EXIT_DISC is an optional non-transitive attribute that is intended to be used on external (inter-AS) links to discriminate among multiple exit or entry points to the same neighboring AS. The value of the MULTI_EXIT_DISC attribute is a four-octet unsigned number, called a metric. All other factors being equal, the exit point with the lower metric SHOULD be preferred. If received over External BGP (EBGP), the MULTI_EXIT_DISC attribute MAY be propagated over Internal BGP (IBGP) to other BGP speakers within the same AS (see also 9.1.2.2). The MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be propagated to other neighboring ASes.
MULTI_EXIT_DISCは同じ隣接ASに複数の出口またはエントリポイントを区別するために、外部（インターAS）リンク上で使用されることが意図されている任意の非推移的な属性です。 MULTI_EXIT_DISC属性の値は、メトリックと呼ばれる、4オクテット符号なしの数値です。他のすべての要因が等しい場合、より低いメトリックの出口点が好まれるべきです。外部BGP（EBGP）を介して受信した場合、MULTI_EXIT_DISC属性は（も9.1.2.2を参照）と同じAS内の他のBGPスピーカに内部BGP（IBGP）上で増殖させてもよいです。他の近隣のASに伝播してはならないMULTI_EXIT_DISC属性は、隣接ASから受信しました。
A BGP speaker MUST implement a mechanism (based on local configuration) that allows the MULTI_EXIT_DISC attribute to be removed from a route. If a BGP speaker is configured to remove the MULTI_EXIT_DISC attribute from a route, then this removal MUST be done prior to determining the degree of preference of the route and prior to performing route selection (Decision Process phases 1 and 2).
BGPスピーカはMULTI_EXIT_DISC属性が経路から除去することを可能にする（ローカル設定に基づいて）メカニズムを実装しなければなりません。 BGPスピーカが経路からMULTI_EXIT_DISC属性を削除するように構成されている場合、この除去は、従来の経路の優先度を決定する前ルート選択（決定プロセスのフェーズ1および2）を実行するために行われなければなりません。
An implementation MAY also (based on local configuration) alter the value of the MULTI_EXIT_DISC attribute received over EBGP. If a BGP speaker is configured to alter the value of the
実装はまた、（ローカル設定に基づいて）EBGPを介して受信MULTI_EXIT_DISC属性の値を変更することができます。 BGPスピーカはの値を変更するように構成されている場合
MULTI_EXIT_DISC attribute received over EBGP, then altering the value MUST be done prior to determining the degree of preference of the route and prior to performing route selection (Decision Process phases 1 and 2). See Section 9.1.2.2 for necessary restrictions on this.
MULTI_EXIT_DISC属性は、その値は、ルートの優先度を決定する前に経路選択実行の前に行われなければならない変更、EBGPを介して受信（決定プロセス段階1及び2）。この上必要な制限については、セクション9.1.2.2を参照してください。
Section 9.1.2.2 (c) of [BGP4] defines the following route selection criteria regarding MEDs:
[BGP4]のセクション9.1.2.2（c）は、医療検査素子に関する以下の経路選択基準を定義します。
c) Remove from consideration routes with less-preferred MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable between routes learned from the same neighboring AS (the neighboring AS is determined from the AS_PATH attribute). Routes that do not have the MULTI_EXIT_DISC attribute are considered to have the lowest possible MULTI_EXIT_DISC value.
C）以下、好ましくMULTI_EXIT_DISC属性を考慮ルートから削除。 MULTI_EXIT_DISCは同じ隣接AS（AS_PATH属性から決定される、隣接する）から学習した経路間の唯一匹敵します。 MULTI_EXIT_DISC属性を持たない経路は可能な限り低いMULTI_EXIT_DISC値を有すると考えられます。
This is also described in the following procedure:
これは、以下の手順で説明されています。
for m = all routes still under consideration for n = all routes still under consideration if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) remove route m from consideration
N =考慮中のまだすべてのルートを考慮下依然としてM =すべてのルートの（neighborAS（M）== neighborAS（N））及び（MED（N）<MED（M））は考慮から経路mを削除する場合
In the pseudo-code above, MED(n) is a function that returns the value of route n's MULTI_EXIT_DISC attribute. If route n has no MULTI_EXIT_DISC attribute, the function returns the lowest possible MULTI_EXIT_DISC value (i.e., 0).
上記の擬似コードでは、MED（n）は、NルートのMULTI_EXIT_DISC属性の値を返す関数です。ルートnはないMULTI_EXIT_DISC属性を持っていない場合、機能は可能な限り低いMULTI_EXIT_DISC値を返す（すなわち、0）。
Similarly, neighborAS(n) is a function that returns the neighbor AS from which the route was received. If the route is learned via IBGP, and the other IBGP speaker didn't originate the route, it is the neighbor AS from which the other IBGP speaker learned the route. If the route is learned via IBGP, and the other IBGP speaker either (a) originated the route, or (b) created the route by aggregation and the AS_PATH attribute of the aggregate route is either empty or begins with an AS_SET, it is the local AS.
同様に、neighborAS（n）は、ルートが受信されたASネイバーを返す関数です。ルートがIBGPによって学習され、他のIBGPスピーカーがルートを発信しなかった場合、それは他のIBGPスピーカーがルートを学んだように、そこからの隣人です。ルートがIBGPによって学習、および他のIBGPスピーカー（a）は経路を発信し、又は（b）の凝集によってルートを作成し、集約経路のAS_PATH属性が空であるか、またはAS_SETで始まるのいずれかである場合、それはローカルAS。
If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then comparison based on the received EBGP MULTI_EXIT_DISC attribute MAY still be performed. If an implementation chooses to remove MULTI_EXIT_DISC, then the optional comparison on MULTI_EXIT_DISC, if performed, MUST be performed only among EBGP-learned routes. The best EBGP-learned route may then be compared with IBGP-learned routes after the removal of the MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a subset of EBGP-learned routes, and the selected "best" EBGP-learned route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC must be used in the comparison with IBGP-learned routes. For IBGP-learned routes, the MULTI_EXIT_DISC MUST be used in route comparisons that reach this step in the Decision Process. Including the MULTI_EXIT_DISC of an EBGP-learned route in the comparison with an IBGP-learned route, then removing the MULTI_EXIT_DISC attribute, and advertising the route has been proven to cause route loops.
MULTI_EXIT_DISC属性はIBGPへの再広告するルートの前に削除された場合は、受信したEBGP MULTI_EXIT_DISC属性に基づく比較はまだ行われてもよいです。実装はMULTI_EXIT_DISC、MULTI_EXIT_DISCに次にオプションの比較を削除することを選択した場合、実行した場合、EBGP、学習した経路間のみ実行されなければなりません。最高のEBGP学習ルートは、MULTI_EXIT_DISC属性を除去した後のIBGP、学習されたルートと比較してもよいです。 MULTI_EXIT_DISCはEBGP、学習されたルートのサブセットから除去され、選択された「ベスト」EBGP学習ルートはMULTI_EXIT_DISCは削除していない場合は、その後、MULTI_EXIT_DISCはIBGP、学習されたルートと比較して使用する必要があります。 IBGP学習経路について、MULTI_EXIT_DISCは、決定プロセスのこの段階に達する経路の比較で使用されなければなりません。その後、MULTI_EXIT_DISC属性を削除し、ルートの広告を出し、IBGP学習ルートと比較して、EBGP学習ルートのMULTI_EXIT_DISCを含めて、ルートループを引き起こすことが証明されています。
Let's consider a situation where traffic flows between a pair of hosts, each connected to a different transit network, which is in itself interconnected at two or more locations. Each transit network has the choice of either sending traffic to the closest peering to the adjacent transit network or passing traffic to the interconnection location that advertises the least-cost path to the destination host.
トラフィックがホスト、それ自体が2箇所以上で相互接続されている別の中継網に接続された各対の間を流れるような状況を考えてみましょう。各トランジットネットワークは、隣接する中継網に最も近いピアにトラフィックを送信または宛先ホストへの最小コストの経路をアドバタイズ配線位置にトラフィックを通過させるいずれかの選択肢を有します。
The former method is called "hot potato routing" (or closest-exit) because like a hot potato held in bare hands, whoever has it tries to get rid of it quickly. Hot potato routing is accomplished by not passing the EBGP-learned MED into IBGP. This minimizes transit traffic for the provider routing the traffic. Far less common is "cold potato routing" (or best-exit) where the transit provider uses its own transit capacity to get the traffic to the point that adjacent transit provider advertised as being closest to the destination. Cold potato routing is accomplished by passing the EBGP-learned MED into IBGP.
素手で開催されたホットポテトのように、誰でもそれを持っていることはすぐにそれを取り除くしようとするため、前者の方法は、「ホットポテトルーティング」（または最も近い出口）と呼ばれています。ホットポテトルーティングはIBGPにEBGP学習MEDを渡していないことによって達成されます。これは、トラフィックをルーティングするプロバイダの通過トラフィックを最小限に抑えることができます。トランジット・プロバイダが隣接トランジットプロバイダが先に最も近いものとしてアドバタイズする点へのトラフィックを取得するために、独自の輸送能力を使用する場合にはるかに少ない共通の「冷たいポテトルーティング」（または最良の出口）です。冷たいポテトルーティングはIBGPにEBGP学習MEDを通過させることによって達成されます。
If one transit provider uses hot potato routing and another uses cold potato, traffic between the two tends to be more symmetric. However, if both providers employ cold potato routing or hot potato routing between their networks, it's likely that a larger amount of asymmetry would exist.
1つのトランジットプロバイダはホットポテトルーティングを使用し、別の冷たいジャガイモを使用している場合、両者の間のトラフィックは、より対称的になる傾向があります。両方のプロバイダが自社のネットワークとの間に冷たいポテトルーティングやホットポテトルーティングを採用する場合は、それが非対称の大きな量が存在するであろうと考えられます。
Depending on the business relationships, if one provider has more capacity or a significantly less congested backbone network, then that provider may use cold potato routing. An example of widespread use of cold potato routing was the NSF-funded NSFNET backbone and NSF-funded regional networks in the mid-1990s.
1つのプロバイダは、より多くの容量または大幅に少なく混雑バックボーンネットワークを持っている場合は、ビジネスの関係によっては、そのプロバイダは冷たいポテトルーティングを使用することができます。冷たいポテトルーティングの普及の例は、NSFが資金提供NSFNETバックボーンと、1990年代半ばにおけるNSFの資金による地域ネットワークでした。
In some cases, a provider may use hot potato routing for some destinations for a given peer AS and cold potato routing for others. An example of this is the different treatment of commercial and research traffic in the NSFNET in the mid-1990s. Today, many commercial networks exchange MEDs with customers but not with bilateral peers. However, commercial use of MEDs varies widely, from ubiquitous use to none at all.
いくつかのケースでは、プロバイダは、他と同様に、所与のピアと冷たいポテトルーティングのためのいくつかの地域にホットポテトルーティングを使用することができます。この例では、1990年代半ばにおけるNSFNETの商業および研究トラフィックの異なる治療法です。今日では、顧客とのではなく、二国間の仲間と多くの商用ネットワークの交換のMED。しかし、のMEDの商用利用は全くユビキタス使用から誰にも負けない、大きく異なります。
In addition, many deployments of MEDs today are likely behaving differently (e.g., resulting in sub-optimal routing) than the network operator intended, which results not in hot or cold potatoes, but mashed potatoes! More information on unintended behavior resulting from MEDs is provided throughout this document.
また、のMEDの多くの配備今日はおそらく異なる動作をされている（例えば、サブ最適なルーティングを生じる）高温または低温ジャガイモでない結果意図ネットワークオペレータ、よりますが、マッシュポテト！ MED起因する予期しない動作の詳細については、この文書を通じて提供されます。
There are a number of implementation and protocol peculiarities relating to MEDs that have been discovered that may affect network behavior. The following sections provide information on these issues.
ネットワークの動作に影響を与えることが発見されているのMEDに関連する実装とプロトコル特殊性の数があります。次のセクションでは、これらの問題に関する情報を提供しています。
MULTI_EXIT_DISC is a non-transitive optional attribute whose advertisement to both IBGP and EBGP peers is discretionary. As a result, some implementations enable sending of MEDs to IBGP peers by default, while others do not. This behavior may result in sub-optimal route selection within an AS. In addition, some implementations send MEDs to EBGP peers by default, while others do not. This behavior may result in sub-optimal inter-domain route selection.
MULTI_EXIT_DISCは、その広告の両方IBGPとEBGPピアに任意で非推移オプションの属性です。その結果、いくつかの実装は、他の人がいない間、デフォルトでピアをIBGPするのMEDの送信を可能にします。この現象は、AS内のサブ最適経路選択をもたらすことができます。他の人がいない間加えて、いくつかの実装では、デフォルトではEBGPピアするためのMEDを送ります。この動作は、次善のドメイン間のルート選択をもたらすことができます。
Some implementations consider an MED value of zero less preferable than no MED value. This behavior resulted in path selection inconsistencies within an AS. The current version of the BGP specification [BGP4] removes ambiguities that existed in [RFC1771] by stating that if route n has no MULTI_EXIT_DISC attribute, the lowest possible MULTI_EXIT_DISC value (i.e., 0) should be assigned to the attribute.
いくつかの実装はないMED値よりゼロのMED値はあまり好ましい考えます。この動作は、AS内のパス選択の不整合が生じました。 BGP仕様[BGP4]の現在のバージョンは、ルートnはないMULTI_EXIT_DISC属性を、可能な限り低いMULTI_EXIT_DISC値を有していない場合（即ち、0）属性に割り当てられるべきであることを示すことによって、[RFC1771]に存在する曖昧さを除去します。
It is apparent that different implementations and different versions of the BGP specification have been all over the map with interpretation of missing-MED. For example, earlier versions of the specification called for a missing MED to be assigned the highest possible MED value (i.e., 2^32-1).
異なる実装とBGPの仕様の異なるバージョンが存在しない-MEDの解釈とマップ上のすべてをされていることは明らかです。例えば、欠落MEDを求め仕様の以前のバージョンは、可能な限り高いMED値を割り当てることができる（すなわち、2 ^ 32-1）。
In addition, some implementations have been shown to internally employ a maximum possible MED value (2^32-1) as an "infinity" metric (i.e., the MED value is used to tag routes as unfeasible); upon receiving an update with an MED value of 2^32-1, they would rewrite the value to 2^32-2. Subsequently, the new MED value would be propagated and could result in routing inconsistencies or unintended path selections.
加えて、いくつかの実装形態（すなわち、MED値を不可能としてルートにタグを付けるために使用される）、「無限」メトリックとして最大可能MED値（^ 32-1 2）を採用し、内部に示されています。 2 ^ 32-1のMED値で更新を受信すると、彼らは2 ^ 32-2の値を書き換えます。その後、新しいMED値が伝播されるだろうし、ルーティング矛盾または意図しないパスの選択につながる可能性があります。
As a result of implementation inconsistencies and protocol revision variances, many network operators today explicitly reset (i.e., set to zero or some other 'fixed' value) all MED values on ingress to conform to their internal routing policies (i.e., to include policy that requires that MED values of 0 and 2^32-1 not be used in configurations, whether the MEDs are directly computed or configured), so as not to have to rely on all their routers having the same missing-MED behavior.
実装の矛盾やプロトコルリビジョン分散の結果として、多くのネットワークオペレータは、今日が明示的に（つまり、ゼロまたはいくつかの他の「固定」の値に設定）リセットすべての入力のMED値は、そのポリシーが含まれるように、内部ルーティングポリシー（すなわち、に合致しますすべてのルータが同じ欠落-MED挙動を有することに依存する必要がないように、0から2 ^ 32-1のMED値は、）医療検査素子が直接計算又は構成されているかどうか、構成で使用されないことを要求します。
Because implementations don't normally provide a mechanism to disable MED comparisons in the decision algorithm, "not using MEDs" usually entails explicitly setting all MEDs to some fixed value upon ingress to the routing domain. By assigning a fixed MED value consistently to all routes across the network, MEDs are a effectively a non-issue in the decision algorithm.
実装は、通常、通常、明示的にルーティングドメインへの進入時にいくつかの固定値へのすべてのMEDを設定することを伴う「のMEDを使用していない」、決定アルゴリズムでMED比較を無効にするメカニズムを提供していないので。ネットワーク全体のすべてのルートに一貫して固定されたMED値を割り当てることによって、医療検査素子は、決定アルゴリズムにおける効率的非問題です。
The MED was intended to be used on external (inter-AS) links to discriminate among multiple exit or entry points to the same neighboring AS. However, a large number of MED applications now employ MEDs for the purpose of determining route preference between like routes received from different autonomous systems.
MEDは、同じ隣接ASに複数の出口またはエントリポイントを区別するために、外部（インターAS）リンク上で使用されるように意図されていました。しかし、MEDアプリケーションの多数は、現在、異なる自律システムから受信したような経路間の経路優先度を決定する目的のために医療検査素子を採用しています。
A large number of implementations provide the capability to enable comparison of MEDs between routes received from different neighboring autonomous systems. While this capability has demonstrated some benefit (e.g., that described in [RFC3345]), operators should be wary of the potential side effects of enabling such a function. The deployment section below provides some examples as to why this may result in undesirable behavior.
実装多数の異なる隣接自律システムから受信した経路間のMEDの比較を可能にする能力を提供します。この機能は、いくつかの利点を実証しているが（例えば、[RFC3345]に記載されている）、オペレータは、このような機能を可能にする潜在的な副作用を警戒しなければなりません。以下の展開部は、これは望ましくない動作を引き起こすことができる理由として、いくつかの例を提供します。
In particular configurations, the BGP scaling mechanisms defined in "BGP Route Reflection - An Alternative to Full Mesh IBGP" [RFC2796] and "Autonomous System Confederations for BGP" [RFC3065] will introduce persistent BGP route oscillation [RFC3345]. The problem is inherent in the way BGP works: a conflict exists between information hiding/hierarchy and the non-hierarchical selection process imposed by lack of total ordering caused by the MED rules. Given current practices, we see the problem manifest itself most frequently in the context of MED + route reflectors or confederations.
特定の構成では、BGPは、「BGPルートリフレクション - フルメッシュIBGPの代替」で定義されたメカニズムをスケーリング[RFC2796]及び「BGPのための自律システム同盟」[RFC3065]は永続的なBGPルート発振[RFC3345]を紹介します。コンフリクトは、情報隠蔽/階層とMEDルールによって引き起こされる全体の順序付けの欠如によって課される非階層的選択プロセスの間に存在する：問題は、BGPの動作方法に固有のものです。現在の慣行を考えると、我々は問題がMED +のルートリフレクタや同盟の文脈の中で最も頻繁に現れる参照してください。
One potential way to avoid this is by configuring inter-Member-AS or inter-cluster IGP metrics higher than intra-Member-AS IGP metrics and/or using other tie-breaking policies to avoid BGP route selection based on incomparable MEDs. Of course, IGP metric constraints may be unreasonably onerous for some applications.
これを回避する1つの潜在的な方法は、イントラメンバー-AS IGPメトリックよりも高い間メンバー-ASまたはクラスタ間のIGPメトリックを設定し、および/または無類のMEDに基づいてBGPルート選択を避けるために、他のタイブレークポリシーを使用することです。もちろん、IGPメトリック制約がいくつかのアプリケーションのために不当に厄介かもしれません。
Not comparing MEDs between multiple paths for a prefix learned from different adjacent autonomous systems, as discussed in section 2.3, or not utilizing MEDs at all, significantly decreases the probability of introducing potential route oscillation conditions into the network.
セクション2.3で議論するように、異なる隣接自律システムから学んだプレフィックスに対して複数のパス間でMEDを比較しない、またはまったく医療検査素子を利用しない、著しくネットワークに潜在的経路発振条件を導入する可能性を減少させます。
Although perhaps "legal" as far as current specifications are concerned, modifying MED attributes received on any type of IBGP session (e.g., standard IBGP, EBGP sessions between Member-ASes of a BGP confederation, route reflection, etc.) is not recommended.
おそらく「合法」限り現在の仕様が関係しているが、変更MEDはIBGPセッションの任意のタイプで受信された属性（例えば、標準IBGPは、BGP連合のメンバーAS間EBGPセッションは、ルートリフレクション、等）が推奨されません。
MEDs are often derived dynamically from IGP metrics or additive costs associated with an IGP metric to a given BGP NEXT_HOP. This typically provides an efficient model for ensuring that the BGP MED advertised to peers, used to represent the best path to a given destination within the network, is aligned with that of the IGP within a given AS.
医療検査素子は、多くの場合、IGPメトリックまたは所与のBGP NEXT_HOPにIGPメトリックに関連付けられた添加剤のコストから動的に導出されます。これは、典型的にはBGP MEDピアにアドバタイズすることを確保するための効率的なモデルを提供し、ネットワーク内の指定された宛先への最適なパスを表すために使用される、として与えられた内IGPのそれと整合されます。
The consequence with dynamically derived IGP-based MEDs is that instability within an AS, or even on a single given link within the AS, can result in widespread BGP instability or BGP route advertisement churn that propagates across multiple domains. In short, if your MED "flaps" every time your IGP metric flaps, your routes are likely going to be suppressed as a result of BGP Route Flap Damping [RFC2439].
動的に由来IGPベースの医療検査素子との結果はAS内、あるいはAS内の単一の所与のリンク上の不安定性は、広範BGP不安定または複数のドメインを横切って伝播BGPルート広告解約をもたらすことができることです。要するに、あなたのMED「フラップ」するたびに、あなたのIGPメトリックフラップは、あなたのルートはおそらくBGPルートフラップダンピング[RFC2439]の結果として抑制しようとしている場合。
Employment of MEDs may compound the adverse effects of BGP flap-dampening behavior because it may cause routes to be re-advertised solely to reflect an internal topology change.
それはルートがもっぱら内部トポロジの変更を反映するために再アドバタイズされる原因となりますのでのMEDの雇用は、BGPフラップ・ダンプニング行動の悪影響を配合します。
Many implementations don't have a practical problem with IGP flapping; they either latch their IGP metric upon first advertisement or employ some internal suppression mechanism. Some implementations regard BGP attribute changes as less significant than route withdrawals and announcements to attempt to mitigate the impact of this type of event.
多くの実装では、IGPフラッピングと実用的な問題はありません。彼らは、最初の広告時に彼らのIGPメトリックをラッチするか、いくつかの内部抑制機構を採用してどちらか。いくつかの実装では、BGPルートの引き出しと、このタイプのイベントの影響を軽減しようとすると発表未満を有意と属性変更を考えています。
Multiple unfeasible routes can be advertised in a single BGP Update message. The BGP4 protocol also permits advertisement of multiple prefixes with a common set of path attributes to be advertised in a single update message. This is commonly referred to as "update packing". When possible, update packing is recommended as it provides a mechanism for more efficient behavior in a number of areas, including the following:
複数不可能ルートが単一のBGPアップデートメッセージでアドバタイズすることができます。パスの共通セットが単一の更新メッセージでアドバタイズされる属性とBGP4プロトコルは、複数のプレフィックスの広告を可能にします。これは一般に「アップデートのパッキング」と呼ばれています。可能な場合には、以下を含む多くの分野でのより効率的な動作のためのメカニズムを提供して、更新パックをお勧めします。
o Reduction in system overhead due to generation or receipt of fewer Update messages.
世代またはそれ以下の更新メッセージを受信したことに起因するシステムオーバーヘッドのO削減。
o Reduction in network overhead as a result of fewer packets and lower bandwidth consumption.
少ないパケットおよび低帯域幅消費の結果としてネットワークオーバーヘッドのO削減。
o Less frequent processing of path attributes and searches for matching sets in your AS_PATH database (if you have one). Consistent ordering of the path attributes allows for ease of matching in the database as you don't have different representations of the same data.
（お持ちの場合）Oパスの頻度が少ない処理は、あなたのAS_PATHデータベースのセットを整合させるための属性と検索します。パス属性の一貫性の順序は、同じデータの異なる表現を持っていないとしてデータベースにマッチングを容易にします。
Update packing requires that all feasible routes within a single update message share a common attribute set, to include a common MULTI_EXIT_DISC value. As such, potential wide-scale variance in MED values introduces another variable and may result in a marked decrease in update packing efficiency.
アップデートパッキングは、単一のアップデートメッセージを共有内のすべての実行可能なルート共通の属性セットは、共通MULTI_EXIT_DISC値を含めるようにする必要があります。このように、MED値の潜在的大規模な分散は、別の変数を導入し、更新充填効率の著しい低下をもたらすことができます。
Some implementations had bugs that led to temporal behavior in MED-based best path selection. These usually involved methods to store the oldest route and to order routes for MED, which caused non-deterministic behavior as to whether or not the oldest route would truly be selected.
いくつかの実装では、MED-基づいて最適パス選択の時間的行動につながったバグを持っていました。これら通常関与する方法は、最も古いルートを記憶し、最も古い経路が真に選択されるか否かなどの非決定論的挙動を引き起こしMEDのルートを、注文します。
The reasoning for this is that older paths are presumably more stable, and thus preferable. However, temporal behavior in route selection results in non-deterministic behavior and, as such, is often undesirable.
このための理由は、古いパスは、おそらくより安定し、したがって、好ましいことです。しかし、非決定論的行動における経路選択の結果では、時間的挙動と、のような、望ましくない場合が多いです。
It has been discussed that accepting MEDs from other autonomous systems has the potential to cause traffic flow churns in the network. Some implementations only ratchet down the MED and never move it back up to prevent excessive churn.
他の自律システムからの受諾のMEDは、ネットワーク内のトラフィックフローの大量生産で有名を引き起こす可能性があることを議論してきました。いくつかの実装では、唯一のMEDをダウンラチェットと過度の解約を防ぐためにバックアップそれを動かすことはありません。
However, if a session is reset, the MEDs being advertised have the potential of changing. If a network is relying on received MEDs to route traffic properly, the traffic patterns have the potential for changing dramatically, potentially resulting in congestion on the network. Essentially, accepting and routing traffic based on MEDs allows other people to traffic engineer your network. This may or may not be acceptable to you.
セッションがリセットされている場合は、公示されているのMEDは、変更の可能性を秘めています。ネットワークが正常にトラフィックをルーティングするために受け取ったのMEDに頼っている場合は、トラフィックパターンは、潜在的にネットワーク上の混雑で、その結果、劇的に変える可能性を持っています。基本的に、医療検査素子に基づいて受け入れ、ルーティングトラフィックはトラフィックに他の人があなたのネットワークを設計できます。これは、またはあなたに許容可能であってもなくてもよいです。
As previously discussed, many network operators choose to reset MED values on ingress. In addition, many operators explicitly do not employ MED values of 0 or 2^32-1 in order to avoid inconsistencies with implementations and various revisions of the BGP specification.
前述したように、多くのネットワークオペレータは、入力上のMED値をリセットすることを選択しました。また、多くの事業者は、明示的に実装し、BGPの仕様の様々な改訂と不整合を回避するために、0または2 ^ 32-1のMED値を採用していません。
Although the MED was meant to be used only when comparing paths received from different external peers in the same AS, many implementations provide the capability to compare MEDs between different autonomous systems as well. AS operators often use LOCAL_PREF to select the external preferences (primary, secondary upstreams, peers, customers, etc.), using MED instead of LOCAL_PREF would possibly lead to an inconsistent distribution of best routes, as MED is compared only after the AS_PATH length.
MEDを比較するパスが同じASに異なる外部ピアから受信した場合にのみ使用されることを意図しているが、多くの実装は、同様に異なる自律システム間のMEDを比較する能力を提供します。事業者は、多くの場合、MEDは唯一のAS_PATHの長さの後に比較される代わりに、LOCAL_PREFのMEDはおそらく、最適なルートの一貫性のない分布につながる使用して、外部の環境設定（プライマリ、セカンダリアップストリーム、同僚、顧客、など）を選択するLOCAL_PREFを使用しています。
Though this may seem like a fine idea for some configurations, care must be taken when comparing MEDs between different autonomous systems. BGP speakers often derive MED values by obtaining the IGP metric associated with reaching a given BGP NEXT_HOP within the local AS. This allows MEDs to reasonably reflect IGP topologies when advertising routes to peers. While this is fine when comparing MEDs between multiple paths learned from a single AS, it can result in potentially "weighted" decisions when comparing MEDs between different autonomous systems. This is most typically the case when the autonomous systems use different mechanisms to derive IGP metrics or BGP MEDs, or when they perhaps even use different IGP protocols with vastly contrasting metric spaces (e.g., OSPF vs. traditional metric space in IS-IS).
これは、いくつかの構成の細かいアイデアのように思えるかもしれないが異なる自律システム間でのMEDを比較する際、注意が必要です。 BGPスピーカは、多くの場合、ローカルAS内の所定BGP NEXT_HOPに達するに関連付けられているIGPメトリックを取得することによって、MED値を導き出します。これは、ピアへのルートをアドバタイズするときのMEDは、合理的IGPトポロジを反映することができます。単一ASから学んだ複数のパス間でMEDを比較するとき、これが細かいですが異なる自律システム間でのMEDを比較するとき、それは潜在的に「加重」の意思決定につながることができます。これは、彼らがおそらく非常に対照的な距離空間（IS-ISで、例えば、OSPF対伝統的な距離空間）と異なるIGPプロトコルを使用する際に自律システムは、IGPメトリックやBGPのMEDを導き出すために異なるメカニズムを使用する場合、または最も典型的なケースです。
Another MED deployment consideration involves the impact that aggregation of BGP routing information has on MEDs. Aggregates are often generated from multiple locations in an AS in order to accommodate stability, redundancy, and other network design goals. When MEDs are derived from IGP metrics associated with said aggregates, the MED value advertised to peers can result in very suboptimal routing.
別のMED配備の考慮事項は、BGPルーティング情報の集合が医療検査素子に与える影響を含みます。凝集体は、多くの場合、安定性、冗長性、およびその他のネットワーク設計目標に対応するために、AS内の複数の場所から生成されています。医療検査素子は、前記凝集体に関連したIGPメトリックから導出されている場合、ピアにアドバタイズMED値が非常に準最適ルーティングをもたらすことができます。
The MED was purposely designed to be a "weak" metric that would only be used late in the best-path decision process. The BGP working group was concerned that any metric specified by a remote operator would only affect routing in a local AS if no other preference was specified. A paramount goal of the design of the MED was to ensure that peers could not "shed" or "absorb" traffic for networks that they advertise. As such, accepting MEDs from peers may in some sense increase a network's susceptibility to exploitation by peers.
MEDは、意図的に、最高のパス決定プロセスの後半で使用される「弱い」メトリックなるように設計されました。 BGPワーキンググループは、他の優先を指定しなかったかのように遠隔操作で指定されたメトリックは、ローカルにルーティング影響を与えることを懸念しました。 MEDの設計の最も重要な目標は、ピアは「小屋」や、彼らが宣伝のためにネットワークトラフィックを「吸収」ことができなかったことを確実にするためでした。このように、ピアから受け入れる医療検査素子は、ある意味でピアによって搾取にネットワークの感受性を増加させることができます。
Thanks to John Scudder for applying his usual keen eye and constructive insight. Also, thanks to Curtis Villamizar, JR Mitchell, and Pekka Savola for their valuable feedback.
彼のいつもの鋭い目と建設的な洞察力を与えるためのジョン・スカダーに感謝します。また、彼らの貴重なフィードバックのためのカーティスVillamizar、JRミッチェル、およびペッカSavolaに感謝。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC2796]ベイツ、T.、チャンドラ、R.、およびE.チェン、 "BGPルートリフレクション - フルメッシュIBGPへの代替"、RFC 2796、2000年4月。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[RFC3065] Trainaの、P.、マクファーソン、D.、およびJ.スカダー、 "BGPのための自律システム同盟"、RFC 3065、2001年2月。
[BGP4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP4] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP4）"、RFC 4271、2006年1月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、チャンドラ、R.、およびR.ゴヴィンダン、 "BGPルートフラップダンピング"、RFC 2439、1998年11月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345]マクファーソン、D.、ギル、V.、ウォルトン、D.、およびA. Retana、 "ボーダーゲートウェイプロトコル（BGP）永続的なルート発振条件"、RFC 3345、2002年8月。
Authors' Addresses
著者のアドレス
Danny McPherson Arbor Networks
ダニー・マクファーソンアーバーネットワークス
EMail: danny@arbor.net
メールアドレス：danny@arbor.net
Vijay Gill AOL
ビジェイ・ギルAOL
EMail: VijayGill9@aol.com
メールアドレス：VijayGill9@aol.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。