Internet Engineering Task Force (IETF)                      P. Mohapatra
Request for Comments: 7311                              Sproute Networks
Category: Standards Track                                    R. Fernando
ISSN: 2070-1721                                                 E. Rosen
                                                     Cisco Systems, Inc.
                                                               J. Uttaro
                                                                    AT&T
                                                             August 2014
        
Internet Engineering Task Force (IETF)                      P. Mohapatra
Request for Comments: 7311                              Sproute Networks
Category: Standards Track                                    R. Fernando
ISSN: 2070-1721                                                 E. Rosen
                                                     Cisco Systems, Inc.
                                                               J. Uttaro
                                                                    AT&T
                                                             August 2014
        

The Accumulated IGP Metric Attribute for BGP

BGP的累积IGP度量属性

Abstract

摘要

Routing protocols that have been designed to run within a single administrative domain (IGPs) generally do so by assigning a metric to each link and then choosing, as the installed path between two nodes, the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains (autonomous systems), does not make its path-selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so.

设计为在单个管理域(IGPs)内运行的路由协议通常通过为每个链路分配一个度量,然后选择总距离(沿路径的每个链路的度量之和)最小化的路径作为两个节点之间的安装路径来实现。BGP设计用于在大量独立管理域(自治系统)上提供路由,它不通过使用度量来做出路径选择决策。人们普遍认为,任何这样做的尝试都会带来重大的可扩展性问题以及行政间协调问题。但是,在某些部署中,单个管理运行多个连续的BGP网络。在这种情况下,希望BGP在单个管理域内根据度量选择路径,就像IGP那样。本文件的目的是提供相关规范。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7311.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7311.

Copyright Notice

版权公告

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2014 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1. Introduction ....................................................3
   2. Specification of Requirements ...................................4
   3. AIGP Attribute ..................................................4
      3.1. Applicability Restrictions and Cautions ....................6
      3.2. Handling a Malformed AIGP Attribute ........................6
      3.3. Restrictions on Sending/Receiving ..........................6
      3.4. Creating and Modifying the AIGP Attribute ..................7
           3.4.1. Originating the AIGP Attribute ......................7
           3.4.2. Modifications by the Originator .....................8
           3.4.3. Modifications by a Non-Originator ...................8
   4. Decision Process ...............................................10
      4.1. When a Route Has an AIGP Attribute ........................11
      4.2. When the Route to the Next Hop Has an AIGP Attribute ......11
   5. Deployment Considerations ......................................12
   6. IANA Considerations ............................................13
   7. Security Considerations ........................................13
   8. Acknowledgments ................................................13
   9. References .....................................................14
      9.1. Normative Reference .......................................14
      9.2. Informative References ....................................14
        
   1. Introduction ....................................................3
   2. Specification of Requirements ...................................4
   3. AIGP Attribute ..................................................4
      3.1. Applicability Restrictions and Cautions ....................6
      3.2. Handling a Malformed AIGP Attribute ........................6
      3.3. Restrictions on Sending/Receiving ..........................6
      3.4. Creating and Modifying the AIGP Attribute ..................7
           3.4.1. Originating the AIGP Attribute ......................7
           3.4.2. Modifications by the Originator .....................8
           3.4.3. Modifications by a Non-Originator ...................8
   4. Decision Process ...............................................10
      4.1. When a Route Has an AIGP Attribute ........................11
      4.2. When the Route to the Next Hop Has an AIGP Attribute ......11
   5. Deployment Considerations ......................................12
   6. IANA Considerations ............................................13
   7. Security Considerations ........................................13
   8. Acknowledgments ................................................13
   9. References .....................................................14
      9.1. Normative Reference .......................................14
      9.2. Informative References ....................................14
        
1. Introduction
1. 介绍

There are many routing protocols that have been designed to run within a single administrative domain. These are known collectively as "Interior Gateway Protocols" (IGPs). Typically, each link is assigned a particular "metric" value. The path between two nodes can then be assigned a "distance", which is the sum of the metrics of all the links that belong to that path. An IGP selects the "shortest" (minimal distance) path between any two nodes, perhaps subject to the constraint that if the IGP provides multiple "areas", it may prefer the shortest path within an area to a path that traverses more than one area. Typically, the administration of the network has some routing policy that can be approximated by selecting shortest paths in this way.

有许多路由协议被设计为在单个管理域中运行。这些协议统称为“内部网关协议”(IGP)。通常,为每个链接分配一个特定的“度量”值。然后可以为两个节点之间的路径分配一个“距离”,该距离是属于该路径的所有链路的度量的总和。IGP选择任意两个节点之间的“最短”(最小距离)路径,可能受到这样的约束,即如果IGP提供多个“区域”,则它可能更喜欢一个区域内的最短路径,而不是穿过多个区域的路径。通常,网络管理有一些路由策略,可以通过以这种方式选择最短路径来近似。

BGP, as distinguished from the IGPs, was designed to run over an arbitrarily large number of administrative domains ("autonomous systems" or "ASes") with limited coordination among the various administrations. BGP does not make its path-selection decisions based on a metric; there is no such thing as an "inter-AS metric". There are two fundamental reasons for this:

BGP不同于IGP,其设计旨在运行任意数量的管理域(“自治系统”或“ASE”),各管理部门之间的协调有限。BGP不会根据度量做出路径选择决策;没有“国际标准”这样的东西。这有两个根本原因:

