[要約] 要約： RFC 4451は、BGPのMULTI_EXIT_DISC（MED）属性に関する考慮事項を提供しています。このRFCは、MED属性の使用方法とその影響について説明しています。目的： RFC 4451の目的は、BGPのMED属性の使用に関するガイドラインを提供し、ネットワークエンジニアが効果的にMEDを使用できるようにすることです。また、MED属性の使用に関連する問題や制約についても説明しています。
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
BGP Multi_exit_disc（med）考慮事項
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).
Copyright（c）The Internet Society（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 MEDSは正しく機能しますが、動的または複雑なトポロジーで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 MEDSは正しく機能しますが、動的または複雑なトポロジーで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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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は、外部（inter-as）リンクで使用することを目的としたオプションの非転写属性です。Multi_exit_disc属性の値は、メトリックと呼ばれる4-OCTETの符号なし番号です。他のすべての要因が等しいため、メートリックが低い出口ポイントを優先する必要があります。外部BGP（EBGP）を介して受信した場合、Multi_Exit_Disc属性は、内部BGP（IBGP）を介して他のBGPスピーカーと同じように伝播する場合があります（9.1.2.2も参照）。近隣から受け取ったMulti_exit_disc属性は、他の隣接するASEに伝播してはなりません。
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 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.
また、実装は（ローカル構成に基づいて）EBGPを介して受信したmulti_exit_disc属性の値を変更する場合があります。BGPスピーカーがEBGPを介して受信したMulti_Exit_Disc属性の値を変更するように構成されている場合、ルートの好みの程度を決定し、ルート選択を実行する前に値を変更する必要があります（決定プロセスフェーズ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）は、MEDに関する次のルート選択基準を定義しています。
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) PREFEREDが少ないMulti_Exit_Disc属性を持つ対価ルートから削除します。Multi_exit_discは、同じ隣接する（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
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）は、Route 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）は、ルートが受信されたように隣人を返す関数です。ルートが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.
IBGPへのルートを再承認する前にmulti_exit_disc属性が削除された場合、受信したEBGP multi_exit_disc属性に基づいて比較が実行される場合があります。実装がMulti_Exit_Discを削除することを選択した場合、Multi_Exit_Discのオプションの比較は、実行された場合、EBGP学習ルート間でのみ実行する必要があります。Multi_exit_disc属性を削除した後、最適なEBGP学習ルートをIBGP学習ルートと比較できます。Multi_exit_discがEBGP学習ルートのサブセットから削除され、選択された「最高の」EBGP学習ルートにmulti_exit_discが削除されていない場合、IBGP学習ルートと比較してMulti_exit_discを使用する必要があります。IBGP学習ルートの場合、Multi_exit_discを、決定プロセスでこのステップに到達するルート比較で使用する必要があります。IBGP学習ルートとの比較でEBGP学習ルートのMulti_exit_discを含め、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.
前者の方法は「ホットポテトルーティング」（または最も近い排除）と呼ばれます。なぜなら、裸の手で抱いているホットポテトのように、それをすぐに取り除こうとする人は誰でも。ホットポテトルーティングは、EBGP学習の薬をIBGPに渡さないことで達成されます。これにより、トラフィックをルーティングするプロバイダーのトランジットトラフィックが最小化されます。それほど一般的ではない「コールドポテトルーティング」（またはベストエキシット）は、輸送プロバイダーが独自のトランジット容量を使用して、隣接するトランジットプロバイダーが目的地に最も近いと宣伝するポイントまでトラフィックを獲得します。コールドポテトルーティングは、EBGP学習の薬をIBGPに渡すことによって達成されます。
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つのトランジットプロバイダーがホットポテトルーティングを使用し、別のトランジットプロバイダーがコールドポテトを使用している場合、2つの間の交通はより対称的になる傾向があります。ただし、両方のプロバイダーがネットワーク間でコールドポテトルーティングまたはホットポテトルーティングを使用している場合、より多くの非対称性が存在する可能性があります。
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つのプロバイダーがより多くの容量を持っているか、混雑したバックボーンネットワークが大幅に少ない場合、そのプロバイダーはコールドポテトルーティングを使用する場合があります。コールドポテトルーティングの広範な使用の例は、1990年代半ばのNSFが資金提供したNSFNETバックボーンと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の商業および研究トラフィックのさまざまな扱いです。今日、多くの商業ネットワークは顧客と交換しますが、二国間仲間とは交換していません。ただし、医療の商業的使用は、ユビキタスな使用からまったくまったく存在せずに大きく異なります。
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).
Missing-Medの解釈とともに、さまざまな実装とBGP仕様の異なるバージョンがマップ全体に存在していることは明らかです。たとえば、仕様の以前のバージョンでは、不足している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値（2^32-1）を内部的に使用することが示されています（つまり、MED値は、ルートを実行不可能としてタグ付けするために使用されます）。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.
実装の不一致とプロトコルリビジョンの分散の結果として、多くのネットワークオペレーターは今日明示的にリセットされます（つまり、ゼロまたは他の「固定」値に設定されています）。0および2^32-1のMED値は、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値を割り当てることにより、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間）リンクで使用することを目的としていました。ただし、さまざまな自律システムから受け取ったルート間のルート選好を決定する目的で、多数のMEDアプリケーションが現在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ルートリフレクション - フルメッシュIBGPの代替」[RFC2796]および「BGPの自律システムコンフェデレーション」[RFC3065]で定義されたBGPスケーリングメカニズムは、持続的なBGPルート膨張[RFC3345]を導入します。この問題は、BGPの仕組みに固有のものです。情報の隠れ/階層と、MED規則によって引き起こされる総注文の欠如によって課される非階層選択プロセスの間に競合が存在します。現在の慣行を考えると、問題は、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つは、IGPメトリックとしてのメンバー内またはクラスター間IGPメトリックを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を比較せず、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.
おそらく現在の仕様に関する限り「法的」がありますが、あらゆるタイプのIBGPセッション（例えば、標準のIBGP、BGP連合、ルート反射などのメンバーエイゼ間のEBGPセッションなど）で受け取ったMED属性を変更することは推奨されません。
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.
MEDは、多くの場合、IGPメトリックまたはIGPメトリックに関連する加算コストから、特定のBGP Next_hopに関連する追加コストから導き出されます。これは通常、ネットワーク内の特定の宛先への最適なパスを表すために使用されるピアに宣伝されているBGP MEDが、特定のAS内の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ベースのMEDSの結果は、AS内またはAS内の単一のリンク内でさえ、BGPの不安定性またはBGPルートの広告チャーンが複数のドメインに広がるBGPルート広告チャーンをもたらす可能性があることです。要するに、IGPメトリックフラップのたびにMEDが「フラップ」する場合、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のルートを注文する方法が含まれていました。
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のラチェットだけで、過度の解約を防ぐためにそれを動かすことはありません。
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は、同じように異なる外部ピアから受信したパスを比較する場合にのみ使用されることを意図していましたが、多くの実装は、異なる自律システム間でMEDを比較する機能を提供します。オペレーターはしばしばlocal_prefを使用して外部設定（プライマリ、セカンダリアップストリーム、ピア、顧客など）を選択しますが、local_prefの代わりにMEDを使用すると、MEDがAS_Pathの長さの後にのみ比較されるため、最高のルートの一貫性のない分布につながる可能性があります。
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).
これはいくつかの構成にとって素晴らしいアイデアのように思えるかもしれませんが、異なる自律システム間で薬を比較する場合は注意が必要です。BGPスピーカーは、多くの場合、ローカルAS内の特定のBGP Next_hopに到達することに関連するIGPメトリックを取得することにより、MED値を導き出します。これにより、MEDはピアへのルートを広告するときにIGPトポロジを合理的に反映できます。これは、単一のASから学んだ複数の経路間でMEDを比較する場合は問題ありませんが、異なる自律システム間でMEDを比較すると、潜在的に「加重」決定をもたらす可能性があります。これは、自律システムが異なるメカニズムを使用してIGPメトリックまたはBGP MEDを導出する場合、またはおそらく非常に対照的なメトリック空間を持つ異なるIGPプロトコルを使用する場合の場合に最もよく当てはまります（たとえば、OSPF vs.従来のメトリック空間はIS-IS）。
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ルーティング情報の集約がMEDに与える影響が含まれます。集合体は、安定性、冗長性、およびその他のネットワーク設計目標に対応するために、ASの複数の場所から生成されることがよくあります。MEDが上記の凝集体に関連付けられた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.
彼のいつもの鋭い目と建設的な洞察を適用してくれたJohn Scudderに感謝します。また、Curtis Villamizar、Jr Mitchell、Pekka Savolaの貴重なフィードバックに感謝します。
[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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Bates、T.、Chandra、R。、およびE. Chen、「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.、McPherson、D。、およびJ. Scudder、「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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[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月。
[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月。
Authors' Addresses
著者のアドレス
Danny McPherson Arbor Networks
ダニーマクファーソンアーバーネットワーク
EMail: danny@arbor.net
Vijay Gill AOL
Vijay Gill Aol
EMail: VijayGill9@aol.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。