[要約] RFC 2918は、BGP-4のルートリフレッシュ機能に関する仕様です。このRFCの目的は、BGPピア間でのルーティング情報の更新を効率化することです。
Network Working Group E. Chen
Request for Comments: 2918 Redback Networks
Category: Standards Track September 2000
Route Refresh Capability for BGP-4
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、「ルートリフレッシュ機能」と呼ばれる新しいBorder Gateway Protocol（BGP）機能を定義します。これにより、BGPスピーカー間のルートリフレッシュリクエストの動的交換と、それぞれのadj-rib-outの再承認が可能になります。この機能の可能な適用の1つは、破壊的でないルーティングポリシーの変更を促進することです。
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-4 [BGP-4]には、BGPピアからのadj-rib-outの再承認を動的に要求するメカニズムは存在しません。ピアのインバウンドルーティングポリシーが変更された場合、そのピアからのすべての接頭辞を何らかの形で利用できるようにし、新しいポリシーに対して再検討する必要があります。これを達成するために、「ソフトレコンフィギュレーション」として知られる一般的に使用されるアプローチは、ルーティングポリシーが頻繁に変更されない場合でも、常にそのピアからすべてのルートのコピーを常に保存することです（通常は数倍以下日）。これらのルートを維持するには、追加のメモリと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機能を定義します。これにより、BGPスピーカー間のルートリフレッシュリクエストの動的な交換と、それぞれのadj-rib-outの再承認が可能になります。
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で定義されているように）を受信して適切に処理できることをピアに伝えます。
The ROUTE-REFRESH message is a new BGP message type defined as follows:
Route-Refreshメッセージは、次のように定義された新しいBGPメッセージタイプです。
Type: 5 - ROUTE-REFRESH
タイプ：5-ルートリフレッシュ
Message Format: One <AFI, SAFI> encoded as
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、sect。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).
SAFI-後続のアドレスファミリ識別子（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>の1つである必要があります。
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>を使用してルートリフレッシュメッセージを受信した場合、スピーカーは能力広告を介してセッションの確立時間でピアに宣伝しなかった場合、スピーカーはそのようなメッセージを無視するものとします。それ以外の場合、BGPスピーカーは、そのアウトバウンドルートフィルタリングポリシーに基づいて、メッセージに掲載された<AFIのafi-rib-outを再承認するものとします。
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.
著者は、ヤコフ・レクター、ラビ・チャンドラ、スリハリ・ラマチャンドラ、ブルース・コールのレビューとコメントに感謝したいと思います。
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP-4] Rekhter、Y。およびT. Li、「Border Gateway Protocol 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] Bates、T.、Chandra、R.、Katz、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] Chandra、R。およびJ. Scudder、「BGP-4による機能広告」、RFC 2842、2000年5月。
Enke Chen Redback Networks Inc. 350 Holger Way San Jose, CA 95134
Enke Chen Redback Networks Inc. 350 Holger Way San Jose、CA 95134
EMail: enke@redback.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。