- The distance between two nodes in a common administrative domain may change at any time due to events occurring in that domain. These changes are not propagated around the Internet unless they actually cause the border routers of the domain to select routes with different BGP attributes for some set of address prefixes. This accords with a fundamental principle of scaling, viz., that changes with only local significance must not have global effects. If local changes in distance were always propagated around the Internet, this principle would be violated.

- 由于公共管理域中发生的事件,该域中两个节点之间的距离可能随时发生变化。这些更改不会在Internet上传播,除非它们实际导致域的边界路由器为某些地址前缀集选择具有不同BGP属性的路由。这符合缩放的基本原则,即仅具有局部意义的变化不得具有全局影响。如果本地距离的变化总是在互联网上传播,这一原则将被违反。

- A basic principle of inter-domain routing is that the different administrative domains may have their own policies, which do not have to be revealed to other domains and which certainly do not have to be agreed to by other domains. Yet, the use of an inter-AS metric in the Internet would have exactly these effects.

- 域间路由的一个基本原则是,不同的管理域可能有自己的策略,这些策略不必向其他域公开,当然也不必得到其他域的同意。然而,在互联网上使用inter作为度量标准将产生这些效果。

There are, however, deployments in which a single administration runs a network that has been sub-divided into multiple, contiguous ASes, each running BGP. There are several reasons why a single administrative domain may be broken into several ASes (which, in this case, are not really autonomous.) It may be that the existing IGPs do not scale well in the particular environment; it may be that a more generalized topology is desired than could be obtained by use of a single IGP domain; it may be that a more finely grained routing policy is desired than can be supported by an IGP. In such deployments, it can be useful to allow BGP to make its routing

但是,在有些部署中,一个管理运行一个网络,该网络被细分为多个连续的ASE,每个ASE运行BGP。一个管理域可能被分成几个ASE(在本例中,这些ASE不是真正自主的)有几个原因。可能是现有的IGP在特定环境中不能很好地扩展;可能需要比使用单个IGP域更通用的拓扑结构;可能需要比IGP支持的更细粒度的路由策略。在这样的部署中,允许BGP进行路由是非常有用的

decisions based on the IGP metric, so that BGP chooses the shortest path between two nodes, even if the nodes are in two different ASes within that same administrative domain.

基于IGP度量的决策,以便BGP选择两个节点之间的最短路径,即使节点位于同一管理域内的两个不同ASE中。

There are, in fact, some implementations that already do something like this, using BGP's MULTI_EXIT_DISC (MED) attribute to carry a value based on IGP metrics. However, that doesn't really provide IGP-like shortest path routing, as the BGP decision process gives priority to other factors, such as the AS_PATH length. Also, the standard procedures for use of the MED do not ensure that the IGP metric is properly accumulated so that it covers all the links along the path.

事实上,有些实现已经实现了类似的功能,使用BGP的MULTI_EXIT_DISC(MED)属性携带基于IGP度量的值。然而,这并不能真正提供类似IGP的最短路径路由,因为BGP决策过程优先考虑其他因素,例如as_路径长度。此外,MED的标准使用程序不能确保IGP度量正确累积,从而覆盖路径上的所有链路。

In this document, we define a new optional, non-transitive BGP attribute, called the "Accumulated IGP Metric Attribute", or "AIGP attribute", and specify the procedures for using it.

在本文档中,我们定义了一个新的可选、不可传递的BGP属性,称为“累计IGP度量属性”或“AIGP属性”,并指定了使用该属性的过程。

The specified procedures prevent the AIGP attribute from "leaking out" past an administrative domain boundary into the Internet. We will refer to the set of ASes in a common administrative domain as an "AIGP administrative domain".

指定的过程防止AIGP属性通过管理域边界“泄漏”到Internet。我们将公共管理域中的ASE集称为“AIGP管理域”。

The specified procedures also ensure that the value in the AIGP attribute has been accumulated all along the path from the destination, i.e., that the AIGP attribute does not appear when there are "gaps" along the path where the IGP metric is unknown.

指定的程序还确保AIGP属性中的值已从目标沿路径累积,即,当IGP度量未知的路径上存在“间隙”时,AIGP属性不会出现。

2. Specification of Requirements
2. 需求说明

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]中所述进行解释。

3. AIGP Attribute
3. AIGP属性

The AIGP attribute is an optional, non-transitive BGP path attribute. The attribute type code for the AIGP attribute is 26.

AIGP属性是可选的、不可传递的BGP路径属性。AIGP属性的属性类型代码为26。

The value field of the AIGP attribute is defined here to be a set of elements encoded as "Type/Length/Value" (i.e., a set of TLVs). Each such TLV is encoded as shown in Figure 1.

AIGP属性的值字段在这里定义为一组编码为“类型/长度/值”的元素(即一组TLV)。如图1所示,对每个这样的TLV进行编码。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |         Length                |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
    ~                                                               ~
    |                           Value                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |         Length                |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
    ~                                                               ~
    |                           Value                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
        

Figure 1: AIGP TLV

图1:AIGP TLV

- Type: A single octet encoding the TLV Type. Only type 1, "AIGP TLV", is defined in this document. Use of other TLV types is outside the scope of this document.

- 类型:编码TLV类型的单个八位组。本文件中仅定义了类型1“AIGP TLV”。其他TLV类型的使用不在本文件范围内。

- Length: Two octets encoding the length in octets of the TLV, including the Type and Length fields. The length is encoded as an unsigned binary integer. (Note that the minimum length is 3, indicating that no Value field is present.)

