[要約] RFC 4724は、BGPの優雅な再起動メカニズムに関する規格です。その目的は、ネットワークの再起動時にBGPセッションを維持し、ネットワークの停止を最小限に抑えることです。
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
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）The IETF Trust（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の終了マーカーが指定されており、ルーティング収束情報を伝えるために使用できます。「Graceful Restart機能」と呼ばれる新しい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の終了マーカーが指定されており、ルーティング収束情報を伝えるために使用できます。「Graceful Restart機能」と呼ばれる新しい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）と空の撤回NLRIのない更新メッセージは、BGPスピーカーが使用するために使用できるRIBの終了マーカーとして指定されています。確立されています。IPv4ユニキャストアドレスファミリの場合、RIBの終了マーカーは最小長の更新メッセージです[BGP-4]。他のアドレスファミリの場合、それは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.
RIBの終了マーカーはBGP Graceful Restartの目的で指定されていますが、初期更新の完了時にそのようなマーカーの生成は、一般的に収束をルーティングするのに役立つことに注意してください。したがって、実践が推奨されます。
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の再起動中に転送状態を維持する能力に関係なく、BGPスピーカーがピアを上回っていることを確認できる場合、収束をルーティングするのに有益です。これは、次のセクションで説明した優雅な再起動機能を使用して実現できます。
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]です。また、最初のルーティングアップデートが完了すると、リブの終了マーカーを生成する意図をピアに伝えるために使用することもできます。
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:
機能値：「フラグを再起動」フィールド、「タイム」フィールド、および0〜63のタプル<afi、safi、住所ファミリのフラグ>次のように構成されています。
+--------------------------------------------------+
| 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.
最も重要なビットは、再起動状態（R）ビットとして定義されます。これは、複数のBGPスピーカーが互いの再起動を覗くと、RIBの終了マーカーを待つことで生じる可能性のあるデッドロックを回避するために使用できます。セット（値1）の場合、このビットはBGPスピーカーが再起動したことを示し、そのピアはスピーカーに情報を広告する前にスピーカーからの終了マーカーを待ってはなりません。
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、SAFI = UNICAST>に暗黙的に関連付けられている場合があります。
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]に優雅な再起動機能のインスタンスを1つ以上含めることはできません。優雅な再起動機能の複数のインスタンスが機能広告に掲載されている場合、広告の受信者は、優雅な再起動機能の最後のインスタンスを除くすべてを無視する必要があります。
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、safi = unicast>を含むことは、BGPマルチプロトコル拡張[BGP-MP]を使用してIPv4ユニキャストルーティング情報を実施することを意味するものではありません。BGP更新メッセージ。
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つあります。1つ目は、最初のルーティングアップデートが完了するとRIBの終了マーカーを生成する意図を示すことです。これは、一般的なルーティングの収束に役立つためです。2つ目は、優雅な再起動を行うことを希望するピアへのサポートを示すことです。
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セッションが確立された後、アドレスファミリの最初のルーティングアップデート（送信する更新がない場合を含む）を完了すると、BGPスピーカーが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.
BGP通知メッセージの送信または受信により、TCPセッションが終了する場合、通常のBGP手順に従う必要があることに注意してください。
A suggested default for the Restart Time is a value less than or equal to the HOLDTIME carried in the OPEN.
再起動時間の提案されたデフォルトは、オープンで運ばれる保留タイム以下の値です。
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.
ピアでセッションを再確立するには、再起動スピーカーは、オープンメッセージの優雅な再起動機能に「再起動状態」ビットを設定する必要があります。構成を介して許可されない限り、能力の住所ファミリの「転送状態」ビットは、再起動中にそのアドレスファミリーのために転送状態が実際に保存されている場合にのみ設定できます。
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の終了マーカーを受信するまで、アドレスファミリのルート選択を延期する必要があります（受信した機能に「再起動状態」ビットが設定されているものを除外し、除外し、それを除外する必要があります。グレースフルな再起動機能を宣伝しないでください）ルート選択の前に、スピーカーにはピアに宣伝するルートがなく、転送状態を更新するルートはないことに注意してください。
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スピーカーがルート選択を実行した後、スピーカーの転送状態を更新する必要があり、以前にマークされた古い情報を削除する必要があります。その後、adj-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 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-Auth]が使用されているかどうか、および次のような状況に応じて、再起動スピーカーとの再起動スピーカーの終了を検出する場合と検出できない場合があります。再起動。古いTCPセッションの終了を検出せず、BGPセッションを確立されていると考えている場合、ピアからの後続のオープン接続を古い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.
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.
セッションを再確立する際に、受信スピーカーが受信スピーカーが再起動しない限り、受信スピーカーによって送信された開いたメッセージの優雅な再起動機能の「再起動状態」ビットは設定されてはなりません。アドレスファミリの「転送状態」ビットの存在と設定は、実際の転送状態と構成に依存します。
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]または2つの情報を監視することにより、依然として実行可能かどうかを判断する方法があります。このようなメカニズムの詳細は、このドキュメントの範囲を超えています。セッションが再確立される前に、ピアの転送状態が実行可能でないと判断した場合、スピーカーは、保持しているピアからすべての古いルートを削除することができます。
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.
TCP接続が正常に確立されることを示していることに応じて（イベント16またはイベント17）、2番目の接続は開かれたメッセージを送信するまで追跡するものとします。
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.
1つ以上のAFIS/SAFISを使用した優雅な再起動機能がセッションで受信されていない場合、TCP接続が正常に確立されることを示している場合（イベント16またはイベント17）、2番目の接続を送信するまで追跡するものとします。開かれたメッセージ。
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:
ただし、1つ以上の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,
- ConnectRetryCounterを1で増やし、
- changes its state to 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）を受信する場合、またはローカルシステムが基礎となるTCPからTCPConnectionFails（イベント18）を受信し、1つ以上のAFIS/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
- ConnectRetryCounterを1で増やします
- changes its state to 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からTCPConnectionFails（イベント18）を受信し、1つ以上のAFIS/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
-
- changes its state to 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がしっかりと結合されている自律システム（AS）にBGPの優雅な再起動を展開する利点（つまり、BGPとIGPが再起動する）とIGPSには、同様の優雅な再起動機能が減少していないことに注意してください。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.
著者は、ブルース・コール、ラース・エガート、ビル・フェナー、エリック・グレイ、ジェフリー・ハース、サム・ハートマン、アルバロ・レタナ、ペッカ・サヴォーラ・ナイミング・シェン、サティンダー・シン、マーク・タウンズリー、デビッド・ワード、シェーン・ライト、アレックス・ジンのレビューに感謝したいコメント。
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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 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] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[BGP-CAP] Chandra、R。およびJ. Scudder、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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
[iana-safi] http://www.iana.org/assignments/safi-namespace
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress.
[BFD] Katz、D。およびD. Ward、「双方向転送検出」、進行中の作業。
Authors' Addresses
著者のアドレス
Srihari R. Sangli Cisco Systems, Inc.
Srihari R. Sangli Cisco Systems、Inc。
EMail: rsrihari@cisco.com
Yakov Rekhter Juniper Networks, Inc.
Yakov Rekhter Juniper Networks、Inc。
EMail: yakov@juniper.net
Rex Fernando Juniper Networks, Inc.
Rex Fernando Juniper Networks、Inc。
EMail: rex@juniper.net
John G. Scudder Juniper Networks, Inc.
John G. Scudder Juniper Networks、Inc。
EMail: jgs@juniper.net
Enke Chen Cisco Systems, Inc.
Enke Chen Cisco Systems、Inc。
EMail: enkechen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。