[要約] 要約：RFC 7705は、自律システム（AS）の移行メカニズムとBGP AS_PATH属性への影響について説明しています。 目的：このRFCの目的は、ASの移行がBGP AS_PATH属性に与える影響を理解し、ネットワークエンジニアが効果的なAS移行戦略を開発できるようにすることです。
Internet Engineering Task Force (IETF) W. George
Request for Comments: 7705 Time Warner Cable
Updates: 4271 S. Amante
Category: Standards Track Apple, Inc.
ISSN: 2070-1721 November 2015
Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute
自律システム移行メカニズムとBGP AS_PATH属性への影響
Abstract
概要
This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work.
このドキュメントでは、正式にはBGP4プロトコル仕様の一部ではない、自律システム番号（ASN）の移行に一般的に使用されているいくつかのBGPメカニズムについて説明します。これらの事実上の標準を文書化して、将来の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/rfc7705.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7705で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Documentation Note . . . . . . . . . . . . . . . . . . . 3
2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3
3. External BGP Autonomous System Migration Mechanisms . . . . . 5
3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 5
3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7
3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8
4. Internal BGP Autonomous System Migration Mechanisms . . . . . 9
4.1. Internal BGP AS Migration . . . . . . . . . . . . . . . . 10
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12
5. Additional Operational Considerations . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Implementation Report . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 [RFC4271] protocol specification. These mechanisms are local to a given BGP speaker and do not require negotiation with or cooperation of BGP neighbors. The deployment of these mechanisms do not need to interwork with one another to accomplish the desired results, so slight variations between existing vendor implementations exist and will not necessarily be harmonized due to this document. However, it is necessary to document these de facto standards to ensure that new implementations can be successful, and any future protocol enhancements to BGP that propose to read, copy, manipulate, or compare the AS_PATH attribute can do so without inhibiting the use of these very widely used ASN migration mechanisms.
このドキュメントでは、BGP4 [RFC4271]プロトコル仕様の正式な一部ではない、自律システム番号（ASN）の移行に一般的に使用されているいくつかのBGPメカニズムについて説明します。これらのメカニズムは、特定のBGPスピーカーに対してローカルであり、BGPネイバーとのネゴシエーションまたは協力を必要としません。これらのメカニズムの展開は、目的の結果を達成するために相互に連携する必要がないため、既存のベンダーの実装間にわずかな違いが存在し、このドキュメントのために必ずしも調和する必要はありません。ただし、新しい実装を確実に成功させるには、これらの事実上の標準を文書化する必要があります。また、AS_PATH属性の読み取り、コピー、操作、または比較を提案するBGPの将来のプロトコル拡張は、これらの使用を妨げることなく実行できます。非常に広く使用されているASN移行メカニズム。
The migration mechanisms discussed here are useful to ISPs and organizations of all sizes, but it is important to understand the business need for these mechanisms and illustrate why they are so critical for ISPs' operations. During a merger, acquisition, or divestiture involving two organizations it is necessary to seamlessly migrate both internal and external BGP speakers from one ASN to a second ASN. The overall goal in doing so is to simplify operations through consistent configurations across all BGP speakers in the combined network. In addition, given that the BGP Path Selection algorithm selects routes with the shortest AS_PATH attribute, it is critical that the ISP does not increase AS_PATH length during or after ASN migration, because an increased AS_PATH length would likely result in sudden, undesirable changes in traffic-patterns in the network.
ここで説明する移行メカニズムは、ISPおよびあらゆる規模の組織に役立ちますが、これらのメカニズムのビジネスニーズを理解し、それらがISPの運用にとって非常に重要である理由を示すことが重要です。 2つの組織が関与する合併、買収、または売却の際、内部と外部の両方のBGPスピーカーを1つのASNから2番目のASNにシームレスに移行する必要があります。そのための全体的な目標は、結合されたネットワーク内のすべてのBGPスピーカー全体で一貫した構成を使用して操作を簡素化することです。さらに、BGPパス選択アルゴリズムはAS_PATH属性が最短のルートを選択するため、ASNの移行中または移行後に、ISPがAS_PATHの長さを増加させないことが重要です。 -ネットワーク内のパターン。
By default, the BGP protocol requires an operator to configure a router to use a single remote ASN for the BGP neighbor, and the ASN must match on both ends of the peering in order to successfully negotiate and establish a BGP session. Prior to the existence of these migration mechanisms, it would have required an ISP to coordinate an ASN change with, in some cases, tens of thousands of customers. In particular, as each router is migrated to the new ASN, to avoid an outage due to ASN mismatch, the ISP would have to force all customers on that router to change their router configurations to use the new ASN immediately after the ASN change. Thus, it was critical to define a more asymmetric migration method so that the ISP could seamlessly change the ASN within its network(s) but allow the customers to gradually migrate to the ISP's new ASN when convenient. These customer migrations could occur either by coordinating individual session reconfigurations or, to allow for truly asymmetric migration, by accepting sessions using either the old or new ASN.
デフォルトでは、BGPプロトコルでは、BGPネイバーに単一のリモートASNを使用するようにルーターを設定するオペレーターが必要です。BGPセッションを正常にネゴシエートして確立するには、ASNがピアリングの両端で一致する必要があります。これらの移行メカニズムが存在する前は、ISPがASNの変更を、場合によっては数万の顧客と調整する必要がありました。特に、各ルーターが新しいASNに移行されると、ASNの不一致による停止を回避するために、ISPはそのルーターのすべての顧客に、ASNの変更直後に新しいASNを使用するようにルーター構成を変更するように強制する必要があります。したがって、ISPがネットワーク内のASNをシームレスに変更できるようにしながら、顧客が都合の良いときにISPの新しいASNに徐々に移行できるように、より非対称の移行方法を定義することが重要でした。これらの顧客の移行は、個々のセッションの再構成を調整するか、または完全に非対称の移行を可能にするために、古いまたは新しいASNのいずれかを使用してセッションを受け入れることによって行うことができます。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses Autonomous System Numbers (ASNs) from the range reserved for documentation as described in RFC 5398 [RFC5398]. In the examples used here, they are intended to represent Globally Unique ASNs, not private use ASNs as documented in Section 5 of RFC 6996 [RFC6996].
このドキュメントでは、RFC 5398 [RFC5398]で説明されているように、ドキュメント用に予約された範囲の自律システム番号（ASN）を使用します。ここで使用されている例では、RFC 6996 [RFC6996]のセクション5に記載されている私的使用のASNではなく、グローバルに一意のASNを表すことを目的としています。
The use case being discussed here is an ISP merging two or more ASNs, where eventually one ASN subsumes the other(s). In this use case, we will assume the most common case where there are two ISPs, A and B, that prior to the ASN migration use AS 64500 and 64510, respectively. AS 64500 will be the permanently retained ASN used across the consolidated set of both ISPs network equipment, and AS 64510 will be retired. Thus, at the conclusion of the ASN migration, there will be a single ISP A' with all internal BGP speakers configured to use AS 64500. To all external BGP speakers, the AS_PATH length will not be increased.
ここで説明する使用例は、2つ以上のASNをマージするISPであり、最終的に1つのASNが他のASNを包含します。この使用例では、2つのISP、AとBがあり、ASN移行前にそれぞれAS 64500と64510を使用する最も一般的なケースを想定しています。 AS 64500は、両方のISPネットワーク機器の統合セット全体で使用される永続的に保持されるASNとなり、AS 64510は廃止されます。したがって、ASN移行の最後に、すべての内部BGPスピーカーがAS 64500を使用するように構成された単一のISP A 'があります。すべての外部BGPスピーカーに対して、AS_PATHの長さは増加しません。
In this same scenario, AS 64496 and AS 64499 represent two separate customer networks: C and D, respectively. Originally, customer C (AS 64496) is attached to ISP B, which will undergo ASN migration from AS 64510 to AS 64500. Furthermore, customer D (AS 64499) is attached to ISP A, which does not undergo ASN migration since the ASN for ISP A will remain constant, (AS 64500). Although this example refers to AS 64496 and 64499 as customer networks, either or both may be settlement-free or other types of peers. In this use case, they are referred to as "customers" merely for convenience.
この同じシナリオでは、AS 64496とAS 64499は、それぞれCとDの2つの個別のカスタマーネットワークを表しています。当初、顧客C（AS 64496）はISP Bに接続されており、AS 64510からAS 64500にASN移行されます。さらに、顧客D（AS 64499）はISP Aに接続されます。 ISP Aは一定のままです（AS 64500）。この例では、AS 64496および64499をカスタマーネットワークと呼んでいますが、どちらかまたは両方が決済なしまたは他のタイプのピアである場合があります。この使用例では、単に便宜上「顧客」と呼ばれています。
------ ------
/ ISP A \ / ISP B \
| AS 64500 | | AS 64510 |
\ / \ /
------- -------
| |
| |
------------ -------------
| Cust D | | Cust C |
| AS 64499 | | AS 64496 |
------------ -------------
Figure 1: Before Migration
図1：移行前
---------------
/ \
| ISP A' |
| AS 64500 |
\ /
---------------
/ \
/ \
| |
------------ -------------
| Cust D | | Cust C |
| AS 64499 | | AS 64496 |
------------ -------------
Figure 2: After Migration
図2：移行後
The general order of operations, typically carried out in a single maintenance window by the network undergoing ASN migration (ISP B), is as follows. First, ISP B will change the global BGP ASN used by a Provider Edge (PE) router, from ASN 64510 to 64500. At this point, the router will no longer be able to establish External BGP (eBGP) sessions toward the existing Customer Edge (CE) devices that are attached to it and still using AS 64510. Second, since ISP B needs to do this without coordinating the simultaneous change of its ASN with all of its eBGP peers, ISP B will configure two separate, but related ASN migration mechanisms discussed in this document on all eBGP sessions toward all CE devices. These mechanisms enable the router to establish BGP neighbors using the legacy ASN, modify the AS_PATH attribute received from a CE device when advertising it further, and modify AS_PATH when transmitted toward CE devices to achieve the desired effect of not increasing the length of the AS_PATH.
通常、ASN移行中のネットワーク（ISP B）によって単一のメンテナンスウィンドウで実行される操作の一般的な順序は、次のとおりです。まず、ISP Bはプロバイダーエッジ（PE）ルーターが使用するグローバルBGP ASNをASN 64510から64500に変更します。この時点で、ルーターは既存のカスタマーエッジに向けて外部BGP（eBGP）セッションを確立できなくなります。 （CE）接続されていて、AS 64510を使用しているデバイス。次に、ISP Bは、すべてのeBGPピアとのASNの同時変更を調整せずにこれを行う必要があるため、ISP Bは2つの別個の、ただし関連するASN移行を構成します。このドキュメントで説明されているすべてのCEデバイスに対するすべてのeBGPセッションのメカニズム。これらのメカニズムにより、ルータはレガシーASNを使用してBGPネイバーを確立し、CEデバイスから受信したAS_PATH属性をさらにアドバタイズするときに変更し、CEデバイスに送信するときにAS_PATHを変更して、AS_PATHの長さを長くしないという望ましい効果を実現できます。
At the conclusion of the ASN migration, the CE devices at the edge of the network are not aware of the fact that their upstream router is now in a new ASN and do not observe any change in the length of the AS_PATH attribute. However, after the changes discussed in this document are put in place by ISP A', there is a change to the contents of the AS_PATH attribute to ensure the AS_PATH is not artificially lengthened while these AS migration parameters are used.
ASN移行の最後に、ネットワークのエッジにあるCEデバイスは、上流のルーターが新しいASNにあることを認識せず、AS_PATH属性の長さの変化を観察しません。ただし、このドキュメントで説明されている変更がISP A 'によって導入された後、AS_PATH属性の内容が変更され、これらのAS移行パラメーターが使用されている間、AS_PATHが不自然に長くならないようにします。
In this use case, neither ISP is using BGP Confederations [RFC5065] internally.
この使用例では、どちらのISPも内部でBGPコンフェデレーション[RFC5065]を使用していません。
The following section addresses optional capabilities that are specific to modifying the AS_PATH attribute at the Autonomous System Border Routers (ASBRs) of an organization (typically a single Service Provider). This ensures that external BGP customers/peers are not forced to make any configuration changes on their CE routers before or during the exact time the Service Provider wishes to migrate to a new, permanently retained ASN. Furthermore, these mechanisms eliminate the artificial lengthening of the AS_PATH both transmitted from and received by the Service Provider that is undergoing AS Migration, which would have negative implications on path selection by external networks.
次のセクションでは、組織（通常は単一のサービスプロバイダー）の自律システムボーダールーター（ASBR）でAS_PATH属性の変更に固有のオプション機能について説明します。これにより、サービスプロバイダーが新しい永続的なASNへの移行を希望する正確な時間の前または間に、外部のBGPカスタマー/ピアがCEルータの設定変更を強制されることがなくなります。さらに、これらのメカニズムは、ASマイグレーションを実行しているサービスプロバイダーから送信および受信されるAS_PATHの人工的な延長を排除します。これは、外部ネットワークによるパス選択に悪影響を及ぼします。
The first instrument used in the process described above is called "Local AS". This allows the router to supersede the globally configured ASN in the "My Autonomous System" field of the BGP OPEN [RFC4271] with a locally defined AS value for a specific BGP neighbor or group of neighbors. This mechanism allows the PE router that was formerly in ISP B to establish an eBGP session toward the existing CE devices using the legacy AS -- AS 64510. Ultimately, the CE devices (i.e., customer C) are completely unaware that ISP B has reconfigured its router to participate as a member of a new AS. Within the context of the former ISP B PE router, the second effect this specific mechanism has on AS_PATH is that, by default, it prepends all received BGP UPDATEs with the legacy AS of ISP B -- AS 64510 -- while advertising it (Adj-RIB-Out) to other BGP speakers (A'). Within the Loc-RIB on ISP B prior to the migration, the AS_PATH of route announcements received from customer C would appear as 64496, whereas the same RIB on ISP A' (ISP B routers post-migration) would contain AS_PATH 64510 64496.
上記のプロセスで使用される最初の機器は「ローカルAS」と呼ばれます。これにより、ルータは、BGP OPEN [RFC4271]の[My Autonomous System]フィールドでグローバルに設定されたASNを、特定のBGPネイバーまたはネイバーグループのローカルに定義されたAS値で置き換えることができます。このメカニズムにより、以前ISP BにあったPEルーターは、レガシーAS-AS 64510を使用して既存のCEデバイスに向けてeBGPセッションを確立できます。最終的に、CEデバイス（つまり、顧客C）は、ISP Bが再構成したことを完全に認識しません新しいASのメンバーとして参加するルーター。以前のISP B PEルーターのコンテキスト内では、この特定のメカニズムがAS_PATHに及ぼす2番目の影響は、デフォルトで、受信したすべてのBGP UPDATEの前に、ISP BのレガシーAS-AS 64510-を付加して、それをアドバタイズします（Adj -RIB-Out）から他のBGPスピーカーへ（A '）。移行前のISP BのLoc-RIB内では、顧客Cから受信したルートアナウンスのAS_PATHは64496と表示されますが、ISP A '（移行後のISP Bルーター）の同じRIBにはAS_PATH 64510 64496が含まれます。
The second instrument, referred to as "No Prepend Inbound", is enabled on PE routers migrating from ISP B. The "No Prepend Inbound" capability causes ISP B's routers to not prepend the legacy AS (AS 64510), when advertising UPDATES received from customer C. This restores the AS_PATH within ISP A' for route announcements received from customer C so that it is just one ASN in length: 64496.
「No Prepend Inbound」と呼ばれる2番目の機器は、ISP Bから移行するPEルーターで有効になります。「No Prepend Inbound」機能により、ISP Bのルーターは、レガシーAS（AS 64510）からプリケーションを追加しません。カスタマーC。これにより、カスタマーCから受信したルートアナウンスメントのISP A '内のAS_PATHが復元され、長さが1つのASNである64496になります。
In the direction of CE -> PE (inbound):
CE-> PE（インバウンド）の方向：
1. "Local AS": Allows the local BGP router to generate a BGP OPEN to an eBGP neighbor with the old, legacy ASN value in the "My Autonomous System" field. When this capability is activated, it also causes the local router to prepend the <old_ASN> value to the AS_PATH when installing or advertising routes received from a CE to Internal BGP (iBGP) neighbors inside the Autonomous System.
1. 「ローカルAS」：ローカルBGPルーターが、「My Autonomous System」フィールドに古いレガシーASN値を持つeBGPネイバーへのBGP OPENを生成できるようにします。この機能をアクティブにすると、ローカルシステムは、CEから受信したルートを自律システム内の内部BGP（iBGP）ネイバーにインストールまたはアドバタイズするときに、AS_PATHに<old_ASN>値を付加します。
2. "No Prepend Inbound (of Local AS)": The local BGP router does not prepend the <old_ASN> value to the AS_PATH when installing or advertising routes received from the CE to iBGP neighbors inside the Autonomous System
2. 「インバウンド（ローカルASの）を付加しない」：CEから受信したルートを自律システム内のiBGPネイバーにインストールまたはアドバタイズするときに、ローカルBGPルーターはAS_PATHに<old_ASN>値を付加しません。
PE-B is a PE that was originally in ISP B, and has a customer eBGP session to CE-B. PE-B has had its global configuration ASN changed from AS 64510 to AS 64500 to make it part of the permanently retained ASN. This now makes PE-B a member of ISP A'. PE-A is a PE that was originally in ISP A, and has a customer peer CE-A. Although its global configuration ASN remains AS 64500, throughout this exercise we also consider PE-A a member of ISP A'.
PE-Bは、もともとISP BにあったPEであり、CE-BへのカスタマーeBGPセッションがあります。 PE-Bのグローバル設定ASNがAS 64510からAS 64500に変更され、永続的に保持されるASNの一部になりました。これにより、PE-BがISP A 'のメンバーになります。 PE-Aは、もともとISP AにあったPEで、カスタマーピアCE-Aがあります。グローバル構成のASNはAS 64500のままですが、この演習全体を通じて、PE-AはISP A 'のメンバーであるとも見なします。
ISP A' ISP A'
CE-A <--- PE-A <------------------- PE-B <--- CE-B
64499 New_ASN: 64500 Old_ASN: 64510 64496
New_ASN: 64500
Note: Direction of BGP UPDATE as per the arrows.
注：矢印によるBGP UPDATEの方向。
Figure 3: Local AS and No Prepend BGP UPDATE Diagram
図3：ローカルASとプリペンドなしのBGP UPDATE図
As a result, using both the "Local AS" and "No Prepend Inbound" capabilities on PE-B, CE-A will see an AS_PATH of 64500 64496. CE-A will not receive a BGP UPDATE containing AS 64510 in the AS_PATH. (If only the "Local AS" mechanism was configured without "No Prepend Inbound" on PE-B, then CE-A would have seen an AS_PATH of 64500 64510 64496, which results in an unacceptable lengthening of the AS_PATH). Note: If there are still routers in the old ASN (64510), it is possible for them to accept these manipulated routes (i.e., those with 64510 removed from the AS_PATH by this command) as if they have not already passed through their ASN, potentially causing a loop, since BGP's normal loop-prevention behavior of rejecting routes that include its ASN in the path will not catch these. Careful filtering between routers remaining in the old ASN and routers migrated to the new ASN is necessary to minimize the risk of routing loops.
その結果、PE-Bで「ローカルAS」機能と「プリペンドインバウンドなし」機能の両方を使用すると、CE-Aには64500 64496のAS_PATHが表示されます。CE-Aは、AS_PATHにAS 64510を含むBGP UPDATEを受信しません。 （「ローカルAS」メカニズムのみがPE-Bで「前向き着信なし」なしで設定された場合、CE-Aは64500 64510 64496のAS_PATHを表示し、AS_PATHが許容できないほど長くなります）。注：古いASN（64510）にまだルーターがある場合、ASNをまだ通過していないかのように、これらの操作されたルート（つまり、64510がこのコマンドによってAS_PATHから削除されたもの）を受け入れることができます。パスにASNを含むルートを拒否するBGPの通常のループ防止動作はこれらをキャッチしないため、ループを引き起こす可能性があります。ルーティングループのリスクを最小限に抑えるには、古いASNに残っているルーターと新しいASNに移行されたルーターとの間の注意深いフィルタリングが必要です。
The two aforementioned mechanisms, "Local AS" and "No Prepend Inbound", only modify the AS_PATH attribute received by the ISP's PEs in the course of processing BGP UPDATEs from CE devices when CE devices still have an eBGP session established with the ISPs legacy AS (AS64510).
前述の2つのメカニズム「ローカルAS」と「プリペンドインバウンドなし」は、CEデバイスがISPのレガシーASとのeBGPセッションを確立している場合、CEデバイスからのBGP UPDATEの処理中にISPのPEが受信したAS_PATH属性のみを変更します。 （AS64510）。
In some existing implementations, "Local AS" and "No Prepend Inbound" do not concurrently modify the AS_PATH attribute for BGP UPDATEs that are transmitted by the ISP's PEs to CE devices. In these implementations, with "Local AS" and "No Prepend Inbound" used on PE-B, there is an automatic lengthening of the AS_PATH in outbound BGP UPDATEs from ISP A' toward directly attached eBGP speakers (customer C in AS 64496). The externally observed result is that customer C in AS 64496 will receive the following AS_PATH: 64510 64500 64499. Therefore, if ISP A' takes no further action, there will be an unacceptable increase in the AS_PATH length within the customer's networks directly attached to ISP A'.
一部の既存の実装では、「ローカルAS」と「プリペンドインバウンドなし」は、ISPのPEからCEデバイスに送信されるBGP UPDATEのAS_PATH属性を同時に変更しません。これらの実装では、PE-Bで「ローカルAS」と「プリペンドインバウンドなし」が使用されているため、ISP A 'から直接接続されたeBGPスピーカー（AS 64496の顧客C）へのアウトバウンドBGP UPDATEでAS_PATHが自動的に延長されます。外部で観察された結果として、AS 64496の顧客Cは次のAS_PATHを受け取ります：64510 6450064499。したがって、ISP A 'がそれ以上のアクションを実行しない場合、ISPに直接接続されている顧客のネットワーク内でAS_PATHの長さが許容できないほど長くなります。 A '。
A tertiary mechanism, referred to as "Replace Old AS", is used to resolve this problem. This capability allows ISP A' to prevent routers from appending the globally configured ASN in outbound BGP UPDATEs toward directly attached eBGP neighbors that are using the "Local AS" mechanism. Instead, only the old (or previously used) AS will be prepended in the outbound BGP UPDATE toward the customer's network, restoring the AS_PATH length to what it what was before AS Migration occurred.
この問題を解決するために、「古いASを置き換える」と呼ばれる3次メカニズムが使用されます。この機能により、ISP A 'は、ルーターがアウトバウンドBGP UPDATEでグローバルに構成されたASNを、「ローカルAS」メカニズムを使用している直接接続されたeBGPネイバーに向けて追加するのを防ぐことができます。代わりに、古い（または以前に使用された）ASのみが、アウトバウンドBGP UPDATEで顧客のネットワークに追加され、AS_PATHの長さがAS移行が発生する前の状態に復元されます。
To reuse the above diagram, but in the opposite direction, we have:
上の図を再利用するには、反対の方向に、次のようにします。
ISP A' ISP A'
CE-A ---> PE-A -------------------> PE-B ---> CE-B
64499 New_ASN: 64500 Old_ASN: 64510 64496
New_ASN: 64500
Note: Direction of BGP UPDATE as per the arrows.
注：矢印によるBGP UPDATEの方向。
Figure 4: Replace AS BGP UPDATE Diagram
図4：AS BGP更新図の置き換え
By default, without the use of "Replace Old AS", CE-B would see an AS_PATH of 64510 64500 64499. After ISP A' changes PE-B to use "Replace Old AS", CE-B would receive an AS_PATH of 64510 64499, which is the same AS_PATH length pre-AS migration.
デフォルトでは、「Replace Old AS」を使用しない場合、CE-Bは64510 64500 64499のAS_PATHを参照します。ISPA 'がPE-Bを変更して「Replace Old AS」を使用すると、CE-Bは64510のAS_PATHを受け取ります。これは、AS移行前のAS_PATHの長さと同じです。
The mechanisms introduced in this section MUST be configurable on a per-neighbor or per-neighbor-group basis to allow for maximum flexibility. (Here, "neighbor group" refers to a group of similar BGP neighbor statements that reuse some common configuration to simplify provisioning.) When the "Local AS" capability is used, a local ASN will be provided in the configuration that is different from the globally configured ASN of the BGP router. To implement this mechanism, a BGP speaker SHOULD send BGP OPEN [RFC4271] (see Section 4.2) messages to the configured eBGP peer(s) using the local ASN configured for this session as the value sent in "My Autonomous System". The BGP router SHOULD NOT use the ASN configured globally within the BGP process as the value sent in "My Autonomous System" in the OPEN message. This prevents causing the eBGP neighbor to unnecessarily generate a BGP OPEN Error message "Bad Peer AS". This method is typically used to re-establish eBGP sessions with peers expecting the legacy ASN after a router has been moved to a new ASN.
このセクションで紹介するメカニズムは、最大の柔軟性を可能にするために、ネイバーごとまたはネイバーグループごとに設定可能である必要があります。 （ここで、「ネイバーグループ」とは、プロビジョニングを簡略化するためにいくつかの一般的な構成を再利用する同様のBGPネイバーステートメントのグループを指します。）「ローカルAS」機能が使用される場合、ローカルASNは、構成とは異なる構成で提供されますBGPルーターのグローバルに構成されたASN。このメカニズムを実装するには、BGPスピーカーは、「My Autonomous System」で送信される値としてこのセッション用に構成されたローカルASNを使用して、構成済みeBGPピアにBGP OPEN [RFC4271]（セクション4.2を参照）メッセージを送信する必要があります（SHOULD）。 BGPルーターは、OPENメッセージの「My Autonomous System」で送信される値として、BGPプロセス内でグローバルに構成されたASNを使用してはなりません（SHOULD NOT）。これにより、eBGPネイバーがBGP OPENエラーメッセージ「Bad Peer AS」を不必要に生成するのを防ぎます。この方法は通常、ルーターが新しいASNに移動された後に、レガシーASNを予期しているピアとのeBGPセッションを再確立するために使用されます。
Implementations MAY support a more flexible model where the eBGP speaker attempts to open the BGP session using either the ASN configured as "Local AS" or the globally configured AS as discussed in BGP Alias (Section 4.2). If the session is successfully established to the globally configured ASN, then the modifications to AS_PATH described in this document SHOULD NOT be performed, as they are unnecessary. The benefit to this more flexible model is that it allows the remote neighbor to reconfigure to the new ASN without direct coordination between the ISP and the customer.
実装は、eBGPスピーカーが「ローカルAS」として構成されたASNまたはBGPエイリアス（セクション4.2）で説明されているグローバルに構成されたASを使用してBGPセッションを開こうとする、より柔軟なモデルをサポートする場合があります。グローバルに構成されたASNへのセッションが正常に確立された場合、このドキュメントで説明されているAS_PATHへの変更は必要ないため、実行しないでください。このより柔軟なモデルの利点は、ISPと顧客の間で直接調整しなくても、リモートネイバーが新しいASNに再構成できることです。
Note that this procedure will vary slightly if the locally or globally configured ASN is a 4-octet ASN. See Section 3 of [RFC6793].
ローカルまたはグローバルに構成されたASNが4オクテットASNである場合、この手順は少し異なることに注意してください。 [RFC6793]のセクション3をご覧ください。
When the BGP router receives UPDATEs from its eBGP neighbor configured with the "Local AS" mechanism, it processes the UPDATE as described in RFC4271 Section 5.1.2 [RFC4271]. However, the presence of a second ASN due to "Local AS" adds the following behavior to processing UPDATEs received from an eBGP neighbor configured with this mechanism:
BGPルーターは、「ローカルAS」メカニズムで構成されたeBGPネイバーからUPDATEを受信すると、RFC4271セクション5.1.2 [RFC4271]で説明されているようにUPDATEを処理します。ただし、「ローカルAS」による2番目のASNの存在は、このメカニズムで構成されたeBGPネイバーから受信したUPDATEの処理に次の動作を追加します。
1. Internal: The router SHOULD append the configured "Local AS" ASN in the AS_PATH attribute before installing the route or advertising the UPDATE to an iBGP neighbor. The decision of when to append the ASN is an implementation detail outside the scope of this document. Some considerations factoring into this decision include consistency in the AS_PATH throughout the AS, and implementation of the loop detection mechanism.
1. 内部：ルーターは、ルートをインストールしたり、UPDATEをiBGPネイバーにアドバタイズしたりする前に、設定された「ローカルAS」ASNをAS_PATH属性に追加する必要があります（SHOULD）。 ASNを追加するタイミングの決定は、このドキュメントの範囲外の実装の詳細です。この決定を考慮に入れるいくつかの考慮事項には、AS全体のAS_PATHの一貫性、およびループ検出メカニズムの実装が含まれます。
2. External: The BGP router SHOULD first append the globally configured ASN to the AS_PATH immediately followed by the "Local AS" value before advertising the UPDATE to an eBGP neighbor.
2. 外部：BGPルーターは、最初にグローバルに構成されたASNをAS_PATHに追加し、直後に「ローカルAS」値を追加してから、UPDATEをeBGPネイバーにアドバタイズします。
Two options exist to manipulate the behavior of the basic "Local AS" mechanism. They modify the behavior as described below:
基本的な「ローカルAS」メカニズムの動作を操作するには、2つのオプションがあります。以下で説明するように動作を変更します。
1. "No Prepend Inbound": When the BGP router receives inbound BGP UPDATEs from its eBGP neighbor configured with this option, it MUST NOT append the "Local AS" ASN value in the AS_PATH attribute when installing the route or advertising that UPDATE to iBGP neighbors, but it MUST still append the globally configured ASN as normal when advertising the UPDATE to other local eBGP neighbors (i.e., those natively peering with the globally configured ASN).
1. 「No Prepend Inbound」：BGPルーターがこのオプションで構成されたeBGPネイバーからインバウンドBGP UPDATEを受信する場合、ルートをインストールするとき、またはUPDATEをiBGPネイバーにアドバタイズするときに、AS_PATH属性に「Local AS」ASN値を追加しないでください。ただし、UPDATEを他のローカルeBGPネイバー（つまり、グローバルに構成されたASNとネイティブにピアリングしているもの）にアドバタイズするときは、グローバルに構成されたASNを通常どおり追加する必要があります。
2. "Replace Old AS" (outbound): When the BGP router generates outbound BGP UPDATEs toward an eBGP neighbor configured with this option, the BGP speaker MUST NOT append the globally configured ASN from the AS_PATH attribute. The BGP router MUST append only the configured "Local AS" ASN value to the AS_PATH attribute before sending the BGP UPDATEs outbound to the eBGP neighbor.
2. 「古いASを置き換える」（アウトバウンド）：BGPルーターがこのオプションで構成されたeBGPネイバーへのアウトバウンドBGP UPDATEを生成する場合、BGPスピーカーは、AS_PATH属性からグローバルに構成されたASNを追加してはなりません。 BGPルーターは、BGP UPDATEをeBGPネイバーに送信する前に、設定された「ローカルAS」ASN値のみをAS_PATH属性に追加する必要があります。
The following section describes mechanisms that assist with a gradual and least service-impacting migration of Internal BGP sessions from a legacy ASN to the permanently retained ASN. The following mechanism is very valuable to networks undergoing AS migration, but its use does not cause changes to the AS_PATH attribute.
次のセクションでは、レガシーASNから永続的に保持されるASNへの内部BGPセッションの段階的でサービスへの影響が少ない移行を支援するメカニズムについて説明します。次のメカニズムは、AS移行中のネットワークにとって非常に価値がありますが、その使用によってAS_PATH属性が変更されることはありません。
In this case, all of the routers to be consolidated into a single, permanently retained ASN are under the administrative control of a single entity. Unfortunately, the traditional method of migrating all Internal BGP speakers, particularly within larger networks, is both time-consuming and widely service impacting.
この場合、単一の永続的に保持されるASNに統合されるすべてのルーターは、単一のエンティティの管理制御下にあります。残念ながら、すべての内部BGPスピーカーを移行する従来の方法は、特に大規模なネットワーク内では、時間がかかり、サービスに大きな影響を与えます。
The traditional method to migrate Internal BGP sessions was strictly limited to reconfiguration of the global configuration ASN and, concurrently, changing all iBGP neighbors' remote ASN from the legacy ASN to the new, permanently retained ASN on each router within the legacy AS. These changes can be challenging to swiftly execute in networks with more than a few dozen internal BGP routers. There are also the concomitant service interruptions as these changes are made to routers within the network, resulting in a reset of iBGP sessions and subsequent route reconvergence to reestablish optimal routing paths. Operators often cannot make such sweeping changes given the associated risks of a highly visible service interruption; rather, they require a more gradual method to migrate Internal BGP sessions, from one ASN to a second, permanently retained ASN, that is not visibly service impacting to its customers.
内部BGPセッションを移行する従来の方法は、グローバル構成ASNの再構成に厳密に限定され、同時に、すべてのiBGPネイバーのリモートASNをレガシーASNからレガシーAS内の各ルーターで永続的に保持される新しいASNに変更しました。これらの変更は、数十を超える内部BGPルーターを備えたネットワークで迅速に実行することが困難な場合があります。これらの変更がネットワーク内のルーターに加えられると、付随するサービスの中断も発生します。その結果、iBGPセッションがリセットされ、その後最適なルーティングパスを再確立するためにルートが再収束されます。オペレーターは、非常に目に見えるサービス中断の関連リスクを考えると、そのような抜本的な変更を行うことができないことがよくあります。むしろ、内部BGPセッションを1つのASNから2番目の永続的に保持されているASNに移行するために、より段階的な方法が必要です。
With the "Internal BGP AS Migration" mechanism described herein, it allows an Internal BGP speaker to form a single iBGP session using either the old, legacy ASN or the new, permanently retained ASN. The benefits of using this mechanism are several fold. First, it allows for a more gradual and less service-impacting migration away from the legacy ASN to the permanently retained ASN. Second, it (temporarily) permits the coexistence of the legacy and permanently retained ASN within a single network, allowing for uniform BGP path selection among all routers within the consolidated network.
ここで説明する「内部BGP AS移行」メカニズムにより、内部BGPスピーカーは、古いレガシーASNまたは新しい永続的に保持されるASNのいずれかを使用して単一のiBGPセッションを形成できます。このメカニズムを使用する利点はいくつかあります。 1つ目は、レガシーASNから永続的に保持されるASNへの、段階的でサービスに影響の少ない移行を可能にすることです。第2に、単一のネットワーク内でレガシーおよび永続的に保持されるASNの（一時的な）共存を許可し、統合ネットワーク内のすべてのルーター間で均一なBGPパス選択を可能にします。
The iBGP router with the "Internal BGP AS Migration" capability enabled allows the receipt of a BGP OPEN message with either the legacy ASN value or the new, globally configured ASN value in the "My Autonomous System" field of the BGP OPEN message from iBGP neighbors. It is important to recognize that enablement of the "Internal BGP AS Migration" mechanism preserves the semantics of a regular iBGP session (i.e., using identical ASNs). Thus, the BGP attributes transmitted by and the acceptable methods of operation on BGP attributes received from iBGP sessions configured with "Internal BGP AS Migration" capability are no different than those exchanged across an iBGP session without "Internal BGP AS Migration" configured, as defined by [RFC4271] and [RFC4456].
「内部BGP AS移行」機能が有効になっているiBGPルーターでは、iBGPからのBGP OPENメッセージの「My Autonomous System」フィールドにレガシーASN値または新しいグローバルに構成されたASN値のいずれかを含むBGP OPENメッセージを受信できます。隣人。 「内部BGP AS移行」メカニズムを有効にすると、通常のiBGPセッションのセマンティクスが維持される（つまり、同一のASNを使用する）ことを認識することが重要です。したがって、「内部BGP AS移行」機能で構成されたiBGPセッションから受信したBGP属性によって送信されるBGP属性と許容される操作方法は、「内部BGP AS移行」が構成されていないiBGPセッションで交換されるものと同じです。 [RFC4271]および[RFC4456]による。
Typically, in medium to large networks, BGP Route Reflectors (RRs) [RFC4456] are used to aid in reduction of configuration of iBGP sessions and scalability with respect to overall TCP (and BGP) session maintenance between adjacent iBGP routers. Furthermore, BGP Route Reflectors are typically deployed in pairs within a single Route Reflection cluster to ensure high reliability of the BGP Control Plane. As such, the following example will use Route Reflectors to aid in understanding the use of the "Internal BGP AS Migration" mechanism. Note that Route Reflectors are not a prerequisite to enable "Internal BGP AS Migration" and this mechanism can be enabled independent of the use of Route Reflectors.
通常、中規模から大規模のネットワークでは、BGPルートリフレクター（RR）[RFC4456]を使用して、隣接するiBGPルーター間の全体的なTCP（およびBGP）セッションメンテナンスに関するiBGPセッションの構成とスケーラビリティの削減を支援します。さらに、BGPルートリフレクターは通常、BGPコントロールプレーンの高い信頼性を確保するために、単一のルートリフレクションクラスター内でペアで展開されます。そのため、次の例では、ルートリフレクターを使用して、「内部BGP AS移行」メカニズムの使用を理解するのに役立ちます。ルートリフレクターは「内部BGP AS移行」を有効にするための前提条件ではなく、このメカニズムはルートリフレクターの使用とは関係なく有効にできることに注意してください。
The general order of operations is as follows:
操作の一般的な順序は次のとおりです。
1. Within the legacy network, (the routers comprising the set of devices that still have a globally configured legacy ASN), one member of a redundant pair of RRs has its global configuration ASN changed to the permanently retained ASN. Concurrently, the "Internal BGP AS Migration" capability is enabled on all iBGP sessions on that device. This will comprise Non-Client iBGP sessions to other RRs as well as Client iBGP sessions, typically to PE devices, both still utilizing the legacy ASN. Note that during this step there will be a reset and reconvergence event on all iBGP sessions on the RRs whose configuration was modified; however, this should not be service impacting due to the use of redundant RRs in each RR Cluster.
1. レガシーネットワーク内で（グローバルに構成されたレガシーASNがまだあるデバイスのセットを構成するルーター）、RRの冗長ペアの1つのメンバーのグローバル構成ASNが永続的に保持されるASNに変更されます。同時に、そのデバイスのすべてのiBGPセッションで「内部BGP AS移行」機能が有効になります。これは、他のRRへの非クライアントiBGPセッションと、通常はPEデバイスへのクライアントiBGPセッションで構成され、どちらもレガシーASNを利用しています。このステップ中に、設定が変更されたRR上のすべてのiBGPセッションでリセットおよび再コンバージェンスイベントが発生することに注意してください。ただし、これは、各RRクラスターで冗長RRを使用するため、サービスに影響を与えるべきではありません。
2. The above step is repeated for the other side of the redundant pair of RRs. The one alteration to the above procedure is that the "Internal BGP AS Migration" mechanism is now removed from the Non-Client iBGP sessions toward the other (previously reconfigured) RRs, since it is no longer needed. The "Internal BGP AS Migration" mechanism is still required on all RRs for all RR Client iBGP sessions. Also during this step, there will be a reset and reconvergence event on all iBGP sessions whose configuration was modified, but this should not be service impacting. At the conclusion of this step, all RRs will have their globally configured ASN set to the permanently retained ASN and "Internal BGP AS Migration" enabled and in use toward RR Clients.
2. 上記の手順は、RRの冗長ペアのもう一方の側で繰り返されます。上記の手順の1つの変更点は、「内部BGP AS移行」メカニズムが不要になったため、非クライアントiBGPセッションから他の（以前に再構成された）RRに向けて削除されていることです。 「内部BGP AS移行」メカニズムは、すべてのRRクライアントiBGPセッションのすべてのRRで引き続き必要です。また、このステップ中に、設定が変更されたすべてのiBGPセッションでリセットおよび再コンバージェンスイベントが発生しますが、これはサービスに影響しないはずです。この手順の最後に、すべてのRRのグローバルに構成されたASNが永続的に保持されるASNに設定され、「内部BGP AS移行」が有効になり、RRクライアントに対して使用されます。
3. At this point, the network administrators would then be able to establish iBGP sessions between all Route Reflectors in both the legacy and permanently retained networks. This would allow the network to appear to function, both internally and externally, as a single, consolidated network using the permanently retained network.
3. この時点で、ネットワーク管理者は、レガシーネットワークと永続的に保持されるネットワークの両方で、すべてのルートリフレクター間にiBGPセッションを確立できます。これにより、ネットワークは、内部的にも外部的にも、永続的に保持されるネットワークを使用する単一の統合ネットワークとして機能するように見えます。
4. To complete the AS migration, each RR Client (PE) in the legacy network still utilizing the legacy ASN is now modified. Specifically, each legacy PE would have its globally configured ASN changed to use the permanently retained ASN. The ASN configured within the PE for the iBGP sessions toward each RR would be changed to use the permanently retained ASN. It is unnecessary to enable the "Internal BGP AS Migration" mechanism on these migrated iBGP sessions. During the same maintenance window, External BGP sessions would be modified to include the above "Local AS", "No Prepend", and "Replace Old AS" mechanisms described in Section 3 above, since all of the changes are service interrupting to the eBGP sessions of the PE. At this point, all PEs will have been migrated to the permanently retained ASN.
4. ASの移行を完了するために、レガシーASNを引き続き使用しているレガシーネットワーク内の各RRクライアント（PE）が変更されました。具体的には、各レガシーPEは、グローバルに構成されたASNを変更して、永続的に保持されるASNを使用するようにします。 PE内で各RRへのiBGPセッション用に構成されたASNは、永続的に保持されるASNを使用するように変更されます。これらの移行されたiBGPセッションで「内部BGP AS移行」メカニズムを有効にする必要はありません。同じメンテナンスウィンドウの間に、外部BGPセッションは、上記の「ローカルAS」、「前置なし」、および上記のセクション3で説明した「古いASを置き換える」メカニズムを含むように変更されます。 PEのセッション。この時点で、すべてのPEは永続的に保持されるASNに移行されています。
5. The final step is to excise the "Internal BGP AS Migration" configuration from the Router Reflectors in an orderly fashion. After this is complete, all routers in the network will be using the new, permanently retained ASN for all iBGP sessions with no vestiges of the legacy ASN on any iBGP sessions.
5. 最後の手順は、 "内部BGP AS移行"構成をルーターリフレクターから規則正しく削除することです。これが完了すると、ネットワーク内のすべてのルーターは、すべてのiBGPセッションに対して、永続的に保持される新しいASNを使用し、iBGPセッション上のレガシーASNの痕跡はありません。
The benefit of using the aforementioned "Internal BGP AS Migration" capability is that it is a more gradual and less externally service impacting change to accomplish an AS migration. Previously, without "Internal BGP AS Migration", such an AS migration change would carry a high risk and need to be successfully accomplished in a very short time frame (e.g., at most several hours). In addition, it would likely cause substantial routing churn and rapid fluctuations in traffic carried -- potentially causing periods of congestion and resultant packet loss -- during the period when the configuration changes are underway to complete the AS Migration. On the other hand, with "Internal BGP AS Migration", the migration from the legacy ASN to the permanently retained ASN can occur over a period of days or weeks with reduced customer disruption. (The only observable service disruption should be when each PE undergoes the changes discussed in step 4 above.)
前述の「内部BGP AS移行」機能を使用する利点は、AS移行を実現するための、より緩やかで外部からのサービスへの影響が少ない変更です。以前は、「内部BGP AS移行」がなければ、そのようなAS移行の変更は高いリスクを伴い、非常に短い時間枠（たとえば、最大で数時間）で正常に完了する必要がありました。さらに、AS移行を完了するための構成変更が行われている期間中に、ルーティングチャーンが大幅に増加し、トラフィックの急速な変動が発生する可能性があります。一方、「内部BGP AS移行」を使用すると、レガシーASNから永続的に保持されるASNへの移行が数日または数週間にわたって発生し、顧客の混乱を減らすことができます。 （唯一の観察可能なサービスの中断は、各PEが上記のステップ4で説明された変更を受けたときでなければなりません。）
The mechanism introduced in this section MUST be configurable on a per-neighbor or per-neighbor-group basis to allow for maximum flexibility. When configured with this mechanism, a BGP speaker MUST accept BGP OPEN and establish an iBGP session from configured iBGP peers if the ASN value in "My Autonomous System" is either the globally configured ASN or a locally configured ASN provided when this capability is utilized. Additionally, a BGP router configured with this mechanism MUST send its own BGP OPEN [RFC4271] (see Section 4.2) using either the globally configured or the locally
このセクションで紹介するメカニズムは、最大の柔軟性を可能にするために、ネイバーごとまたはネイバーグループごとに設定可能である必要があります。このメカニズムを使用して構成する場合、「My Autonomous System」のASN値がグローバルに構成されたASNまたはこの機能が利用されるときに提供されるローカルに構成されたASNの場合、BGPスピーカーはBGP OPENを受け入れ、構成されたiBGPピアからiBGPセッションを確立する必要があります。さらに、このメカニズムで構成されたBGPルーターは、グローバルに構成された、またはローカルに構成された独自のBGP OPEN [RFC4271]（セクション4.2を参照）を送信する必要があります。
configured ASN in "My Autonomous System" as follows. To avoid potential deadlocks when two BGP speakers are attempting to establish a BGP peering session and are both configured with this mechanism, the speaker SHOULD send BGP OPEN using the globally configured ASN first, and only send a BGP OPEN using the locally configured ASN as a fallback if the remote neighbor responds with the BGP error "Bad Peer AS". In each case, the BGP speaker MUST treat UPDATEs sent and received to this peer as if this was a natively configured iBGP session, as defined by [RFC4271] and [RFC4456].
「My Autonomous System」でASNを次のように構成しました。 2つのBGPスピーカーがBGPピアリングセッションを確立しようとし、両方がこのメカニズムで構成されている場合、潜在的なデッドロックを回避するために、スピーカーは最初にグローバルに構成されたASNを使用してBGP OPENを送信し、ローカルに構成されたASNを使用してのみBGP OPENを送信する必要がありますリモートネイバーがBGPエラー「Bad Peer AS」で応答した場合のフォールバック。いずれの場合も、BGPスピーカーは、このピアに送信および受信したUPDATEを、[RFC4271]および[RFC4456]で定義されている、ネイティブに構成されたiBGPセッションであるかのように処理する必要があります。
Note that this procedure will vary slightly if the locally or globally configured ASN is a 4-octet ASN. See Section 3 of [RFC6793].
ローカルまたはグローバルに構成されたASNが4オクテットASNである場合、この手順は少し異なることに注意してください。 [RFC6793]のセクション3をご覧ください。
This document describes several mechanisms to support ISPs and other organizations that need to perform ASN migrations. Other variations of these mechanisms may exist, for example, in legacy router software that has not been upgraded or reached End of Life, but continues to operate in the network. Such variations are beyond the scope of this document.
このドキュメントでは、ASN移行を実行する必要のあるISPおよびその他の組織をサポートするためのいくつかのメカニズムについて説明します。これらのメカニズムの他のバリエーションは、たとえば、アップグレードされていない、またはサポート終了に達していないが、ネットワークで引き続き動作しているレガシールータソフトウェアに存在する可能性があります。このようなバリエーションは、このドキュメントの範囲を超えています。
Companies routinely go through periods of mergers, acquisitions, and divestitures, which in the case of the former cause them to accumulate several legacy ASNs over time. ISPs often do not have control over the configuration of customers' devices (i.e., the ISPs are often not providing a managed CE router service, particularly to medium and large customers that require eBGP). Furthermore, ISPs are using methods to perform ASN migration that do not require coordination with customers. Ultimately, this means there is not a finite period of time after which legacy ASNs will be completely expunged from the ISP's network. In fact, it is common that legacy ASNs and the associated External BGP AS Migration mechanisms discussed in this document can and do persist for several years, if not longer. Thus, it is prudent to plan that legacy ASNs and associated External BGP AS Migration mechanisms will persist in an operational network indefinitely.
企業は、合併、買収、売却の期間を定期的に通過します。前者の場合、これにより、時間の経過とともに複数のレガシーASNが蓄積されます。 ISPは、顧客のデバイスの構成を制御できないことがよくあります（つまり、ISPは、多くの場合、特にeBGPを必要とする中規模および大規模の顧客に対して、マネージドCEルーターサービスを提供していません）。さらに、ISPは、顧客との調整を必要としない方法を使用してASN移行を実行しています。最終的に、これは、レガシーASNがISPのネットワークから完全に消去されるまでの有限の期間がないことを意味します。実際、このドキュメントで説明されているレガシーASNとそれに関連する外部BGP AS移行メカニズムは、それ以上ではなくても、数年間存続することができ、実際に存続するのが一般的です。したがって、レガシーASNおよび関連する外部BGP AS移行メカニズムが運用ネットワークで無期限に持続することを計画することは賢明です。
With respect to the Internal BGP AS Migration mechanism, all of the routers to be consolidated into a single, permanently retained ASN are under the administrative control of a single entity. Thus, completing the migration from iBGP sessions using the legacy ASN to the permanently retained ASN is more straightforward and could be accomplished in a matter of days to months. Finally, good operational hygiene would dictate that it is good practice to avoid using "Internal BGP AS Migration" capability over a long period of time for reasons of not only operational simplicity of the network, but also reduced reliance on that mechanism during the ongoing life cycle management of software, features, and configurations that are maintained on the network.
内部BGP AS移行メカニズムに関しては、単一の永続的に保持されるASNに統合されるすべてのルーターは、単一のエンティティの管理制御下にあります。したがって、レガシーASNを使用してiBGPセッションから永続的に保持されるASNへの移行を完了するのはより簡単で、数日から数か月で完了できます。最後に、運用の衛生状態が良好な場合、ネットワークの運用が単純になるだけでなく、継続的な運用中にそのメカニズムへの依存度が低下するため、「内部BGP AS移行」機能を長期間使用しないことをお勧めします。ネットワーク上で維持されるソフトウェア、機能、および構成のサイクル管理。
This document discusses a process by which one ASN is migrated into and subsumed by another. This involves manipulating the AS_PATH attribute with the intent of not increasing the AS_PATH length, which would typically cause the BGP route to no longer be selected by BGP's Path Selection Algorithm in others' networks. This could result in sudden and unexpected shifts in traffic patterns in the network, potentially resulting in congestion.
このドキュメントでは、あるASNが別のASNに移行され、別のASNに組み込まれるプロセスについて説明します。これには、AS_PATHの長さを増加させない目的でAS_PATH属性を操作することが含まれます。これにより、通常、他のネットワークでBGPのパス選択アルゴリズムによってBGPルートが選択されなくなります。これにより、ネットワーク内のトラフィックパターンが突然予期せずシフトし、輻輳が発生する可能性があります。
Given that these mechanisms can only be enabled through configuration of routers within a single network, standard security measures should be taken to restrict access to the management interface(s) of routers that implement these mechanisms. Additionally, BGP sessions SHOULD be protected using TCP Authentication Option [RFC5925] and the Generalized TTL Security Mechanism [RFC5082]
これらのメカニズムは単一のネットワーク内のルーターの構成を通じてのみ有効にできるため、これらのメカニズムを実装するルーターの管理インターフェイスへのアクセスを制限するために、標準のセキュリティ対策を講じる必要があります。さらに、BGPセッションは、TCP認証オプション[RFC5925]および一般化されたTTLセキュリティメカニズム[RFC5082]を使用して保護する必要があります（SHOULD）。
[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 Route Reflection：An Alternative to Full Mesh Internal BGP（IBGP）」、RFC 4456、DOI 10.17487 / RFC4456、2006年4月、<http：/ /www.rfc-editor.org/info/rfc4456>。
[ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, <https://infoproducts.alcatel-lucent.com/html/0_add-h-f/ 93-0074-10-01/7750_SR_OS_Routing_Protocols_Guide/ BGP-CLI.html#709567>.
[ALU] Alcatel-Lucent、「BGPローカルAS属性」、2006-2012、<https://infoproducts.alcatel-lucent.com/html/0_add-hf/ 93-0074-10-01 / 7750_SR_OS_Routing_Protocols_Guide / BGP-CLI .html＃709567>。
[CISCO] Cisco Systems, Inc., "BGP Support for Dual AS Configuration for Network AS Migrations", 2013, <http://www.cisco.com/c/en/us/td/docs/ios-xml/ ios/iproute_bgp/configuration/xe-3s/asr1000/ irg-xe-3s-asr1000-book/irg-dual-as.html>.
[CISCO] Cisco Systems、Inc。、「BGP Support for Dual AS Configuration for Network AS Migrations」、2013、<http://www.cisco.com/c/en/us/td/docs/ios-xml/ ios / iproute_bgp / configuration / xe-3s / asr1000 / irg-xe-3s-asr1000-book / irg-dual-as.html>。
[JUNIPER] Juniper Networks, Inc., "Understanding the BGP Local AS Attribute", December 2013, <http://www.juniper.net/techpubs/en_US/junos13.3/topics/ concept/bgp-local-as-introduction.html>.
[ジュニパー]ジュニパーネットワークス社、「BGPローカルAS属性について」、2013年12月、<http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/bgp-local-as- Introduction.html>。
[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>。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、DOI 10.17487 / RFC5082、 2007年10月、<http://www.rfc-editor.org/info/rfc5082>。
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, DOI 10.17487/RFC5398, December 2008, <http://www.rfc-editor.org/info/rfc5398>.
[RFC5398] Huston、G。、「Autonomous System（AS）Number Reservation for Documentation Use」、RFC 5398、DOI 10.17487 / RFC5398、2008年12月、<http://www.rfc-editor.org/info/rfc5398>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<http://www.rfc-editor.org/info / rfc5925>。
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.
[RFC6793] Vohra、Q。およびE. Chen、「BGP Support for Four-Octet Autonomous System（AS）Number Space」、RFC 6793、DOI 10.17487 / RFC6793、2012年12月、<http：//www.rfc-editor。 org / info / rfc6793>。
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <http://www.rfc-editor.org/info/rfc6996>.
[RFC6996] Mitchell、J。、「プライベート使用のための自律システム（AS）予約」、BCP 6、RFC 6996、DOI 10.17487 / RFC6996、2013年7月、<http://www.rfc-editor.org/info/rfc6996 >。
As noted elsewhere in this document, this set of migration mechanisms has multiple existing implementations in wide use.
このドキュメントの他の場所で述べたように、この一連の移行メカニズムには、広く使用されている複数の既存の実装があります。
o Cisco [CISCO]
o シスコ[CISCO]
o Juniper [JUNIPER]
o ジュニパー[JUNIPER]
o Alcatel-Lucent [ALU]
o アルカテルルーセント[ALU]
This is not intended to be an exhaustive list, as equivalent features do exist in other implementations; however, the authors were unable to find publicly available documentation of the vendor-specific implementation to reference.
他の実装にも同等の機能が存在するため、これは完全なリストではありません。ただし、作成者は、参照するベンダー固有の実装の公開されているドキュメントを見つけることができませんでした。
Acknowledgements
謝辞
Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson, David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, Alvaro Retana, and John Scudder for their comments.
Kotikalapudi Sriram、Stephane Litkowski、Terry Manderson、David Farmer、Jaroslaw Adam Gralak、Gunter Van de Velde、Juan Alcaide、Jon Mitchell、Thomas Morin、Alia Atlas、Alvaro Retana、John Scudderのコメントに感謝します。
Authors' Addresses
著者のアドレス
Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 United States
Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon、VA 20171アメリカ合衆国
Phone: +1 703-561-2540
Email: wesley.george@twcable.com
Shane Amante Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 United States
Shane Amante Apple、Inc. 1 Infinite Loop Cupertino、CA 95014アメリカ合衆国
Email: amante@apple.com