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
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.
ボーダーゲートウェイプロトコル（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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
ボーダーゲートウェイプロトコル（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.
私たちは、サービスプロバイダは、保守操作を実行し、一つまたは複数のBGPピアリングのリンク（S）または全体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ピアにアドバタイズするメカニズムはありません。該当する場合、このようなメカニズムは、トラフィック損失を軽減または防止するであろう。それは、典型的には、転送リソースのシャットダウンを必要とするメンテナンス作業の場合に適用可能です。典型的な例は、リンクまたはラインカードの保守、交換、またはアップグレードします。それはラインカード上のファームウェアのリセットを伴うので、中断を転送することとして、それはまた、ソフトウェアのアップグレードのために適用することができます。
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.
[RFC4456]の通りのルートリフレクタ（RRS）の導入は、フルメッシュが予備パスを非表示にすることができるいくつかのルートリフレクタとして収束ルーティングの持続時間を悪化させた内部BGP（IBGP）に結合されたスケーラビリティの問題を解決します。したがって、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のみ転送が制御プレーンの再起動時に保存されている場合に適用されるように、これらの計画された保守操作がグレースフルリスタート（GR）拡張[RFC4724]によって対処することができないことに留意されたいです。転送が中断されたとき逆に、正常なシャットダウンが適用されます。
Also, note that some protocols are already considering such a graceful shutdown procedure (e.g., GMPLS in [RFC5817]).
また、いくつかのプロトコルはすでに正常なシャットダウン手順（[RFC5817]で、例えば、GMPLS）を考慮していることに注意してください。
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.
1つ（または多くの）BGPセッション（複数可）がシャットダウンされている[RFC4271]に従って、BGP通知メッセージがピアに送信され、セッションが閉じています。プロトコルの収束は、ローカルルータによって、およびピアの両方によってトリガされます。既知の場合目的地への代替経路が選択されます。これらの代替パスがBGPセッションをシャットダウンする前に知られていない場合は、追加のBGPコンバージェンス手順は、代替パスを検索するASそれぞれで必要とされます。
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は同じAS内にあり、同じサービスプロバイダによって所有されています。どちらも、ルートリフレクタR1のIBGPクライアントです。
'
AS1 ' AS2
'
/-----------ASBR1---
/ \
/ \
CUST R1
\ /
Z/z \ /
\-----------ASBR2---
'
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.
R1は、IGPコストに基づいてASBR1の経路を選択するので、メンテナンス前に、先のZ / Zのパケットが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に行われた場合、現在、以下のステップが実行されます。
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
ルータが同時にルーティング情報ベース（リブ）を更新していないので、同時に自分を更新しないので、一時的なルーティング矛盾はIBGP収束の間に起こります
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トポロジに依存している（例えば、入口及び出口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].
IPルックアップのみASへのエントリ上で実行される場合、例えば、ASを横断トンネルに入る前に、マイクロループが発生しないことに留意されたいです。 [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]はループフリー収束するためのフレームワークを定義することに留意されたいです。これは、リンク状態IGP [RFC5714]のためのIP高速リルートの文脈で書かれているが、いくつかの概念は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-シャット：正常なシャットダウン。明示的に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：グレースフルシャットダウンなし。明示的にBGPセッション（したがって、接頭辞は、そのセッションで学んだ）BGPルータに通知するための方法が有効にされようとしています。
g-shut initiator: the router on which the session(s) shutdown(s) is (are) performed for maintenance.
G-シャットイニシエータ：ルータセッションその上に（S）シャットダウン（S）される（されている）は、メンテナンスのために行います。
g-shut neighbor: a router that peers with the g-shut initiator via (one of) the session(s) undergoing maintenance.
G-シャット隣人：メンテナンス中（の一つ）を介してG-シャット開始剤とピアルータのセッション（複数可）。
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-シャットイニシエータルータの自律システム。
neighbor AS(es): the autonomous system(s) of the g-shut neighbor router(s).
隣人AS（ES）：G-シャットネイバールータ（複数可）の自律システム（複数可）。
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セッション（複数可）（のセット）のBGPグレースフルシャットダウンの目標は、計画停止中のトラフィック損失を最小限に抑えることです。理想的には、解決策がゼロにこのトラフィック損失を減らす必要があります。
Another goal is to minimize and, preferably, to eliminate packet loss when the BGP session is re-established following the maintenance.
もう一つの目標は、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に隣接のASの両方に配置することができることに留意されたいです。注また、保守アクションは、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.
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（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セッションで運ばアドレスファミリー識別子（AFIS）のサブセットの閉鎖または可能にすることができた場合、このメカニズムはAFISのこのサブセットに適用することができます。
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;
- 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（例えば、静的ルート以外のプロトコルで行うことができる、RIPv2の、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）に提案された解決策は、ASイニシエータとその隣人AS（ES）より、すなわち、ASの他の保守プロセスへのASの外部のためのBGPの収束挙動を変更しないでください。
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セッションごとに増分の展開を可能にしなければなりません。部分的な配備の場合には、提案された解決策は、増分メンテナンス処理を改善するはずです。ドメイン間の関係で、1 ASが他よりも正常なシャットダウンを使用するより多くのインセンティブを持っていることに留意すべきです。同様に、BGP / MPLS VPN環境では、それはPEとPEの場所よりも大きさよりCEおよびCE場所の順序は、少なくともそこにある主な理由は、CEのものよりもPEルータをアップグレードする方がはるかに簡単です。 G-シャットダウン開始およびG-シャットネイバー間の溶液の費用を分割する場合、結果として、溶液は、G-シャット近隣への影響を低減するために、側ASネイバーで低コストのソリューションを好むべきです。インパクトは、その後最初に、ハードウェア、ソフトウェア、コンフィギュレーションのアップグレードが含まれ、一般的な用語として理解されるべきです。
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.
BGPセッションがG-shutおよびBGPセッションが正常G-noshut以下開かれると、次の閉じられたときに、H）は、特定の手順が終了します。計画的なメンテナンスが終了したら終わりでは、名目上のBGPルーティングを再確立する必要があります。従って、G-遮断手順の持続時間、およびBGPセッション前の時間は、溶液文書によって議論されるべきであり、安全に閉じられます。可能な解決策としては、例えば、予め設定されたタイマーの使用は、メッセージの使用はBGPコンバージェンスの端、またはG-シャットインターフェイス上のトラフィックの監視を知らせるためです。
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".
ⅰ）ソリューションは、シンプルで操作が簡単であるべきです。したがって、それが唯一の例サブセットをカバーすることができます。その結果、上記の要件の大部分はむしろ、「MUST」よりも「SHOULD」として表されます。
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に導入された追加の負荷（例えば、ルータをピアに送信されるBGPメッセージ、ピアのAS、インターネット）。
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-シャットメッセージの問題に対処する必要があり、それらがネットワーク（複数可）、ならびにG-遮断が行われないように、G-シャットダウンメッセージを隠蔽の影響に影響を与えるだろうか。
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セッションのシャットダウンの例外（インバウンドトラフィックエンジニアリング）ASピアにルーティングの決定に影響を与えるAS 1の能力を増加させるべきではありません。そうしないと、ピアはAS、このような動作を検出する手段を持っているべきです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル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]ベイツ、T.、チャンドラ、R.、カッツ、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]ベイツ、T.、チェン、E.、およびR.チャンドラ、 "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]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、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]アリ、Z.、Vasseur、JP。、Zamfir、A.、およびJ.ニュートン、 "MPLSおよび一般化MPLSトラフィックエンジニアリングネットワークの正常なシャットダウン"、RFC 5817、2010年4月。
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010.
[RFC5715]シャンド、M.とS.ブライアント、 "ループフリーコンバージェンスのための枠組み"、RFC 5715、2010年1月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714]シャンド、M.とS.ブライアント、 "IP高速リルートフレームワーク"、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]サングリ、S.、チェン、E.、フェルナンド、R.、スカダー、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.
著者は、このテーマに関する自分の有益な議論のためのレビューをニコラス・デュボア、ブノワFondeviole、クリスチャンJacquenet、オリヴィエ・ボナベンチャー、スティーブUhlig、ザビエルVINET、ヴィンセントジレ、ジャン=ルイ・ル・ルー、ピエール・アラン・コステ、およびロナルドBonicaに感謝したいと思い、そして、コメント。
This document has been partly sponsored by the European project IST AGAVE.
この文書では、一部の欧州プロジェクトISTリュウゼツランが主催されています。
Appendix A. Reference BGP Topologies
付録A.リファレンスBGPトポロジ
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）内とのAS（EBGP）間の両方使用されるいくつかの頻繁なBGPトポロジを記述する。ソリューションには、次のトポロジとその組み合わせに適用可能であるべきです。
A.1. EBGP Topologies
A.1。 EBGPトポロジ
This section describes some frequent BGP topologies used between ASes. In each figure, a line represents a BGP session.
このセクションでは、AS間使用されるいくつかの頻繁BGPトポロジについて説明します。各図において、行は、BGPセッションを表します。
A.1.1. One ASBR in AS1 Connected to Two ASBRs in the Neighboring AS2
A.1.1。近隣AS2における二つのASBRに接続AS1で一つのASBR
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側では、二つの異なるルータは、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
ASの一つで冗長ASBR図2. 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セッションはメンテナンスの終わりに育っメンテナンスと優雅の冒頭に正常にシャットダウンする必要があることに注意してください。
A.1.2. Two ASBRs in AS1 Connected to Two ASBRs in AS2
A.1.2。 AS2における二つのASBRに接続AS1における二つのASBR
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の間の対称保護スキームを持っています。両側に、二つの異なるルータがAS2にAS1を接続するために使用されています。
'
AS1 ' AS2
'
ASBR1.1----------- ASBR2.1
'
'
'
'
'
ASBR1.2----------- ASBR2.2
'
AS1 ' AS2
'
Figure 3. EBGP Topology with Redundant ASBRs in Both ASes
両方のAS内の冗長のASBR図3. EBGPトポロジ
BGP graceful shutdown is expected to be applicable for the maintenance of:
BGPグレースフルシャットダウンをのメンテナンスのための応用が期待されます。
- any of the ASBR routers (in AS1 or AS2);
- （AS1又はAS2における）ASBRルータのいずれか。
- one link between AS1 and AS2, performed either on an AS1 or AS2 router.
- AS1とAS2との間に1つのリンクは、AS1又はAS2ルータのいずれかを行いました。
A.1.3. Two ASBRs in AS2 Each Connected to Two Different ASes
A.1.3。 AS2における二つのASBRつの異なるのASに接続された各
In this topology, at least three ASes are involved.
このトポロジでは、少なくとも3つのASが関与しています。
'
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節で表現要件は、唯一のイニシエータと隣人のAS内のメンテナンスを宣伝するためにインターネット全体ではないので、BGPグレースフルシャットダウン・ソリューションは、このトポロジには適用できない場合があります。ルートがこれらのAS間で交換されるに応じて、トラフィックの一部のためのいくつかの保護が可能です。
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セッションの維持が通知されない場合があります。
A.2. IBGP Topologies
A.2。 IBGPトポロジ
This section describes some frequent BGP topologies used within an AS. In each figure, a line represents a BGP session.
このセクションでは、AS内で使用されるいくつかの頻繁にBGPトポロジについて説明します。各図において、行は、BGPセッションを表します。
A.2.1. IBGP Full-Mesh
A.2.1。 IBGPフルメッシュ
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間のセッションの前にASBR1.2にAS1・リルート・トラフィックの影響を受けるすべてのルータがシャットダウンされていることが必要です。
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を好むAS1の影響を受けるすべてのルータがASBR1.2を通してあまり好ましくないパスはおそらくある前にASBR1.1にトラフィックを再ルーティングする必要があります引きこもった。
A.2.2. Route Reflector
A.2.2。ルートリフレクタ
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を好むAS1の影響を受けるすべてのルータがASBR1.2を通してあまり好ましくないパスはおそらくある前にASBR1.1にトラフィックを再ルーティングする必要があります引きこもった。
A.2.3. Hierarchical Route Reflector
A.2.3。階層的なルートリフレクタ
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セッションの数を制限するために使用されます。そこルートリフレクタつ以上のレベルであってもよいし、最上位のルートリフレクタは完全に噛み合っています。
P1 (RR) -------- P2 (RR)
| |
| |
| | AS1
| |
| |
P3 (RR) P4 (RR) | | | | | | AS1 | | | | ASBR1.1 ASBR1.2 \ / \ / ''''''\'''''''''/'''''''''''' \ / \ / AS2 ASBR2.1
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を好むAS1の影響を受けるすべてのルータがASBR1.2を通してあまり好ましくないパスはおそらくある前にASBR1.1にトラフィックを再ルーティングする必要があります引きこもった。
A.2.4. Confederations
A.2.4。コンフェデレーションズ
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.
このトポロジでは、のASの連合はIBGPセッションの数を制限するために使用されます。また、RRは連合のメンバーのASに存在してもよいです。
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に関しては、AS各メンバーは、自身の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.
溶液部材-ASおよびAS外部連合の間のEBGPセッションの育て正常なシャットダウンと優雅に加えて連合のメンバーAS間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.
上記の図では、部材のASのAS1A、AS1B、及びAS1Cは、AS1でのASの連合に属します。 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上ASBR1A.1を好むAS1の影響を受けるすべてのルータがASBR1B.1を通してあまり好ましくないパスはおそらくある前にASBR1A.1にトラフィックを再ルーティングする必要があります引きこもった。
A.3. Routing Decisions
A.3。ルーティング決定
Here we describe some routing engineering choices that are frequently used in ASes and that should be supported by the solution.
ここでは、頻繁のASで使用され、それが解決策によってサポートされる必要があり、いくつかのルーティング技術の選択肢を説明します。
A.3.1. Hot Potato (IGP Cost)
A.3.1。ホットポテト（IGPコスト）
The ingress router selects the nominal egress ASBR (AS exit point) based on the IGP cost to reach the BGP next-hop.
入口ルータは、BGPネクストホップに到達するためのIGPコストに基づいて（出口点AS）、公称の出口ASBRを選択します。
A.3.2. Cold Potato (BGP LOCAL_PREF)
A.3.2。冷たいポテト（BGP LOCAL_PREF）
The ingress router selects the nominal egress ASBR based on the BGP LOCAL_PREF value set and advertised by the exit point.
入口ルータは、出口点によって設定され、アドバタイズBGP LOCAL_PREF値に基づいて、公称出口ASBRを選択します。
A.3.3. Cold Potato (BGP Preference Set on Ingress)
A.3.3。冷たいポテト（イングレスに設定してBGP優先）
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).
入口ルータは、事前に設定ポリシー情報に基づいて、公称の出口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間でパケットを転送するために使用されていない場合に注意してください。これは、永続的なフォワーディングループにつながることができます。
Authors' Addresses
著者のアドレス
Bruno Decraene France Telecom 38-40 rue du General Leclerc 92794 Issy Moulineaux cedex 9 France EMail: bruno.decraene@orange-ftgroup.com
ブルーノDecraeneフランステレコム38-40 RUEデュ一般ルクレール92794イシムリノーCEDEX 9、フランスEメール：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
ルーヴァン・プレイスサントバーベのピエール・フランソワ・カトリック大学、2ルーバン・ラ・ヌーブは1348 EメールBE：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
Ｃりｓてｌ ぺｌっせｒ いんてｒねｔ いにちあちゔぇ じゃぱん じんぼちょ みつい ぶいｌぢんｇ １ー１０５ かんだ じんぼーちょ ちよだーく、 ときょ １０１ー００５１ じゃぱん えまいｌ： ｃりｓてｌ＠いいｊ。あｄ。ｊｐ
Zubair Ahmad Orange Business Services 13775 McLearen Road, Oak Hill VA 20171 USA EMail: zubair.ahmad@orange-ftgroup.com
ズバイルアフマドオレンジビジネスサービス13775 McLearen道路、オークヒル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
ホセ・アントニオ・エリゾンドArmengol分析課Tecnologicos技術解析課電話R＆D C /エミリオ・バルガス6 28043マドリードEメール：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
とものり たけだ んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ Ｃｈろめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん えまいｌ： たけだ。とものり＠ぁｂ。んっｔ。こ。ｊｐ