Network Working Group E. Chen
Request for Comments: 2918 Redback Networks
Category: Standards Track September 2000
Route Refresh Capability for BGP-4
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 Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. One possible application of this capability is to facilitate non-disruptive routing policy changes.
この文書では、BGPスピーカーとそれぞれのAdj-RIBアウトのその後の再広告間のルートリフレッシュ要求の動的な交換を可能とする「ルートリフレッシュ機能」と呼ばれる新しいボーダーゲートウェイプロトコル（BGP）機能を定義しています。この機能の一つの可能な用途は、無停止ルーティングポリシーの変更を容易にすることです。
Currently there does not exist a mechanism in BGP-4 [BGP-4] to dynamically request a re-advertisement of the Adj-RIB-Out from a BGP peer. When the inbound routing policy for a peer changes, all prefixes from that peer must be somehow made available and then re-examined against the new policy. To accomplish this, a commonly used approach, known as 'soft-reconfiguration', is to store an unmodified copy of all routes from that peer at all times, even though routing policies do not change frequently (typically no more than a couple times a day). Additional memory and CPU are required to maintain these routes.
現在動的BGPピアからのAdj-RIBアウトの再広告を要求するために、BGP-4 [BGP-4]で機構が存在しません。ピア変更の場合は、インバウンドルーティングポリシー、そのピアからのすべてのプレフィックスは、何らかの形で利用できるようにする必要があり、その後、新しいポリシーに対して再検討。これを実現するために、「ソフト・再構成」として知られている一般的に使用されるアプローチは、ルーティングポリシーは（頻繁に通常より多くない数回変更されないにもかかわらず、すべての回でそのピアからのすべてのルートの未修正のコピーを格納することです日）。追加のメモリとCPUがこれらのルートを維持するために必要とされています。
This document proposes an alternative solution that avoids the additional maintenance cost. More specifically, it defines a new BGP capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out.
この文書では、追加のメンテナンスコストを回避し、代替ソリューションを提案しています。具体的には、BGPスピーカーとそれぞれのAdj-RIBアウトのその後の再広告間のルートリフレッシュ要求の動的な交換を可能とする「ルートリフレッシュ機能」と呼ばれる新しいBGP機能を定義します。
To advertise the Route Refresh Capability to a peer, a BGP speaker uses BGP Capabilities Advertisement [BGP-CAP]. This capability is advertised using the Capability code 2 and Capability length 0.
ピアにルートリフレッシュ機能を宣伝するために、BGPスピーカは、BGP機能広告[BGP-CAP]を使用しています。この機能は、機能コード2と能力長さ0を使用してアドバタイズされます。
By advertising the Route Refresh Capability to a peer, a BGP speaker conveys to the peer that the speaker is capable of receiving and properly handling the ROUTE-REFRESH message (as defined in Section 3) from the peer.
ピアにルートリフレッシュ機能を広告することによって、BGPスピーカは、スピーカが受信して適切にピアから（セクション3で定義されるように）ROUTEリフレッシュメッセージを処理することができるピアに伝えます。
The ROUTE-REFRESH message is a new BGP message type defined as follows:
次のようにROUTE-REFRESHメッセージは、新しいBGPメッセージタイプに定義されます。
Type: 5 - ROUTE-REFRESH
タイプ：5 - ROUTE-REFRESH
Message Format: One <AFI, SAFI> encoded as
メッセージフォーマット：ワン<AFI、SAFI>としてエンコード
0 7 15 23 31
+-------+-------+-------+-------+
| AFI | Res. | SAFI |
+-------+-------+-------+-------+
The meaning, use and encoding of this <AFI, SAFI> field is the same as defined in [BGP-MP, sect. 7]. More specifically,
この<AFI、SAFI>フィールドの意味、使用および符号化は[BGP-MP、宗派で定義されたものと同じです。 7]。すなわち、
AFI - Address Family Identifier (16 bit).
AFI - ファミリ識別子（16ビット）のアドレス。
Res. - Reserved (8 bit) field. Should be set to 0 by the sender and ignored by the receiver.
RES。 - 予約（8ビット）フィールド。送信者によって0に設定され、受信機によって無視されるべきです。
SAFI - Subsequent Address Family Identifier (8 bit).
サフィ - 次のアドレスファミリー識別子（8ビット）。
A BGP speaker that is willing to receive the ROUTE-REFRESH message from its peer should advertise the Route Refresh Capability to the peer using BGP Capabilities advertisement [BGP-CAP].
BGP機能広告[BGP-CAP]を使用してピアにルートリフレッシュ機能をアドバタイズする必要があり、そのピアからのルートリフレッシュメッセージを受信する意思があるBGPスピーカ。
A BGP speaker may send a ROUTE-REFRESH message to its peer only if it has received the Route Refresh Capability from its peer. The <AFI, SAFI> carried in such a message should be one of the <AFI, SAFI> that the peer has advertised to the speaker at the session establishment time via capability advertisement.
BGPスピーカは、そのピアからのルートリフレッシュ機能を受信した場合にのみ、そのピアへのルートリフレッシュメッセージを送信することができます。 <AFI、SAFI>このようなメッセージで運ばれたピアが機能広告を介してセッション確立時にスピーカにアドバタイズしたことを<AFI、SAFI>のいずれかであるべきです。
If a BGP speaker receives from its peer a ROUTE-REFRESH message with the <AFI, SAFI> that the speaker didn't advertise to the peer at the session establishment time via capability advertisement, the speaker shall ignore such a message. Otherwise, the BGP speaker shall re-advertise to that peer the Adj-RIB-Out of the <AFI, SAFI> carried in the message, based on its outbound route filtering policy.
BGPスピーカがピアからのスピーカーは、能力の広告を経由してセッション確立時にピアに広告していなかったことを<AFI、SAFI>とROUTE-REFRESHメッセージを受信した場合、スピーカーは、このようなメッセージを無視するものとします。それ以外の場合は、BGPスピーカは、その<AFI、SAFI>の調整]-RIBアウトピアへの再広告を出すのアウトバウンドルートフィルタリングポリシーに基づいて、メッセージで運ばばなりません。
This extension to BGP does not change the underlying security issues.
BGPへのこの拡張は、根本的なセキュリティ問題を変更しません。
The concept of Route Refresh proposed is similar to the one used in IDRP.
提案ルートのリフレッシュの概念がIDRPに使用されているものと同様です。
The author would like to thank Yakov Rekhter, Ravi Chandra, Srihari Ramachandra and Bruce Cole for their review and comments.
作者は彼らのレビューとコメントをヤコフ・レックター、ラヴィチャンドラ、スリアリRamachandraとブルース・コールに感謝したいと思います。
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP-4] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-MP]ベイツ、T.、チャンドラ、R.、カッツ、D.およびY. Rekhter、 "BGP-4のためのマルチプロトコルの拡張"、RFC 2858、2000年6月。
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.
[BGP-CAP]チャンドラ、R.及びJ.スカダー、 "BGP-4との機能広告"、RFC 2842、2000年5月。
Enke Chen Redback Networks Inc. 350 Holger Way San Jose, CA 95134
エンケ陳レッドバックネットワークス株式会社350ホルガー・ウェイサンノゼ、CA 95134
EMail: enke@redback.com
メールアドレス：enke@redback.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。