- 长度:两个八位字节编码TLV的长度(以八位字节为单位),包括类型和长度字段。长度编码为无符号二进制整数。(请注意,最小长度为3,表示不存在值字段。)

- Value: A field containing zero or more octets.

- 值:包含零个或多个八位字节的字段。

This document defines only a single such TLV, the "AIGP TLV". The AIGP TLV is encoded as follows:

本文件仅定义了一个此类TLV,即“AIGP TLV”。AIGP TLV编码如下:

- Type: 1

- 类型:1

- Length: 11

- 长度:11

- Value: Accumulated IGP Metric.

- 值:累计IGP度量。

The value field of the AIGP TLV is always 8 octets long, and its value is interpreted as an unsigned 64-bit integer. IGP metrics are frequently expressed as 4-octet values. By using an 8-octet field, we ensure that the AIGP attribute can be used to hold the sum of an arbitrary number of 4-octet values.

AIGP TLV的值字段长度始终为8个八位字节,其值被解释为无符号64位整数。IGP度量通常表示为4个八位组的值。通过使用8个八位组字段,我们确保可以使用AIGP属性来保存任意数量的4个八位组值之和。

When an AIGP attribute is created, it SHOULD contain no more than one AIGP TLV. However, if it contains more than one AIGP TLV, only the first one is used as described in Sections 3.4 and 4. In the remainder of this document, we will use the term "value of the AIGP TLV" to mean the value of the first AIGP TLV in the AIGP attribute. Any other AIGP TLVs in the AIGP attribute MUST be passed along unchanged if the AIGP attribute is passed along.

创建AIGP属性时,该属性不应包含多个AIGP TLV。但是,如果包含多个AIGP TLV,则仅使用第3.4节和第4节中所述的第一个AIGP TLV。在本文档的其余部分中,我们将使用术语“AIGP TLV的值”来表示AIGP属性中第一个AIGP TLV的值。如果传递AIGP属性,则AIGP属性中的任何其他AIGP TLV必须原封不动地传递。

3.1. Applicability Restrictions and Cautions
3.1. 适用性限制和注意事项

This document only considers the use of the AIGP attribute in networks where each router uses tunneling of some sort to deliver a packet to its BGP next hop. Use of the AIGP attribute in other scenarios is outside the scope of this document.

本文档仅考虑在网络中使用AIGP属性,其中每个路由器使用某种类型的隧道传输数据包到其BGP下一跳。在其他场景中使用AIGP属性超出了本文档的范围。

If a Route Reflector supports the AIGP attribute but some of its clients do not, then the routing choices that result may not all reflect the intended routing policy.

如果路由反射器支持AIGP属性,但其某些客户端不支持,则结果中的路由选择可能并不全部反映预期的路由策略。

3.2. Handling a Malformed AIGP Attribute
3.2. 处理格式错误的AIGP属性

When receiving a BGP Update message containing a malformed AIGP attribute, the attribute MUST be treated exactly as if it were an unrecognized non-transitive attribute. That is, it "MUST be quietly ignored and not passed along to other BGP peers" (see [BGP], Section 5). This is equivalent to the "attribute discard" action specified in [BGP-ERROR].

当接收到包含格式错误的AIGP属性的BGP更新消息时,必须将该属性视为无法识别的非传递属性。也就是说,它“必须被悄悄地忽略,并且不能传递给其他BGP对等方”(参见[BGP],第5节)。这相当于[BGP-ERROR]中指定的“属性丢弃”操作。

Note that an AIGP attribute MUST NOT be considered to be malformed because it contains more than one TLV of a given type or because it contains TLVs of unknown types.

请注意,AIGP属性不能被视为格式错误,因为它包含多个给定类型的TLV,或者因为它包含未知类型的TLV。

If a BGP path attribute is received that has the AIGP attribute codepoint but also has the transitive bit set, the attribute MUST be considered to be a malformed AIGP attribute and MUST be discarded as specified in this section.

如果接收到的BGP path属性具有AIGP属性codepoint,但也设置了可传递位,则必须将该属性视为格式错误的AIGP属性,并且必须按照本节中的规定丢弃该属性。

If an AIGP attribute is received and its first AIGP TLV contains the maximum value 0xffffffffffffffff, the attribute SHOULD be considered to be malformed and SHOULD be discarded as specified in this section. (Since the TLV value cannot be increased any further, it is not useful for metric-based path selection.)

如果接收到AIGP属性,且其第一个AIGP TLV包含最大值0xFFFFFFFFFFFFFF,则应将该属性视为格式错误,并应按照本节的规定丢弃该属性。(由于TLV值不能再增加,因此它对于基于度量的路径选择不有用。)

3.3. Restrictions on Sending/Receiving
3.3. 发送/接收限制

An implementation that supports the AIGP attribute MUST support a per-session configuration item, AIGP_SESSION, that indicates whether the attribute is enabled or disabled for use on that session.

支持AIGP属性的实现必须支持每会话配置项AIGP_session,该项指示在该会话上使用该属性是启用还是禁用。

- For Internal BGP (IBGP) sessions, and for External BGP (EBGP) sessions between members of the same BGP Confederation [BGP-CONFED], the default value of AIGP_SESSION SHOULD be "enabled".

- 对于内部BGP(IBGP)会话,以及同一BGP联盟[BGP-CONFED]成员之间的外部BGP(EBGP)会话,AIGP_会话的默认值应为“启用”。

- For all other External BGP (EBGP) sessions, the default value of AIGP_SESSION MUST be "disabled".

