[要約] RFC 7311は、BGPにおける累積IGPメトリック属性に関する要約と目的を提供しています。このRFCの目的は、BGP経路選択においてIGPメトリックを考慮するための属性を定義することです。
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.
単一の管理ドメイン（IGP）内で実行するように設計されたルーティングプロトコルは、通常、各リンクにメトリックを割り当て、2つのノード間にインストールされているパスとして、合計距離（メトリックの合計）パスに沿った各リンクの）が最小化されます。多数の独立した管理ドメイン（自律システム）でルーティングを提供するように設計されたBGPは、メトリックを使用してパス選択を決定しません。一般に、そうしようとすると、スケーラビリティに関する重大な問題と、管理間の調整に関する問題が発生することが認識されています。ただし、単一の管理者が複数の隣接するBGPネットワークを実行する展開もあります。このような場合、その単一の管理ドメイン内では、IGPと同じように、BGPがメトリックに基づいてパスを選択することが望ましい場合があります。このドキュメントの目的は、そのための仕様を提供することです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
単一の管理ドメイン内で実行するように設計された多くのルーティングプロトコルがあります。これらは総称して "Interior Gateway Protocols"（IGP）として知られています。通常、各リンクには特定の「メトリック」値が割り当てられます。次に、2つのノード間のパスに「距離」を割り当てることができます。これは、そのパスに属するすべてのリンクのメトリックの合計です。 IGPは、任意の2つのノード間の「最短」（最小距離）パスを選択します。おそらく、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とは異なり、任意の数の管理ドメイン（「自律システム」または「AS」）で実行されるように設計されており、さまざまな管理間の調整が制限されています。 BGPは、メトリックに基づいてパス選択を決定しません。 「AS間メトリック」などはありません。これには2つの基本的な理由があります。
- 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.
- 共通の管理ドメイン内の2つのノード間の距離は、そのドメインで発生したイベントにより、いつでも変化する可能性があります。これらの変更は、ドメインの境界ルーターが実際にアドレスプレフィックスのセットに対して異なる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.
- ドメイン間ルーティングの基本原則は、さまざまな管理ドメインが独自のポリシーを持っている可能性があることです。これらのポリシーは、他のドメインに明らかにする必要はなく、他のドメインが同意する必要もありません。しかし、インターネットでのAS間メトリックの使用は、まさにこれらの効果をもたらします。
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 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.
ただし、単一の管理者が複数の隣接するASに細分されたネットワークを実行していて、それぞれがBGPを実行しているデプロイメントもあります。単一の管理ドメインが複数のASに分割される理由はいくつかあります（この場合、ASは実際には自律的ではありません）。特定の環境では既存のIGPが適切に拡張されない可能性があります。単一のIGPドメインを使用して取得できるトポロジーよりも一般化されたトポロジーが望まれる場合があります。 IGPでサポートできるよりも詳細なルーティングポリシーが必要な場合があります。このような展開では、BGPがIGPメトリックに基づいてルーティングを決定できるようにすると、ノードが同じ管理ドメイン内の2つの異なるASにある場合でも、BGPが2つのノード間の最短パスを選択できるようになります。
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メトリックに基づいて値を運ぶ、すでにこのようなことをしている実装がいくつかあります。ただし、BGP決定プロセスはAS_PATHの長さなどの他の要素を優先するため、実際にはIGPのような最短パスルーティングは提供されません。また、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.
このドキュメントでは、「累積IGPメトリック属性」または「AIGP属性」と呼ばれる新しいオプションの非推移的BGP属性を定義し、それを使用する手順を指定します。
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属性が管理ドメインの境界を越えてインターネットに「漏れ出す」のを防ぎます。一般的な管理ドメイン内のASのセットを「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属性が表示されないことが保証されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
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のセット）として定義されています。このような各TLVは、図1に示すようにエンコードされます。
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のオクテット単位の長さをエンコードする2つのオクテット（タイプおよび長さフィールドを含む）。長さは、符号なし2進整数としてエンコードされます。 （最小長は3であり、値フィールドが存在しないことを示しています。）
- Value: A field containing zero or more octets.
- 値：0個以上のオクテットを含むフィールド。
This document defines only a single such TLV, the "AIGP TLV". The AIGP TLV is encoded as follows:
このドキュメントでは、そのようなTLVの1つである「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属性が作成されるとき、それは1つだけのAIGP TLVを含む必要があります。ただし、複数のAIGP TLVが含まれている場合は、セクション3.4および4で説明されているように、最初の1つだけが使用されます。このドキュメントの残りの部分では、「AIGP TLVの値」という用語を使用して、 AIGP属性の最初のAIGP TLV。 AIGP属性が渡される場合、AIGP属性内の他のAIGP TLVは変更せずに渡される必要があります。
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.
このドキュメントでは、各ルータが何らかのトンネリングを使用してパケットをBGPネクストホップに配信するネットワークでのAIGP属性の使用のみを考慮しています。他のシナリオでの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属性をサポートしているが、そのクライアントの一部がサポートしていない場合、結果として生じるルーティングの選択はすべて、意図したルーティングポリシーを反映していない場合があります。
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.
AIGP属性コードポイントがあり、推移ビットも設定されているBGPパス属性を受信した場合、その属性は不正な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に最大値0xffffffffffffffffが含まれている場合、属性は不正な形式であると見なされるべきであり、このセクションで指定されているように破棄されるべきです（SHOULD）。 （TLV値はこれ以上増加できないため、メトリックベースのパス選択には役立ちません。）
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_SESSIONのデフォルト値を「有効」にする必要があります（SHOULD）。
- For all other External BGP (EBGP) sessions, the default value of AIGP_SESSION MUST be "disabled".
- 他のすべての外部BGP（EBGP）セッションでは、AIGP_SESSIONのデフォルト値を「無効」にする必要があります。
The AIGP attribute MUST NOT be sent on any BGP session for which AIGP_SESSION is disabled.
AIGP_SESSIONが無効になっているBGPセッションでは、AIGP属性を送信してはなりません（MUST NOT）。
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_SESSIONが無効になっているBGPセッションでAIGP属性を受信した場合、その属性は、認識されない非推移的属性であるかのように正確に処理する必要があります。つまり、「静かに無視し、他のBGPピアに渡さないでください」（[BGP]、セクション5を参照）。ただし、属性が受信されたという事実はログに記録する必要があります（レート制限された方法で）。
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_ORIGINATEのデフォルト値は「無効」でなければなりません。
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スピーカーは、そのパスがBGPスピーカーが属するAIGP管理ドメインの外側につながるルートにAIGP属性を追加してはなりません（MUST NOT）。 AIGP属性が使用されている場合、IGPルーティングの変更はBGPルーティングに直接影響します。 AIGP属性をカスタマールート、インターネットルート、または特定の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
- ルートは、AS_PATH属性が空のIBGP学習ルートです。または
- 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_PATHには、BGPスピーカーと同じAIGP管理ドメインにあるASのみが含まれています。
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は、Rが自身をネクストホップとして設定しないルートにAIGP属性を追加してはなりません（MUST NOT）。
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_ORIGINATEを "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:
アドレスプレフィックスPへのBGPルートの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がアドレスプレフィックスPへのIGPルートをBGPに再配布している場合、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は、RからPまでの距離が設定されているアドレスプレフィックスPへの静的ルートをBGPに再配布している可能性があります。この距離は、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は、ネクストホップNでプレフィックスPへのBGP学習ルートを受信してインストールした可能性があります。または、ネクストホップNでPへの静的ルートを再配布している可能性があります。次に、
* 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値として使用できます（MAY）。
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はAIGP属性のAIGP TLVの新しい値を含む新しいBGP更新を発行する必要があります。 （ここでは、「距離」という用語を使用して、発信者がAIGP TLVに割り当てる値を指しますが、計算されます。セクション3.4.1を参照してください。）ただし、新しい距離とAIGPでアドバタイズされた距離の差がTLVが構成可能なしきい値よりも小さい場合、更新は抑制される場合があります。
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が、値がAであるAIGP属性と、値が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属性値を変更してはなりません（MUST NOT）。
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値はその最大の符号なし値0xffffffffffffffffで上限を設定する必要があります。 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に変更するとします。 R2へのR1のルートが（a）IGP学習ルートまたは（b）再帰的なネクストホップ解決を必要としない静的ルートの場合、R1は、AにR1からの距離を追加することにより、AIGP TLVの値を増やす必要があります。 R2。この距離は、IGPが計算したR1からR2までの距離、またはポリシーによって決定された値のいずれかです。ただし、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メトリックに適切に匹敵するようなものであるべきです（SHOULD）。たとえば、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. XNHへのルートを検索します。
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 TLVのないAIGP属性がある場合、AIGP属性は変更せずに渡すことができます（MAY）。
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によって変更されていない、R1によって受信されたときのルートのAIGP TLV値であることです。）
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属性が複数のASにまたがっており、それぞれが独自のIGPドメインを持っている場合、IGPが異なる場合（たとえば、一部のOSPFと一部のIS-IS）、または意味が異なる場合、これらの手順で実用的な結果が得られないことは明らかです。 IGPによってメトリックの値が異なります（たとえば、メトリックが一部のIGPドメインの帯域幅を表し、他のドメインの遅延を表す場合）。これらの手順では、AS-BGP間リンク（IGPが実行されていない）または静的ルートに割り当てられたメトリックがIGPメトリックと比較できない場合にも、適切な結果が得られる可能性は低いです。そのようなケースはすべて、現在のドキュメントの範囲外です。
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決定プロセスがタイブレイク手順を実行せずにルートをインストールすることがあります。これは、たとえば、特定のプレフィックスへのルートが1つだけ優先度が最も高い場合に発生する可能性があります（[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属性は考慮されません。
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の最小値に関連付けられていないすべてのルートを考慮から削除します。
Suppose that a given router R1 is comparing two BGP-learned routes, such that either:
特定のルーターR1が、BGPで学習した2つのルートを比較しているとします。
- the two routes have equal AIGP TLV values, or else
- 2つのルートのAIGP TLV値が等しい、または
- neither of the two routes has an AIGP attribute containing an AIGP TLV.
- 2つのルートのどちらにも、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.
ルートの内部コストは、ルーティングテーブルを使用してルートのNEXT_HOPへのメトリックを計算することによって決定されます。
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 TLVのAIGP属性がある場合は、セクション3.4.3の手順に従って計算されたAIGP TLV値にAを設定します。
- 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]の「内部コスト」タイブレーカーが適用されます。
- 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.
- AIGP属性を使用して目的のルーティングポリシーを実現することは、各BGPスピーカーがそれを使用して複数のルートから選択できる場合により効果的です。したがって、[BESTEXT]および[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属性を持つルートは、そうでないルートよりも優先されることを理解する必要があります。これは、エリア内ルートの距離が遠くても、エリア内ルートがエリア間ルートまたは外部ルートよりも優先されるOSPFエリアなどの動作に似ています。
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属性タイプ」のレジストリを作成しました。 Typeフィールドは1オクテットで構成され、可能な値は1〜255です（値0は「予約済み」です）。このレジストリの登録手順は「標準アクション」です。タイプ1は「AIGP」として定義され、このドキュメントを参照します。
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属性が渡される可能性があります。これにより、パスの選択が不正確になる可能性があります。
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.
著者は、ワカスアラム、ラジブアサティ、アリアアトラス、ロンボニカ、ブルーノデクレイエン、ブライアンディクソン、クラレンスフィルスフィル、スーヘレス、アヌープカプール、プラティマキニ、トーマスマンギン、ロバートラズク、ヤコフレクター、エリックロゼンバーグ、サミルサードに感謝します、John Scudder、Shyam Sethuram、Ilya Varlashkinからの情報提供。
[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。、編、Li、T。、編、およびS. Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年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月。
[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での複数のパスのアドバタイズ」、Work in Progress、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での最良の外部ルートの広告」、Work in Progress、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 UPDATEメッセージのエラー処理の改訂版」、進行中の作業、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 Synchronization」、RFC 5443、2009年3月。
Authors' Addresses
著者のアドレス
Pradosh Mohapatra Sproute Networks
Pradosh Mohapatra Sprout Networks
EMail: mpradosh@yahoo.com
Rex Fernando Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 US
Rex Fernando Cisco Systems、Inc. 170 Tasman Drive San Jose、CA 95134 US
EMail: rex@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 US
えりｃ Ｃ。 ろせん しｓこ Ｓｙｓてｍｓ、 いんｃ。 １４１４ まっさちゅせっｔｓ あゔぇぬえ ぼｘぼろうｇｈ、 ま、 ０１７１９ うＳ
EMail: erosen@cisco.com
James Uttaro AT&T 200 S. Laurel Avenue Middletown, NJ 07748 US
James Uttaro AT＆T 200 S. Laurel Avenue Middletown、NJ 07748 US
EMail: uttaro@att.com