[要約] RFC 9494 introduces the Long-Lived Graceful Restart Capability for BGP, allowing retention of stale routes longer upon session failure than BGP Graceful Restart. The purpose is to improve network stability by marking and handling long-lived stale routes appropriately.
Internet Engineering Task Force (IETF) J. Uttaro
Request for Comments: 9494 Independent Contributor
Updates: 6368 E. Chen
Category: Standards Track Palo Alto Networks
ISSN: 2070-1721 B. Decraene
Orange
J. Scudder
Juniper Networks
November 2023
This document introduces a BGP capability called the "Long-Lived Graceful Restart Capability" (or "LLGR Capability"). The benefit of this capability is that stale routes can be retained for a longer time upon session failure than is provided for by BGP Graceful Restart (as described in RFC 4724). A well-known BGP community called "LLGR_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community called "NO_LLGR" is introduced for marking routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least preferred and that their advertisements be limited to BGP speakers that have advertised the capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is.
このドキュメントでは、「長寿命の優雅な再起動機能」（または「LLGR機能」）と呼ばれるBGP機能を紹介します。この機能の利点は、BGP Graceful Restart（RFC 4724で説明されているように）が提供するよりも、セッション障害時に長期にわたって古いルートを保持できることです。「LLGR_STALE」と呼ばれる有名なBGPコミュニティが、長時間保持された古いルートをマークするために導入されています。「no_llgr」と呼ばれる2番目の有名なBGPコミュニティは、これらの手順を適用しないルートをマークするために導入されています。また、このような長寿命の古いルートは、最も好まれていないものとして扱われ、その広告が機能を宣伝したBGPスピーカーに限定されることを指定します。この拡張機能の使用はすべての場合においてお勧めできません。ガイドラインでは、それがあるかどうかを判断するのに役立ちます。
This memo updates RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between the Provider Edge (PE) and Customer Edge (CE) routers.
このメモは、llgr_staleコミュニティをプロバイダーエッジ（PE）と顧客エッジ（CE）ルーターの間で交換するパス属性に伝播する必要があることを指定することにより、RFC 6368を更新します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9494.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9494で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
2.1. Definitions
2.2. Abbreviations
2.3. Requirements Language
3. Protocol Extensions
3.1. Long-Lived Graceful Restart Capability
3.2. LLGR_STALE Community
3.3. NO_LLGR Community
4. Theory of Operation
4.1. Use of the Graceful Restart Capability
4.2. Session Resets
4.3. Processing LLGR_STALE Routes
4.4. Route Selection
4.5. Errors
4.6. Optional Partial Deployment Procedure
4.7. Procedures When BGP Is the PE-CE Protocol in a VPN
4.7.1. Procedures When EBGP Is the PE-CE Protocol in a VPN
4.7.2. Procedures When IBGP Is the PE-CE Protocol in a VPN
5. Deployment Considerations
5.1. When BGP Is the PE-CE Protocol in a VPN
5.2. Risks of Depreferencing Routes
6. Security Considerations
7. Examples of Operation
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Routing protocols in general, and BGP in particular, have historically been designed with a focus on "correctness", where a key part of correctness is for each network element's forwarding state to converge to the current state of the network as quickly as possible. For this reason, the protocol was designed to remove state advertised by routers that went down (from a BGP perspective) as quickly as possible. Over time, this has been relaxed somewhat, notably by BGP Graceful Restart (GR) [RFC4724]; however, the paradigm has remained one of attempting to rapidly remove stale state from the network.
一般に、ルーティングプロトコル、特にBGPは、歴史的に「正確性」に焦点を当てて設計されてきました。ここでは、各ネットワーク要素の転送状態が可能な限り迅速にネットワークの現在の状態に収束するための正確性の重要な部分です。このため、プロトコルは、できるだけ早く（BGPの観点から）下がったルーターによって宣伝された状態を削除するように設計されています。時間が経つにつれて、これは幾分リラックスしています。特に、BGP Graceful Restart（GR）[RFC4724]によってリラックスされました。ただし、パラダイムは、ネットワークから古い状態を迅速に除去しようとしていることの1つであり続けています。
Over time, two phenomena have arisen that call into question the underlying assumptions of this paradigm.
時間が経つにつれて、このパラダイムの根本的な仮定に疑問を投げかける2つの現象が発生しました。
1. The widespread adoption of tunneled forwarding infrastructures (for example, MPLS). Such infrastructures eliminate the risk of some types of forwarding loops that can arise in hop-by-hop forwarding; thus, they reduce one of the motivations for strong consistency between forwarding elements.
1. トンネル転送インフラストラクチャ（たとえば、MPLS）の広範な採用。このようなインフラストラクチャは、ホップバイホップ転送で発生する可能性のあるある種の転送ループのリスクを排除します。したがって、それらは、転送要素間の強い一貫性の動機の1つを減らします。
2. The increasing use of BGP as a transport for data that is less closely associated with packet forwarding than was originally the case. Examples include the use of BGP for auto-discovery (Virtual Private LAN Service (VPLS) [RFC4761]) and filter programming (Flow Specification (FLOWSPEC) [RFC8955]). In these cases, BGP data takes on a character more akin to configuration than to conventional routing.
2. BGPの使用の増加は、当初の場合よりもパケット転送とは密接に関連していないデータの輸送としての使用の増加です。例には、自動指示（仮想プライベートLANサービス（VPLS）[RFC4761]）およびフィルタープログラミング（フロー仕様（FlowsPec）[RFC8955]）にBGPを使用することが含まれます。これらの場合、BGPデータは、従来のルーティングよりも構成に似たキャラクターを使用します。
The observations above motivate a desire to offer network operators the ability to choose to retain BGP data for a longer period than has hitherto been possible when the BGP control plane fails for some reason. Although the semantics of BGP Graceful Restart [RFC4724] are close to those desired, several gaps exist, most notably in the maximum time for which stale information can be retained: Graceful Restart imposes a 4095-second upper bound.
上記の観察結果は、ネットワークオペレーターに、BGPコントロールプレーンが何らかの理由で故障したときにこれまで可能だったよりも長い間BGPデータを保持することを選択する能力を提供することを望んでいます。BGPの優雅な再起動[RFC4724]のセマンティクスは望ましいものに近いですが、いくつかのギャップが存在します。最も顕著なのは、古い情報を保持できる最大時間です。優雅な再起動は4095秒の上限を課します。
In this document, we introduce a BGP capability called the "Long-Lived Graceful Restart Capability". The goal of this capability is that stale information can be retained for a longer time across a session reset. We also introduce two BGP well-known communities:
このドキュメントでは、「長寿命の優雅な再起動機能」と呼ばれるBGP機能を紹介します。この機能の目標は、古い情報をセッションリセット全体で長時間保持できることです。また、2つのBGPの有名なコミュニティを紹介します。
* LLGR_STALE to mark such information, and
* llgr_staleそのような情報をマークする
* NO_LLGR to indicate that these procedures should not be applied to the marked route.
* これらの手順をマークされたルートに適用しないでください。
Long-lived stale information is to be treated as least preferred, and its advertisement limited to BGP speakers that support the capability. Where possible, we reference the semantics of BGP Graceful Restart [RFC4724] rather than specifying similar semantics in this document.
長寿命の古い情報は、能力をサポートするBGPスピーカーに限定され、その広告を最小限に抑えます。可能であれば、このドキュメントで同様のセマンティクスを指定するのではなく、BGP Graceful Restart [RFC4724]のセマンティクスを参照します。
The expected deployment model for this extension is that it will only be invoked for certain address families. This is discussed in more detail in Section 5. The use of this extension may be combined with that of conventional Graceful Restart; in such a case, it is invoked after the conventional Graceful Restart interval has elapsed. When not combined, LLGR is invoked immediately. Apart from the potential to greatly extend the timer, the most obvious difference between LLGR and conventional Graceful Restart is that in LLGR, routes are "depreferenced"; that is, they are treated as least preferred. Contrarily, in conventional GR, route preference is not affected. The design choice to treat long-lived stale routes as least preferred was informed by the expectation that they might be retained for (potentially) an almost unbounded period of time; whereas, in the conventional Graceful Restart case, stale routes are retained for only a brief interval. In the case of Graceful Restart, the trade-off between advertising new route status (at the cost of routing churn) and not advertising it (at the cost of suboptimal or incorrect route selection) is resolved in favor of not advertising. In the case of LLGR, it is resolved in favor of advertising new state, using stale information only as a last resort.
この拡張機能の予想される展開モデルは、特定のアドレスファミリに対してのみ呼び出されることです。これについては、セクション5で詳しく説明します。この拡張機能の使用は、従来の優雅な再起動の使用と組み合わせることができます。そのような場合、従来の優雅な再起動間隔が経過した後に呼び出されます。組み合わされていない場合、LLGRはすぐに呼び出されます。タイマーを大きく拡張する可能性とは別に、LLGRと従来の優雅な再起動の最も明らかな違いは、LLGRではルートが「除外される」ことです。つまり、それらは最小の好みとして扱われます。反対に、従来のGRでは、ルートの選好は影響を受けません。長寿命の古いルートを最も好まないように扱うための設計の選択は、それらが（潜在的に）ほとんど無制限の期間保持される可能性があるという期待によって知らされました。一方、従来の優雅な再起動ケースでは、古いルートは短い間隔でのみ保持されます。優雅な再起動の場合、新しいルートステータスを広告する（ルーティングのコストで）広告を宣伝しないことと（最適ではない、または誤ったルート選択の犠牲を払って）広告なしを支持して解決されます。LLGRの場合、古い情報を最後の手段としてのみ使用して、新しい状態を宣伝することを支持して解決されます。
Section 7 provides some simple examples illustrating the operation of this extension.
セクション7では、この拡張機能の動作を示す簡単な例をいくつか示します。
Depreference:
prefereference：
A route is said to be depreferenced if it has its route selection preference reduced in reaction to some event.
ルートは、いくつかのイベントに反応してルートの選択の選好が減少した場合、除外されると言われています。
Helper:
ヘルパー：
Sometimes referred to as "helper router". During Graceful Restart or Long-Lived Graceful Restart, the router that detects a session failure and applies the listed procedures. [RFC4724] refers to this as the "receiving speaker".
「ヘルパールーター」と呼ばれることもあります。優雅な再起動または長寿命の優雅な再起動中、セッションの障害を検出し、リストされた手順を適用するルーター。[RFC4724]は、これを「受信スピーカー」と呼んでいます。
Route:
ルート：
In this document, "route" means any information encoded as BGP Network Layer Reachability Information (NLRI) and a set of path attributes. As discussed above, the connection between such routes and the installation of forwarding state may be quite remote.
このドキュメントでは、「ルート」とは、BGPネットワークレイヤーリーチビリティ情報（NLRI）およびパス属性のセットとしてエンコードされた情報を意味します。上記で説明したように、そのようなルートと転送状態の設置との関係は非常に遠い場合があります。
Further note that, for brevity, in this document when we reference conventional Graceful Restart, we cite its base specification, [RFC4724]. That specification has been updated by [RFC8538]. The citation to [RFC4724] is not intended to be limiting.
さらに、簡潔にするために、このドキュメントでは、従来の優雅な再起動を参照するときに、その基本仕様[RFC4724]を引用することに注意してください。その仕様は[RFC8538]によって更新されました。[RFC4724]への引用は、制限することを意図していません。
CE:
CE：
Customer Edge (See [RFC4364] for more information on Customer Edge routers.)
カスタマーエッジ（[RFC4364]を参照してください。顧客エッジルーターの詳細については。
EoR:
EOR：
End-of-RIB (See Section 2 of [RFC4724] for more information on End-of-RIB markers.)
RIBの終わり（[RFC4724]のセクション2を参照してください。RIB終了マーカーの詳細については。
GR:
GR：
Graceful Restart (See [RFC4724] for more information on GR.) This term is also sometimes referred to herein as "conventional Graceful Restart" or "conventional GR" to distinguish it from the "Long-Lived Graceful Restart" or "LLGR" defined by this document.
GRの詳細については、Gr.fulful Restart（[RFC4724]を参照）を参照してください。この用語は、「長寿命の優雅な再起動」または「LLGR」と定義された「長寿命の優雅な再起動」または「LLGR」と区別するための「従来の優雅な再起動」または「従来のGR」とも呼ばれることもあります。このドキュメントによって。
LLGR:
LLGR：
Long-Lived Graceful Restart
長寿命の優雅な再起動
LLST:
llst：
Long-Lived Stale Time
長寿命の古い時間
PE:
PE：
Provider Edge (See [RFC4364] for more information on Provider Edge routers.)
プロバイダーエッジ（プロバイダーエッジルーターの詳細については、[RFC4364]を参照してください。）
VRF:
VRF：
VPN Routing and Forwarding (See [RFC4364] for more information on VRF tables.)
VPNルーティングと転送（VRFテーブルの詳細については、[RFC4364]を参照してください。）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A BGP capability and two BGP communities are introduced in the subsections that follow.
BGP機能と2つのBGPコミュニティが、以下のサブセクションに導入されています。
The "Long-Lived Graceful Restart Capability", or "LLGR Capability", (value: 71) is a BGP capability [RFC5492] that can be used by a BGP speaker to indicate its ability to preserve its state according to the procedures of this document. If the LLGR capability is advertised, the Graceful Restart capability [RFC4724] MUST also be advertised; see Section 4.1.
「長寿命の優雅な再起動機能」、または「LLGR機能」（値：71）は、BGPスピーカーが使用して、この手順に従って状態を保存する能力を示すために使用できるBGP機能[RFC5492]です。書類。LLGR機能が宣伝されている場合、優雅な再起動機能[RFC4724]も宣伝する必要があります。セクション4.1を参照してください。
The capability value consists of zero or more tuples <AFI, SAFI, Flags, LLST> as follows:
機能値は、次のように、ゼロ以上のタプル<afi、safi、flags、llst>で構成されています。
+--------------------------------------------------+
| Address Family Identifier (16 bits) |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) |
+--------------------------------------------------+
| Flags for Address Family (8 bits) |
+--------------------------------------------------+
| Long-Lived Stale Time (24 bits) |
+--------------------------------------------------+
| ... |
+--------------------------------------------------+
| Address Family Identifier (16 bits) |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) |
+--------------------------------------------------+
| Flags for Address Family (8 bits) |
+--------------------------------------------------+
| Long-Lived Stale Time (24 bits) |
+--------------------------------------------------+
The meaning of the fields are as follows:
フィールドの意味は次のとおりです。
Address Family Identifier (AFI), Subsequent Address Family Identifier (SAFI):
住所ファミリ識別子（AFI）、後続のアドレスファミリ識別子（SAFI）：
The AFI and SAFI, taken in combination, indicate that the BGP speaker has the ability to preserve its forwarding state for the address family during a subsequent BGP restart. Routes may be either: * explicitly associated with a particular AFI and SAFI if using the encoding described in [RFC4760], or * implicitly associated with <AFI=IPv4, SAFI=Unicast> if using the encoding described in [RFC4271].
組み合わせて撮影されたAFIとSAFIは、BGPスピーカーがその後のBGP再起動中に住所ファミリーの転送状態を保存する能力を持っていることを示しています。ルートは次のとおりです。 * [RFC4760]で説明されているエンコードを使用する場合、特定のAFIおよびSAFIに明示的に関連付けられています。
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 used to indicate whether the 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 state has been preserved. This bit is called the "F bit" since it was historically used to indicate the preservation of forwarding state. Use of the F bit is detailed in Section 4.2. The remaining bits are reserved and MUST be set to zero by the sender and ignored by the receiver.
最も重要なビットは、与えられたAFIおよびSAFIで宣伝されたルートの状態が、以前のBGP再起動中に実際に保存されているかどうかを示すために使用されます。設定すると（値1）、ビットは状態が保存されていることを示します。このビットは、転送状態の保存を示すために歴史的に使用されていたため、「Fビット」と呼ばれます。Fビットの使用については、セクション4.2で詳しく説明しています。残りのビットは予約されており、送信者によってゼロに設定され、受信機によって無視される必要があります。
Long-Lived Stale Time:
長寿命の古い時間：
This time (in seconds) specifies how long stale information (for this AFI/SAFI) may be retained by the receiver (in addition to the period specified by the "Restart Time" in the Graceful Restart Capability). Because the potential use cases for this extension vary widely, there is no suggested default value for the LLST.
今回（秒単位）、レシーバーによって（このAFI/SAFIの場合）古くなった情報（このAFI/SAFIの場合）が（優雅な再起動機能の「再起動時間」で指定された期間に加えて）によって保持される可能性があることを指定します。この拡張機能の潜在的なユースケースは大きく異なるため、LLSTには提案されたデフォルト値はありません。
The well-known BGP community LLGR_STALE (value: 0xFFFF0006) can be used to mark stale routes retained for a longer period of time (see [RFC1997] for more information on BGP communities). Such long-lived stale routes are to be handled according to the procedures specified in Section 4.
よく知られているBGPコミュニティLLGR_STALE（値：0xFFFF0006）を使用して、BGPコミュニティの詳細については、長期間保持された古いルートをマークすることができます（[RFC1997]を参照）。このような長寿命の古いルートは、セクション4で指定された手順に従って処理されます。
An implementation MAY allow users to configure policies that accept, reject, or modify routes based on the presence or absence of this community.
実装により、ユーザーは、このコミュニティの存在または不在に基づいてルートを受け入れ、拒否、または変更するポリシーを構成できる場合があります。
The well-known BGP community NO_LLGR (value: 0xFFFF0007) can be used to mark routes that a BGP speaker does not want to be treated according to these procedures, as detailed in Section 4.
有名なBGPコミュニティNO_LLGR（値：0xFFFF0007）を使用して、セクション4で詳述しているように、BGPスピーカーがこれらの手順に従って扱われたくないルートをマークすることができます。
An implementation MAY allow users to configure policies that accept, reject, or modify routes based on the presence or absence of this community.
実装により、ユーザーは、このコミュニティの存在または不在に基づいてルートを受け入れ、拒否、または変更するポリシーを構成できる場合があります。
If a BGP speaker is configured to support the procedures of this document, it MUST use BGP Capabilities Advertisement [RFC5492] to advertise the Long-Lived Graceful Restart Capability. The setting of the parameters for an AFI/SAFI depends on the properties of the BGP speaker, network scale, and local configuration.
BGPスピーカーがこのドキュメントの手順をサポートするように構成されている場合、BGP機能広告[RFC5492]を使用して、長寿命の優雅な再起動機能を宣伝する必要があります。AFI/SAFIのパラメーターの設定は、BGPスピーカー、ネットワークスケール、およびローカル構成のプロパティに依存します。
In the presence of the Long-Lived Graceful Restart Capability, the procedures specified in [RFC4724] continue to apply unless explicitly revised by this document.
長寿命の優雅な再起動機能の存在下で、[RFC4724]で指定された手順は、このドキュメントで明示的に改訂されない限り、引き続き適用されます。
If the LLGR Capability is advertised, the Graceful Restart capability MUST also be advertised. If it is not so advertised, the LLGR Capability MUST be disregarded. The purpose for mandating this is to enable the reuse of certain base mechanisms that are common to both "flavors" notably: origination, collection, and processing of EoR as well as the finite-state-machine modifications and connection-reset logic introduced by GR.
LLGR機能が宣伝されている場合、優雅な再起動機能も宣伝する必要があります。それがそれほど宣伝されていない場合、LLGR機能を無視する必要があります。これを義務付ける目的は、特に「フレーバー」の両方に共通する特定のベースメカニズムの再利用を可能にすることです。EORの発信、収集、処理、およびGRによって導入された有限状態マシンの変更と接続リセットロジックを導入することです。。
We observe that, if support for conventional Graceful Restart is not desired for the session, the conventional GR phase can be skipped by omitting all AFIs/SAFIs from the GR Capability, advertising a Restart Time of zero, or both. Section 4.2 discusses the interaction of conventional and LLGR.
セッションに従来の優雅な再起動のサポートが望まれない場合、GR機能からすべてのAFI/SAFISを省略し、再起動時間をゼロまたはその両方に宣伝することにより、従来のGRフェーズをスキップできることがわかります。セクション4.2では、従来型とLLGRの相互作用について説明します。
BGP Graceful Restart [RFC4724] defines conditions under which a BGP session can reset and have its associated routes retained. If such a reset occurs for a session in which the LLGR Capability has also been exchanged, the following procedures apply:
BGP Graceful Restart [RFC4724]は、BGPセッションがリセットされ、関連するルートを保持できる条件を定義します。LLGR機能も交換されているセッションでこのようなリセットが発生した場合、次の手順が適用されます。
* If the Graceful Restart Capability that was received does not list all AFIs/SAFIs supported by the session, then the GR Restart Time shall be deemed zero for those AFIs/SAFIs that are not listed.
* 受信された優雅な再起動機能がセッションでサポートされているすべてのAFI/SAFISをリストしていない場合、GRの再起動時間は、リストされていないAFI/SAFIの場合はゼロと見なされます。
* Similarly, if the received LLGR Capability does not list all AFIs/ SAFIs supported by the session, then the Long-Lived Stale Time shall be deemed zero for those AFIs/SAFIs that are not listed.
* 同様に、受信したLLGR機能がセッションでサポートされているすべてのAFI/ SAFISをリストしていない場合、リストされていないAFI/ SAFISの長期的な古い時間はゼロと見なされます。
The following text in Section 4.2 of [RFC4724] no longer applies:
[RFC4724]のセクション4.2の次のテキストは、もはや適用されません。
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.
セッションが以前に宣伝されていたピアが宣伝した「再起動時間」内に再確立されない場合、受信スピーカーは、保持されているピアからすべての古いルートを削除する必要があります。
and the following procedures are specified instead:
代わりに、次の手順が指定されています。
After the session goes down, and before the session is re-established, the stale routes for an AFI/SAFI MUST be retained. The interval for which they are retained is limited by the sum of the Restart Time in the received Graceful Restart Capability and the Long-Lived Stale Time in the received Long-Lived Graceful Restart Capability. The timers received in the Long-Lived Graceful Restart Capability SHOULD be modifiable by local configuration, which may impose an upper bound, a lower bound, or both on their respective values.
セッションがダウンし、セッションが再確立される前に、AFI/SAFIの古いルートを保持する必要があります。それらが保持される間隔は、受信した優雅な再起動能力の再起動時間の合計と、受け取った長寿命の優雅な再起動機能の長寿命の古い時間の合計によって制限されます。長寿命の優雅な再起動機能で受け取ったタイマーは、ローカル構成によって変更可能である必要があります。これにより、それぞれの値に上限、下限、またはその両方が課される場合があります。
If the value of the Restart Time or the Long-Lived Stale Time is zero, the duration of the corresponding period would be zero seconds. For example, if the Restart Time is zero and the Long-Lived Stale Time is nonzero, only the procedures particular to LLGR would apply. Conversely, if the Long-Lived Stale Time is zero and the Restart Time is nonzero, only the procedures of GR would apply. If both are zero, none of these procedures would apply, only those of the base BGP specification [RFC4271] (although EoR would still be used as detailed in [RFC4724]). And finally, if both are nonzero, then the procedures would be applied serially: first those of GR and then those of LLGR. During the first interval, we observe that, while the procedures of GR are in effect, route preference would not be affected. During the second interval, while LLGR procedures are in effect, routes would be treated as least preferred as specified elsewhere in this document.
再起動時間または長寿命の古い時間の値がゼロの場合、対応する期間の期間はゼロ秒になります。たとえば、再起動時間がゼロで、長寿命の古い時間がゼロである場合、LLGRに特有の手順のみが適用されます。逆に、長寿命の古い時間がゼロで、再起動時間がゼロである場合、GRの手順のみが適用されます。両方がゼロの場合、これらの手順はどれも適用されず、ベースBGP仕様[RFC4271]のみの手順のみが適用されません（ただし、EORは[RFC4724]で詳細に使用されますが）。そして最後に、両方がゼロではない場合、手順は連続的に適用されます。最初はGRの手順、次にLLGRの手順です。最初の間隔では、GRの手順が有効である一方で、ルートの好みが影響を受けないことを観察します。2番目の間隔では、LLGR手順が有効ですが、ルートは、このドキュメントの他の場所で指定されているように最も好ましくないように扱われます。
Once the Restart Time period ends (including the case in which the Restart Time is zero), the LLGR period is said to have begun and the following procedures MUST be performed:
再起動期間が終了したら（再起動時間がゼロである場合を含む）、LLGR期間が始まったと言われ、次の手順を実行する必要があります。
* For each AFI/SAFI for which it has received a nonzero Long-Lived Stale Time, the helper router MUST start a timer for that Long-Lived Stale Time. If the timer for the Long-Lived Stale Time for a given AFI/SAFI expires before the session is re-established, the helper MUST delete all stale routes of that AFI/SAFI from the neighbor that it is retaining.
* ゼロ以外の長寿命の古い時間を受け取った各AFI/SAFIについて、ヘルパールーターはその長寿命の古い時間のタイマーを開始する必要があります。セッションが再確立される前に、特定のAFI/SAFIの長寿命の古い時間のタイマーが期限切れになる場合、ヘルパーは、保持している隣人からそのAFI/SAFIのすべての古いルートを削除する必要があります。
* The helper router MUST attach the LLGR_STALE community to the stale routes being retained. Note that this requirement implies that the routes would need to be readvertised in order to disseminate the modified community.
* ヘルパールーターは、llgr_staleコミュニティを保持する古いルートに接続する必要があります。この要件は、変更されたコミュニティを広めるためにルートを読み取りする必要があることを意味することに注意してください。
* If any of the routes from the peer have been marked with the NO_LLGR community, either as sent by the peer or as the result of a configured policy, they MUST NOT be retained and MUST be removed as per the normal operation of [RFC4271].
* ピアからのルートのいずれかがNO_LLGRコミュニティでマークされている場合、ピアによって送信された、または構成されたポリシーの結果として、[RFC4271]の通常の操作に従って保持する必要はありません。
* The helper router MUST perform the procedures listed in Section 4.3.
* ヘルパールーターは、セクション4.3にリストされている手順を実行する必要があります。
Once the session is re-established, the procedures specified in [RFC4724] apply for the stale routes irrespective of whether the stale routes are retained during the Restart Time period or the Long-Lived Stale Time period. However, in the case of consecutive restarts, the previously marked stale routes MUST NOT be deleted before the timer for the Long-Lived Stale Time expires.
セッションが再確立されると、[RFC4724]で指定された手順は、再起動期間中に古いルートが保持されるか、長期に寿命の古い期間に保持されるかに関係なく、古いルートに適用されます。ただし、連続した再起動の場合、以前にマークされた古いルートを削除してはなりません。
Similar to [RFC4724], once the LLGR Period begins, the Helper MUST immediately remove all the stale routes from the peer that it is retaining for that address family if any of the following occur:
[RFC4724]と同様に、LLGR期間が始まると、ヘルパーは、以下のいずれかが発生した場合、その住所ファミリーのために保持されているピアからすべての古いルートをすぐに削除する必要があります。
* the F bit for a specific address family is not set in the newly received LLGR Capability, or
* 特定のアドレスファミリのFビットは、新しく受け取ったLLGR機能には設定されていません。
* a specific address family is not included in the newly received LLGR Capability, or
* 特定のアドレスファミリは、新しく受け取ったLLGR機能に含まれていません、または
* the LLGR and accompanying GR Capability are not received in the re-established session at all.
* LLGRと付随するGR機能は、再確立されたセッションではまったく受信されません。
If a Long-Lived Stale Time timer is running for routes with a given AFI/SAFI received from a peer, it MUST NOT be updated (other than by manual operator intervention) until the peer has established and synchronized a new session. The session is termed "synchronized" for a given AFI/SAFI once the EoR for that AFI/SAFI has been received from the peer or once the Selection_Deferral_Timer discussed in [RFC4724] expires.
長年の古いタイムタイマーが、ピアから受け取った特定のAFI/SAFIを備えたルートのために実行されている場合、ピアが新しいセッションを確立して同期するまで、（手動オペレーターの介入以外）更新してはなりません。セッションは、特定のAFI/SAFIの「同期」と呼ばれ、そのAFI/SAFIのEORがピアから受信された場合、または[RFC4724]で議論されたSELECTION_DEFERAR_TIMERが期限切れになったら。
The value of a Long-Lived Stale Time in the capability received from a neighbor MAY be reduced by local configuration.
隣人から受け取った機能における長寿命の古い時間の価値は、ローカル構成によって減少する場合があります。
While the session is down, the expiration of a Long-Lived Stale Time timer is treated analogously to the expiration of the Restart Time timer in [RFC4724], other than applying only to the AFI/SAFI it accompanies. However, the timer continues to run once the session has re-established. The timer is neither stopped nor updated until the EoR marker is received for the relevant AFI/SAFI from the peer. If the timer expires during synchronization with the peer, any stale routes that the peer has not refreshed are removed. If the session subsequently resets prior to becoming synchronized, any remaining routes (for the AFI/SAFI whose LLST timer expired) MUST be removed immediately.
セッションがダウンしている間、長寿命の古いタイムタイマーの有効期限は、[RFC4724]の再起動タイムタイマーの有効期限と同様に扱われます。ただし、セッションが再確立されると、タイマーは実行され続けます。ピアからの関連するAFI/SAFIのEORマーカーが受信されるまで、タイマーは停止も更新もありません。ピアとの同期中にタイマーが期限切れになると、ピアが更新していない古いルートが削除されます。同期する前にセッションがその後リセットされた場合、残りのルート（LLSTタイマーの有効期限が切れたAFI/SAFIの場合）はすぐに削除する必要があります。
A BGP speaker that has advertised the Long-Lived Graceful Restart Capability to a neighbor MUST perform the following upon receiving a route from that neighbor with the LLGR_STALE community or upon attaching the LLGR_STALE community itself per Section 4.2:
隣人に長寿命の優雅な再起動機能を宣伝したBGPスピーカーは、LLGR_STALEコミュニティのその隣人からルートを受け取ったとき、またはセクション4.2に従ってLLGR_STALEコミュニティ自体を添付したときに、以下を実行する必要があります。
* Treat the route as the least preferred in route selection (see below). See Section 5.2 for a discussion of potential risks inherent in doing this.
* ルートをルート選択で最も好まないものとして扱います（以下を参照）。これを行うことに固有の潜在的なリスクの議論については、セクション5.2を参照してください。
* The route SHOULD NOT be advertised to any neighbor from which the Long-Lived Graceful Restart Capability has not been received. The exception is described in Section 4.6. Note that this requirement implies that such routes should be withdrawn from any such neighbor.
* ルートは、長寿命の優雅な再起動機能が受信されていない隣人に宣伝されるべきではありません。例外については、セクション4.6で説明します。この要件は、そのようなルートをそのような隣人から撤回すべきであることを意味することに注意してください。
* The LLGR_STALE community MUST NOT be removed when the route is further advertised.
* ルートがさらに宣伝されたときに、LLGR_STALEコミュニティを削除してはなりません。
A least preferred route MUST be treated as less preferred than any other route that is not also least preferred. When performing route selection between two routes when both are least preferred, normal tiebreaking applies. Note that this would only be expected to happen if the only routes available for selection were least preferred; in all other cases, such routes would have been eliminated from consideration.
少なくとも好ましいルートは、少なくとも好まれる他のどのルートよりも優先性が低いとして扱われなければなりません。両方が最も優先される場合、2つのルート間でルート選択を実行する場合、通常のタイブレークが適用されます。これは、選択に利用できる唯一のルートが最も好ましくない場合にのみ発生すると予想されることに注意してください。他のすべての場合、そのようなルートは検討から排除されていたでしょう。
If the LLGR Capability is received without an accompanying GR Capability, the LLGR Capability MUST be ignored, that is, the implementation MUST behave as though no LLGR Capability has been received.
添付のGR機能なしでLLGR機能が受信された場合、LLGR機能は無視する必要があります。つまり、実装はLLGR機能が受信されていないかのように動作する必要があります。
Ideally, all routers in an Autonomous System (AS) would support this specification before it were enabled. However, to facilitate incremental deployment, stale routes MAY be advertised to neighbors that have not advertised the Long-Lived Graceful Restart Capability under the following conditions:
理想的には、自律システム内のすべてのルーター（AS）が有効になる前にこの仕様をサポートします。ただし、増分展開を容易にするために、以下の条件下で長寿命の優雅な再起動機能を宣伝していない隣人に古いルートを宣伝することができます。
* The neighbors MUST be internal (Internal BGP (IBGP) or Confederation) neighbors.
* 隣人は内部（内部BGP（IBGP）または連合）隣人でなければなりません。
* The NO_EXPORT community [RFC1997] MUST be attached to the stale routes.
* NO_EXPORTコミュニティ[RFC1997]は、古いルートに接続する必要があります。
* The stale routes MUST have their LOCAL_PREF set to zero. See Section 5.2 for a discussion of potential risks inherent in doing this.
* 古いルートには、local_prefがゼロに設定されている必要があります。これを行うことに固有の潜在的なリスクの議論については、セクション5.2を参照してください。
If this strategy for partial deployment is used, the network operator should set the LOCAL_PREF to zero for all long-lived stale routes throughout the Autonomous System. This trades off a small reduction in flexibility (ordering may not be preserved between competing long-lived stale routes) for consistency between routers that do, and do not, support this specification. Since the consistency of route selection can be important for preventing forwarding loops, the latter consideration dominates.
部分的な展開のためのこの戦略が使用される場合、ネットワークオペレーターは、自律システム全体のすべての長寿命の古いルートのLocal_Prefをゼロに設定する必要があります。これにより、この仕様をサポートしていないルーター間の一貫性のために、柔軟性のわずかな柔軟性の削減（競合する長寿命の古いルート間で保存されない場合があります）をトレードオフします。ルートの選択の一貫性は、転送ループの防止に重要である可能性があるため、後者の考慮事項が支配的です。
In VPN deployments (for example, [RFC4364]), External BGP (EBGP) is often used as a PE-CE protocol. It may be a practical necessity in such deployments to accommodate interoperation with peer routers that cannot easily be upgraded to support specifications such as this one. This leads to a problem: the procedures defined elsewhere in this document generally prevent LLGR stale routes from being sent across EBGP sessions that don't support LLGR, but this could prevent the VPN routes from being used for their intended purpose.
VPN展開（たとえば[RFC4364]）では、外部BGP（EBGP）がPE-CEプロトコルとしてよく使用されます。このような仕様をサポートするために簡単にアップグレードできないピアルーターとの相互操作に対応するために、このような展開における実際的な必要性かもしれません。これは問題につながります。このドキュメントの他の場所で定義されている手順は、一般に、LLGRをサポートしないEBGPセッション全体でLLGRの古いルートが送信されるのを防ぎますが、これによりVPNルートが意図した目的で使用されるのを防ぐことができます。
We observe that the principal motivation for restricting the propagation of "stale" routing information is the desire to prevent it from spreading without limit once it exits the "safe" perimeter. We further observe that VPN deployments are typically topologically constrained, making this concern moot. For this reason, an implementation MAY advertise stale routes over a PE-CE session, when explicitly configured to do so. That is, the second rule listed in Section 4.3 MAY be disregarded in such cases. All other rules continue to apply. Finally, if this exception is used, the implementation SHOULD, by default, attach the NO_EXPORT community to the routes in question, as an additional protection against stale routes spreading without limit. Attachment of the NO_EXPORT community MAY be disabled by explicit configuration in order to accommodate exceptional cases.
「古くなった」ルーティング情報の伝播を制限する主な動機は、「安全な」境界線を出た後、制限なく拡散するのを防ぐことを望んでいることを観察します。さらに、VPNの展開は通常、トポロジカルに制約されているため、この懸念は論争していることを観察します。このため、実装は、そのように明示的に構成されている場合、PE-CEセッションで古いルートを宣伝する場合があります。つまり、セクション4.3にリストされている2番目のルールは、そのような場合には無視される場合があります。他のすべてのルールは引き続き適用されます。最後に、この例外を使用する場合、実装は、デフォルトでは、制限なしに広がる古いルートに対する追加の保護として、問題のルートにno_exportコミュニティを添付する必要があります。NO_Exportコミュニティの添付ファイルは、例外的なケースに対応するために明示的な構成によって無効になる場合があります。
See further discussion of using an explicitly configured policy to mitigate this issue in Section 5.1.
セクション5.1でこの問題を軽減するために、明示的に構成されたポリシーを使用していることの詳細については、詳細を参照してください。
If IBGP is used as the PE-CE protocol, following the procedures of [RFC6368], then when a PE router imports a VPN route that contains the ATTR_SET attribute into a destination VRF and subsequently advertises that route to a CE router:
IBGPが[RFC6368]の手順に従ってPE-CEプロトコルとして使用される場合、PEルーターがattr_set属性を宛先VRFに含むVPNルートをインポートし、その後そのルートをCEルーターに宣伝する場合：
* If the CE router supports the procedures of this document (in other words, if the CE router has advertised the LLGR Capability):
* CEルーターがこのドキュメントの手順をサポートしている場合（言い換えれば、CEルーターがLLGR機能を宣伝している場合）：
* In addition to including the path attributes derived from the ATTR_SET attribute in the advertised route as per [RFC6368], the PE router MUST also include the LLGR_STALE community if it is present in the path attributes of the imported route, even if it is not present in the ATTR_SET attribute.
* [RFC6368]に従って、広告ルートの属性属性から派生したパス属性を含めることに加えて、PEルーターは、輸入ルートのパス属性に存在する場合、LLGR_STALEコミュニティも含める必要があります。attr_set属性。
* If the CE router does not support the procedures of this document:
* CEルーターがこのドキュメントの手順をサポートしていない場合：
* Then the optional procedures of Section 4.6 MAY be followed, attaching the NO_EXPORT community and setting the value of LOCAL_PREF to zero, overriding the value found in the ATTR_SET.
* 次に、セクション4.6のオプションの手順に従って、NO_EXPORTコミュニティを添付し、local_prefの値をゼロに設定し、attr_setで見つかった値をオーバーライドできます。
Similarly, when a PE router receives a route from a CE into its VRF and subsequently exports that route to a VPN address family:
同様に、PEルーターがCEからVRFへのルートを受信し、その後VPNアドレスファミリにそのルートをエクスポートする場合：
* If the PE router supports the procedures of this document (in other words, if the PE router has advertised the LLGR Capability):
* PEルーターがこのドキュメントの手順をサポートしている場合（言い換えれば、PEルーターがLLGR機能を宣伝している場合）：
* In addition to including in the VPN route the ATTR_SET derived from the path attributes as per [RFC6368], the PE router MUST also include the LLGR_STALE community in the VPN route if it is present in the path attributes of the route as received from the CE.
* VPNルートに含めることに加えて、[RFC6368]に従ってパス属性から派生したattr_setを含めることに加えて、PEルーターは、CEから受信したルートのパス属性に存在する場合は、VPNルートにLLGR_STALEコミュニティを含める必要があります。。
* If the PE router does not support the procedures of this document:
* PEルーターがこのドキュメントの手順をサポートしていない場合：
* There exists no ideal solution. The CE could advertise a route with LLGR_STALE, with the understanding that the LLGR_STALE marking will only be honored by the provider network if appropriate policy configuration exists on the PE (see Section 5.1). It is at least guaranteed that LLGR_STALE will be propagated when the route is propagated beyond the provider network, or the CE could refrain from advertising the LLGR_STALE route to the incapable PE.
* 理想的な解決策はありません。CEは、LLGR_STALEのマーキングがPEに適切なポリシー構成が存在する場合にのみプロバイダーネットワークによって尊重されることを理解して、LLGR_STALEでルートを宣伝できます（セクション5.1を参照）。ルートがプロバイダーネットワークを超えて伝播されると、LLGR_STALEが伝播されるか、CEがLLGR_STALEルートの宣伝を控えることができないことが少なくとも保証されています。
The deployment considerations discussed in [RFC4724] apply to this document. In addition, network operators are cautioned to carefully consider the potential disadvantages of deploying these procedures for a given AFI/SAFI. Most notably, if used for an AFI/SAFI that conveys conventional reachability information, the use of a long-lived stale route could result in a loss of connectivity for the covered prefix. This specification takes pains to mitigate this risk where possible by making such routes least preferred and by restricting the scope of such routes to routers that support these procedures (or, optionally, a single Autonomous System, see Section 4.6). However, if a stale route is chosen as best for a given prefix, then according to the normal rules of IP forwarding, that route will be used for matching destinations, even if a non-stale less specific matching route is also available. Networks in which the deployment of these procedures would be especially concerning include those that do not use "tunneled" forwarding (in other words, those using conventional hop-by-hop forwarding).
[RFC4724]で説明されている展開の考慮事項は、このドキュメントに適用されます。さらに、ネットワークオペレーターは、特定のAFI/SAFIのこれらの手順を展開する潜在的な欠点を慎重に検討するよう警告されています。最も顕著なのは、従来の到達可能性情報を伝えるAFI/SAFIに使用される場合、長寿命の古いルートを使用すると、カバーされたプレフィックスの接続が失われる可能性があります。この仕様は、可能な限りこのリスクを緩和するのに苦労し、そのようなルートを最小限に抑え、そのようなルートの範囲をこれらの手順をサポートするルーターに制限することにより（または、オプションでは単一の自律システムを参照）。ただし、特定のプレフィックスに最適なルートを選択した場合、IP転送の通常のルールに従って、そのルートも目的地のマッチングに使用されます。これらの手順の展開が特に懸念されるネットワークには、「トンネリング」転送を使用しないネットワーク（つまり、従来のホップバイホップ転送を使用するもの）が含まれます。
Implementations MUST NOT enable these procedures by default. They MUST require affirmative configuration per AFI/SAFI in order to enable them.
実装は、デフォルトでこれらの手順を有効にしてはなりません。それらを有効にするために、AFI/SAFIごとの肯定的な構成を必要とする必要があります。
The procedures of this document do not alter the route resolvability requirement of Section 9.1.2.1 of [RFC4271]. Because of this, it will commonly be the case that "stale" IBGP routes will only continue to be used if the router depicted in the next hop remains resolvable, even if its BGP component is down. Details of IGP fault-tolerance strategies are beyond the scope of this document. In addition to the foregoing, it may be advisable to check the viability of the next hop through other means, for example, Bidirectional Forwarding Detection (BFD) [RFC5880]. This may be especially useful in cases where the next hop is known directly at the network layer, notably EBGP.
このドキュメントの手順は、[RFC4271]のセクション9.1.2.1のルート解決可能性要件を変更しません。このため、次のホップに描かれたルーターがBGPコンポーネントがダウンしていても、解決可能なままである場合にのみ、「古い」IBGPルートを使用し続けることがあります。IGPフォールトトレランス戦略の詳細は、このドキュメントの範囲を超えています。上記に加えて、たとえば双方向転送検出（BFD）[RFC5880]など、他の手段を介して次のホップの実行可能性を確認することをお勧めします。これは、次のホップがネットワークレイヤー、特にEBGPで直接知られている場合に特に役立ちます。
As discussed in this document, after a BGP session goes down and before the session is re-established, stale routes may be retained for up to two consecutive periods, controlled by the Restart Time and the Long-Lived Stale Time, respectively:
このドキュメントで説明したように、BGPセッションがダウンし、セッションが再確立される前に、古いルートは最大2つの連続した期間保持される場合があります。
* During the first period, routing churn would be prevented, but with potential persistent packet loss.
* 最初の期間中、ルーティングチャーンは防止されますが、潜在的な持続的なパケット損失があります。
* During the second period, potential persistent packet loss may be reduced, but routing churn would be visible throughout the network.
* 第2期間には、潜在的な持続的なパケット損失が減少する可能性がありますが、ルーティングチャーンがネットワーク全体に表示されます。
The setting of the relevant parameters for a particular application should take into account trade-offs, network dynamics, and potential failure scenarios. If needed, the first period can be bypassed either by local configuration or by setting the Restart Time in the Graceful Restart Capability to zero and/or not listing the AFI/SAFI in that capability.
特定のアプリケーションの関連パラメーターの設定は、トレードオフ、ネットワークダイナミクス、および潜在的な障害シナリオを考慮に入れる必要があります。必要に応じて、最初の期間は、ローカル構成によって、または優雅な再起動機能の再起動時間をゼロにゼロに、および/またはその機能にafi/safiをリストしないことによってバイパスすることができます。
The setting of the F bit (and the Forwarding State bit of the accompanying GR Capability) depends, in part, on deployment considerations. The F bit can be understood as an indication that the Helper should flush associated routes (if the bit is left clear). As discussed in Section 1, an important use case for LLGR is for routes that are more akin to configuration than to conventional routing. For such routes, it may make sense to always set the F bit, regardless of other considerations. Likewise, for control-plane-only entities, such as dedicated route reflectors that do not participate in the forwarding plane, it makes sense to always set the F bit. Overall, the rule of thumb is that if loss of state on the restarting router can reasonably be expected to cause a forwarding loop or persistent packet loss, the F bit should be set scrupulously according to whether state has been retained. Specifics of whether or not the F bit is set are implementation dependent and may also be controlled by configuration. Also, for every AFI/SAFI represented in the LLGR Capability that is also represented in the GR Capability, there will be two corresponding F bits: the LLGR F bit and the GR F bit. If the LLGR F bit is set, the corresponding GR F bit should also be set, since to do otherwise would cause the state to be cleared on the Receiving Router per the normal rules of GR, violating the intent of the set LLGR bit.
Fビットの設定（および添付のGR機能の転送状態ビット）は、部分的には展開の考慮事項に依存します。Fビットは、ヘルパーが関連するルートをフラッシュする必要があることを示すこととして理解できます（ビットがクリアされている場合）。セクション1で説明したように、LLGRの重要なユースケースは、従来のルーティングよりも構成に似ているルート用です。そのようなルートについては、他の考慮事項に関係なく、常にFビットを設定することは理にかなっているかもしれません。同様に、転送面に参加しない専用のルートリフレクターなどのコントロールプレーンのみのエンティティの場合、常にFビットを設定することは理にかなっています。全体的に、経験則は、再起動ルーターの状態の損失が、転送ループまたは永続的なパケット損失を引き起こすと合理的に予想される場合、状態が保持されているかどうかに従ってfビットをしっかりと設定する必要があるということです。Fビットが設定されているかどうかの詳細は実装依存であり、構成によって制御される場合があります。また、GR機能にも表されるLLGR機能に表されるすべてのAFI/SAFIについて、2つの対応するFビットがあります：LLGR fビットとGR fビット。LLGR fビットが設定されている場合、対応するGR fビットも設定する必要があります。これは、GRの通常のルールごとに受信ルーターで状態をクリアするため、SET LLGRビットの意図に違反するためです。
As discussed in Section 4.7, it may be necessary for a PE to advertise stale routes to a CE in some VPN deployments, even if the CE does not support this specification. In that case, the operator configuring their PE to advertise such routes should notify the operator of the CE receiving the routes, and the CE should be configured to depreference the routes.
セクション4.7で説明したように、CEがこの仕様をサポートしていなくても、PEが一部のVPN展開で古いルートをCEに宣伝する必要がある場合があります。その場合、そのようなルートを宣伝するようにPEを構成するオペレーターは、ルートを受信するCEのオペレーターに通知する必要があり、CEはルートを剥奪するように構成する必要があります。
Similarly, it may be necessary for a CE to advertise stale routes to a PE, even if the PE does not support this specification. In that case, the operator configuring their CE to advertise such routes should notify the operator of the PE receiving the routes, and the PE should be configured to depreference the routes.
同様に、PEがこの仕様をサポートしていなくても、CEが古いルートをPEに宣伝する必要がある場合があります。その場合、そのようなルートを宣伝するようにCEを構成するオペレーターは、ルートを受信するPEのオペレーターに通知する必要があり、PEはルートを削除するように構成する必要があります。
Typical BGP implementations will be able to be configured to depreference routes by matching on the LLGR_STALE community and setting the LOCAL_PREF for matching routes to zero, similar to the procedure described in Section 4.6.
典型的なBGP実装は、llgr_staleコミュニティを一致させ、セクション4.6で説明した手順と同様に、ルートを一致させるルートのlocal_prefをゼロに設定することにより、depreferenceルートに設定できます。
Depreferencing EBGP routes is considered safe, no different from the common practice of applying a routing policy to an EBGP session. However, the same is not always true of IBGP.
EBGPルートの削除は安全であると考えられており、ルーティングポリシーをEBGPセッションに適用するという一般的な慣行と違いはありません。ただし、同じことがIBGPに常に当てはまるわけではありません。
Consistent route selection is a fundamental tenet of IBGP correctness and safe operation in hop-by-hop routed networks. When routers within an AS apply different criteria in selecting routes, they can arrive at inconsistent route selections. This can lead to the formation of forwarding loops unless some form of tunneled forwarding is used to prevent "core" routers from making a (potentially inconsistent) forwarding decision based on the IP header.
一貫したルート選択は、ホップバイホップルーティングネットワークにおけるIBGPの正確性と安全な動作の基本的な教義です。AS内のルーターがルートを選択する際に異なる基準を適用する場合、一貫性のないルートの選択に到達することができます。これは、「コア」ルーターがIPヘッダーに基づいて（潜在的に一貫性のない）転送決定を行うのを防ぐために何らかの形のトンネル転送を使用しない限り、転送ループの形成につながる可能性があります。
This specification uses the state of a peering session as an input to the selection criteria, depreferencing routes that are associated with a session that has gone down but that have not yet aged out. Since different routers within an AS might have different notions as to whether their respective sessions with a given peer are up or down, they might apply different selection criteria to routes from that peer. This could result in a forwarding loop forming between such routers.
この仕様では、ピアリングセッションの状態を、選択基準への入力として、ダウンしているがまだ老化していないセッションに関連付けられているルートを削除します。AS内の異なるルーターは、特定のピアとのそれぞれのセッションが上下にあるかどうかについて異なる概念を持っている可能性があるため、そのピアからのルートに異なる選択基準を適用する可能性があります。これにより、そのようなルーター間に転送ループが形成される可能性があります。
For an example of such a forwarding loop, consider the following simple topology:
このような転送ループの例については、次の単純なトポロジーを検討してください。
A ---- B ---- C ------------------------- D
^ ^
| |
R1 R2
Figure 1
In this example, A - D are routers with a full mesh of IBGP sessions between them (the sessions are not shown). The short links have unit cost, the long link has cost 5. Routers A and D are AS border routers, each advertising some route, R, with the same LOCAL_PREF into the AS: denoted R1 and R2 in the diagram. In ordinary operation, it can be seen that routers B and C will select R1 for forwarding and will forward toward A.
この例では、a -dは、それらの間のIBGPセッションの完全なメッシュを持つルーターです（セッションは表示されません）。短いリンクには単位コストがあり、長いリンクのコストは5のコストです。ルーターAとDはボーダールーターと同じです。各ルートRは、同じlocal_prefをDIAGRAMのASに示します。通常の操作では、ルーターBとCが転送用にR1を選択し、Aに向かって転送することがわかります。
Suppose that the session between A and B goes down for some reason, and it stays down long enough for LLGR processing to be invoked on B. Then, on B, route R1 will be depreferenced, leading to the selection of R2 by B. However, C will continue to prefer R1. In this case, it can be seen that a forwarding loop for packets destined to R would form between B and C. (We note that other forwarding loop scenarios can be constructed for conventional GR, but these are generally considered less severe since GR can remain in effect for a much more limited interval.)
AとBの間のセッションが何らかの理由でダウンし、LLGR処理がBで呼び出されるのに十分な長さを維持し、BでR1が除外され、BがR2の選択につながると仮定します。、Cは引き続きR1を好みます。この場合、Rに導かれるパケットの転送ループがBとCの間に形成されることがわかります（従来のGRに対して他の転送ループシナリオは構築できることに注意してください。はるかに限られた間隔のために実際に。）
The potential benefits of this specification can outweigh the risks discussed above, as long as care is exercised in deployment. The cardinal rule to be followed is that if a given set of routes is being used within an AS for hop-by-hop forwarding, enabling LLGR procedures is not recommended. If tunneled forwarding (such as MPLS) is used within the AS, or if routes are being used for purposes other than hop-by-hop forwarding, less caution is needed; however, the operator should still carefully consider the consequences of enabling LLGR.
この仕様の潜在的な利点は、展開に注意が払われている限り、上記のリスクを上回る可能性があります。従うべき基本的なルールは、Hop-by-Hop転送のためにAS内で特定のルートセットが使用されている場合、LLGR手順を有効にすることは推奨されないということです。Tunneled Forwarding（MPLSなど）がAS内で使用されている場合、またはホップバイホップ転送以外の目的でルートが使用されている場合は、注意が必要です。ただし、オペレーターは、LLGRを有効にすることの結果を慎重に検討する必要があります。
The security implications of the LLGR mechanism defined in this document are akin to those incurred by the maintenance of stale routing information within a network. However, since the retention time may be much longer, the window during which certain attacks are feasible may substantially increase. This is particularly relevant when considering the maintenance of routing information that is used for service segregation, such as MPLS label entries.
このドキュメントで定義されているLLGRメカニズムのセキュリティへの影響は、ネットワーク内の古いルーティング情報のメンテナンスによって発生したものと似ています。ただし、保持時間ははるかに長くなる可能性があるため、特定の攻撃が実現可能なウィンドウが大幅に増加する可能性があります。これは、MPLSラベルエントリなどのサービス分離に使用されるルーティング情報のメンテナンスを検討する場合に特に関連します。
For MPLS VPN services, the effectiveness of the traffic isolation between VPNs relies on the correctness of the MPLS labels between ingress and egress PEs. In particular, when an egress PE withdraws a label L1 allocated to a VPN1 route, this label must not be assigned to a VPN route of a different VPN until all ingress PEs stop using the old VPN1 route using L1.
MPLS VPNサービスの場合、VPN間のトラフィック分離の有効性は、イングレスと出口PEの間のMPLSラベルの正確性に依存しています。特に、出力PEがVPN1ルートに割り当てられたラベルL1を撤回した場合、このラベルは、L1を使用して古いVPN1ルートの使用を停止するまで、異なるVPNのVPNルートに割り当てられてはなりません。
Such a corner case may happen today if the propagation of VPN routes by BGP messages between PEs takes more time than the label reallocation delay on a PE. Given that we can generally bound the worst-case BGP propagation time to a few minutes (for example, 2-5 minutes), the security breach will not occur if PEs are designed to not reallocate a previously used and withdrawn label before a few minutes.
このようなコーナーケースは、PE間のBGPメッセージによるVPNルートの伝播が、PEのラベル再配置遅延よりも時間がかかる場合に発生する可能性があります。一般に、最悪のBGP伝播時間を数分（たとえば2〜5分）にバインドできることを考えると、PESが数分前に以前に使用および撤回されたラベルを再割り当てしないように設計されている場合、セキュリティ侵害は発生しません。
The problem is made worse with BGP GR between PEs because VPN routes can be stalled for a longer period of time (for example, 20 minutes).
VPNルートをより長い期間（たとえば20分）停止できるため、PES間のBGP GRで問題が悪化します。
This is further aggravated by the LLGR extension specified in this document because VPN routes can be stalled for a much longer period of time (for example, 2 hours, 1 day).
これは、VPNルートをはるかに長い期間（たとえば2時間、1日）停止できるため、このドキュメントで指定されたLLGR拡張によってさらに悪化します。
In order to exploit the vulnerability described above, an attacker needs to engineer a specific LLGR state between two PE devices and also cause the label reallocation to occur such that the two topologies overlap. To avoid the potential for a VPN breach, the operator should ensure that the lower bound for label reuse is greater than the upper bound on the LLST before enabling LLGR for a VPN address family. Section 4.2 discusses the provision of an upper bound on LLST. Details of features for setting a lower bound on label reuse time are beyond the scope of this document; however, factors that might need to be taken into account when setting this value include:
上記の脆弱性を活用するために、攻撃者は2つのPEデバイス間で特定のLLGR状態を設計し、2つのトポロジーが重複するようにラベルの再配置を発生させる必要があります。VPN違反の可能性を回避するために、オペレーターは、VPNアドレスファミリのLLGRを有効にする前に、ラベル再利用用の下限がLLSTの上限よりも大きいことを確認する必要があります。セクション4.2では、LLSTの上限の提供について説明します。ラベルの再利用時間に下限を設定するための機能の詳細は、このドキュメントの範囲を超えています。ただし、この値を設定する際に考慮する必要がある可能性のある要因には次のものがあります。
* The load of the BGP route churn on a PE (in terms of the number of VPN labels advertised and the churn rate).
* BGPルートの負荷は、PE（宣伝されているVPNラベルの数と解約率の観点から）で解約されます。
* The label allocation policy on the PE, which possibly depends upon the size of the pool of the VPN labels (which can be restricted by hardware considerations or other MPLS usages), the label allocation scheme (for example, per route or per VRF/CE), and the reallocation policy (for example, least recently used label).
* VPNラベルのプールのサイズ（ハードウェアの考慮事項またはその他のMPLS使用法によって制限される可能性がある）に依存する可能性のあるPEのラベル割り当てポリシー、ラベル割り当てスキーム（例えば、ルートごとまたはVRF/CEごとに）、および再配置ポリシー（たとえば、最近使用されたラベルなど）。
Note that [RFC4781], which defines the Graceful Restart Mechanism for BGP with MPLS, is also applicable to LLGR.
MPLSを使用したBGPの優雅な再起動メカニズムを定義する[RFC4781]は、LLGRにも適用されることに注意してください。
For illustrative purposes, we present a few examples of how this specification might be used in practice. These examples are neither exhaustive nor normative.
実例のために、この仕様が実際にどのように使用されるかについてのいくつかの例を紹介します。これらの例は、網羅的でも規範的でもありません。
Consider the following scenario: A border router, ASBR1, has an IBGP peering with a route reflector, RR1, from which it learns routes. It has an EBGP peering with an external peer, EXT, to which it advertises those routes. The external peer has advertised the GR and LLGR Capabilities to ASBR1. ASBR1 is configured to support GR and LLGR on its sessions with RR1 and EXT. RR1 advertises a GR Restart Time of 1 (second) and an LLST of 3600 (seconds):
次のシナリオを考慮してください。BorderRouterのASBR1には、ルートを学習するルートリフレクターRR1を備えたIBGPのピアリングがあります。それらのルートを宣伝する外部ピア、extを備えたEBGPのピアリングがあります。外部ピアは、ASBR1にGRおよびLLGR機能を宣伝しています。ASBR1は、RR1およびExt。RR1は、GRの再起動時間1（2番目）とLLSTの3600（秒）を宣伝します。
+==========+=====================================================+
| Time | Event |
+==========+=====================================================+
| t | ASBR1's IBGP session with RR fails. ASBR1 retains |
| | RR's routes according to the rules of GR [RFC4724]. |
+----------+-----------------------------------------------------+
| t+1 | GR Restart Time expires. ASBR1 transitions RR's |
| | routes to long-lived stale routes by attaching the |
| | LLGR_STALE community and depreferencing them. |
| | However, since it has no backup routes, it |
| | continues to make use of them. It re-announces |
| | them to EXT with the LLGR_STALE community attached. |
+----------+-----------------------------------------------------+
| t+1+3600 | LLST expires. ASBR1 removes RR's stale routes from |
| | its own RIB and sends BGP updates to withdraw them |
| | from EXT. |
+----------+-----------------------------------------------------+
Table 1
Next, imagine the same scenario, but suppose RR1 advertised a GR Restart Time of zero, effectively disabling GR. Equally, ASBR1 could have used a local configuration to override RR1's offered Restart Time, setting it to a locally configured value of zero:
次に、同じシナリオを想像しますが、RR1がGRの再起動時間をゼロで宣伝し、GRを効果的に無効にしたと仮定します。同様に、ASBR1はローカル構成を使用してRR1の提供された再起動時間をオーバーライドし、ローカルで構成されたゼロ値に設定することができました。
+==========+=======================================================+
| Time | Event |
+==========+=======================================================+
| t | ASBR1's IBGP session with RR fails. ASBR1 |
| | transitions RR's routes to long-lived stale routes by |
| | attaching the LLGR_STALE community and depreferencing |
| | them. However, since it has no backup routes, it |
| | continues to make use of them. It re-announces them |
| | to EXT with the LLGR_STALE community attached. |
+----------+-------------------------------------------------------+
| t+0+3600 | LLST expires. ASBR1 removes RR's stale routes from |
| | its own RIB and sends BGP updates to withdraw them |
| | from EXT. |
+----------+-------------------------------------------------------+
Table 2
Next, imagine the original scenario, but consider that the ASBR1-RR1 session comes back up and becomes synchronized 180 seconds after the failure was detected:
次に、元のシナリオを想像してください。ただし、ASBR1-RR1セッションが戻ってきて、障害が検出されてから180秒後に同期されることを考えてください。
+=========+=====================================================+
| Time | Event |
+=========+=====================================================+
| t | ASBR1's IBGP session with RR fails. ASBR1 retains |
| | RR's routes according to the rules of GR [RFC4724]. |
+---------+-----------------------------------------------------+
| t+1 | GR Restart Time expires. ASBR1 transitions RR's |
| | routes to long-lived stale routes by attaching the |
| | LLGR_STALE community and depreferencing them. |
| | However, since it has no backup routes, it |
| | continues to make use of them. It re-announces |
| | them to EXT with the LLGR_STALE community attached. |
+---------+-----------------------------------------------------+
| t+1+179 | Session is re-established and resynchronized. |
| | ASBR1 removes the LLGR_STALE community from RR1's |
| | routes and re-announces them to EXT with the |
| | LLGR_STALE community removed. |
+---------+-----------------------------------------------------+
Table 3
Finally, imagine the original scenario, but consider that EXT has not advertised the LLGR Capability to ASBR1:
最後に、元のシナリオを想像してください。ただし、ExtはASBR1にLLGR機能を宣伝していないことを考えてください。
+==========+======================================================+
| Time | Event |
+==========+======================================================+
| t | ASBR1's IBGP session with RR fails. ASBR1 retains |
| | RR's routes according to the rules of GR [RFC4724]. |
+----------+------------------------------------------------------+
| t+1 | GR Restart Time expires. ASBR1 transitions RR's |
| | routes to long-lived stale routes by attaching the |
| | LLGR_STALE community and depreferencing them. |
| | However, since it has no backup routes, it continues |
| | to make use of them. It withdraws them from EXT. |
+----------+------------------------------------------------------+
| t+1+3600 | LLST expires. ASBR1 removes RR's stale routes from |
| | its own RIB. |
+----------+------------------------------------------------------+
Table 4
This document defines a BGP capability called the "Long-Lived Graceful Restart Capability". IANA has assigned a value of 71 from the "Capability Codes" registry.
このドキュメントは、「長寿命の優雅な再起動機能」と呼ばれるBGP機能を定義しています。IANAは、「機能コード」レジストリから71の値を割り当てました。
This document introduces two BGP well-known communities:
この文書では、2つのBGPの有名なコミュニティを紹介します。
* the first called "LLGR_STALE" for marking long-lived stale routes, and
* 長寿命の古いルートをマークするための「llgr_stale」と呼ばれる最初のもの、そして
* the second called "NO_LLGR" for marking routes that should not be retained if stale.
* 2番目は、古くても保持されないルートをマークするための「no_llgr」と呼ばれます。
IANA has assigned these well-known community values 0xFFFF0006 and 0xFFFF0007, respectively, from the "BGP Well-known Communities" registry.
IANAは、「BGPよく知られているコミュニティ」レジストリから、それぞれこれらのよく知られているコミュニティの価値0xffff0006および0xffff0007を割り当てました。
IANA has established a registry called the "Long-Lived Graceful Restart Flags for Address Family" registry under the "Border Gateway Protocol (BGP) Parameters" group. The registration procedures are Standards Action (see [RFC8126]). The registry is initially populated as follows:
IANAは、「Border Gateway Protocol（BGP）パラメーター」グループの下で、「アドレスファミリーのための長寿命の優雅な再起動フラグ」と呼ばれるレジストリを確立しました。登録手順は標準アクションです（[RFC8126]を参照）。レジストリは最初に次のように入力されます。
+==============+=======================+============+===========+
| Bit Position | Name | Short Name | Reference |
+==============+=======================+============+===========+
| 0 | Preservation of state | F | RFC 9494 |
+--------------+-----------------------+------------+-----------+
| 1-7 | Unassigned | | |
+--------------+-----------------------+------------+-----------+
Table 5
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
DOI 10.17487/RFC4724, January 2007,
<https://www.rfc-editor.org/info/rfc4724>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
Yamagata, "Internal BGP as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 6368, DOI 10.17487/RFC6368, September 2011,
<https://www.rfc-editor.org/info/rfc6368>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8538] Patel, K., Fernando, R., Scudder, J., and J. Haas,
"Notification Message Support for BGP Graceful Restart",
RFC 8538, DOI 10.17487/RFC8538, March 2019,
<https://www.rfc-editor.org/info/rfc8538>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
[RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism
for BGP with MPLS", RFC 4781, DOI 10.17487/RFC4781,
January 2007, <https://www.rfc-editor.org/info/rfc4781>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
We would like to thank Nabil Bitar, Martin Djernaes, Roberto Fragassi, Jeffrey Haas, Jakob Heitz, Daniam Henriques, Nicolai Leymann, Mike McBride, Paul Mattes, John Medamana, Pranav Mehta, Han Nguyen, Saikat Ray, Valery Smyslov, and Bo Wu for their valuable input and contributions to the discussion and solution.
Nabil Bitar、Martin Djernaes、Roberto Fragassi、Jeffrey Haas、Jakob Heitz、Daniam Henriques、Nicolai Leymann、Mike McBride、Paul Mattes、John Medamana、Pranav Mehta、Han Nguyen、Saikat Ray、Valer議論と解決策への貴重な意見と貢献のため。
Clarence Filsfils
Cisco Systems
1150 Brussels
Belgium
Email: cf@cisco.com
Pradosh Mohapatra
Sproute Networks
Email: mpradosh@yahoo.com
Yakov Rekhter
Eric Rosen
Email: erosen52@gmail.com
Rob Shakir
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: robjs@google.com
Adam Simpson
Nokia
Email: adam.1.simpson@nokia.com
James Uttaro
Independent Contributor
Email: juttaro@ieee.org
Enke Chen
Palo Alto Networks
Email: enchen@paloaltonetworks.com
Bruno Decraene
Orange
Email: bruno.decraene@orange.com
John G. Scudder
Juniper Networks
Email: jgs@juniper.net