- 对于所有其他外部BGP(EBGP)会话,AIGP_会话的默认值必须为“禁用”。

The AIGP attribute MUST NOT be sent on any BGP session for which AIGP_SESSION is disabled.

AIGP属性不得在禁用AIGP_会话的任何BGP会话上发送。

If an AIGP attribute is received on a BGP session for which AIGP_SESSION is disabled, the attribute MUST be treated exactly as if it were an unrecognized non-transitive attribute. That is, it "MUST be quietly ignored and not passed along to other BGP peers" (see [BGP], Section 5). However, the fact that the attribute was received SHOULD be logged (in a rate-limited manner).

如果在禁用AIGP_会话的BGP会话上接收到AIGP属性,则必须将该属性视为无法识别的非传递属性。也就是说,它“必须被悄悄地忽略,并且不能传递给其他BGP对等方”(参见[BGP],第5节)。但是,应该记录接收属性的事实(以速率受限的方式)。

3.4. Creating and Modifying the AIGP Attribute
3.4. 创建和修改AIGP属性
3.4.1. Originating the AIGP Attribute
3.4.1. 创建AIGP属性

An implementation that supports the AIGP attribute MUST support a configuration item, AIGP_ORIGINATE, that enables or disables its creation and attachment to routes. The default value of AIGP_ORIGINATE MUST be "disabled".

支持AIGP属性的实现必须支持配置项AIGP_ORIGINATE,该配置项启用或禁用其创建和连接到路由。AIGP_的默认值必须为“禁用”。

A BGP speaker MUST NOT add the AIGP attribute to any route whose path leads outside the AIGP administrative domain to which the BGP speaker belongs. When the AIGP attribute is used, changes in IGP routing will directly impact BGP routing. Attaching the AIGP attribute to customer routes, Internet routes, or other routes whose paths lead outside the infrastructure of a particular AIGP administrative domain could result in BGP scaling and/or thrashing problems.

BGP演讲者不得将AIGP属性添加到路径指向BGP演讲者所属AIGP管理域之外的任何路由。使用AIGP属性时,IGP路由的更改将直接影响BGP路由。将AIGP属性附加到客户路由、Internet路由或其路径指向特定AIGP管理域的基础架构之外的其他路由可能会导致BGP扩展和/或抖动问题。

The AIGP attribute may be added only to routes that satisfy one of the following conditions:

AIGP属性只能添加到满足以下条件之一的路线:

- The route is a static route, not leading outside the AIGP administrative domain, that is being redistributed into BGP;

- 该路由是一条静态路由,不在AIGP管理域之外,正在重新分配到BGP中;

- The route is an IGP route that is being redistributed into BGP;

- 该路由是正在重新分配到BGP中的IGP路由;

- The route is an IBGP-learned route whose AS_PATH attribute is empty; or

- 该路由为IBGP学习路由,其AS_路径属性为空;或

- The route is an EBGP-learned route whose AS_PATH contains only ASes that are in the same AIGP administrative domain as the BGP speaker.

- 该路由是一个EBGP学习路由,其AS_路径仅包含与BGP扬声器位于同一AIGP管理域中的ASE。

A BGP speaker R MUST NOT add the AIGP attribute to any route for which R does not set itself as the next hop.

BGP演讲者R不得将AIGP属性添加到R未将自身设置为下一跳的任何路由。

It SHOULD be possible to set AIGP_ORIGINATE to "enabled for the routes of a particular IGP that are redistributed into BGP" (where "a particular IGP" might be OSPF or IS-IS). Other policies determining when and whether to originate an AIGP attribute are also possible, depending on the needs of a particular deployment scenario.

应该可以将AIGP_origin设置为“为重新分配到BGP的特定IGP的路由启用”(其中“特定IGP”可能是OSPF或IS-IS)。根据特定部署场景的需要,确定何时以及是否发起AIGP属性的其他策略也是可能的。

When originating an AIGP attribute for a BGP route to address prefix P, the value of the AIGP TLV is set according to policy. There are a number of useful policies, some of which are in the following list:

当为BGP路由到地址前缀P发起AIGP属性时,将根据策略设置AIGP TLV的值。有许多有用的策略,其中一些在以下列表中:

- When a BGP speaker R is redistributing into BGP an IGP route to address prefix P, the IGP will have computed a distance from R to P. This distance MAY be assigned as the value of the AIGP TLV.

- 当BGP扬声器R向BGP重新分配到地址前缀P的IGP路由时,IGP将计算从R到P的距离。该距离可指定为AIGP TLV的值。

- A BGP speaker R may be redistributing into BGP a static route to address prefix P, for which a distance from R to P has been configured. This distance MAY be assigned as the value of the AIGP TLV.

- BGP扬声器R可以将到地址前缀P的静态路由重新分配到BGP中,已经为其配置了从R到P的距离。该距离可指定为AIGP TLV的值。

- A BGP speaker R may have received and installed a BGP-learned route to prefix P, with next hop N. Or it may be redistributing a static route to P, with next hop N. Then:

- BGP扬声器R可能已经接收并安装了一个BGP学习路由到前缀P,下一跳为N。或者它可能正在将一个静态路由重新分配到前缀P,下一跳为N。然后:

* If R has an IGP route to N, the IGP-computed distance from R to N MAY be used as the value of the AIGP TLV of the route to P.

* 如果R有到N的IGP路线,则从R到N的IGP计算距离可用作到P路线的AIGP TLV值。

