Network Working Group D. McPherson
Request for Comments: 4451 Arbor Networks, Inc.
Category: Informational V. Gill
AOL
March 2006
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多出口光盘（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).
版权所有（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作为最佳入口点传送到本地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
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作为最佳入口点传送到本地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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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:
BGP MULTI_EXIT_DISC（MED）属性，以前称为INTER_as_METRIC，目前在[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属性的值是一个四个八位组的无符号数，称为度量。在所有其他因素相同的情况下，应首选具有较低度量的出口点。如果通过外部BGP（EBGP）接收，则可以通过内部BGP（IBGP）将MULTI_EXIT_DISC属性传播到与相同的系统中的其他BGP扬声器（另请参见9.1.2.2）。从相邻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.
通过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) 从考虑中删除具有较少首选多出口光盘属性的路由。MULTI_EXIT_DISC仅在从同一相邻AS（相邻AS由AS_路径属性确定）学习的路由之间具有可比性。不具有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
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）是一个函数，返回路由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说话者学习该路由的邻居AS。如果路由是通过IBGP学习的，而另一个IBGP说话者（a）发起路由，或（b）通过聚合创建路由，并且聚合路由的AS_PATH属性为空或以AS_集开始，则它是本地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
如果在将路由重新播发到IBGP之前删除了MULTI_EXIT_DISC属性，则仍然可以执行基于接收到的EBGP MULTI_EXIT_DISC属性的比较。如果某个实现选择移除MULTI_EXIT_DISC，则MULTI_EXIT_DISC上的可选比较（如果执行）必须仅在EBGP学习的路由之间执行。删除MULTI_EXIT_DISC属性后，可将最佳EBGP学习路径与IBGP学习路径进行比较。如果从EBGP学习路径的子集中移除多个退出光盘，则选定的“最佳”EBGP学习路径将不会被移除
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学习路径进行比较。对于IBGP学习的路线，在决策过程中达到此步骤的路线比较中必须使用MULTI_EXIT_光盘。在与IBGP学习路由的比较中，包括EBGP学习路由的多个出口盘，然后删除多个出口盘属性，并且已证明该路由的广告会导致路由循环。
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.
让我们考虑这样一种情况，即在一对主机之间的业务流，每个主机连接到不同的传输网络，在两个或多个位置互连。每个传输网络都可以选择将流量发送到与相邻传输网络最近的对等网络，或者将流量传递到向目的主机播发成本最低路径的互连位置。
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.
如果一个公交服务提供商使用热土豆路由，而另一个使用冷土豆路由，那么两者之间的交通往往更加对称。然而，如果两个提供商在其网络之间采用冷土豆路由或热土豆路由，则可能存在更大的不对称性。
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.
根据业务关系，如果一个提供商的容量更大或主干网络拥塞程度明显降低，则该提供商可能会使用冷土豆路由。20世纪90年代中期，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
在某些情况下，提供商可能对给定对等机的某些目的地使用热土豆路由，而对其他目的地使用冷土豆路由。这方面的一个例子是1990年代中期NSFNET对商业和研究流量的不同处理。今天，许多
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.
商业网络与客户交换药品，但不与双边同行交换。然而，药物的商业用途差别很大，从普遍使用到完全没有。
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
此外，一些实现已被证明在内部使用最大可能MED值（2^32-1）作为“无限”度量（即，MED值用于将路由标记为不可行）；收到MED值为2^32-1的更新后，他们将重写
the value to 2^32-2. Subsequently, the new MED value would be propagated and could result in routing inconsistencies or unintended path selections.
将值设置为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值，以符合其内部路由策略（即，包括要求在配置中不使用0和2^32-1的MED值的策略，无论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间）链路，以区分与相邻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.
避免这种情况的一种潜在方法是，将成员间或集群间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联盟成员ASE之间的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下一跳。这通常提供了一个有效的模型，用于确保向对等方发布的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的MED的结果是，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_路径数据库中搜索匹配集（如果有）。路径属性的一致顺序允许在数据库中轻松匹配，因为同一数据没有不同的表示形式。
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值。此外，许多运营商明确不使用MED值0或2^32-1，以避免与BGP规范的实施和各种修订不一致。
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来选择外部首选项（主要、次要上游、对等、客户等），因此使用MED而不是LOCAL_PREF可能会导致最佳路由的分布不一致，因为MED仅在AS_路径长度之后进行比较。
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下一跳相关的IGP度量来获得MED值。这使得MED在向对等方宣传路线时能够合理地反映IGP拓扑。当比较从单个AS学习的多条路径之间的MED时，这是很好的，但当比较不同自治系统之间的MED时，它可能会导致潜在的“加权”决策。当自治系统使用不同的机制来导出IGP度量或BGP MED时，或者当自治系统甚至可能使用不同的IGP协议，且度量空间存在巨大差异（例如，在is-is中OSPF与传统度量空间）时，这是最典型的情况。
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设计的一个首要目标是确保对等网络不能为它们所宣传的网络“甩”或“吸收”流量。因此，从某种意义上说，接受来自对等方的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.
感谢约翰·斯卡德尔运用他一贯敏锐的眼光和建设性的洞察力。此外，感谢柯蒂斯·维拉米扎、小米切尔和佩卡·萨沃拉的宝贵反馈。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年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，“边境网关协议4（BGP-4）”，RFC 42712006年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路线襟翼阻尼”，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，“边界网关协议（BGP）持续路由振荡条件”，RFC 33452002年8月。
Authors' Addresses
作者地址
Danny McPherson Arbor Networks
丹尼·麦克弗森阿伯网络公司
EMail: danny@arbor.net
EMail: danny@arbor.net
Vijay Gill AOL
Vijay Gill AOL
EMail: VijayGill9@aol.com
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。