[要約] RFC 7196は、ルートフラップダンピングの利用可能性を向上させるための提案です。その目的は、ネットワークの安定性を向上させ、ルートフラップによるネットワークのパフォーマンス低下を軽減することです。
Internet Engineering Task Force (IETF) C. Pelsser
Request for Comments: 7196 R. Bush
Category: Standards Track Internet Initiative Japan
ISSN: 2070-1721 K. Patel
Cisco Systems
P. Mohapatra
Sproute Networks
O. Maennel
Loughborough University
May 2014
Making Route Flap Damping Usable
ルートフラップダンピングを使用可能にする
Abstract
概要
Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process.
ルートフラップダンピング（RFD）は、ルーターのBGPチャーンを減らすために最初に提案されました。残念ながら、トポロジの豊富さが交換される更新メッセージの数を増幅するため、RFDはサイトが適切に接続されていることでサイトに深刻なペナルティを課すことが判明しました。多くのオペレーターがRFDをオフにしています。実験的な測定に基づいて、このドキュメントでは、RFDによる高いリスクを減らすために、いくつかのRFDアルゴリズム定数と制限を調整することを推奨しています。その結果、適切に動作するプレフィックスの通常の収束プロセスにペナルティを課すことなく、重要な量の長期チャーンが抑制されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7196.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7196で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Suggested Reading . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. RFD Parameters . . . . . . . . . . . . . . . . . . . . . . . 3
4. Suppress Threshold versus Churn . . . . . . . . . . . . . . . 4
5. Maximum Penalty . . . . . . . . . . . . . . . . . . . . . . . 4
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Route Flap Damping (RFD) was first proposed (see [RIPE178] and [RFC2439]) and subsequently implemented to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged, see [MAO2002]. Subsequently, many operators turned RFD off; see [RIPE378]. Based on the measurements of [PELSSER2011], [RIPE580] now recommends that RFD is usable with some changes to the parameters. Based on the same measurements, this document recommends adjusting a few RFD algorithmic constants and limits. The result is damping of a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process.
Route Flap Damping（RFD）は最初に提案され（[RIPE178]および[RFC2439]を参照）、その後実装されて、ルーターのBGPチャーンを減らします。残念ながら、トポロジの豊富さが交換される更新メッセージの数を増幅するため、RFDはサイトが適切に接続されていることをサイトに深刻なペナルティを課すことがわかりました。[MAO2002]を参照してください。その後、多くのオペレーターがRFDをオフにしました。 [RIPE378]を参照してください。 [PELSSER2011]の測定結果に基づいて、[RIPE580]はRFDを使用してパラメーターにいくつかの変更を加えることを推奨しています。同じ測定に基づいて、このドキュメントでは、いくつかのRFDアルゴリズム定数と制限を調整することを推奨しています。その結果、適切に動作するプレフィックスの通常の収束プロセスにペナルティを課すことなく、重要な量の長期チャーンが減衰します。
Very few prefixes are responsible for a large amount of the BGP messages received by a router; see [HUSTON2006] and [PELSSER2011]. For example, the measurements in [PELSSER2011] showed that only 3% of
ルーターが受信する大量のBGPメッセージを処理するプレフィックスはほとんどありません。 [HUSTON2006]および[PELSSER2011]を参照してください。たとえば、[PELSSER2011]での測定では、
the prefixes were responsible for 36% percent of the BGP messages at a router with real feeds from a Tier-1 provider and an Internet Exchange Point during a one-week experiment. Only these very frequently flapping prefixes should be damped. The values recommended in Section 6 achieve this. Thus, RFD can be enabled, and some churn reduced.
プレフィックスは、1週間の実験中に、Tier-1プロバイダーとInternet Exchange Pointからの実際のフィードを含むルーターでBGPメッセージの36％を占めていました。これらの非常に頻繁にフラッピングするプレフィックスだけが減衰されるべきです。セクション6で推奨される値は、これを実現します。したがって、RFDを有効にして、チャーンを減らすことができます。
The goal is to, with absolutely minimal change, ameliorate the danger of current RFD implementations and use. It is not a panacea, nor is it a deep and thorough approach to flap reduction.
目標は、最小限の変更で、現在のRFD実装と使用の危険性を改善することです。これは万能薬ではなく、フラップを減らすための深く徹底的なアプローチでもありません。
It is assumed that the reader understands BGP [RFC4271] and Route Flap Damping [RFC2439]. This work is based on the measurements in the paper [PELSSER2011]. A survey of Japanese operators' use of RFD and their desires is reported in [RFD-SURVEY].
読者がBGP [RFC4271]とルートフラップダンピング[RFC2439]を理解していることを前提としています。この研究は、論文[PELSSER2011]の測定に基づいています。日本の事業者によるRFDの使用とその要望に関する調査は、[RFD-SURVEY]で報告されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without normative meaning.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は解釈されますRFC 2119 [RFC2119]で説明されているように、すべて大文字で表記されている場合のみ。それらは、規範的な意味なしに、英語の単語として小文字または大文字と小文字が混在して表示される場合もあります。
The following RFD parameters are common to all implementations. Some may be tuned by the operator, some not. There is currently no consensus on a single set of default values.
次のRFDパラメータは、すべての実装に共通です。オペレーターによって調整されるものとそうでないものがあります。現在のところ、デフォルト値の単一のセットについてコンセンサスはありません。
+--------------------------+----------+-------+---------+
| Parameter | Tunable? | Cisco | Juniper |
+--------------------------+----------+-------+---------+
| Withdrawal | No | 1,000 | 1,000 |
| Re-Advertisement | No | 0 | 1,000 |
| Attribute Change | No | 500 | 500 |
| Suppress Threshold | Yes | 2,000 | 3,000 |
| Half-Life (min.) | Yes | 15 | 15 |
| Reuse Threshold | Yes | 750 | 750 |
| Max Suppress Time (min.) | Yes | 60 | 60 |
+--------------------------+----------+-------+---------+
Note: Values without units specified are dimensionless constants.
注：単位が指定されていない値は、無次元定数です。
Table 1: Default RFD Parameters of Juniper and Cisco
表1：ジュニパーネットワークスとシスコのデフォルトのRFDパラメータ
By turning RFD back on with the values recommended in Section 6, churn is reduced. Moreover, with these values, prefixes going through normal convergence are generally not damped.
セクション6で推奨されている値でRFDをオンに戻すことで、チャーンが減少します。さらに、これらの値を使用すると、通常の収束を通過するプレフィックスは通常減衰されません。
[PELSSER2011] estimates that, with a suppress threshold of 6,000, the BGP update rate is reduced by 19% compared to a situation without RFD enabled. [PELSSER2011] studies the number of prefixes damped over a week between September 29, 2010 and October 6, 2010. With this 6,000 suppress threshold, 90% fewer prefixes are damped compared to use of a 2,000 threshold. That is, far fewer well-behaved prefixes are damped.
[PELSSER2011]は、抑制しきい値を6,000にすると、RFDが有効になっていない状況と比較して、BGP更新レートが19％減少すると推定しています。 [PELSSER2011]は、2010年9月29日から2010年10月6日までの1週間に減衰されるプレフィックスの数を調査します。この6,000の抑制しきい値を使用すると、2,000のしきい値を使用する場合と比較して、減衰されるプレフィックスが90％少なくなります。つまり、ダンピングされる適切に動作するプレフィックスははるかに少なくなります。
Setting the suppress threshold to 12,000 leads to very few damped prefixes (0.22% of the prefixes were damped with a threshold of 12,000 in the experiments in [PELSSER2011], yielding an average hourly update reduction of 11% compared to not using RFD).
抑制しきい値を12,000に設定すると、プレフィックスの減衰が非常に少なくなります（[PELSSER2011]の実験では、プレフィックスの0.22％がしきい値12,000で減衰され、RFDを使用しない場合と比較して、1時間あたりの平均更新量が11％減少しました）。
+---------------+-------------+--------------+----------------------+
| Suppress | Damped | % of Table | Update Rate (one- |
| Threshold | Prefixes | Damped | hour bins) |
+---------------+-------------+--------------+----------------------+
| 2,000 | 43,342 | 13.16% | 53.11% |
| 4,000 | 11,253 | 3.42% | 74.16% |
| 6,000 | 4,352 | 1.32% | 81.03% |
| 8,000 | 2,104 | 0.64% | 84.85% |
| 10,000 | 1,286 | 0.39% | 87.12% |
| 12,000 | 720 | 0.22% | 88.74% |
| 14,000 | 504 | 0.15% | 89.97% |
| 16,000 | 353 | 0.11% | 91.01% |
| 18,000 | 311 | 0.09% | 91.88% |
| 20,000 | 261 | 0.08% | 92.69% |
+---------------+-------------+--------------+----------------------+
Note: the current default Suppress Threshold (2,000) is overly agressive.
注：現在のデフォルトの抑制しきい値（2,000）は過度に積極的です。
Table 2: Damped Prefixes vs. Churn, from [PELSSER2011]
表2：[PELSSER2011]のダンピングプレフィックスとチャーンの比較
It is important to understand that the parameters shown in Table 1 and the implementation's sampling rate impose an upper bound on the penalty value, which we can call the 'computed maximum penalty'.
表1に示すパラメーターと実装のサンプリングレートによって、ペナルティ値に上限が課されることを理解することが重要です。これは、「計算された最大ペナルティ」と呼ばれます。
In addition, BGP implementations have an internal constant, which we will call the 'maximum penalty', and the current computed penalty may not exceed it.
さらに、BGP実装には「最大ペナルティ」と呼ばれる内部定数があり、現在計算されているペナルティはそれを超えることはできません。
Use of the following values is recommended:
以下の値の使用をお勧めします。
Router Maximum Penalty: The internal constant for the maximum penalty value MUST be raised to at least 50,000.
ルータの最大ペナルティ：最大ペナルティ値の内部定数を少なくとも50,000に引き上げる必要があります。
Default Configurable Parameters: In order not to break existing operational configurations, existing BGP implementations, including the examples in Table 1, SHOULD NOT change their default values.
デフォルトの構成可能パラメーター：既存の運用構成を壊さないために、表1の例を含む既存のBGP実装は、それらのデフォルト値を変更してはなりません（SHOULD NOT）。
Minimum Suppress Threshold: Operators that want damping that is much less destructive than the current damping, but still somewhat aggressive, SHOULD configure the Suppress Threshold to no less than 6,000.
最小抑制しきい値：現在のダンピングよりも破壊的ではないが、それでもいくらか積極的であるダンピングが必要なオペレーターは、抑制しきい値を6,000以上に設定する必要があります（SHOULD）。
Conservative Suppress Threshold: Conservative operators SHOULD configure the Suppress Threshold to no less than 12,000.
控えめな抑制しきい値：控えめな演算子は、抑制閾値を12,000以上に設定する必要があります（SHOULD）。
Calculate But Do Not Damp: Implementations MAY have a test mode where the operator can see the results of a particular configuration without actually damping any prefixes. This will allow for fine-tuning of parameters without losing reachability.
計算するがダンプしない：実装には、オペレーターが実際に接頭辞をダンプすることなく特定の構成の結果を確認できるテストモードがある場合があります。これにより、到達可能性を失うことなくパラメーターを微調整できます。
It is well known that an attacker can generate false flapping to cause a victim's prefix(es) to be damped.
攻撃者が偽のフラッピングを生成して、被害者の接頭辞を減衰させることができることはよく知られています。
As the recommendations merely change parameters to more conservative values, there should be no increase in risk. In fact, the parameter change to more conservative values should slightly mitigate the false-flap attack.
推奨事項はパラメーターをより保守的な値に変更するだけなので、リスクが増加することはありません。実際、パラメータをより保守的な値に変更すると、偽のフラップ攻撃がわずかに軽減されます。
Nate Kushman initiated this work some years ago. Ron Bonica, Seiichi Kawamura, and Erik Muller contributed useful suggestions.
ネイトクシュマンは数年前にこの仕事を始めました。 Ron Bonica、川村誠一、およびErik Mullerは有益な提案を提供してくれました。
[MAO2002] Mao, Z., Govidan, R., Varghese, G., and R. Katz, "Route Flap Damping Exacerbates Internet Routing Convergence", In Proceedings of SIGCOMM, August 2002, <http://conferences.sigcomm.org/sigcomm/2002/papers/ routedampening.pdf>.
[MAO2002]毛、Z。、ゴビダン、R。、バルゲーゼ、G。、およびR.カッツ、「ルートフラップダンピングはインターネットルーティングの収束を悪化させる」、SIGCOMMのプロシーディングス、2002年8月、<http：//conferences.sigcomm org / sigcomm / 2002 / papers / routedampening.pdf>。
[PELSSER2011] Pelsser, C., Maennel, O., Mohapatra, P., Bush, R., and K. Patel, "Route Flap Damping Made Usable", PAM 2011: Passive and Active Measurement Conference, March 2011, <http://pam2011.gatech.edu/papers/pam2011--Pelsser.pdf>.
[PELSSER2011] Pelsser、C.、Maennel、O.、Mohapatra、P.、Bush、R。、およびK. Patel、「Route Flap Damping Made Usable」、PAM 2011：Passive and Active Measurement Conference、2011年3月、<http ：//pam2011.gatech.edu/papers/pam2011--Pelsser.pdf>。
[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月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、Chandra、R。、およびR. Govindan、「BGP Route Flap Damping」、RFC 2439、1998年11月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RIPE378] Smith, P. and P. Panigl, "RIPE Routing Working Group Recommendations On Route-flap Damping", RIPE 378, May 2006, <http://www.ripe.net/ripe/docs/ripe-378>.
[RIPE378] Smith、P。およびP. Panigl、「ルートフラップダンピングに関するRIPEルーティングワーキンググループの推奨事項」、RIPE 378、2006年5月、<http://www.ripe.net/ripe/docs/ripe-378> 。
[HUSTON2006] Huston, G., "2005 - A BGP Year in Review", RIPE 52, 2006, <http://meetings.ripe.net/ripe-52/presentations/ ripe52-plenary-bgp-review.pdf>.
[HUSTON2006] Huston、G。、「2005-A BGP Year in Review」、RIPE 52、2006、<http://meetings.ripe.net/ripe-52/presentations/ ripe52-plenary-bgp-review.pdf> 。
[RFD-SURVEY] Tsuchiya, S., Kawamura, S., Bush, R., and C. Pelsser, "Route Flap Damping Deployment Status Survey", Work in Progress, June 2012.
[RFD-SURVEY]土屋晋一郎、川村晋一郎、ブッシュR.、C。ペルサー、「Route Flap Damping Deployment Status Survey」、Work in Progress、2012年6月。
[RIPE178] Barber, T., Doran, S., Karrenberg, D., Panigl, C., and J. Schmitz, "RIPE Routing-WG Recommendation for Coordinated Route-flap Damping Parameters", RIPE 178, February 1998, <http://www.ripe.net/ripe/docs/ripe-178>.
[RIPE178] Barber、T.、Doran、S.、Karrenberg、D.、Panigl、C。、およびJ. Schmitz、「RIPE Routing-WG Recommendation for Coordinated Route-flap Damping Parameters」、RIPE 178、1998年2月、< http://www.ripe.net/ripe/docs/ripe-178>。
[RIPE580] Bush, R., Pelsser, C., Kuhne, M., Maennel, O., Mohapatra, P., Patel, K., and R. Evans, "RIPE Routing Working Group Recommendation for Route Flap Damping", RIPE 580, January 2013, <http://www.ripe.net/ripe/docs/ripe-580>.
[RIPE580] Bush、R.、Pelsser、C.、Kuhne、M.、Maennel、O.、Mohapatra、P.、Patel、K.、and R. Evans、 "RIPE Routing Working Group Recommendation for Route Flap Damping"、 RIPE 580、2013年1月、<http://www.ripe.net/ripe/docs/ripe-580>。
Authors' Addresses
著者のアドレス
Cristel Pelsser Internet Initiative Japan Jinbocho Mitsui Buiding, 1-105 Kanda-Jinbocho, Chiyoda-ku, Tokyo 101-0051 JP
Ｃりｓてｌ ぺｌっせｒ いんてｒねｔ いにちあちゔぇ じゃぱん じんぼちょ みつい ぶいぢんｇ、 １ー１０５ かんだーじんぼちょ、 ちよだーく、 ときょ １０１ー００５１ ＪＰ
Phone: +81 3 5205 6464
EMail: cristel@iij.ad.jp
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US
ランディブッシュインターネットイニシアティブ日本5147 Crystal Springsベインブリッジ島、ワシントン98110 US
EMail: randy@psg.com
Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 US
EMail: keyupate@cisco.com
Pradosh Mohapatra Sproute Networks 41529 Higgins Way Fremont, CA 94539 US
Pradosh Mohapatra Sproute Networks 41529 Higgins Way Fremont、CA 94539 US
EMail: mpradosh@yahoo.com
Olaf Maennel Loughborough University Department of Computer Science - N.2.03 Loughborough UK
オラフメーネルラフバラ大学コンピュータサイエンス学部-N.2.03ラフバライギリス
Phone: +44 115 714 0042
EMail: o@maennel.net