* If R has a BGP route to N, and an AIGP TLV attribute value has been computed for that route (see Section 3.4.3), that value MAY be used as the AIGP TLV value of the route to P.

* 如果R有到N的BGP路由,并且已经为该路由计算了AIGP TLV属性值(参见第3.4.3节),则该值可以用作到P的路由的AIGP TLV值。

3.4.2. Modifications by the Originator
3.4.2. 发起人的修改

If BGP speaker R is the originator of the AIGP attribute of prefix P, and the distance from R to P changes at some point, R SHOULD issue a new BGP update containing the new value of the AIGP TLV of the AIGP attribute. (Here we use the term "distance" to refer to whatever value the originator assigns to the AIGP TLV, however it is computed; see Section 3.4.1.) However, if the difference between the new distance and the distance advertised in the AIGP TLV is less than a configurable threshold, the update MAY be suppressed.

如果BGP说话人R是前缀P的AIGP属性的发起人,并且从R到P的距离在某一点上发生变化,则R应发布一个新的BGP更新,其中包含AIGP属性的AIGP TLV的新值。(此处,我们使用术语“距离”来表示发起者分配给AIGP TLV的任何值,无论该值是如何计算的;请参见第3.4.1节。)但是,如果新距离与AIGP TLV中公布的距离之间的差值小于可配置阈值,则可能会抑制更新。

3.4.3. Modifications by a Non-Originator
3.4.3. 非发起人的修改

Suppose a BGP speaker R1 receives a route with an AIGP attribute whose value is A and with a next hop whose value is R2. Suppose also that R1 is about to redistribute that route on a BGP session that is enabled for sending/receiving the attribute.

假设BGP扬声器R1接收到一条路由,该路由的AIGP属性值为a,下一跳的值为R2。还假设R1将在启用了发送/接收属性的BGP会话上重新分发该路由。

If R1 does not change the next hop of the route, then R1 MUST NOT change the AIGP attribute value of the route.

如果R1不更改路由的下一个跃点,则R1不得更改路由的AIGP属性值。

In all the computations discussed in this section, the AIGP value MUST be capped at its maximum unsigned value 0xffffffffffffffff. Increasing the AIGP value MUST NOT cause the value to wrap around.

在本节讨论的所有计算中,AIGP值必须限制在其最大无符号值0xFFFFFFFFFFFF。增加AIGP值不得导致该值缠绕。

Suppose R1 changes the next hop of the route from R2 to R1. If R1's route to R2 is either (a) an IGP-learned route or (b) a static route that does not require recursive next hop resolution, then R1 MUST increase the value of the AIGP TLV by adding to A the distance from R1 to R2. This distance is either the IGP-computed distance from R1 to R2 or some value determined by policy. However, A MUST be increased by a non-zero amount.

假设R1将路由的下一个跃点从R2更改为R1。如果R1到R2的路由是(a)IGP学习路由或(b)不需要递归下一跳解析的静态路由,则R1必须通过增加从R1到R2的距离来增加AIGP TLV的值。该距离是从R1到R2的IGP计算的距离,或者是由策略确定的某个值。但是,A必须以非零的数量增加。

It is possible that R1 and R2 above are EBGP neighbors and that there is a direct link between them on which no IGP is running. Then, when R1 changes the next hop of a route from R2 to R1, the AIGP TLV value MUST be increased by a non-zero amount. The amount of the increase SHOULD be such that it is properly comparable to the IGP metrics. For example, if the IGP metric is a function of latency, then the amount of the increase should be a function of the latency from R1 to R2.

上面的R1和R2可能是EBGP邻居,并且它们之间存在没有IGP运行的直接链路。然后,当R1将路由的下一个跃点从R2更改为R1时,AIGP TLV值必须增加非零量。增加的金额应与IGP指标具有适当的可比性。例如,如果IGP度量是延迟的函数,那么增加的量应该是从R1到R2的延迟的函数。

Suppose R1 changes the next hop of the route from R2 to R1 and R1's route to R2 is either (a) a BGP-learned route or (b) a static route that requires recursive next-hop resolution. Then, the AIGP TLV value needs to be increased in several steps, according to the following procedure. (Note that this procedure is ONLY used when recursive next-hop resolution is needed.)

假设R1将路由的下一跳从R2更改为R1,并且R1到R2的路由是(a)BGP学习路由或(b)需要递归下一跳解析的静态路由。然后,需要按照以下程序分几个步骤增加AIGP TLV值。(请注意,此过程仅在需要递归下一跳解析时使用。)

1. Let Xattr be the new AIGP TLV value.

1. 设Xattr为新的AIGP TLV值。

2. Initialize Xattr to A.

2. 将Xattr初始化为A。

3. Set XNH to R2.

3. 将XNH设置为R2。

4. Find the route to XNH.

4. 找到去新罕布什尔州的路线。

5. If the route to XNH does not require recursive next-hop resolution, get the distance D from R1 to XNH. (Note that this condition cannot be satisfied the first time through this procedure.) If D is above a configurable threshold, set the AIGP TLV value to Xattr+D. If D is below a configurable threshold, set the AIGP TLV value to Xattr. In either case, exit this procedure.

5. 如果到XNH的路由不需要递归下一跳分辨率,则获取从R1到XNH的距离D。(请注意,通过本程序第一次无法满足此条件。)如果D高于可配置阈值,则将AIGP TLV值设置为Xattr+D。如果D低于可配置阈值,则将AIGP TLV值设置为Xattr。无论哪种情况,请退出此过程。

