Network Working Group S. Sangli
Request for Comments: 4724 E. Chen
Category: Standards Track Cisco Systems
R. Fernando
J. Scudder
Y. Rekhter
Juniper Networks
January 2007
Graceful Restart Mechanism for BGP
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.
この文書では、BGPの再起動によって引き起こされるルーティングにマイナスの影響を最小限に抑える助けとなるBGPのためのメカニズムについて説明します。エンド・オブ・RIBマーカーが指定されており、収束ルーティング情報を伝達するために使用することができます。 「グレースフルリスタート機能」と呼ばれる新しいBGP機能は、BGPスピーカは、BGPの再起動時に転送状態を維持する能力を表現できるようになることが規定されています。最後に、手順は、一時的にTCPセッション終了/再確立を横切ってルーティング情報を保持するために概説されています。
The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document).
本書で説明されたメカニズムは、すべてのルータ、BGPの再起動時に転送状態を維持する能力を有するものと、（本書で説明されたメカニズムのサブセットのみを実装する後者の必要が）ないものの両方に適用可能です。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Marker for End-of-RIB ...........................................3
3. Graceful Restart Capability .....................................3
4. Operation .......................................................6
4.1. Procedures for the Restarting Speaker ......................6
4.2. Procedures for the Receiving Speaker .......................7
5. Changes to BGP Finite State Machine .............................9
6. Deployment Considerations ......................................11
7. Security Considerations ........................................12
8. Acknowledgments ................................................13
9. IANA Considerations ............................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................13
Usually, when BGP on a router restarts, all the BGP peers detect that the session went down and then came up. This "down/up" transition results in a "routing flap" and causes BGP route re-computation, generation of BGP routing updates, and unnecessary churn to the forwarding tables. It could spread across multiple routing domains. Such routing flaps may create transient forwarding blackholes and/or transient forwarding loops. They also consume resources on the control plane of the routers affected by the flap. As such, they are detrimental to the overall network performance.
ルータの再起動の際にBGP通常、すべてのBGPピアは、セッションがダウンした、その後、思い付いたことを検出します。この「ダウン/アップ」「ルーティングフラップ」に遷移した結果とBGPルート再計算、BGPルーティングアップデートの生成、および転送テーブルに不要チャーンを引き起こします。これは、複数のルーティングドメインに広がる可能性があります。そのようなルーティングフラップは、過渡転送ブラックホール及び/又は過渡転送ループを作成することができます。彼らはまた、フラップによって影響を受けるルータの制御プレーン上のリソースを消費します。そのため、彼らは、ネットワーク全体のパフォーマンスに悪影響を及ぼしています。
This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.
この文書では、BGPの再起動によって引き起こされるルーティングにマイナスの影響を最小限に抑える助けとなるBGPのためのメカニズムについて説明します。エンド・オブ・RIBマーカーが指定されており、収束ルーティング情報を伝達するために使用することができます。 「グレースフルリスタート機能」と呼ばれる新しいBGP機能は、BGPスピーカは、BGPの再起動時に転送状態を維持する能力を表現できるようになることが規定されています。最後に、手順は、一時的にTCPセッション終了/再確立を横切ってルーティング情報を保持するために概説されています。
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]に記載されているように解釈されます。
An UPDATE message with no reachable Network Layer Reachability Information (NLRI) and empty withdrawn NLRI is specified as the End-of-RIB marker that can be used by a BGP speaker to indicate to its peer the completion of the initial routing update after the session is established. For the IPv4 unicast address family, the End-of-RIB marker is an UPDATE message with the minimum length [BGP-4]. For any other address family, it is an UPDATE message that contains only the MP_UNREACH_NLRI attribute [BGP-MP] with no withdrawn routes for that <AFI, SAFI>.
無到達可能なネットワーク層到達可能性情報（NLRI）、空とUPDATEメッセージは、NLRIは、セッション後にそのピアに初期ルーティングの更新が完了したことを示すために、BGPスピーカによって使用することができるエンドのリブマーカーとして指定され抜き出さ確立されています。 IPv4ユニキャストアドレスファミリのために、エンド・オブ・RIBマーカーは、最小の長さ[BGP-4]とUPDATEメッセージです。他のアドレスファミリーのために、その<AFI、SAFI>なし取り下げ経路のみMP_UNREACH_NLRI属性[BGP-MP]を含む更新メッセージです。
Although the End-of-RIB marker is specified for the purpose of BGP graceful restart, it is noted that the generation of such a marker upon completion of the initial update would be useful for routing convergence in general, and thus the practice is recommended.
エンドのリブマーカーがBGPグレースフルリスタートのために指定されているが、最初の更新の完了時にそのようなマーカーの生成は、一般に、収束をルーティングするために有用であろう、従って練習が推奨されることに留意されたいです。
In addition, it would be beneficial for routing convergence if a BGP speaker can indicate to its peer up-front that it will generate the End-of-RIB marker, regardless of its ability to preserve its forwarding state during BGP restart. This can be accomplished using the Graceful Restart Capability described in the next section.
BGPスピーカは、アップフロントそれは関係なく、BGPの再起動時にその転送状態を維持する能力の、エンド・オブ・RIBマーカーを生成することをそのピアに知らせることができればまた、収束をルーティングするために有益であろう。これは、次のセクションで説明したグレースフルリスタート機能を使用して達成することができます。
The Graceful Restart Capability is a new BGP capability [BGP-CAP] that can be used by a BGP speaker to indicate its ability to preserve its forwarding state during BGP restart. It can also be used to convey to its peer its intention of generating the End-of-RIB marker upon the completion of its initial routing updates.
グレースフルリスタート機能は、BGPの再起動時にその転送状態を維持する能力を示すために、BGPスピーカによって使用することができる新しいBGP機能[BGP-CAP]です。また、そのピアにその最初のルーティングアップデートの完了時にエンドの-RIBマーカーを生成する意向を伝えるために使用することができます。
This capability is defined as follows:
次のようにこの機能は定義されています。
Capability code: 64
機能コード：64
Capability length: variable
機能長：変数
Capability value: Consists of the "Restart Flags" field, "Restart Time" field, and 0 to 63 of the tuples <AFI, SAFI, Flags for address family> as follows:
能力値は、次のように<アドレスファミリのフラグは、AFI、SAFI>タプルの63に「再起動フラグ」フィールド、「再起動時」フィールド、および0で構成されています。
+--------------------------------------------------+
| Restart Flags (4 bits) |
+--------------------------------------------------+
| Restart Time in seconds (12 bits) |
+--------------------------------------------------+
| Address Family Identifier (16 bits) |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) |
+--------------------------------------------------+
| Flags for Address Family (8 bits) |
+--------------------------------------------------+
| ... |
+--------------------------------------------------+
| Address Family Identifier (16 bits) |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) |
+--------------------------------------------------+
| Flags for Address Family (8 bits) |
+--------------------------------------------------+
The use and meaning of the fields are as follows:
次のようにフィールドの使用と意味は以下のとおりです。
Restart Flags:
フラグを再起動します。
This field contains bit flags related to restart.
このフィールドは、再起動するように関連するビットフラグが含まれています。
0 1 2 3
+-+-+-+-+
|R|Resv.|
+-+-+-+-+
The most significant bit is defined as the Restart State (R) bit, which can be used to avoid possible deadlock caused by waiting for the End-of-RIB marker when multiple BGP speakers peering with each other restart. When set (value 1), this bit indicates that the BGP speaker has restarted, and its peer MUST NOT wait for the End-of-RIB marker from the speaker before advertising routing information to the speaker.
最上位ビットは、複数のBGPスピーカが互いに再起動とのピアリングエンドの-RIBマーカーを待っによって引き起こされる可能性デッドロックを回避するために使用することができます再起動状態（R）ビットとして定義されます。 （値1）に設定すると、このビットは、BGPスピーカが再起動したことを示し、そのピアは、スピーカーに広告ルーティング情報の前にスピーカーから終了のRIBマーカーを待つてはなりません。
The remaining bits are reserved and MUST be set to zero by the sender and ignored by the receiver.
残りのビットは予約され、送信者によってゼロに設定され、受信機で無視しなければなりません。
Restart Time:
再起動時間：
This is the estimated time (in seconds) it will take for the BGP session to be re-established after a restart. This can be used to speed up routing convergence by its peer in case that the BGP speaker does not come back after a restart.
これは、BGPセッションが再起動後に再確立されることがかかります（秒）推定時間です。これは、BGPスピーカは、再起動後に戻って来ていないことの場合にはそのピアによって収束のルーティングを高速化するために使用することができます。
Address Family Identifier (AFI), Subsequent Address Family Identifier (SAFI):
ファミリ識別子（AFI）、次のアドレスファミリ識別子（SAFI）をアドレス：
The AFI and SAFI, taken in combination, indicate that Graceful Restart is supported for routes that are advertised with the same AFI and SAFI. Routes may be explicitly associated with a particular AFI and SAFI using the encoding of [BGP-MP] or implicitly associated with <AFI=IPv4, SAFI=Unicast> if using the encoding of [BGP-4].
組み合わせて採取AFIとSAFIは、グレースフルリスタートが同じAFIとSAFIでアドバタイズされたルートのためにサポートされていることを示しています。ルートは、明示的に[BGP-MP]のエンコーディングを使用して特定のAFIとSAFIに関連付けられた、または[BGP-4]のエンコーディングを使用する場合、暗黙的に<AFI = IPv4の、サフィ=ユニキャスト>に関連付けられてもよいです。
Flags for Address Family:
アドレスファミリのためのフラグ：
This field contains bit flags relating to routes that were advertised with the given AFI and SAFI.
このフィールドは、指定されたAFIとSAFIでアドバタイズされたルートに関連するビットフラグを含みます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| Reserved |
+-+-+-+-+-+-+-+-+
The most significant bit is defined as the Forwarding State (F) bit, which can be used to indicate whether the forwarding state for routes that were advertised with the given AFI and SAFI has indeed been preserved during the previous BGP restart. When set (value 1), the bit indicates that the forwarding state has been preserved.
最上位ビットは、所与のAFIとSAFIでアドバタイズされたルートの転送状態が実際に以前のBGPの再起動時に保存されているかどうかを示すために使用することができるフォワーディング状態（F）ビットとして定義されます。 （値1）に設定すると、ビットは、転送状態が保存されていることを示しています。
The remaining bits are reserved and MUST be set to zero by the sender and ignored by the receiver.
残りのビットは予約され、送信者によってゼロに設定され、受信機で無視しなければなりません。
When a sender of this capability does not include any <AFI, SAFI> in the capability, it means that the sender is not capable of preserving its forwarding state during BGP restart, but supports procedures for the Receiving Speaker (as defined in Section 4.2 of this document). In that case, the value of the "Restart Time" field advertised by the sender is irrelevant.
この機能の送信者が能力がどの<AFI、SAFI>を含んでいない場合は、送信者がBGPの再起動時にその転送状態を保存することができないことを意味するが、セクション4.2で定義されている（受信スピーカーのための手続きをサポートしていますこのドキュメント）。その場合には、送信側によってアドバタイズ「再起動時間」フィールドの値は無関係です。
A BGP speaker MUST NOT include more than one instance of the Graceful Restart Capability in the capability advertisement [BGP-CAP]. If more than one instance of the Graceful Restart Capability is carried in the capability advertisement, the receiver of the advertisement MUST ignore all but the last instance of the Graceful Restart Capability.
BGPスピーカは、能力広告[BGP-CAP]でグレースフルリスタート機能の複数のインスタンスを含んではいけません。グレースフルリスタート機能の複数のインスタンスが、能力の広告に実施される場合には、広告の受信機は、グレースフルリスタート機能の最後のインスタンス以外のすべてを無視しなければなりません。
Including <AFI=IPv4, SAFI=unicast> in the Graceful Restart Capability does not imply that the IPv4 unicast routing information should be carried by using the BGP multiprotocol extensions [BGP-MP] -- it could be carried in the NLRI field of the BGP UPDATE message.
グレースフルリスタート機能に<AFI = IPv4の、サフィ=ユニキャスト>を含むこと[BGP-MP]のIPv4ユニキャストルーティング情報は、BGPマルチプロトコル拡張を使用して実施すべきであることを意味するものではない - それはのNLRIフィールドで搬送することができますBGP UPDATEメッセージ。
A BGP speaker MAY advertise the Graceful Restart Capability for an address family to its peer if it has the ability to preserve its forwarding state for the address family when BGP restarts. In addition, even if the speaker does not have the ability to preserve its forwarding state for any address family during BGP restart, it is still recommended that the speaker advertise the Graceful Restart Capability to its peer (as mentioned before this is done by not including any <AFI, SAFI> in the advertised capability). There are two reasons for doing this. The first is to indicate its intention of generating the End-of-RIB marker upon the completion of its initial routing updates, as doing this would be useful for routing convergence in general. The second is to indicate its support for a peer which wishes to perform a graceful restart.
それはBGPの再起動時にアドレスファミリ用の転送状態を維持する能力を持っている場合はBGPスピーカは、そのピアにアドレスファミリのグレースフルリスタート機能を広告するかもしれません。また、スピーカーはBGPの再起動時に任意のアドレスファミリーのための転送状態を維持する能力を持っていない場合でも、まだスピーカーが、これは含めないことによって行われる前に述べたように（そのピアにグレースフルリスタート機能を宣伝することをお勧めしますアドバタイズされた機能のいずれかの<AFI、SAFI>）。これを行うには2つの理由があります。最初は、これは一般的に収束をルーティングするために有用であろうこととして、その最初のルーティングアップデートの完了時にエンドの-RIBマーカーを生成する意向を示すためです。第二には、グレースフルリスタートを実行することを望むピアのサポートを示すためです。
The End-of-RIB marker MUST be sent by a BGP speaker to its peer once it completes the initial routing update (including the case when there is no update to send) for an address family after the BGP session is established.
BGPセッションが確立された後、それはアドレスファミリ用（送信するための更新がないときの場合を含む）最初のルーティングアップデートを完了すると、エンド・オブ・RIBマーカーは、そのピアにBGPスピーカーによって送らなければなりません。
It is noted that the normal BGP procedures MUST be followed when the TCP session terminates due to the sending or receiving of a BGP NOTIFICATION message.
TCPセッションが原因送信またはBGP通知メッセージの受信を終了すると、通常のBGP手順が続くなければならないことに留意されたいです。
A suggested default for the Restart Time is a value less than or equal to the HOLDTIME carried in the OPEN.
再起動時の推奨デフォルトはOPENで運ばHOLDTIME以下の値です。
In the following sections, "Restarting Speaker" refers to a router whose BGP has restarted, and "Receiving Speaker" refers to a router that peers with the restarting speaker.
次のセクションでは、「スピーカーを再起動すると、」そのBGPが再起動されたルータを指し、「スピーカーを受け取ると、」再起動スピーカーとピアルータを指します。
Consider that the Graceful Restart Capability for an address family is advertised by the Restarting Speaker, and is understood by the Receiving Speaker, and a BGP session between them is established. The following sections detail the procedures that MUST be followed by the Restarting Speaker as well as the Receiving Speaker once the Restarting Speaker restarts.
アドレスファミリのグレースフルリスタート機能が再開スピーカーによってアドバタイズされ、受信スピーカーによって理解され、そしてそれらの間のBGPセッションが確立されていることを考えてみましょう。以下のセクションで詳細再開スピーカーが続かなければならない手順と同様に受信スピーカー再起動スピーカー再開一度。
When the Restarting Speaker restarts, it MUST retain, if possible, the forwarding state for the BGP routes in the Loc-RIB and MUST mark them as stale. It MUST NOT differentiate between stale and other information during forwarding.
ときに再起動スピーカー再起動、それが可能な場合のLoc-RIBにおけるBGPルートのために、転送状態を保持しなければならなくて、古くなったとしてマークしなければなりません。それは、転送中に古いとその他の情報を区別してはなりません。
To re-establish the session with its peer, the Restarting Speaker MUST set the "Restart State" bit in the Graceful Restart Capability of the OPEN message. Unless allowed via configuration, the "Forwarding State" bit for an address family in the capability can be set only if the forwarding state has indeed been preserved for that address family during the restart.
ピアとのセッションを再確立するには、再起動のスピーカーは、OPENメッセージのグレースフルリスタート機能で「再起動状態」ビットを設定しなければなりません。コンフィギュレーションを経て許可されていない限り、能力のアドレスファミリの「フォワーディングステート」ビットは、転送状態が実際に再起動時にそのアドレスファミリのために保存されている場合にのみ設定することができます。
Once the session between the Restarting Speaker and the Receiving Speaker is re-established, the Restarting Speaker will receive and process BGP messages from its peers. However, it MUST defer route selection for an address family until it either (a) receives the End-of-RIB marker from all its peers (excluding the ones with the "Restart State" bit set in the received capability and excluding the ones that do not advertise the graceful restart capability) or (b) the Selection_Deferral_Timer referred to below has expired. It is noted that prior to route selection, the speaker has no routes to advertise to its peers and no routes to update the forwarding state.
再起動スピーカーと受信スピーカー間のセッションが再確立されると、再起動のスピーカーは、そのピアからのBGPメッセージを受信して処理します。それは（a）のもの受信機能に設定されている「再起動状態」ビットを持つものを除くとを除くすべてのピア（からエンドの-RIBマーカーを受信するまで、しかし、それはアドレスファミリのルート選択を延期しなければならないこと期限が切れているグレースフルリスタート機能を広告）または（b）Selection_Deferral_Timerは、以下を参照していません。従来の経路選択に、スピーカがそのピアと転送状態を更新するルートをアドバタイズするいかなる経路を有していないことに留意されたいです。
In situations where both Interior Gateway Protocol (IGP) and BGP have restarted, it might be advantageous to wait for IGP to converge before the BGP speaker performs route selection.
インテリアゲートウェイプロトコル（IGP）とBGPの両方が再起動した状況では、BGPスピーカが経路選択を行う前に収束するIGP待つことが有利かもしれません。
After the BGP speaker performs route selection, the forwarding state of the speaker MUST be updated and any previously marked stale information MUST be removed. The Adj-RIB-Out can then be advertised to its peers. Once the initial update is complete for an address family (including the case that there is no routing update to send), the End-of-RIB marker MUST be sent.
BGPスピーカが経路選択を実行した後に、スピーカの転送状態を更新する必要があり、任意の以前にマークされた古い情報を除去しなければなりません。調整]-RIB-Outが、そのピアにアドバタイズすることができます。最初の更新は（送るべきルーティングアップデートがない場合を含む）アドレスファミリの完了すると、エンド・オブ・RIBマーカーを送らなければなりません。
To put an upper bound on the amount of time a router defers its route selection, an implementation MUST support a (configurable) timer that imposes this upper bound. This timer is referred to as the "Selection_Deferral_Timer". The value of this timer should be large enough, so as to provide all the peers of the Restarting Speaker with enough time to send all the routes to the Restarting Speaker.
ルータがルート選択を延期する時間の量に上限を置くために、実装は、この上限を課して（設定可能）タイマーをサポートしなければなりません。このタイマーは、「Selection_Deferral_Timer」と呼ばれています。再起動のスピーカーへのすべてのルートを送信するために十分な時間で再起動スピーカーのすべてのピアを提供するように、このタイマの値は、十分な大きさでなければなりません。
If one wants to apply graceful restart only when the restart is planned (as opposed to both planned and unplanned restart), then one way to accomplish this would be to set the Forwarding State bit to 1 after a planned restart, and to 0 in all other cases. Other approaches to accomplish this are outside the scope of this document.
1は、再起動が予定されているのみグレースフルリスタートを（両方の計画的および計画外の再起動ではなく）に適用したい場合は、これを実現するための一つの方法は、計画の再起動後1にフォワーディングステートビットを設定し、全て0にすることです他の例。これを達成するための他のアプローチはこの文書の範囲外です。
When the Restarting Speaker restarts, the Receiving Speaker may or may not detect the termination of the TCP session with the Restarting Speaker, depending on the underlying TCP implementation, whether or not [BGP-AUTH] is in use, and the specific circumstances of the restart. In case it does not detect the termination of the old TCP session and still considers the BGP session as being established, it
再起動スピーカーを再起動すると、受信スピーカーまたは[BGP-AUTH]が使用中であるか否かを、基礎となるTCPの実装に依存して、再起動スピーカーとのTCPセッションの終了を検出し、特定の状況してもしなくてもよいです再起動。ケースでは、それを古いTCPセッションの終了を検出し、まだ確立されているとして、BGPセッションを考慮していません
MUST treat the subsequent open connection from the peer as an indication of the termination of the old TCP session and act accordingly (when the Graceful Restart Capability has been received from the peer). See Section 8 for a description of this behavior in terms of the BGP finite state machine.
古いTCPセッションの終了を示すものとして、ピアからの後続のオープン接続を治療し、（グレースフルリスタート機能がピアから受信されたとき）に応じて行動しなければなりません。 BGP有限状態マシンの面で、この動作の説明については、第8章を参照してください。
"Acting accordingly" in this context means that the previous TCP session MUST be closed, and the new one retained. Note that this behavior differs from the default behavior, as specified in [BGP-4], Section 6.8. Since the previous connection is considered to be terminated, no NOTIFICATION message should be sent -- the previous TCP session is simply closed.
この文脈で「それに応じて行動することは、」以前のTCPセッションを閉じなければならないことを意味し、新しいものを保持しました。 [BGP-4]、セクション6.8で指定されるように、この動作は、デフォルトの動作とは異なることに注意してください。前の接続が終了していると考えられるので、何の通知メッセージが送信されるべきではない - 以前のTCPセッションが簡単に閉じられています。
When the Receiving Speaker detects termination of the TCP session for a BGP session with a peer that has advertised the Graceful Restart Capability, it MUST retain the routes received from the peer for all the address families that were previously received in the Graceful Restart Capability and MUST mark them as stale routing information. To deal with possible consecutive restarts, a route (from the peer) previously marked as stale MUST be deleted. The router MUST NOT differentiate between stale and other routing information during forwarding.
受信スピーカーは、グレースフルリスタート機能をアドバタイズしたピアとのBGPセッションのためのTCPセッションの終了を検出すると、それは以前にグレースフルリスタート機能とMUSTで受信したすべてのアドレスファミリのためのピアから受信したルートを保有しなければなりません古いルーティング情報としてそれらをマークします。可能な連続的な再起動に対処するために、以前に失効としてマーク（ピアから）経路を削除する必要があります。ルータは、転送中に古いと他のルーティング情報を区別してはなりません。
In re-establishing the session, the "Restart State" bit in the Graceful Restart Capability of the OPEN message sent by the Receiving Speaker MUST NOT be set unless the Receiving Speaker has restarted. The presence and the setting of the "Forwarding State" bit for an address family depend upon the actual forwarding state and configuration.
受信スピーカーが再起動しない限り、セッションを再確立するには、受信スピーカーによって送信されたOPENメッセージのグレースフルリスタート機能で「再起動状態」ビットを設定してはいけません。存在とアドレスファミリの「フォワーディングステート」ビットの設定は、実際の転送状態や設定に依存します。
If the session does not get re-established within the "Restart Time" that the peer advertised previously, the Receiving Speaker MUST delete all the stale routes from the peer that it is retaining.
セッションがピアが以前に広告を出していること、「再起動時間」以内に再確立されない場合は、受信スピーカーは、それが保持されていることを、ピアからのすべての古いルートを削除しなければなりません。
A BGP speaker could have some way of determining whether its peer's forwarding state is still viable, for example through Bidirectional Forwarding Detection [BFD] or through monitoring layer two information. Specifics of such mechanisms are beyond the scope of this document. In the event that it determines that its peer's forwarding state is not viable prior to the re-establishment of the session, the speaker MAY delete all the stale routes from the peer that it is retaining.
BGPスピーカは、そのピアの転送状態は、例えば、双方向フォワーディング検出[BFD]を介して、またはモニター層二つの情報を介して、依然として生存可能であるかどうかを決定する何らかの方法を有することができます。そのようなメカニズムの詳細は、このドキュメントの範囲を超えています。それはそのピアの転送状態は、セッションの再確立する前に実行可能でないと判断した場合には、話者は、それが保持されていることを、ピアからのすべての古いルートを削除する場合があります。
Once the session is re-established, if the "Forwarding State" bit for a specific address family is not set in the newly received Graceful Restart Capability, or if a specific address family is not included in the newly received Graceful Restart Capability, or if the Graceful Restart Capability is not received in the re-established session at all, then the Receiving Speaker MUST immediately remove all the stale routes from the peer that it is retaining for that address family.
セッションが再確立されると、特定のアドレスファミリの「フォワーディングステート」ビットは、新たに受信したグレースフルリスタート機能に設定されていない場合、または特定のアドレスファミリは、新たに受信したグレースフルリスタート機能、あるいは場合には含まれていない場合グレースフルリスタート機能は、受信スピーカーはすぐにそれがそのアドレスファミリのために保持され、ピアからのすべての古いルートを削除する必要があり、すべてで再確立されたセッションで受信されません。
The Receiving Speaker MUST send the End-of-RIB marker once it completes the initial update for an address family (including the case that it has no routes to send) to the peer.
それはピアに（それが送るべきルートを持っていない場合を含む）アドレスファミリの最初のアップデートを完了すると受信スピーカーは、エンド・オブ・RIBマーカーを送らなければなりません。
The Receiving Speaker MUST replace the stale routes by the routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it MUST immediately remove any routes from the peer that are still marked as stale for that address family.
受信スピーカーは、ピアから受信したルーティング更新によって古いルートを交換しなければなりません。アドレスファミリの終了のRIBマーカーがピアから受信されると、それはすぐにまだそのアドレスファミリの陳腐化としてマークされ、ピアからのすべてのルートを削除する必要があります。
To put an upper bound on the amount of time a router retains the stale routes, an implementation MAY support a (configurable) timer that imposes this upper bound.
ルータは古いルートを保持した時間の量に上限を置くために、実装は、この上限を課して（設定可能）タイマーをサポートするかもしれません。
As mentioned under "Procedures for the Receiving Speaker" above, this specification modifies the BGP finite state machine.
上記の「受信スピーカーのための手順」で述べたように、この仕様は、BGP有限状態マシンを変更します。
The specific state machine modifications to [BGP-4], Section 8.2.2, are as follows.
[BGP-4]、セクション8.2.2にステートマシンの変更特定、以下の通りです。
In the Idle state, make the following changes.
アイドル状態では、以下の変更を行います。
Replace this text:
このテキストを置き換えます。
- initializes all BGP resources for the peer connection,
- ピア接続のためのすべてのBGPリソースを初期化し、
with
とともに
- initializes all BGP resources for the peer connection, other than those resources required in order to retain routes according to section "Procedures for the Receiving Speaker" of this (Graceful Restart) specification,
- この（グレースフルリスタート）仕様のセクション「を受信スピーカー手順」に従ってルートを保持するために必要なリソース以外の、ピア接続のためのすべてのBGPリソースを初期化し、
In the Established state, make the following changes.
設立の状態では、以下の変更を行います。
Replace this text:
このテキストを置き換えます。
In response to an indication that the TCP connection is
successfully established (Event 16 or Event 17), the second
connection SHALL be tracked until it sends an OPEN message.
with
とともに
If the Graceful Restart Capability with one or more AFIs/SAFIs
has not been received for the session, then in response to an
indication that a TCP connection is successfully established
(Event 16 or Event 17), the second connection SHALL be tracked
until it sends an OPEN message.
However, if the Graceful Restart Capability with one or more AFIs/SAFIs has been received for the session, then in response to Event 16 or Event 17 the local system:
しかしながら、一つ以上のAFISとグレースフルリスタート機能が/ SAFIsセッションのために受信された場合、イベント16またはイベント17ローカルシステムへの返信
- retains all routes associated with this connection according to section "Procedures for the Receiving Speaker" of this (Graceful Restart) specification,
- この（グレースフルリスタート）仕様のセクション「を受信スピーカー手順」に従って、この接続に関連付けられているすべてのルートを保持しています
- releases all other BGP resources,
- リリースその他のすべてのBGPリソース、
- drops the TCP connection associated with the ESTABLISHED session,
- 確立されたセッションに関連付けられているTCP接続をドロップし、
- initializes all BGP resources for the peer connection, other than those required in order to retain routes according to section "Procedures for the Receiving Speaker" of this specification,
- 本明細書の「受信スピーカーのための手順」に従ってルートを保持するために必要なもの以外の、ピア接続のためのすべてのBGPリソースを初期化し、
- sets ConnectRetryCounter to zero,
- ConnectRetryCounterは、ゼロに設定し、
- starts the ConnectRetryTimer with the initial value, and
- 初期値でConnectRetryTimerを開始し、
- changes its state to Connect.
- 接続し、その状態を変更します。
Replace this text:
このテキストを置き換えます。
If the local system receives a NOTIFICATION message (Event 24 or Event 25), or a TcpConnectionFails (Event 18) from the underlying TCP, the local system:
ローカルシステムは、通知メッセージ（イベント24またはイベント25）、または基礎TCP、ローカルシステムからTcpConnectionFails（イベント18）を受信した場合：
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定し、
- deletes all routes associated with this connection,
- この接続に関連付けられているすべてのルートを削除し、
- releases all the BGP resources,
- リリースすべてのBGPリソースを、
- drops the TCP connection,
- TCP接続をドロップし、
- increments the ConnectRetryCounter by 1,
- 1 ConnectRetryCounterをインクリメント
- changes its state to Idle.
- Idleにその状態を変更します。
with
とともに
If the local system receives a NOTIFICATION message (Event 24 or Event 25), or if the local system receives a TcpConnectionFails (Event 18) from the underlying TCP and the Graceful Restart capability with one or more AFIs/SAFIs has not been received for the session, the local system:
ローカルシステムは、通知メッセージ（イベント24またはイベント25）を受信する、またはローカルシステムは、1つ以上のAFISと下層のTCPとグレースフルリスタート機能からTcpConnectionFails（イベント18）を受信した場合/ SAFIsがために受信されていない場合セッション、ローカルシステム：
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定し、
- deletes all routes associated with this connection,
- この接続に関連付けられているすべてのルートを削除し、
- releases all the BGP resources,
- リリースすべてのBGPリソースを、
- drops the TCP connection,
- TCP接続をドロップし、
- increments the ConnectRetryCounter by 1, and
- 1 ConnectRetryCounterをインクリメントし、そして
- changes its state to Idle.
- Idleにその状態を変更します。
However, if the local system receives a TcpConnectionFails (Event 18) from the underlying TCP, and the Graceful Restart Capability with one or more AFIs/SAFIs has been received for the session, the local system:
ローカルシステムは、基礎となるTCP、および1つまたは複数のAFISとグレースフルリスタート機能からTcpConnectionFails（イベント18）を受信する場合は、/ SAFIsセッション、ローカルシステム用に受信されています。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定し、
- retains all routes associated with this connection according to section "Procedures for the Receiving Speaker" of this (Graceful Restart) specification,
- この（グレースフルリスタート）仕様のセクション「を受信スピーカー手順」に従って、この接続に関連付けられているすべてのルートを保持しています
- releases all other BGP resources,
- リリースその他のすべてのBGPリソース、
- drops the TCP connection,
- TCP接続をドロップし、
- increments the ConnectRetryCounter by 1, and
- 1 ConnectRetryCounterをインクリメントし、そして
- changes its state to Idle.
- Idleにその状態を変更します。
Although the procedures described in this document would help minimize the effect of routing flaps, it is noted that when a BGP Graceful Restart-capable router restarts, or if it restarts without preserving its forwarding state (e.g., due to a power failure), there is a potential for transient routing loops or blackholes in the network if routing information changes before the involved routers complete routing updates and convergence. Also, depending on the network topology, if not all IBGP speakers are Graceful Restart capable, there could be an increased exposure to transient routing loops or blackholes when the Graceful Restart procedures are exercised.
この文書に記載されている手順は、ルーティングフラップの影響を最小限に抑えることになるが、それはそこに、場合BGPグレースフルリスタート対応ルータの再起動、またはそれが（停電など）の転送状態を保存せずに再起動する場合に留意されたいです関与ルータの完全なルーティングアップデートと収束する前に情報の変更をルーティングする場合は、ネットワーク内の過渡的なルーティングループやブラックホールの可能性です。グレースフルリスタート手順が行使されないときは、すべてのIBGPスピーカーができる再始動優雅である場合も、ネットワークトポロジに応じて、過渡的なルーティングループまたはブラックホールに増加曝露があるかもしれません。
The Restart Time, the upper bound for retaining routes, and the upper bound for deferring route selection may need to be tuned as more deployment experience is gained.
再起動時間、ルートを保持するための上限、およびルート選択を延期の上限は、より多くの導入実績が得られるように調整する必要があるかもしれません。
Finally, it is noted that the benefits of deploying BGP Graceful Restart in an Autonomous System (AS) whose IGPs and BGP are tightly coupled (i.e., BGP and IGPs would both restart) and IGPs have no similar Graceful Restart Capability are reduced relative to the scenario where IGPs do have similar Graceful Restart Capability.
最後に、そののIGPとBGP密結合されている（すなわち、BGPとIGPの両方の再起動します）とのIGP全く同様のグレースフルリスタート機能を持たない自律システム内のBGPグレースフルリスタート（AS）を展開する利点は、と比較して減少していることが注目されますIGPは、同様のグレースフルリスタート機能を持っているシナリオ。
Since with this proposal a new connection can cause an old one to be terminated, it might seem to open the door to denial of service attacks. However, it is noted that unauthenticated BGP is already known to be vulnerable to denials of service through attacks on the TCP transport. The TCP transport is commonly protected through use of [BGP-AUTH]. Such authentication will equally protect against denials of service through spurious new connections.
この提案で新しい接続が古いが終了されることがありますので、サービス拒否攻撃への扉を開くように見えるかもしれません。しかし、認証されていないBGPは既にTCPトランスポートへの攻撃によるサービスの拒否に対して脆弱であることが知られていることに留意されたいです。 TCPトランスポートは、一般的に[BGP-AUTH]を使用して保護されています。このような認証は、均等に偽の新しい接続を介してサービスの拒否から保護します。
If an attacker is able to successfully open a TCP connection impersonating a legitimate peer, the attacker's connection will replace the legitimate one, potentially enabling the attacker to advertise bogus routes. We note, however, that the window for such a route insertion attack is small since through normal operation of the protocol the legitimate peer would open a new connection, in turn causing the attacker's connection to be terminated. Thus, this attack devolves to a form of denial of service.
攻撃者が正当なピアを偽装TCP接続を開くことができる場合、攻撃者の接続は、潜在的に偽のルートをアドバタイズするために、攻撃者を可能にする、合法的なものと置き換えられます。私たちは、プロトコルの通常の操作で、正当な相手が攻撃者の接続が終了させる順番に、新しい接続を開くであろうから、このようなルートの挿入攻撃のためのウィンドウが小さいこと、しかし、注意してください。したがって、この攻撃は、サービス拒否の形にデボルブ。
It is thus concluded that this proposal does not change the underlying security model (and issues) of BGP-4.
したがって、この提案は、BGP-4の基本的なセキュリティモデル（および問題）を変更しないと結論づけています。
We also note that implementations may allow use of graceful restart to be controlled by configuration. If graceful restart is not enabled, naturally the underlying security model of BGP-4 is unchanged.
また、実装がグレースフル・リスタートの使用は、構成によって制御されることを可能にすることに注意してください。グレースフルリスタートが有効でない場合、BGP-4の自然に基本的なセキュリティモデルが変更されません。
The authors would like to thank Bruce Cole, Lars Eggert, Bill Fenner, Eric Gray, Jeffrey Haas, Sam Hartman, Alvaro Retana, Pekka Savola Naiming Shen, Satinder Singh, Mark Townsley, David Ward, Shane Wright, and Alex Zinin for their review and comments.
作者は彼らのレビューのためにブルース・コール、ラースEggertの、ビルフェナー、エリックグレー、ジェフリーハース、サム・ハートマン、アルバロRetana、ペッカSavola Naimingシェン、Satinderシン、マークTownsley、デビッド・ウォード、シェーン・ライト、およびアレックスジニンに感謝したいと思いますそして、コメント。
This document defines a new BGP capability - Graceful Restart Capability. The Capability Code for Graceful Restart Capability is 64.
グレースフルリスタート機能 - この文書は、新しいBGP機能を定義します。グレースフルリスタート機能のための能力コードは64です。
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP-4] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-MP]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.カッツ、 "BGP-4のためのマルチプロトコルの拡張"、RFC 2858、2000年6月。
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[BGP-CAP]チャンドラ、R.及びJ.スカダー、 "BGP-4との機能広告"、RFC 3392、2002年11月。
[BGP-AUTH] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[BGP-AUTH] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[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月。
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace
[月-SAFI] http://www.iana.org/assignments/safi-namespace
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress.
[BFD]カッツ、D.およびD.区、「双方向フォワーディング検出」、進行中の作業。
Authors' Addresses
著者のアドレス
Srihari R. Sangli Cisco Systems, Inc.
スリアリR.サングリシスコシステムズ株式会社
EMail: rsrihari@cisco.com
メールアドレス：rsrihari@cisco.com
Yakov Rekhter Juniper Networks, Inc.
ヤコフ・レックタージュニパーネットワークス株式会社
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Rex Fernando Juniper Networks, Inc.
レックスフェルナンドジュニパーネットワークス株式会社
EMail: rex@juniper.net
メールアドレス：rex@juniper.net
John G. Scudder Juniper Networks, Inc.
ジョン・G.スカダージュニパーネットワークス株式会社
EMail: jgs@juniper.net
メールアドレス：jgs@juniper.net
Enke Chen Cisco Systems, Inc.
エンケ陳シスコシステムズ株式会社
EMail: enkechen@cisco.com
メールアドレス：enkechen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。