[要約] RFC 7964は、BGP持続的な経路振動の解決策に関するガイドラインです。このRFCの目的は、BGPネットワークでの経路振動の問題を理解し、その解決策を提供することです。

Internet Engineering Task Force (IETF)                         D. Walton
Request for Comments: 7964                              Cumulus Networks
Category: Standards Track                                      A. Retana
ISSN: 2070-1721                                                  E. Chen
                                                     Cisco Systems, Inc.
                                                              J. Scudder
                                                        Juniper Networks
                                                          September 2016
        

Solutions for BGP Persistent Route Oscillation

BGP永続ルートオシレーションのソリューション

Abstract

概要

Routing information reduction by BGP Route Reflection or Confederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies. This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network.

BGPルートリフレクションまたはコンフェデレーションによるルーティング情報の削減により、特定のルーティングセットアップとネットワークトポロジで永続的な内部BGPルートの発振が発生する可能性があります。このドキュメントでは、ネットワークでこれらのルートの振動を排除するために使用できる2セットの追加パスを指定します。

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 7841.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc7964.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7964で入手できます。

Copyright Notice

著作権表示

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

Copyright(c)2016 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Advertise All the Available Paths . . . . . . . . . . . . . .   3
   4.  Advertise the Group Best Paths  . . . . . . . . . . . . . . .   3
   5.  Route Reflection and Confederation  . . . . . . . . . . . . .   4
     5.1.  Route Reflection  . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Confederation . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Deployment Considerations . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Why the Group Best Paths Are Adequate  . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
        
1. Introduction
1. はじめに

As documented in [RFC3345], routing information reduction by BGP Route Reflection [RFC4456] or BGP Confederation [RFC5065] can result in persistent Internal BGP (IBGP) route oscillations with certain routing setups and network topologies. Except for a couple of artificially engineered network topologies, the MULTI_EXIT_DISC (MED) attribute [RFC4271] has played a pivotal role in virtually all known persistent IBGP route oscillations. For the sake of brevity, we use the term "MED-induced route oscillation" hereafter to refer to a persistent IBGP route oscillation in which the MED plays a role.

[RFC3345]で文書化されているように、BGPルートリフレクション[RFC4456]またはBGPコンフェデレーション[RFC5065]によるルーティング情報の削減は、特定のルーティング設定とネットワークトポロジで永続的な内部BGP(IBGP)ルートの発振を引き起こす可能性があります。いくつかの人工的に設計されたネットワークトポロジーを除いて、MULTI_EXIT_DISC(MED)属性[RFC4271]は、事実上すべての既知の永続的なIBGPルートの振動で極めて重要な役割を果たしています。簡潔にするために、以下では「MED誘発ルート振動」という用語を使用して、MEDが役割を果たす永続的なIBGPルート振動を指す。

In order to eliminate MED-induced route oscillations and to achieve consistent routing in a network, a route reflector or a confederation Autonomous System Border Router (ASBR) needs to advertise more than just the best path for an address prefix. Our goal is to identify the necessary set of paths for an address prefix that needs to be advertised by a route reflector or a confederation ASBR to prevent the condition.

MEDに起因するルートの振動を排除し、ネットワークで一貫したルーティングを実現するために、ルートリフレクターまたはコンフェデレーション自律システムボーダールーター(ASBR)は、アドレスプレフィックスの最適なパス以上のものをアドバタイズする必要があります。私たちの目標は、状態を防ぐためにルートリフレクターまたはコンフェデレーションASBRによってアドバタイズする必要があるアドレスプレフィックスに必要なパスのセットを識別することです。

In this document, we describe two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS-based Group Best Paths, and would be sufficient to eliminate MED-induced route oscillations (subject to certain commonly adopted topological constraints).

このドキュメントでは、BGPルートリフレクタまたはコンフェデレーションASBRによってアドバタイズして、ネットワーク内のMEDに起因するルートの振動を排除できる、アドレスプレフィックスの2セットのパスについて説明します。最初のセットには、使用可能なすべてのパスが含まれ、完全なIBGPメッシュと同じルーティングの一貫性が実現されます。最初のセットのサブセットである2番目のセットには、ネイバーASベースのグループベストパスが含まれており、MEDに起因するルートの振動を排除するのに十分です(特定のトポロジー制約が適用される場合があります)。