6. If the route to XNH is a BGP-learned route that does NOT have an AIGP attribute, then exit this procedure and do not pass on any AIGP attribute. If the route has an AIGP attribute without an AIGP TLV, then the AIGP attribute MAY be passed along unchanged.

6. 如果到XNH的路由是没有AIGP属性的BGP学习路由,则退出此过程,不要传递任何AIGP属性。如果路线具有AIGP属性而没有AIGP TLV,则AIGP属性可以不加更改地传递。

7. If the route to XNH is a BGP-learned route that has an AIGP TLV value of Y, then set Xattr to Xattr+Y and set XNH to the next hop of this route. (The intention here is that Y is the AIGP TLV value of the route as it was received by R1, without having been modified by R1.)

7. 如果到XNH的路由是具有AIGP TLV值Y的BGP学习路由,则将Xattr设置为Xattr+Y,并将XNH设置为该路由的下一跳。(此处的意图是Y是R1接收到的路线的AIGP TLV值,而R1未对其进行修改。)

8. Go to step 4.

8. 转至步骤4。

The AIGP TLV value of a given route depends on (a) the AIGP TLV values of all the next hops that are recursively resolved during this procedure, and (b) the IGP distance to any next hop that is not recursively resolved. Any change due to (a) in any of these values MUST trigger a new AIGP computation for that route. Whether a change due to (b) triggers a new AIGP computation depends upon whether the change in IGP distance exceeds a configurable threshold.

给定路由的AIGP TLV值取决于(a)在此过程中递归解析的所有下一跳的AIGP TLV值,以及(b)到任何未递归解析的下一跳的IGP距离。由于(a)中任何一个值的任何变化都必须触发该路线的新AIGP计算。(b)引起的变化是否触发新的AIGP计算取决于IGP距离的变化是否超过可配置的阈值。

If the AIGP attribute is carried across several ASes, each with its own IGP domain, it is clear that these procedures are unlikely to give a sensible result if the IGPs are different (e.g., some OSPF and some IS-IS) or if the meaning of the metrics is different in the different IGPs (e.g., if the metric represents bandwidth in some IGP domains but represents latency in others). These procedures also are unlikely to give a sensible result if the metric assigned to inter-AS BGP links (on which no IGP is running) or to static routes is not comparable to the IGP metrics. All such cases are outside the scope of the current document.

如果AIGP属性跨越多个ASE,每个ASE都有自己的IGP域,很明显,如果IGP不同(例如,一些OSPF和一些is-is),或者如果度量的含义在不同的IGP中不同,则这些程序不可能给出合理的结果(例如,如果度量表示某些IGP域中的带宽,但表示其他域中的延迟)。如果将度量指定给AS BGP间链路(没有运行IGP),这些过程也不可能给出合理的结果或静态路由与IGP指标不可比。所有此类情况都不在当前文档的范围内。

4. Decision Process
4. 决策过程

Support for the AIGP attribute involves several modifications to the tie-breaking procedures of the BGP "phase 2" decision described in [BGP], Section 9.1.2.2. These modifications are described in Sections 4.1 and 4.2.

对AIGP属性的支持涉及对[BGP]第9.1.2.2节中所述BGP“第2阶段”决策的平局中断程序的若干修改。第4.1节和第4.2节中描述了这些修改。

In some cases, the BGP decision process may install a route without executing any tie-breaking procedures. This may happen, e.g., if only one route to a given prefix has the highest degree of preference (as defined in [BGP], Section 9.1.1). In this case, the AIGP attribute is not considered.

在某些情况下,BGP决策过程可能会在不执行任何中断连接程序的情况下安装路由。这可能发生,例如,如果只有一条到给定前缀的路由具有最高的优先等级(如[BGP]第9.1.1节所定义)。在这种情况下,不考虑AIGP属性。

In other cases, some routes may be eliminated before the tie-breaking procedures are invoked, e.g., routes with AS-PATH attributes indicating a loop or routes with unresolvable next hops. In these cases, the AIGP attributes of the eliminated routes are not considered.

在其他情况下,某些路由可能在调用中断连接程序之前被消除,例如,具有AS-PATH属性的路由指示循环或具有不可解析的下一跳的路由。在这些情况下,不考虑已消除路线的AIGP属性。

4.1. When a Route Has an AIGP Attribute
4.1. 当路线具有AIGP属性时

Assuming that the BGP decision process invokes the tie-breaking procedures, the procedures in this section MUST be executed BEFORE any of the tie-breaking procedures described in [BGP], Section 9.1.2.2 are executed.

假设BGP决策过程调用了领带断裂程序,则在执行[BGP]第9.1.2.2节所述的任何领带断裂程序之前,必须先执行本节中的程序。

If any routes have an AIGP attribute containing an AIGP TLV, remove from consideration all routes that do not have an AIGP attribute containing an AIGP TLV.

如果任何路线具有包含AIGP TLV的AIGP属性,则从考虑中删除所有不具有包含AIGP TLV的AIGP属性的路线。

If router R is considering route T, where T has an AIGP attribute with an AIGP TLV,

如果路由器R正在考虑路由T,其中T具有带有AIGP TLV的AIGP属性,

- then R must compute the value A, defined as follows: set A to the sum of (a) T's AIGP TLV value and (b) the IGP distance from R to T's next hop.

- 然后R必须计算值A,定义如下:将A设置为(A)T的AIGP TLV值和(b)从R到T的下一跳的IGP距离之和。

