[要約] RFC 6198は、BGPセッションの優雅なシャットダウンに関する要件を定義しています。その目的は、ネットワークの安定性を確保しながら、BGPセッションの終了を円滑に行うことです。
Internet Engineering Task Force (IETF) B. Decraene
Request for Comments: 6198 France Telecom
Category: Informational P. Francois
ISSN: 2070-1721 UCL
C. Pelsser
IIJ
Z. Ahmad
Orange Business Services
A.J. Elizondo Armengol
Telefonica I+D
T. Takeda
NTT
April 2011
Requirements for the Graceful Shutdown of BGP Sessions
BGPセッションの優雅なシャットダウンの要件
Abstract
概要
The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications (e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution.
Border Gateway Protocol（BGP）は、インターネットとBGP/MPLS VPNサービスの両方のサービスプロバイダーネットワークで頻繁に使用されています。回復力のために、冗長ルーターとBGPセッションを展開して、自律システムのボーダールーター（ASBR）またはBGPセッションの故障の結果を減らすことができます。ただし、メンテナンスの目的でBGPセッションを削除したり、持ち上げたりするだけでも、BGP収束中に接続性の損失を引き起こす可能性があります。これは、新しいアプリケーション（例：IP、オンラインゲーム、VPNなど）で満足のいくものではありません。したがって、計画されたシャットダウン中のトラフィックの損失の量を制限するために、BGPセッションのセットの優雅なシャットダウンには解決策が必要です。このドキュメントでは、このようなソリューションの要件を表しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6198.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6198で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Problem Statement ...............................................4
3.1. Example of Undesirable BGP Routing Behavior ................4
3.2. Causes of Packet Loss ......................................5
4. Terminology .....................................................6
5. Goals and Requirements ..........................................7
6. Security Considerations ........................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Acknowledgments ...................................................11
Appendix A. Reference BGP Topologies ..............................12
A.1. EBGP Topologies ...........................................12
A.2. IBGP Topologies ...........................................15
A.3. Routing Decisions .........................................19
The Border Gateway Protocol (BGP) [RFC4271] is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services [RFC4364]. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic.
Border Gateway Protocol（BGP）[RFC4271]は、インターネットとBGP/MPLS VPNサービスの両方のサービスプロバイダーネットワーク[RFC4364]の両方のサービスプロバイダーネットワークでよく使用されています。回復力のために、冗長ルーターとBGPセッションを展開して、自律システムのボーダールーター（ASBR）またはBGPセッションの故障の結果を減らすことができます。
We place ourselves in the context where a Service Provider performs a maintenance operation and needs to shut down one or multiple BGP peering link(s) or a whole ASBR. If an alternate path is available within the Autonomous System (AS), the requirement is to avoid or reduce customer or peer traffic loss during the BGP convergence.
サービスプロバイダーがメンテナンス操作を実行し、1つまたは複数のBGPピアリングリンクまたはASBR全体をシャットダウンする必要があるコンテキストに自分自身を置きます。自律システム内（AS）内で代替パスが利用可能である場合、要件は、BGP収束中の顧客またはピアトラフィックの損失を回避または削減することです。
Indeed, as an alternate path is available in the AS, it should be made possible to reroute the customer or peer traffic on this backup path before the BGP session(s) is/are torn down, the nominal path withdrawn, and the forwarding stopped.
実際、ASで代替パスが利用可能であるため、BGPセッションが取り壊される前にこのバックアップパスで顧客またはピアトラフィックを再ルーティングすることを可能にする必要があります。。
The requirements also cover the subsequent re-establishment of the BGP session as even this "UP" case can currently trigger route loss, and thus traffic loss, at some routers.
また、この「UP」ケースでさえ、一部のルーターでルートの損失、したがってトラフィックの損失を引き起こす可能性があるため、BGPセッションのその後の再確立をカバーしています。
BGP [RFC4271] and MP-BGP [RFC4760] do not currently have a mechanism to gracefully migrate traffic from one BGP next-hop to another without interrupting the flow of traffic. When a BGP session is taken down, BGP behaves as if there were a sudden link or router failure and withdraws the prefixes learned over that session, which may trigger traffic loss. While still being advertised as reachable, there is no mechanism to advertise to its BGP peers that the prefix will soon be unreachable. When applicable, such mechanism would reduce or prevent traffic loss. It would typically be applicable in case of a maintenance operation requiring the shutdown of a forwarding resource. Typical examples would be a link or line card maintenance, replacement, or upgrade. It may also be applicable for a software upgrade, as it may involve a firmware reset on the line cards and hence forwarding interruption.
BGP [RFC4271]およびMP-BGP [RFC4760]には、トラフィックの流れを中断することなく、あるBGPの次のホップから別のBGPの次のホップに優雅に移行するメカニズムは現在ありません。BGPセッションが削除されると、BGPは突然のリンクまたはルーターの故障があるかのように動作し、そのセッションで学習したプレフィックスを引き出し、トラフィックの損失を引き起こす可能性があります。まだ到達可能であると宣伝されていますが、プレフィックスがすぐに到達できないことをBGPピアに宣伝するメカニズムはありません。該当する場合、そのようなメカニズムはトラフィックの損失を減少または防止します。通常、転送リソースのシャットダウンを必要とするメンテナンス操作の場合に適用できます。典型的な例は、リンクまたはラインカードのメンテナンス、交換、またはアップグレードです。また、ラインカードのファームウェアリセットが含まれ、したがって中断の転送が含まれる可能性があるため、ソフトウェアのアップグレードにも適用できる場合があります。
The introduction of route reflectors (RRs) as per [RFC4456] to solve scalability issues bound to Internal BGP (IBGP) full-meshes has worsened the duration of routing convergence as some route reflectors may hide the backup path. Thus, depending on RR topology, more IBGP hops may be involved in the IBGP convergence.
内部BGP（IBGP）フルメッシュに結合したスケーラビリティの問題を解決するためのルートリフレクター（RRS）の導入は、一部のルートリフレクターがバックアップパスを隠す可能性があるため、ルーティング収束の期間が悪化しました。したがって、RRトポロジーに応じて、IBGP収束にもっと多くのIBGPホップが関与している可能性があります。
Note that these planned maintenance operations cannot be addressed by Graceful Restart (GR) extensions [RFC4724] as GR only applies when the forwarding is preserved during the control plane restart. On the contrary, graceful shutdown applies when the forwarding is interrupted.
これらの計画されたメンテナンス操作は、GRがコントロールプレーンの再起動中に転送が保存されている場合にのみ適用されるため、Graceful Restart（GR）拡張[RFC4724]で対処できないことに注意してください。それどころか、転送が中断されると、優雅なシャットダウンが適用されます。
Also, note that some protocols are already considering such a graceful shutdown procedure (e.g., GMPLS in [RFC5817]).
また、一部のプロトコルはすでにこのような優雅なシャットダウン手順を検討していることに注意してください（例：[RFC5817]のGMPL）。
A metric of success is the degree to which such a mechanism eliminates traffic loss during maintenance operations.
成功の指標とは、そのようなメカニズムがメンテナンス操作中のトラフィックの損失を排除する程度です。
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]で説明されているように解釈されます。
As per [RFC4271], when one (or many) BGP session(s) are shut down, a BGP NOTIFICATION message is sent to the peer and the session is then closed. A protocol convergence is then triggered both by the local router and by the peer. Alternate paths to the destination are selected, if known. If those alternate paths are not known prior to the BGP session shutdown, additional BGP convergence steps are required in each AS to search for an alternate path.
[RFC4271]によると、1つ（または多くの）BGPセッションがシャットダウンされると、BGP通知メッセージがピアに送信され、セッションが閉じられます。次に、ローカルルーターとピアによってプロトコル収束がトリガーされます。既知の場合、宛先への代替パスが選択されます。BGPセッションのシャットダウンの前にこれらの代替パスが不明な場合、代替パスを検索するために、それぞれに追加のBGP収束ステップが必要です。
This behavior is not satisfactory in a maintenance situation because the traffic that was directed towards the removed next-hops may be lost until the end of the BGP convergence. As it is a planned operation, a make-before-break solution should be made possible.
この動作は、メンテナンスの状況では満足のいくものではありません。なぜなら、BGP収束の終了まで削除された次元に向けられたトラフィックが失われる可能性があるためです。計画された操作であるため、ブレイク前の解決策を可能にする必要があります。
As maintenance operations are frequent in large networks [Reliable], the global availability of the network is significantly impaired by this BGP maintenance issue.
メンテナンス操作は大規模なネットワーク[信頼性]で頻繁に発生するため、ネットワークの世界的な可用性は、このBGPメンテナンスの問題によって著しく損なわれています。
To illustrate these problems, let us consider the following simple example where one customer router "CUST" is dual-attached to two Service Providers' routers, "ASBR1" and "ASBR2".
これらの問題を説明するために、1つの顧客ルーターの「CUST」が2つのサービスプロバイダーのルーター「ASBR1」と「ASBR2」に二重に接続されているという単純な例を考えてみましょう。
ASBR1 and ASBR2 are in the same AS and are owned by the same Service Provider. Both are IBGP clients of the route reflector R1.
ASBR1とASBR2は同じサービスプロバイダーと同じであり、所有されています。どちらもルートリフレクターR1のIBGPクライアントです。
' AS1 ' AS2 '
「AS1」AS2 '
/-----------ASBR1---
/ \
/ \
CUST R1
\ /
Z/z \ /
\-----------ASBR2---
' AS1 ' AS2 '
「AS1」AS2 '
Figure 1. Dual-Attached Customer
図1.二重の顧客
Before the maintenance, packets for destination Z/z use the ASBR1- CUST link because R1 selects ASBR1's route based on the IGP cost.
メンテナンスの前に、宛先Z/Zのパケットは、IGPコストに基づいてASBR1のルートを選択するため、ASBR1- CUSTリンクを使用します。
Let's assume the Service Provider wants to shut down the ASBR1-CUST link for maintenance purposes. Currently, when the shutdown is performed on ASBR1, the following steps are performed:
サービスプロバイダーがメンテナンス目的でASBR1-Custリンクをシャットダウンしたいと仮定しましょう。現在、ASBR1でシャットダウンが実行されると、次の手順が実行されます。
1. ASBR1 withdraws its prefix Z/z to its route reflector, R1.
1. ASBR1は、そのプレフィックスz/zをルートリフレクターR1に引き出します。
2. R1 runs its decision process, selects the route from ASBR2, and advertises the new path to ASBR1.
2. R1は決定プロセスを実行し、ASBR2からルートを選択し、ASBR1への新しいパスを宣伝します。
3. ASBR1 runs its decision process and recovers the reachability of Z/z.
3. ASBR1は決定プロセスを実行し、z/zの到達可能性を回復します。
Traffic is lost at step 1 when ASBR1 looses its route until step 3 when it discovers a new path.
ASBR1が新しいパスを発見するステップ3までルートを失うステップ1でトラフィックが失われます。
Note that this is a simplified description for illustrative purposes. In a bigger AS, multiple steps of BGP convergence may be required to find and select the best alternate path (e.g., ASBR1 may be chosen based on a higher LOCAL_PREF, hierarchical route reflectors may be used, etc.). When multiple BGP routers are involved and plenty of prefixes are affected, the recovery process can take longer than application requirements.
これは、実例のための簡略化された説明であることに注意してください。より大きなASでは、BGP収束の複数のステップが最適な代替パスを見つけて選択する必要がある場合があります（たとえば、ASBR1は、より高いLocal_Prefに基づいて選択できます。階層ルートリフレクターを使用するなど）。複数のBGPルーターが関与し、多くの接頭辞が影響を受けると、回復プロセスにはアプリケーション要件よりも時間がかかる場合があります。
The loss of packets during maintenance has two main causes:
メンテナンス中のパケットの損失には、2つの主な原因があります。
- lack of an alternate path on some routers, and
- いくつかのルーターに代替パスがないこと、および
- transient routing inconsistency.
- 一時的なルーティングの矛盾。
Some routers may lack an alternate path because another router is hiding the backup path. This router can be:
別のルーターがバックアップパスを隠しているため、一部のルーターは代替パスがない場合があります。このルーターは次のことができます：
- a route reflector only propagating its best path.
- ルートリフレクターは、その最高のパスのみを伝播します。
- the backup ASBR not advertising the backup path because it prefers the nominal path.
- バックアップASBRは、名目パスを好むため、バックアップパスを宣伝していません。
This lack of knowledge regarding the alternate path is the first target of this requirements document.
代替パスに関するこの知識の欠如は、この要件文書の最初のターゲットです。
Transient routing inconsistencies happen during IBGP convergence because routers do not simultaneously update their Routing Information Bases (RIBs) and hence do not simultaneously update their Forwarding Information Bases (FIBs) entries. This can lead to forwarding loops, which result in both link congestion and packet drops. The duration of these transient micro-loops is dependent on the IBGP topology (e.g., number of route reflectors between ingress and egress ASBR), implementation differences among router platforms (which result in differences in the time taken to update specific prefix in the FIB), and forwarding mode (hop-by-hop IP forwarding versus tunneling).
ルーターはルーティング情報ベース（リブ）を同時に更新せず、したがって、転送情報ベース（FIB）エントリを同時に更新しないため、IBGP収束中に一時的なルーティングの矛盾が発生します。これにより、転送ループにつながる可能性があり、その結果、リンクの混雑とパケットドロップの両方が生じます。これらの一時的なマイクロループの持続時間は、IBGPトポロジ（例えば、イングレスと出口ASBRの間のルートリフレクターの数）、ルータープラットフォーム間の実装の違い（FIBの特定のプレフィックスを更新するために取られた時間の違いをもたらす）に依存しています。、および転送モード（ホップバイホップIP転送とトンネリング）。
Note that when an IP lookup is only performed on entry to the AS, for example, prior to entry into a tunnel across the AS, micro-loops will not occur. An example of this is when BGP is being used as the routing protocol for MPLS VPN as defined in [RFC4364].
たとえば、ASへのトンネルに入る前にASへのエントリ時にのみIPルックアップが実行される場合、マイクロループは発生しません。この例は、[RFC4364]で定義されているように、BGPがMPLS VPNのルーティングプロトコルとして使用されている場合です。
Note that [RFC5715] defines a framework for loop-free convergence. It has been written in the context of IP fast reroute for link state IGP [RFC5714], but some concepts are also of interest for BGP convergence.
[RFC5715]は、ループフリーの収束のフレームワークを定義していることに注意してください。これは、Link State IGP [RFC5714]のIP Fast Rerouteのコンテキストで書かれていますが、BGP収束にとっていくつかの概念も興味深いものです。
g-shut: Graceful shutdown. A method for explicitly notifying the BGP routers that a BGP session (and hence the prefixes learned over that session) is going to be disabled.
G-Shut：優雅なシャットダウン。BGPルーターにBGPセッション（したがってそのセッションで学習したプレフィックス）が無効になることを明示的に通知する方法。
g-noshut: Graceful no shutdown. A method for explicitly notifying the BGP routers that a BGP session (and hence the prefixes learned over that session) is going to be enabled.
G-Noshut：Graceful No Shutdown。BGPルーターにBGPセッション（したがってそのセッションで学習したプレフィックス）が有効になることを明示的に通知する方法。
g-shut initiator: the router on which the session(s) shutdown(s) is (are) performed for maintenance.
G-SHUTイニシエーター：セッションがシャットダウンするルーターは、メンテナンスのために実行されます。
g-shut neighbor: a router that peers with the g-shut initiator via (one of) the session(s) undergoing maintenance.
G-Shut Neighbor：G-Shutイニシエーターと一緒に（その1つ）セッションを介して介して協力するルーター。
affected prefixes: a prefix initially reached via the peering link(s) undergoing maintenance.
影響を受けるプレフィックス：メンテナンスを受けているピアリングリンクを介して最初に到達したプレフィックス。
affected router: a router reaching an affected prefix via a peering link undergoing maintenance.
影響を受けるルーター：メンテナンスを受けているピアリングリンクを介して影響を受けるプレフィックスに到達するルーター。
initiator AS: the autonomous system of the g-shut initiator router.
イニシエーターAS：G-shutイニシエータールーターの自律システム。
neighbor AS(es): the autonomous system(s) of the g-shut neighbor router(s).
neighbor as ess：g-shut neighborルーターの自律システム。
Currently, when a BGP session of the router under maintenance is shut down, the router removes the routes and then triggers the BGP convergence on its BGP peers by withdrawing its route.
現在、メンテナンス中のルーターのBGPセッションがシャットダウンされると、ルーターはルートを削除し、ルートを引き出してBGPピアのBGP収束をトリガーします。
The goal of BGP graceful shutdown of a (set of) BGP session(s) is to minimize traffic loss during a planned shutdown. Ideally, a solution should reduce this traffic loss to zero.
BGPの（Set of）BGPセッションの優雅なシャットダウンの目標は、計画されたシャットダウン中のトラフィックの損失を最小限に抑えることです。理想的には、ソリューションはこのトラフィックの損失をゼロに減らす必要があります。
Another goal is to minimize and, preferably, to eliminate packet loss when the BGP session is re-established following the maintenance.
もう1つの目標は、メンテナンス後にBGPセッションが再確立されたときにパケットの損失を最小限に抑え、できれば排除することです。
As the event is known in advance, a make-before-break solution can be used in order to initiate the BGP convergence, find and install the alternate paths before the nominal paths are removed. As a result, before the nominal BGP session is shut down, all affected routers learn and use the alternate paths. Those alternate paths are computed by BGP, taking into account the known status of the network, which includes known failures that the network is processing concurrently with the BGP session graceful shutdown and possibly other known graceful shutdowns under way. Therefore, multiple BGP graceful shutdowns overlapping within a short time frame are gracefully handled. Indeed, a given graceful shutdown takes into account all previous ones.
イベントが事前に知られているように、BGP収束を開始するためにブレイク前の解決策を使用して、公称パスが削除される前に代替パスを見つけてインストールできます。その結果、公称BGPセッションがシャットダウンされる前に、影響を受けるすべてのルーターが代替パスを学習して使用します。これらの代替パスは、ネットワークの既知のステータスを考慮してBGPによって計算されます。これには、ネットワークがBGPセッションの優雅なシャットダウンと同時に処理しているという既知の障害と、おそらく他の既知の優雅なシャットダウンが進行中です。したがって、短い時間枠内で重複する複数のBGPの優雅なシャットダウンが優雅に処理されます。実際、与えられた優雅なシャットダウンは、以前のすべてのものを考慮に入れています。
As a result, provided an alternate path with enough remaining capacity is available, the packets are rerouted before the BGP session termination and fewer packets (possibly none) are lost during the BGP convergence process since, at any time, all routers have a valid path.
その結果、十分な残り容量を備えた代替パスが利用可能である場合、BGPセッション終了の前にパケットが再ルーティングされ、BGP収束プロセス中にすべてのパケットが失われる可能性があります（おそらくなし）はいつでもすべてのルーターが有効なパスを持っているため。
From the above goals, we can derive the following requirements:
上記の目標から、次の要件を導き出すことができます。
a) A mechanism to advertise the maintenance action to all affected routers is REQUIRED. Such a mechanism may be either implicit or explicit. Note that affected routers can be located both in the local AS and in neighboring ASes. Note also that the maintenance action can either be the shutdown of a BGP session or the establishment of a BGP session.
a) 影響を受けるすべてのルーターにメンテナンスアクションを宣伝するメカニズムが必要です。このようなメカニズムは、暗黙的または明示的なものである場合があります。影響を受けるルーターは、ローカルASと隣接するASEの両方に配置できることに注意してください。また、メンテナンスアクションは、BGPセッションのシャットダウンまたはBGPセッションの確立である可能性があることに注意してください。
The mechanism SHOULD allow BGP routers to minimize and, preferably, eliminate packet loss when a path is removed or advertised. In particular, it SHOULD be ensured that the old path is not removed from the routing tables of the affected routers before the new path is known.
このメカニズムにより、BGPルーターが最小化され、できればパスが削除または宣伝されたときにパケットの損失を排除できるようにする必要があります。特に、新しいパスがわかる前に、影響を受けたルーターのルーティングテーブルから古い経路が削除されないようにする必要があります。
The solution mechanism MUST significantly reduce and, ideally, eliminate packet loss. A trade-off may be made between the degree of packet loss and the simplicity of the solution.
ソリューションメカニズムは、パケットの損失を大幅に削減し、理想的には排除する必要があります。パケット損失の程度とソリューションの単純さの間にトレードオフが行われる場合があります。
b) An Internet-wide convergence is OPTIONAL. However, if the initiator AS and the neighbor AS(es) have a backup path, they SHOULD be able to gracefully converge before the nominal path is shut down.
b) インターネット全体の収束はオプションです。ただし、イニシエーターASおよび隣人AS AS（ES）がバックアップパスを持っている場合、公称パスがシャットダウンする前に優雅に収束できるはずです。
c) The proposed solution SHOULD be applicable to any kind of BGP sessions (External BGP (EBGP), IBGP, IBGP route reflector client, EBGP confederations, EBGP multi hop, MultiProtocol BGP extension, etc.) and any address family. If a BGP implementation allows the closing or enabling of a subset of Address Family Identifiers (AFIs) carried in an MP-BGP session, this mechanism MAY be applicable to this subset of AFIs.
c) 提案されたソリューションは、あらゆる種類のBGPセッション（外部BGP（EBGP）、IBGP、IBGPルートリフレクタークライアント、EBGPコンフェデレーション、EBGPマルチホップ、マルチプロトコルBGP拡張など）および任意の住所ファミリに適用する必要があります。BGPの実装により、MP-BGPセッションで携帯されているアドレスファミリ識別子（AFI）のサブセットの閉鎖または有効化が可能になる場合、このメカニズムはAFIのこのサブセットに適用できる場合があります。
Depending on the kind of session, there may be some variations in the proposed solution in order to fulfill the requirements.
セッションの種類によっては、要件を満たすために提案されたソリューションにいくつかのバリエーションがある場合があります。
The following cases should be handled in priority:
次のケースは優先順位で処理する必要があります。
- The shutdown of an inter-AS link and therefore the shutdown of an EBGP session;
- Inter-ASリンクのシャットダウン、したがってEBGPセッションのシャットダウン。
- The shutdown of an ASBR and therefore the shutdown of all its BGP sessions.
- ASBRのシャットダウン、したがってそのすべてのBGPセッションのシャットダウン。
Service Providers and platforms implementing a graceful shutdown solution should note that in BGP/MPLS VPN as per [RFC4364], the Provider Edge - Customer Edge (PE-CE) routing can be performed by protocols other than BGP (e.g., static routes, RIPv2, OSPF, IS-IS). This is out of scope of this document.
優雅なシャットダウンソリューションを実装するサービスプロバイダーとプラットフォームは、[RFC4364]に従ってBGP/MPLS VPNでは、プロバイダーエッジ - 顧客エッジ（PE -CE）ルーティングは、BGP以外のプロトコルで実行できることに注意する必要があります。、ospf、is-is）。これはこのドキュメントの範囲外です。
d) The proposed solution SHOULD NOT change the BGP convergence behavior for the ASes exterior to the maintenance process, namely, ASes other than the initiator AS and its neighbor AS(es).
d) 提案されたソリューションは、メンテナンスプロセスの外側のASESのBGP収束挙動、つまり、イニシエーターASとその隣のAS AS（ES）以外のASESを変更するべきではありません。
e) An incremental deployment on a per-AS or per-BGP session basis MUST be made possible. In case of partial deployment, the proposed solution SHOULD incrementally improve the maintenance process. It should be noted that in an inter-domain relation, one AS may have more incentive to use graceful shutdown than the other. Similarly, in a BGP/MPLS VPN environment, it's much easier to upgrade the PE routers than the CE ones, mainly because there is at least an order of magnitude more CE and CE locations than PE and PE locations. As a consequence, when splitting the cost of the solution between the g-shut initiator and the g-shut neighbor, the solution SHOULD favor a low-cost solution on the neighbor AS side in order to reduce the impact on the g-shut neighbor. Impact should be understood as a generic term that includes first hardware, then software, then configuration upgrade.
e) ASごとまたはBGPごとのセッションベースでの増分展開を可能にする必要があります。部分的な展開の場合、提案されたソリューションはメンテナンスプロセスを徐々に改善する必要があります。ドメイン間の関係では、一方が他のものよりも優雅なシャットダウンを使用するインセンティブがある可能性があることに注意する必要があります。同様に、BGP/MPLS VPN環境では、PEルーターよりもPEルーターをアップグレードする方がはるかに簡単です。これは、主にPEおよびPEの位置よりも少なくとも1桁のCEとCEの場所があるためです。結果として、G-shutイニシエーターとG-shut隣人の間でソリューションのコストを分割する場合、ソリューションはG-shut隣人への影響を減らすために、隣人の低コストのソリューションを側面として好むはずです。影響は、最初のハードウェア、ソフトウェア、構成アップグレードを含む一般的な用語として理解する必要があります。
f) Redistribution or advertisement of (static) IP routes into BGP SHOULD also be covered.
f) BGPへの（静的）IPルートの再配布または広告もカバーする必要があります。
g) The proposed solution MAY be designed in order to avoid transient forwarding loops. Indeed, forwarding loops increase packet transit-delay and may lead to link saturation.
g) 提案されたソリューションは、一時的な転送ループを避けるために設計することができます。実際、転送ループはパケットトランジット遅延を増加させ、リンク飽和につながる可能性があります。
h) The specific procedure SHOULD end when the BGP session is closed following the g-shut and once the BGP session is gracefully opened following the g-noshut. In the end, once the planned maintenance is finished, the nominal BGP routing MUST be re-established. The duration of the g-shut procedure, and hence the time before the BGP session is safely closed, SHOULD be discussed by the solution document. Examples of possible solutions are the use of a pre-configured timer, the use of a message to signal the end of the BGP convergence, or the monitoring of the traffic on the g-shut interface.
h) 特定の手順は、G-Shutに続いてBGPセッションが閉じられ、G-Noshutに続いてBGPセッションが優雅に開かれたときに終了する必要があります。最終的に、計画されたメンテナンスが終了すると、公称BGPルーティングを再確立する必要があります。G-Shut手順の期間、したがってBGPセッションの前の時間は安全に閉じられる必要がありますが、ソリューションドキュメントで説明する必要があります。可能な解決策の例は、事前に構成されたタイマーの使用、BGP収束の終わりを通知するメッセージの使用、またはG-Shutインターフェイスのトラフィックの監視です。
i) The solution SHOULD be simple and simple to operate. Hence, it MAY only cover a subset of the cases. As a consequence, most of the above requirements are expressed as "SHOULD" rather than "MUST".
i) ソリューションはシンプルで操作が簡単でなければなりません。したがって、ケースのサブセットのみをカバーする場合があります。結果として、上記の要件のほとんどは、「必須」ではなく「必要」として表されます。
The metrics to evaluate and compare the proposed solutions are:
提案されたソリューションを評価および比較するメトリックは次のとおりです。
- The duration of the remaining loss of connectivity when the BGP session is brought down or up;
- BGPセッションが削減または上昇するときの接続性の残りの損失の期間。
- The applicability to a wide range of BGP and network topologies;
- 幅広いBGPおよびネットワークトポロジへの適用性。
- The simplicity;
- シンプルさ。
- The duration of transient forwarding loops;
- 一時的な転送ループの持続時間。
- The additional load introduced in BGP (e.g., BGP messages sent to peer routers, peer ASes, the Internet).
- BGPで導入された追加の負荷（たとえば、ピアルーター、ピアASE、インターネットに送信されるBGPメッセージ）。
At the requirements stage, this graceful shutdown mechanism is not expected to affect the security of the BGP protocol, especially if it can be kept simple. No new sessions are required and the additional ability to signal the graceful shutdown is not expected to bring additional attack vectors, as BGP neighbors already have the ability to send incorrect or misleading information or even shut down the session.
要件段階では、この優雅なシャットダウンメカニズムは、特に単純に保つことができる場合、BGPプロトコルのセキュリティに影響を与えるとは期待されていません。新しいセッションは必要ありません。また、BGPの隣人はすでに誤ったまたは誤解を招く情報を送信したり、セッションをシャットダウンする能力を持っているため、優雅なシャットダウンを示す追加の能力は追加の攻撃ベクトルをもたらすことは期待されていません。
Security considerations MUST be addressed by the proposed solutions. In particular, they SHOULD address the issues of bogus g-shut messages and how they would affect the network(s), as well as the impact of hiding a g-shut message so that g-shut is not performed.
セキュリティ上の考慮事項は、提案されたソリューションによって対処する必要があります。特に、偽のG-shutメッセージの問題と、それらがネットワークにどのように影響するか、およびG-shutメッセージが実行されないようにG-shutメッセージを隠すことの影響に対処する必要があります。
The solution SHOULD NOT increase the ability of one AS to selectively influence routing decision in the peer AS (inbound Traffic Engineering) outside of the case of the BGP session shutdown. Otherwise, the peer AS SHOULD have means to detect such behavior.
このソリューションは、BGPセッションのシャットダウンの場合の外側の（インバウンドトラフィックエンジニアリング）として、ピアのルーティング決定に選択的に影響を与えるために、能力を向上させるべきではありません。それ以外の場合、ピアはそのような動作を検出する手段を持っているはずです。
[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月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[RFC4456] Bates、T.、Chen、E。、およびR. Chandra、「BGPルートリフレクション：フルメッシュ内部BGP（IBGP）の代替」、RFC 4456、2006年4月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", RFC 5817, April 2010.
[RFC5817] Ali、Z.、Vasseur、JP。、Zamfir、A。、およびJ. Newton、「MPLSおよびGeneralized MPLS Traffic Engineering Networksの優雅なシャットダウン」、RFC 5817、2010年4月。
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010.
[RFC5715] Shand、M。およびS. Bryant、「ループフリーコンバージェンスのフレームワーク」、RFC 5715、2010年1月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714] Shand、M。およびS. Bryant、「IP Fast Reroute Framework」、RFC 5714、2010年1月。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[RFC4724] Sangli、S.、Chen、E.、Fernando、R.、Scudder、J。、およびY. Rekhter、「BGPの優雅な再起動メカニズム」、RFC 4724、2007年1月。
[Reliable] Network Strategy Partners, LLC. "Reliable IP Nodes: A prerequisite to profitable IP services", November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf
[信頼性]ネットワーク戦略パートナー、LLC。「信頼できるIPノード：収益性の高いIPサービスへの前提条件」、2002年11月。http：//www.nspllc.com/newpages/reliable_ip_nodes.pdf
Acknowledgments
謝辞
The authors would like to thank Nicolas Dubois, Benoit Fondeviole, Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste, and Ronald Bonica for their useful discussions on this subject, review, and comments.
著者は、ニコラス・デュボア、ブノワ・フォンデヴィオール、クリスチャン・ジャケネット、オリビエ・ボナヴェントゥール、スティーブ・ウーリグ、ザビエル・ヴィネット、ヴィンセント・ジレット、ジャン・ルイス・ル・ルー、ピエール・アレイン・コステ、ロナルド・バニカに、この主題についての彼らの有用な議論に感謝します。コメント。
This document has been partly sponsored by the European project IST AGAVE.
この文書は、ヨーロッパのプロジェクトIST Agaveによって部分的に後援されています。
This section describes some frequent BGP topologies used both within the AS (IBGP) and between ASes (EBGP). Solutions should be applicable to the following topologies and their combinations.
このセクションでは、AS（IBGP）とASE（EBGP）内で使用されるいくつかの頻繁なBGPトポロジについて説明します。ソリューションは、次のトポロジとその組み合わせに適用できる必要があります。
This section describes some frequent BGP topologies used between ASes. In each figure, a line represents a BGP session.
このセクションでは、ASEの間で使用されるいくつかの頻繁なBGPトポロジについて説明します。各図では、行はBGPセッションを表します。
In this topology, we have an asymmetric protection scheme between AS1 and AS2:
このトポロジでは、AS1とAS2の間に非対称保護スキームがあります。
- On the AS2 side, two different routers are used to connect to AS1.
- AS2側では、2つの異なるルーターを使用してAS1に接続します。
- On the AS1 side, one single router with two BGP sessions is used.
- AS1側では、2つのBGPセッションを備えた1つのルーターが使用されます。
'
AS1 ' AS2
'
/----------- ASBR2.1
/ '
/ '
ASBR1.1 '
\ '
\ '
\----------- ASBR2.2
'
'
AS1 ' AS2
'
Figure 2. EBGP Topology with Redundant ASBR in One of the ASes
図2. ASESの1つに冗長ASBRを備えたEBGPトポロジー
BGP graceful shutdown is expected to be applicable for the maintenance of:
BGP優雅なシャットダウンは、次のメンテナンスに適用できると予想されます。
- one of the routers of AS2;
- AS2のルーターの1つ。
- one link between AS1 and AS2, performed either on an AS1 or AS2 router.
- AS1とAS2の間の1つのリンクは、AS1またはAS2ルーターで実行されました。
Note that in the case of maintenance of the whole router, all its BGP sessions need to be gracefully shutdown at the beginning of the maintenance and gracefully brought up at the end of the maintenance.
ルーター全体のメンテナンスの場合、すべてのBGPセッションはメンテナンスの開始時に優雅にシャットダウンし、メンテナンスの最後に優雅に育てられる必要があることに注意してください。
In this topology, we have a symmetric protection scheme between AS1 and AS2: on both sides, two different routers are used to connect AS1 to AS2.
このトポロジでは、AS1とAS2の間に対称保護スキームがあります。両側では、2つの異なるルーターを使用してAS1をAS2に接続します。
'
AS1 ' AS2
'
ASBR1.1----------- ASBR2.1
'
'
'
'
'
ASBR1.2----------- ASBR2.2
'
AS1 ' AS2
'
Figure 3. EBGP Topology with Redundant ASBRs in Both ASes
図3.両方のASEに冗長ASBRを備えたEBGPトポロジー
BGP graceful shutdown is expected to be applicable for the maintenance of:
BGP優雅なシャットダウンは、次のメンテナンスに適用できると予想されます。
- any of the ASBR routers (in AS1 or AS2);
- ASBRルーターのいずれか（AS1またはAS2）;
- one link between AS1 and AS2, performed either on an AS1 or AS2 router.
- AS1とAS2の間の1つのリンクは、AS1またはAS2ルーターで実行されました。
In this topology, at least three ASes are involved.
このトポロジでは、少なくとも3つのASEが関与しています。
'
AS1 ' AS2
'
ASBR1.1----------- ASBR2.1
| '
| '
'''''|''''''''''
| '
| '
ASBR3.1----------- ASBR2.2
'
AS3 ' AS2
Figure 4. EBGP Topology of a Dual-Homed Customer
図4.デュアルホームの顧客のEBGPトポロジ
As the requirement expressed in Section 5 is to advertise the maintenance only within the initiator and neighbor ASes, not Internet-wide, BGP graceful shutdown solutions may not be applicable to this topology. Depending on which routes are exchanged between these ASes, some protection for some of the traffic may be possible.
セクション5で表明されている要件は、インターネット全体ではなく、イニシエーターと近隣ASE内でのみメンテナンスを宣伝することであるため、BGPの優雅なシャットダウンソリューションはこのトポロジに適用できない場合があります。これらのASEの間でどのルートが交換されるかによって、一部のトラフィックに対するある程度の保護が可能になる場合があります。
For instance, if ASBR2.2 performs a maintenance affecting ASBR3.1, then ASBR3.1 will be notified. However, ASBR1.1 may not be notified of the maintenance of the EBGP session between ASBR3.1 and ASBR2.2.
たとえば、ASBR2.2がASBR3.1に影響を与えるメンテナンスを実行する場合、ASBR3.1に通知されます。ただし、ASBR1.1には、ASBR3.1とASBR2.2の間のEBGPセッションのメンテナンスについて通知されない場合があります。
This section describes some frequent BGP topologies used within an AS. In each figure, a line represents a BGP session.
このセクションでは、AS内で使用されるいくつかの頻繁なBGPトポロジについて説明します。各図では、行はBGPセッションを表します。
In this topology, we have a full-mesh of IBGP sessions:
このトポロジには、IBGPセッションのフルメッシュがあります。
P1 ----- P2
| \ / |
| \ / |
| \/ | AS1
| /\ |
| / \ |
| / \ |
ASBR1.1--ASBR1.2
\ /
\ /
''''''\'''/''''''''''''
\ / AS2
ASBR2.1
Figure 5. IBGP Full-Mesh
図5. IBGPフルメッシュ
When the session between ASBR1.1 and ASBR2.1 is gracefully shut down, it is required that all affected routers of AS1 reroute traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 is shut down.
ASBR1.1とASBR2.1のセッションが優雅にシャットダウンされると、ASBR1.1とASBR2.1の間のセッションがシャットダウンされる前に、AS1のトラフィックの影響を受けたすべてのルーターがASBR1.2に再ルーティングする必要があります。
Similarly, when the session between ASBR1.1 and ASBR2.1 is gracefully brought up, all affected routers of AS1 preferring ASBR1.1 over ASBR1.2 need to reroute traffic to ASBR1.1 before the less preferred path through ASBR1.2 is possibly withdrawn.
同様に、ASBR1.1とASBR2.1の間のセッションが優雅に育てられると、ASBR1.2よりもASBR1.1を好むASBR1.1のすべての影響を受けるルーターは、ASBR1.2を通るより少ない好ましいパスを前にASBR1.1に再ルーティングする必要があります。引きこもった。
In this topology, route reflectors are used to limit the number of IBGP sessions. There is a single level of route reflectors and the route reflectors are fully meshed.
このトポロジでは、ルートリフレクターを使用してIBGPセッションの数を制限します。ルートリフレクターには単一のレベルがあり、ルートリフレクターは完全にメッシュ化されています。
P1 (RR)-- P2 (RR)
| \ / |
| \ / |
| \ / | AS1
| \/ |
| /\ |
| / \ |
| / \ |
| / \ |
ASBR1.1 ASBR1.2
\ /
\ /
''''''\''''''/''''''''''''
\ /
\ / AS2
ASBR2.1
Figure 6. Route Reflector
図6.ルートリフレクター
When the session between ASBR1.1 and ASBR2.1 is gracefully shut down, all BGP routers of AS1 need to reroute traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 is shut down.
ASBR1.1とASBR2.1のセッションが優雅にシャットダウンされると、AS1のすべてのBGPルーターはASBR1.1とASBR2.1の間のセッションがシャットダウンする前にASBR1.2にトラフィックを再ルーティングする必要があります。
Similarly, when the session between ASBR1.1 and ASBR2.1 is gracefully brought up, all affected routers of AS1 preferring ASBR1.1 over ASBR1.2 need to reroute traffic to ASBR1.1 before the less preferred path through ASBR1.2 is possibly withdrawn.
同様に、ASBR1.1とASBR2.1の間のセッションが優雅に育てられると、ASBR1.2よりもASBR1.1を好むASBR1.1のすべての影響を受けるルーターは、ASBR1.2を通るより少ない好ましいパスを前にASBR1.1に再ルーティングする必要があります。引きこもった。
In this topology, hierarchical route reflectors are used to limit the number of IBGP sessions. There could be more than two levels of route reflectors and the top-level route reflectors are fully meshed.
このトポロジでは、IBGPセッションの数を制限するために階層ルートリフレクターを使用します。ルートリフレクターには3つ以上のレベルがあり、トップレベルのルートリフレクターが完全にメッシュ化されています。
P1 (RR) -------- P2 (RR)
| |
| |
| | AS1
| |
| |
P3 (RR) P4 (RR)
| |
| |
| | AS1
| |
| |
ASBR1.1 ASBR1.2
\ /
\ /
''''''\'''''''''/''''''''''''
\ /
\ / AS2
ASBR2.1
Figure 7. Hierarchical Route Reflector
図7.階層ルートリフレクター
When the session between ASBR1.1 and ASBR2.1 is gracefully shut down, all BGP routers of AS1 need to reroute traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 is shut down.
ASBR1.1とASBR2.1のセッションが優雅にシャットダウンされると、AS1のすべてのBGPルーターはASBR1.1とASBR2.1の間のセッションがシャットダウンする前にASBR1.2にトラフィックを再ルーティングする必要があります。
Similarly, when the session between ASBR1.1 and ASBR2.1 is gracefully brought up, all affected routers of AS1 preferring ASBR1.1 over ASBR1.2 need to reroute traffic to ASBR1.1 before the less preferred path through ASBR1.2 is possibly withdrawn.
同様に、ASBR1.1とASBR2.1の間のセッションが優雅に育てられると、ASBR1.2よりもASBR1.1を好むASBR1.1のすべての影響を受けるルーターは、ASBR1.2を通るより少ない好ましいパスを前にASBR1.1に再ルーティングする必要があります。引きこもった。
In this topology, a confederation of ASes is used to limit the number of IBGP sessions. Moreover, RRs may be present in the member ASes of the confederation.
このトポロジでは、ASESの連合が使用され、IBGPセッションの数を制限します。さらに、RRは、連合のメンバーASESに存在する場合があります。
Confederations may be run with different sub-options. Regarding the IGP, each member AS can run its own IGP or they can all share the same IGP. Regarding BGP, LOCAL_PREF may or may not cross the member AS boundaries.
コンフェデレーションは、異なるサブオプションで実行される場合があります。IGPに関しては、各メンバーが独自のIGPを実行できるか、すべて同じIGPを共有できます。BGPに関しては、local_prefが境界としてメンバーを越える場合としない場合があります。
A solution should support the graceful shutdown and graceful bringing up of EBGP sessions between member ASes in the confederation in addition to the graceful shutdown and graceful bringing up of EBGP sessions between a member-AS and an AS outside of the confederation.
ソリューションは、優雅なシャットダウンと同盟のメンバーASE間のEBGPセッションの優雅なシャットダウンと優雅な育成をサポートする必要があります。
ASBR1C.1 ---------- ASBR1C.2
| |
| |
| AS1C |
| |
| |
"""|"""""""""""""""""""|"""
| " |
ASBR1A.2 " ASBR1B.2
| " |
| " |
| AS1A " AS1B | AS1
| " |
| " |
ASBR1A.1 " ASBR1B.1
\ " /
\ " /
''''''\'''''''''''''/''''''''''''
\ /
\ / AS2
ASBR2.1
Figure 8. Confederation
図8.連合
In the above figure, member ASes AS1A, AS1B, and AS1C belong to a confederation of ASes in AS1. AS1A and AS1B are connected to AS2.
上記の図では、メンバーASES AS1A、AS1B、およびAS1CはAS1のASESの連合に属します。AS1AおよびAS1BはAS2に接続されています。
In normal operation, for the traffic toward AS2:
通常の動作では、AS2へのトラフィックの場合：
- AS1A sends the traffic directly to AS2 through ASBR1A.1.
- AS1Aは、ASBR1A.1を介してトラフィックをAS2に直接送信します。
- AS1B sends the traffic directly to AS2 through ASBR1B.1.
- AS1Bは、ASBR1B.1を介してトラフィックをAS2に直接送信します。
- AS1C load balances the traffic between AS1A and AS1B.
- AS1C負荷は、AS1AとAS1Bの間のトラフィックのバランスをとります。
When the session between ASBR1A.1 and ASBR2.1 is gracefully shut down, all BGP routers of AS1 need to reroute traffic to ASBR1B.1 before the session between ASBR1A.1 and ASBR2.1 is shut down.
ASBR1A.1とASBR2.1のセッションが優雅にシャットダウンされると、AS1のすべてのBGPルーターは、ASBR1A.1とASBR2.1の間のセッションがシャットダウンする前にASBR1B.1にトラフィックを再ルーティングする必要があります。
Similarly, when the session between ASBR1A.1 and ASBR2.1 is gracefully brought up, all affected routers of AS1 preferring ASBR1A.1 over ASBR1B.1 need to reroute traffic to ASBR1A.1 before the less preferred path through ASBR1B.1 is possibly withdrawn.
同様に、ASBR1A.1とASBR2.1の間のセッションが優雅に育てられると、ASBR1B.1よりもASBR1B.1よりもASBR1A.1を好むAS1のすべての影響を受けるルーターは、ASBR1B.1を通るより少ない好ましいパスを前にASBR1A.1に再ルーティングする必要があります。引きこもった。
Here we describe some routing engineering choices that are frequently used in ASes and that should be supported by the solution.
ここでは、ASESで頻繁に使用されるルーティングエンジニアリングの選択肢について説明します。これは、ソリューションによってサポートされる必要があります。
The ingress router selects the nominal egress ASBR (AS exit point) based on the IGP cost to reach the BGP next-hop.
Ingressルーターは、IGPコストに基づいてBGP Next-Hopに到達するためのIGPコストに基づいて、公称出力ASBR（出口点として）を選択します。
The ingress router selects the nominal egress ASBR based on the BGP LOCAL_PREF value set and advertised by the exit point.
Ingressルーターは、BGP local_pref値セットに基づいて公称出力ASBRを選択し、出口ポイントで宣伝します。
The ingress router selects the nominal egress ASBR based on preconfigured policy information. (Typically, this is done by locally setting the BGP LOCAL_PREF based on the BGP communities attached on the routes).
Ingressルーターは、事前に設定されたポリシー情報に基づいて、公称出力ASBRを選択します。（通常、これは、ルートに接続されているBGPコミュニティに基づいてBGP Local_Prefをローカルに設定することによって行われます）。
As per [RFC4271], note that if tunnels are not used to forward packets between the ingress and egress ASBR; this can lead to persistent forwarding loops.
[RFC4271]によると、トンネルがイングレスASBRと出口ASBRの間のパケットを転送するために使用されない場合は注意してください。これにより、永続的な転送ループにつながる可能性があります。
Authors' Addresses
著者のアドレス
Bruno Decraene France Telecom 38-40 rue du General Leclerc 92794 Issy Moulineaux cedex 9 France EMail: bruno.decraene@orange-ftgroup.com
Bruno Decraene France Telecom 38-40 Rue du General Leclerc 92794 Issy Moulineaux Cedex 9 Franceメール：bruno.decraene@orange-ftgroup.com
Pierre Francois Universite catholique de Louvain Place Ste Barbe, 2 Louvain-la-Neuve 1348 BE EMail: francois@info.ucl.ac.be
Pierre Francois Universite Catholique de Louvain Place Ste Barbe、2 Louvain-la-neuve 1348 be email：francois@info.ucl.ac.be
Cristel Pelsser Internet Initiative Japan Jinbocho Mitsui Building 1-105 Kanda jinbo-cho Chiyoda-ku, Tokyo 101-0051 Japan EMail: cristel@iij.ad.jp
クリステルペルサーインターネットイニシアチブジャパンジンボチョミツイビル1-105カンダジンボチョチヨーダクー、東京101-0051日本メール：cristel@iij.ad.jp
Zubair Ahmad Orange Business Services 13775 McLearen Road, Oak Hill VA 20171 USA EMail: zubair.ahmad@orange-ftgroup.com
Zubair Ahmad Orange Business Services 13775 MCLEAREN ROAD、OAK HILL VA 20171 USAメール：zubair.ahmad@orange-ftgroup.com
Antonio Jose Elizondo Armengol Division de Analisis Tecnologicos Technology Analysis Division Telefonica I+D C/ Emilio Vargas 6 28043, Madrid EMail: ajea@tid.es
アントニオ・ホセ・エリゾンド・アーマンゴル部門DEアナリシスTECNOLOGICOSテクノロジー分析部門Telefonica I D C/ Emilio Vargas 6 28043、Madrid Email：ajea@tid.es
Tomonori Takeda NTT Corporation 9-11, Midori-Cho 3 Chrome Musashino-Shi, Tokyo 180-8585 Japan EMail: takeda.tomonori@lab.ntt.co.jp
Tomonori Takeda NTT Corporation 9-11、Midori-Cho 3 Chrome Musashino-Shi、Tokyo 180-8585日本メール：takeda.tomonori@lab.ntt.co.jp