These paths can be advertised using the mechanism described in ADD-PATH [RFC7911] for advertising multiple paths. No other assumptions in functionality beyond the base BGP specification [RFC4271] are made.

これらのパスは、複数のパスをアドバタイズするためのADD-PATH [RFC7911]で説明されているメカニズムを使用してアドバタイズできます。基本的なBGP仕様[RFC4271]を超える機能に関する他の前提はありません。

2. Requirements Language
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].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Advertise All the Available Paths
3. 利用可能なすべてのパスをアドバタイズします

Observe that in a network that maintains a full IBGP mesh, all the BGP speakers have consistent and equivalent routing information. Such a network is thus free of MED-induced route oscillations and other routing inconsistencies such as forwarding loops.

完全なIBGPメッシュを維持するネットワークでは、すべてのBGPスピーカーが一貫した同等のルーティング情報を持っていることに注意してください。したがって、このようなネットワークでは、MEDに起因するルートの振動や、転送ループなどの他のルーティングの不整合がなくなります。

Therefore, one approach is to allow a route reflector or a confederation ASBR to advertise all the available paths for an address prefix. Clearly this approach would yield the same amount of routing information and achieve the same routing consistency as the full IBGP mesh in a network. In this document, "Available Paths" refers to the advertisement of all the available paths.

したがって、1つのアプローチは、ルートリフレクタまたはコンフェデレーションASBRがアドレスプレフィックスに使用可能なすべてのパスをアドバタイズできるようにすることです。明らかに、このアプローチは、ネットワーク内の完全なIBGPメッシュと同じ量のルーティング情報を生成し、同じルーティングの一貫性を実現します。このドキュメントでは、「使用可能なパス」とは、使用可能なすべてのパスの通知を指します。

This approach can be implemented using the mechanism described in ADD-PATH [RFC7911] for advertising multiple paths for certain prefixes.

このアプローチは、特定のプレフィックスの複数のパスをアドバタイズするために、ADD-PATH [RFC7911]で説明されているメカニズムを使用して実装できます。

For the sake of scalability, the advertisement of multiple paths should be limited to those prefixes that are affected by MED-induced route oscillation in a network carrying a large number of alternate paths. A detailed description of how these oscillations can occur can be found in [RFC3345]; the description of how a node would locally detect such conditions is outside the scope of this document.

スケーラビリティのために、複数のパスのアドバタイズは、多数の代替パスを伝送するネットワークでMEDによって引き起こされるルートオシレーションの影響を受けるプレフィックスに制限する必要があります。これらの振動がどのように発生するかについての詳細な説明は、[RFC3345]にあります。ノードがそのような状態をローカルに検出する方法の説明は、このドキュメントの範囲外です。

4. Advertise the Group Best Paths
4. グループの最適なパスをアドバタイズする

The term "neighbor-AS" for a route refers to the neighboring autonomous system (AS) from which the route was received. The calculation of the neighbor-AS is specified in Section 9.1.2.2 of [RFC4271], and Section 5.3 of [RFC5065]. By definition, the MED is comparable only among routes with the same neighbor-AS. Thus, the route selection procedures specified in [RFC4271] would conceptually involve two steps: first, organize the paths for an address prefix into groups according to their respective neighbor-ASes, and calculate the most preferred one (termed "Group Best Path") for each of the groups; then, calculate the overall best path among all the Group Best Paths.

ルートの「neighbor-AS」という用語は、ルートの送信元である隣接自律システム(AS)を指します。 neighbor-ASの計算は、[RFC4271]のセクション9.1.2.2、および[RFC5065]のセクション5.3で指定されています。定義により、MEDは同じネイバーASを持つルート間でのみ比較可能です。したがって、[RFC4271]で指定されたルート選択手順は、概念的に2つのステップを含みます。最初に、アドレスプレフィックスのパスをそれぞれのネイバーASに従ってグループに編成し、最も優先されるもの(「グループの最適パス」と呼ばれます)を計算します。グループごとに;次に、すべてのグループ最適パスの中から全体的な最適パスを計算します。

As a practice that is generally recommended (in [RFC4456] and [RFC5065]) and widely adopted, a route reflection cluster or a confederation sub-AS should be designed such that BGP routes from within the cluster (or confederation sub-AS) are preferred over routes from other clusters (or confederation sub-AS) when the decision is based on the IGP cost to the BGP NEXT_HOP. This is typically done by setting IGP metrics for links within a cluster (or confederation sub-AS) to be much smaller than the IGP metrics for the links between the clusters (or confederation sub-AS). This practice helps achieve consistent routing within a route reflection cluster or a confederation sub-AS.