- remove from consideration all routes that are not tied for the lowest value of A.

- 从考虑中删除所有未绑定到最低值A的路线。

4.2. When the Route to the Next Hop Has an AIGP Attribute
4.2. 当到下一跳的路由具有AIGP属性时

Suppose that a given router R1 is comparing two BGP-learned routes, such that either:

假设给定路由器R1正在比较两个BGP学习路由,这样:

- the two routes have equal AIGP TLV values, or else

- 两条路线的AIGP TLV值相等,否则

- neither of the two routes has an AIGP attribute containing an AIGP TLV.

- 这两条路线都没有包含AIGP TLV的AIGP属性。

The BGP decision process as specified in [BGP] makes use, in its tie-breaking procedures, of "interior cost", defined as follows:

[BGP]中规定的BGP决策过程在其打破僵局的程序中使用了“内部成本”,定义如下:

interior cost of a route is determined by calculating the metric to the NEXT_HOP for the route using the Routing Table.

路由的内部成本是通过使用路由表计算路由下一跳的度量来确定的。

This document replaces the "interior cost" tie breaker of [BGP] with a tie breaker based on the "AIGP-enhanced interior cost". Suppose route T has a next hop of N. The "AIGP-enhanced interior cost" from node R1 to node N is defined as follows:

本文件将[BGP]的“内部成本”分界线替换为基于“AIGP增强内部成本”的分界线。假设路由T的下一跳为N。从节点R1到节点N的“AIGP增强内部成本”定义如下:

- Let R2 be the BGP next hop of the route to N after all recursive resolution of the next hop is done. Let m be the IGP distance (or in the case of a static route, the configured distance) from R1 to R2.

- 在下一跳的所有递归解析完成后,让R2成为路由到N的BGP下一跳。设m为R1到R2的IGP距离(或静态路由情况下的配置距离)。

- If the installed route to N has an AIGP attribute with an AIGP TLV, set A to its AIGP TLV value, computed according to the procedure in Section 3.4.3.

- 如果安装到N的路线具有AIGP属性和AIGP TLV,则将A设置为其AIGP TLV值,并根据第3.4.3节中的程序计算。

- If the installed route to N does not have an AIGP attribute with an AIGP TLV, set A to 0.

- 如果安装到N的路由没有AIGP TLV的AIGP属性,请将A设置为0。

- The "AIGP-enhanced interior cost" of route T is the quantity A+m.

- 路线T的“AIGP增强内部成本”为A+m数量。

The "interior cost" tie breaker of [BGP] is then applied, using the "AIGP-enhanced interior cost" instead of the "interior cost" as defined in [BGP].

然后应用[BGP]的“内部成本”约束条件,使用“AIGP增强内部成本”代替[BGP]中定义的“内部成本”。

5. Deployment Considerations
5. 部署注意事项

- Using the AIGP attribute to achieve a desired routing policy will be more effective if each BGP speaker can use it to choose from among multiple routes. Thus, it is highly recommended that the procedures of [BESTEXT] and [ADD-PATH] be used in conjunction with the AIGP attribute.

- 如果每个BGP演讲者都可以使用AIGP属性从多个路由中进行选择,那么使用AIGP属性来实现所需的路由策略将更加有效。因此,强烈建议将[BestText]和[ADD-PATH]的过程与AIGP属性结合使用。

- If a Route Reflector does not pass all paths to its clients, then it will tend to pass the paths for which the IGP distance from the Route Reflector itself to the next hop is smallest. This may result in a non-optimal choice by the clients.

- 如果路由反射器未将所有路径传递给其客户端,则它将倾向于传递从路由反射器自身到下一跳的IGP距离最小的路径。这可能会导致客户的非最佳选择。

- When the procedures of this document are deployed, it must be understood that frequent changes of the IGP distance towards a certain prefix may result in equally frequent transmission of BGP updates about that prefix.

- 当部署本文件的程序时,必须理解,IGP距离向某个前缀的频繁变化可能导致关于该前缀的BGP更新的传输频率相同。

- In an IGP deployment, there are certain situations in which a network link may be temporarily assigned a metric whose value is the maximum metric value (or close to the maximum) for that IGP. This is known as "costing out" the link. A link may be "costed out" to deflect traffic from the link before the link is actually brought down or to discourage traffic from using a link until all the necessary state for that link has been set up (e.g., [LDP-IGP-SYNC]). This assumes, of course, that a path containing a "costed out" link will have a total distance that is larger than any alternate path within the same IGP area; in that case, the normal IGP decision process will choose the path that does not contain the "costed out" link.

- 在IGP部署中,在某些情况下,可能会临时为网络链路分配一个度量,其值为该IGP的最大度量值(或接近最大值)。这被称为链接的“成本计算”。链路可能被“消耗掉”,以在链路实际关闭之前使通信量偏离链路,或阻止通信量使用链路,直到该链路的所有必要状态都已建立(例如,[LDP-IGP-SYNC])。当然,这假设包含“成本计算”链路的路径的总距离大于同一IGP区域内的任何备用路径;在这种情况下,正常的IGP决策过程将选择不包含“成本计算”链路的路径。

Costing out a link will have the same effect on BGP routes that carry the AIGP attribute. The value of the AIGP TLV will be larger for a route (to a given prefix) that contains a "costed out" link than for a route (to the same prefix) that does not. It must be understood, though, that a route that carries an AIGP attribute will be preferred to a route that does not, no matter what the value of the AIGP TLV is. This is similar to the behavior in, e.g., an OSPF area, where an intra-area route is preferred to an inter-area or external route, even if the intra-area route's distance is large.