[RFC4456]と[RFC5065]で一般的に推奨され、広く採用されている手法として、ルートリフレクションクラスターまたはコンフェデレーションサブASは、クラスター(またはコンフェデレーションサブAS)内からのBGPルートが決定がBGP NEXT_HOPへのIGPコストに基づく場合、他のクラスター(またはコンフェデレーションサブAS)からのルートよりも優先されます。これは通常、クラスター(またはコンフェデレーションサブAS)内のリンクのIGPメトリックを、クラスター(またはコンフェデレーションサブAS)間のリンクのIGPメトリックよりもはるかに小さく設定することで行われます。このプラクティスは、ルートリフレクションクラスタまたはコンフェデレーションサブAS内で一貫したルーティングを実現するのに役立ちます。

When the aforementioned practice for devising a route reflection cluster or confederation sub-AS is followed in a network, we claim that the advertisement of all the Group Best Paths by a route reflector or a confederation ASBR is sufficient to eliminate MED-induced route oscillations in the network. This claim is validated in Appendix A.

ネットワークでルートリフレクションクラスタまたはコンフェデレーションサブASを考案する前述の慣例に従っている場合、ルートリフレクタまたはコンフェデレーションASBRによるすべてのグループベストパスのアドバタイズでMEDによるルートの振動を排除するには十分であると主張します。ネットワーク。この主張は付録Aで検証されています。

Note that a Group Best Path for an address prefix can be identified by the combination of the address prefix and the neighbor-AS. Thus, this approach can be implemented using the mechanism described in ADD-PATH [RFC7911] for advertising multiple paths, and in this case, the neighbor-AS of a path may be used as the path identifier of the path.

アドレスプレフィックスのグループ最適パスは、アドレスプレフィックスとネイバーASの組み合わせで識別できることに注意してください。したがって、このアプローチは、ADD-PATH [RFC7911]で説明されているメカニズムを使用して実装でき、複数のパスをアドバタイズします。この場合、パスのネイバーASをパスのパス識別子として使用できます。

It should be noted that the approach of advertising the Group Best Paths requires certain topological constraints to be satisfied in order to eliminate MED-induced route oscillation. Specific topological considerations are described in [RFC3345].

Group Best Pathsをアドバタイズするアプローチでは、MEDに起因するルートの振動を排除するために、特定のトポロジー制約を満たす必要があることに注意してください。特定のトポロジーの考察は[RFC3345]で説明されています。

5. Route Reflection and Confederation
5. ルートリフレクションとコンフェデレーション

To allow a route reflector or a confederation ASBR to advertise either the Available Paths or Group Best Paths using the mechanism described in ADD-PATH [RFC7911], the following revisions are proposed for BGP Route Reflection and BGP Confederation.

ルートリフレクタまたはコンフェデレーションASBRが、ADD-PATH [RFC7911]で説明されているメカニズムを使用して、利用可能なパスまたはグループの最適なパスをアドバタイズできるようにするために、BGPルートリフレクションおよびBGPコンフェデレーションに次の改訂が提案されています。

5.1. Route Reflection
5.1. ルートリフレクション

For a particular <Address Family Identifier (AFI), Subsequent Address Family (SAFI)>, a route reflector MUST include the <AFI, SAFI> with the "Send/Receive" field set to 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability [RFC7911] advertised to an IBGP peer. When the ADD-PATH Capability is also received from the IBGP peer with the "Send/Receive" field set to 1 (receive multiple paths) or 3 (send/receive multiple paths) for the same <AFI, SAFI>, then the following procedures apply:

特定の<Address Family Identifier(AFI)、Subsequent Address Family(SAFI)>の場合、ルートリフレクターは、「A / S」フィールドに2(複数のパスを送信)または3(送信)を設定して、<AFI、SAFI>を含める必要があります。 IBGPピアにアドバタイズされるADD-PATH機能[RFC7911]の/複数のパスを受信/受信します。同じ<AFI、SAFI>に対して「送信/受信」フィールドを1(複数のパスを受信)または3(複数のパスを送信/受信)に設定して、ADD-PATH機能もIBGPピアから受信した場合、次のようになります。手順が適用されます:

If the peer is a route reflection client, the route reflector MUST advertise to the peer the Group Best Paths (or the Available Paths) received from its non-client IBGP peers. The route reflector MAY also advertise to the peer the Group Best Paths (or the Available Paths) received from its clients.

ピアがルートリフレクションクライアントの場合、ルートリフレクタは、その非クライアントIBGPピアから受信したグループベストパス(または使用可能なパス)をピアにアドバタイズしなければなりません(MUST)。ルートリフレクタは、クライアントから受信したグループの最適パス(または使用可能なパス)もピアにアドバタイズできます(MAY)。

If the peer is a non-client, the route reflector MUST advertise to the peer the Group Best Paths (or the Available Paths) received from its clients.

ピアが非クライアントである場合、ルートリフレクタは、そのクライアントから受信したグループ最適パス(または使用可能なパス)をピアにアドバタイズする必要があります。

5.2. Confederation
5.2. 連合

For a particular <AFI, SAFI>, a confederation ASBR MUST include the <AFI, SAFI> with the "Send/Receive" field set to 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability [RFC7911] advertised to an IBGP peer, and to a confederation external peer. When the ADD-PATH Capability is also received from the IBGP peer or the confederation-external peer with the "Send/Receive" field set to 1 (receive multiple paths) or 3 (send/receive multiple paths) for the same <AFI, SAFI>, then the following procedures apply:

特定の<AFI、SAFI>の場合、コンフェデレーションASBRは、ADD-PATHに「送信/受信」フィールドが2(複数のパスを送信)または3(複数のパスを送信/受信)に設定された<AFI、SAFI>を含める必要があります。機能[RFC7911]は、IBGPピア、および連合外部ピアにアドバタイズされます。同じ<AFIに対して、「送信/受信」フィールドが1(複数のパスを受信)または3(複数のパスを送信/受信)に設定されたIBGPピアまたはコンフェデレーション外部ピアからADD-PATH機能も受信される場合、 SAFI>の場合、次の手順が適用されます。

If the peer is internal, the confederation ASBR MUST advertise to the peer the Group Best Paths (or the Available Paths) received from its confederation-external peers.

ピアが内部の場合、コンフェデレーションASBRは、そのコンフェデレーション外部ピアから受信したグループベストパス(または使用可能なパス)をピアにアドバタイズする必要があります。

If the peer is confederation-external, the confederation ASBR MUST advertise to the peer the Group Best Paths (or the Available Paths) received from its IBGP peers.

ピアがコンフェデレーション外部の場合、コンフェデレーションASBRは、そのIBGPピアから受信したグループベストパス(または使用可能なパス)をピアにアドバタイズする必要があります(MUST)。

6. Deployment Considerations
6. 導入に関する考慮事項

Some route oscillations, once detected, can be eliminated by simple configuration workarounds. As carrying additional paths impacts the memory usage and routing convergence in a network, it is recommended that the impact be evaluated and the approach of using a configuration workaround be considered in deciding whether to deploy the proposed mechanism in a network. In addition, the advertisement of multiple paths should be limited to those prefixes that are affected by MED-induced route oscillation.

一部のルートの振動は、一度検出されると、簡単な設定の回避策によって解消できます。追加のパスを伝送するとネットワークのメモリ使用量とルーティングの収束に影響するため、提案されたメカニズムをネットワークに展開するかどうかを決定する際には、影響を評価し、構成回避策を使用するアプローチを検討することをお勧めします。さらに、複数のパスのアドバタイズは、MEDに起因するルートの振動の影響を受けるプレフィックスに限定する必要があります。

While the route reflectors or confederation ASBRs in a network need to advertise the Group Best Paths or Available Paths, the vast majority of the BGP speakers in the network only need to receive the Group Best Paths or Available Paths, which would involve only minor software changes.

ネットワーク内のルートリフレクターまたはコンフェデレーションASBRは、グループの最適パスまたは使用可能なパスをアドバタイズする必要がありますが、ネットワーク内のBGPスピーカーの大部分は、グループの最適パスまたは使用可能なパスのみを受信する必要があります。 。

It should be emphasized that, in order to eliminate MED-induced route oscillations in a network using the approach of advertising the Group Best Paths, the recommended practice for devising a route reflection cluster or confederation sub-AS with respect to the IGP metrics ([RFC4456] [RFC5065]) should be followed.