计算链路成本将对具有AIGP属性的BGP路由产生相同的影响。对于包含“成本支出”链路的路由(到给定前缀),AIGP TLV的值将大于不包含“成本支出”链路的路由(到相同前缀)。但是,必须理解的是,无论AIGP TLV的值是多少,携带AIGP属性的路由都比不携带AIGP属性的路由更可取。这类似于例如OSPF区域中的行为,其中区域内路由优于区域间路由或外部路由,即使区域内路由的距离较大。

6. IANA Considerations
6. IANA考虑

IANA has assigned the codepoint 26 in the "BGP Path Attributes" registry to the AIGP attribute.

IANA已将“BGP路径属性”注册表中的代码点26分配给AIGP属性。

IANA has created a registry for "BGP AIGP Attribute Types". The Type field consists of a single octet, with possible values from 1 to 255. (The value 0 is "Reserved".) The registration procedure for this registry is "Standards Action". Type 1 is defined as "AIGP" and refers to this document.

IANA已经为“BGP AIGP属性类型”创建了一个注册表。类型字段由一个八位字节组成,可能值为1到255。(值0为“保留”。)此注册表的注册过程为“标准操作”。类型1定义为“AIGP”,并参考本文件。

7. Security Considerations
7. 安全考虑

The spurious introduction, through error or malfeasance, of an AIGP attribute could result in the selection of paths other than those desired.

通过错误或渎职,虚假引入AIGP属性可能导致选择所需路径以外的路径。

Improper configuration on both ends of an EBGP connection could result in an AIGP attribute being passed from one service provider to another. This would likely result in an unsound selection of paths.

EBGP连接两端配置不当可能导致AIGP属性从一个服务提供商传递到另一个服务提供商。这可能会导致路径选择不合理。

8. Acknowledgments
8. 致谢

The authors would like to thank Waqas Alam, Rajiv Asati, Alia Atlas, Ron Bonica, Bruno Decraene, Brian Dickson, Clarence Filsfils, Sue Hares, Anoop Kapoor, Pratima Kini, Thomas Mangin, Robert Raszuk, Yakov Rekhter, Eric Rosenberg, Samir Saad, John Scudder, Shyam Sethuram, and Ilya Varlashkin for their input.

作者要感谢瓦卡斯·阿拉姆、拉吉夫·阿萨蒂、艾莉亚·阿特拉斯、罗恩·博尼卡、布鲁诺·德雷恩、布赖恩·迪克森、克拉伦斯·菲尔斯、苏·哈尔斯、阿努普·卡普尔、普拉蒂玛·基尼、托马斯·曼金、罗伯特·拉祖克、雅科夫·雷克特、埃里克·罗森博格、萨米尔·萨阿德、约翰·斯卡德尔、希亚姆·塞图拉姆和伊利亚·瓦拉什金的投入。

9. References
9. 工具书类
9.1. Normative Reference
9.1. 规范性引用文件

[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[BGP]Rekhter,Y.,Ed.,Li,T.,Ed.,和S.Hares,Ed.,“边境网关协议4(BGP-4)”,RFC 42712006年1月。

[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月。

9.2. Informative References
9.2. 资料性引用

[ADD-PATH] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", Work in Progress, October 2013.

[ADD-PATH]Walton,D.,Retana,A.,Chen,E.,和J.Scudder,“BGP中多路径的广告”,正在进行的工作,2013年10月。

[BESTEXT] Marques, P., Fernando, R., Mohapatra, P., and H. Gredler, "Advertisement of the best external route in BGP", Work in Progress, January 2012.

[BESTEXT]Marques,P.,Fernando,R.,Mohapatra,P.,和H.Gredler,“BGP最佳外部路线广告”,正在进行的工作,2012年1月。

[BGP-CONFED] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, August 2007.

[BGP-CONFED]Traina,P.,McPherson,D.,和J.Scudder,“BGP自治系统联合会”,RFC 5065,2007年8月。

[BGP-ERROR] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", Work in Progress, June 2014.

[BGP-ERROR]Chen,E.,Scudder,J.,Mohapatra,P.,和K.Patel,“修改BGP更新消息的错误处理”,正在进行的工作,2014年6月。

[LDP-IGP-SYNC] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009.

[LDP-IGP-SYNC]Jork,M.,Atlas,A.,和L.Fang,“LDP-IGP同步”,RFC 54432009年3月。

Authors' Addresses

作者地址

Pradosh Mohapatra Sproute Networks

Pradosh Mohapatra Sproute网络

   EMail: mpradosh@yahoo.com
        
   EMail: mpradosh@yahoo.com
        

Rex Fernando Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 US

美国加利福尼亚州圣何塞塔斯曼大道170号,雷克斯费尔南多思科系统公司,邮编95134

   EMail: rex@cisco.com
        
   EMail: rex@cisco.com
        

Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 US

Eric C.Rosen Cisco Systems,Inc.美国马萨诸塞州伯斯堡马萨诸塞大道1414号,邮编01719

   EMail: erosen@cisco.com
        
   EMail: erosen@cisco.com
        

James Uttaro AT&T 200 S. Laurel Avenue Middletown, NJ 07748 US

James Uttaro AT&T美国新泽西州米德尔敦月桂大道200号,邮编07748

   EMail: uttaro@att.com
        
   EMail: uttaro@att.com