Group Best Pathsをアドバタイズするアプローチを使用してネットワーク内のMED誘発ルート振動を排除するために、IGPメトリックに関してルートリフレクションクラスタまたはコンフェデレーションサブASを考案するための推奨される方法([ RFC4456] [RFC5065])に従う必要があります。

It is expected that the approach of advertising the Group Best Paths would be adequate to achieve consistent routing for the vast majority of the networks. For a network that has a large number of alternate paths, the approach should be a good choice as the number of paths advertised by a reflector or a confederation ASBR is bounded by the number of the neighbor-ASes for a particular address prefix. The additional states for an address prefix would also be per neighbor-AS rather than per path. The number of neighbor-ASes for a particular address prefix is typically small because of the limited number of upstream providers for a customer and the nature of advertising only customer routes at the inter-exchange points.

Group Best Pathsをアドバタイズするアプローチは、ネットワークの大部分に対して一貫したルーティングを実現するのに十分であると予想されます。代替パスが多数あるネットワークの場合、リフレクターまたはコンフェデレーションASBRによってアドバタイズされるパスの数は、特定のアドレスプレフィックスのネイバーASの数によって制限されるため、このアプローチは適切な選択です。アドレスプレフィックスの追加の状態も、パスごとではなくネイバーASごとになります。特定のアドレスプレフィックスのネイバーASの数は、顧客のアップストリームプロバイダーの数が限られていることと、交換ポイントで顧客ルートのみをアドバタイズする性質があるため、通常は少なくなります。

The approach of advertising the Group Best Paths, however, may still be inadequate for certain networks to avoid other routing inconsistencies such as forwarding loops. The required topological constraints could also be operationally challenging. In these cases the approach of advertising the Available Paths may be used, but should be limited to those prefixes that are affected by MED-induced route oscillation in a network carrying a large number of alternate paths.

ただし、Group Best Pathsをアドバタイズするアプローチは、転送ループなどの他のルーティングの不整合を回避するために、特定のネットワークでは依然として不十分な場合があります。必要なトポロジーの制約も、運用上困難な場合があります。これらの場合、使用可能なパスをアドバタイズするアプローチを使用できますが、多数の代替パスを伝送するネットワークでMEDによって引き起こされるルートの振動の影響を受けるプレフィックスに限定する必要があります。

7. Security Considerations
7. セキュリティに関する考慮事項

This extension to BGP does not change the underlying security issues inherent in the existing BGP [RFC4271].

BGPへのこの拡張は、既存のBGP [RFC4271]に固有の根本的なセキュリティ問題を変更しません。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4(BGP-4)」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<http://www.rfc-editor.org/info/rfc4271>。

[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <http://www.rfc-editor.org/info/rfc4456>.

[RFC4456]ベイツ、T。、チェン、E。、およびR.チャンドラ、「BGPルートリフレクション:フルメッシュ内部BGP(IBGP)の代替」、RFC 4456、DOI 10.17487 / RFC4456、2006年4月、<http:/ /www.rfc-editor.org/info/rfc4456>。

[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <http://www.rfc-editor.org/info/rfc5065>.

[RFC5065] Traina、P.、McPherson、D。、およびJ. Scudder、「BGPの自律システム連合」、RFC 5065、DOI 10.17487 / RFC5065、2007年8月、<http://www.rfc-editor.org/ info / rfc5065>。

[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <http://www.rfc-editor.org/info/rfc7911>.

[RFC7911] Walton、D.、Retana、A.、Chen、E。、およびJ. Scudder、「Advertisement of Multiple Paths in BGP」、RFC 7911、DOI 10.17487 / RFC7911、2016年7月、<http:// www。 rfc-editor.org/info/rfc7911>。

8.2. Informative References
8.2. 参考引用

[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345, August 2002, <http://www.rfc-editor.org/info/rfc3345>.

[RFC3345] McPherson、D.、Gill、V.、Walton、D。、およびA. Retana、「Border Gateway Protocol(BGP)Persistent Route Oscillation Condition」、RFC 3345、DOI 10.17487 / RFC3345、2002年8月、<http: //www.rfc-editor.org/info/rfc3345>。

Appendix A. Why the Group Best Paths Are Adequate
付録A.グループの最適なパスが適切である理由

It is assumed that the following common practice is followed. A route reflection cluster or a confederation sub-AS should be designed such that the IGP metrics for links within a cluster (or confederation sub-AS) are much smaller than the IGP metrics for the links between the clusters (or confederation sub-AS). This practice helps achieve consistent routing within a route reflection cluster or a confederation sub-AS.

次の一般的な慣例に従っていることを前提としています。ルートリフレクションクラスターまたはコンフェデレーションサブASは、クラスター(またはコンフェデレーションサブAS)内のリンクのIGPメトリックがクラスター(またはコンフェデレーションサブAS)間のリンクのIGPメトリックよりもはるかに小さくなるように設計する必要があります。 。このプラクティスは、ルートリフレクションクラスタまたはコンフェデレーションサブAS内で一貫したルーティングを実現するのに役立ちます。

Observe that in a network that maintains full IBGP mesh only, the paths that survive the (Local_Pref, AS-PATH Length, Origin, and MED) comparisons [RFC4271] would contribute to route selection in the network.

完全なIBGPメッシュのみを維持するネットワークでは、(Local_Pref、AS-PATH長さ、起点、およびMED)比較[RFC4271]を通過したパスがネットワーク内のルート選択に寄与することに注意してください。

Consider a route reflection cluster that sources one or more paths that would survive the (Local_Pref, AS-PATH Length, Origin, and MED) comparisons among all the paths in the network. One of these surviving paths would be selected as the Group Best Path by the route reflector in the cluster. Due to the constraint on the IGP metrics as described previously, this path would remain as the Group Best Path and would be advertised to all other clusters even after a path is received from another cluster.

ネットワーク内のすべてのパス間での比較(Local_Pref、AS-PATH Length、Origin、およびMED)に耐えられる1つ以上のパスをソースとするルートリフレクションクラスターについて考えてみます。これらの生き残ったパスの1つは、クラスター内のルートリフレクターによってグループの最適パスとして選択されます。前述のIGPメトリックの制約により、このパスはGroup Best Pathとして残り、別のクラスターからパスを受信した後でも、他のすべてのクラスターにアドバタイズされます。

On the other hand, when no path in a route reflection cluster would survive the (Local_Pref, AS-PATH Length, Origin, and MED) comparisons among all the paths in the network, the Group Best Path (when it exists) for a route reflector would be from another cluster. Clearly, the advertisement of the Group Best Path by the route reflector to the clients only depends on the paths received from other clusters.

一方、ルートリフレクションクラスター内のパスが、ネットワーク内のすべてのパス間の(Local_Pref、AS-PATH長さ、オリジン、およびMED)比較に耐えられない場合、ルートのグループ最適パス(存在する場合)リフレクターは別のクラスターからのものです。明らかに、ルートリフレクタによるクライアントへのGroup Best Pathのアドバタイズは、他のクラスタから受信したパスにのみ依存します。

Therefore, there is no MED-induced route oscillation in the network as the advertisement of a Group Best Path to a peer does not depend on the paths received from that peer.

したがって、ピアへのGroup Best Pathのアドバタイズはそのピアから受信したパスに依存しないため、ネットワークにMEDに起因するルートの振動はありません。

The claim for the confederation can be validated similarly.

同盟の主張は同様に検証することができます。

Acknowledgements

謝辞

We would like to thank David Cook and Naiming Shen for their contributions to the design and development of the solutions.

ソリューションの設計と開発に貢献してくれたDavid CookとNaiming Shenに感謝します。

Many thanks to Tony Przygienda, Sue Hares, Jon Mitchell, and Paul Kyzivat for their helpful suggestions.

Tony Przygienda、Sue Hares、Jon Mitchell、およびPaul Kyzivatの有益な提案に感謝します。

Authors' Addresses

著者のアドレス

Daniel Walton Cumulus Networks 140C S. Whisman Rd. Mountain View, CA 94041 United States of America

ダニエルウォルトンクムルスネットワークス140C S.ウィスマンロードマウンテンビュー、カリフォルニア94041アメリカ合衆国

   Email: dwalton@cumulusnetworks.com
        

Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 United States of America

Alvaro Retana Cisco Systems、Inc. 7025 Kit Creek Rd。 Research Triangle Park、NC 27709アメリカ合衆国

   Email: aretana@cisco.com
        

Enke Chen Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 United States of America

Enke Chen Cisco Systems、Inc. 170 W. Tasman Dr. San Jose、CA 95134アメリカ合衆国

   Email: enkechen@cisco.com
        

John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 United States of America

John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089アメリカ合衆国

   Email: jgs@juniper.net