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
        
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.

这是一份互联网标准跟踪文件。

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)的产品。它代表了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.

版权所有(c)2014 IETF信托基金和确定为文件作者的人员。版权所有。

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)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

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
        
   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
        
1. Introduction
1. 介绍

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.

路由襟翼阻尼(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消息;参见[Huston 2006]和[PELSSER2011]。例如,[PELSSER2011]中的测量结果表明,只有3%的

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.

在一个为期一周的实验中,路由器上36%的BGP消息是由前缀产生的,这些消息来自一级提供商和互联网交换点。只有这些频繁摆动的前缀才应该被阻尼。第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实施和使用的危险。这不是万灵药,也不是一种深入彻底的皮瓣复位方法。

1.1. Suggested Reading
1.1. 建议阅读

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-survey]中报告了对日本运营商使用RFD及其意愿的调查。

2. Requirements Language
2. 需求语言

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.

关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”仅当出现在所有大写字母中时,才应按照RFC 2119[RFC2119]中所述进行解释。它们也可能以小写或混用形式出现在英语单词中,没有规范意义。

3. RFD Parameters
3. 射频参数

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 |
         +--------------------------+----------+-------+---------+
        
         +--------------------------+----------+-------+---------+
         | 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:Juniper和Cisco的默认RFD参数

4. Suppress Threshold versus Churn
4. 抑制阈值与搅动

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]估计,与未启用RFD的情况相比,抑制阈值为6000时,BGP更新率降低了19%。[PELSSER2011]研究了2010年9月29日至2010年10月6日一周内衰减的前缀数量。使用此6000抑制阈值,与使用2000阈值相比,减少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).

将抑制阈值设置为12000会导致很少的衰减前缀(在[PELSSER2011]中的实验中,0.22%的前缀使用12000的阈值衰减,与不使用RFD相比,平均每小时更新减少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% |
   +---------------+-------------+--------------+----------------------+
        
   +---------------+-------------+--------------+----------------------+
   |      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.

注意:当前的默认抑制阈值(2000)过于激进。

Table 2: Damped Prefixes vs. Churn, from [PELSSER2011]

表2:阻尼前缀与搅动,来自[PELSSER2011]

5. Maximum Penalty
5. 最高刑罚

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实现有一个内部常量,我们称之为“最大惩罚”,当前计算的惩罚可能不会超过它。

6. Recommendations
6. 建议

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.

路由器最大惩罚:最大惩罚值的内部常数必须至少提高到50000。

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.

默认可配置参数:为了不破坏现有操作配置,现有BGP实现(包括表1中的示例)不应更改其默认值。

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.

最小抑制阈值:如果操作员希望阻尼比当前阻尼破坏性小得多,但仍具有一定的攻击性,则应将抑制阈值配置为不小于6000。

Conservative Suppress Threshold: Conservative operators SHOULD configure the Suppress Threshold to no less than 12,000.

保守抑制阈值:保守操作员应将抑制阈值配置为不小于12000。

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.

计算但不阻尼:实现可能有一个测试模式,在该模式下,操作员可以看到特定配置的结果,而不实际阻尼任何前缀。这将允许在不失去可达性的情况下对参数进行微调。

7. Security Considerations
7. 安全考虑

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.

由于建议仅将参数更改为更保守的值,因此不应增加风险。事实上,将参数更改为更保守的值应该会稍微减轻假襟翼攻击。

8. Acknowledgments
8. 致谢

Nate Kushman initiated this work some years ago. Ron Bonica, Seiichi Kawamura, and Erik Muller contributed useful suggestions.

内特·库什曼在几年前开始了这项工作。罗恩·博尼卡、川村成一和埃里克·穆勒提出了有用的建议。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[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]Mao,Z.,Govidan,R.,Varghese,G.,和R.Katz,“路由衰减加剧了互联网路由收敛”,发表于《SIGCOMM学报》,2002年8月<http://conferences.sigcomm.org/sigcomm/2002/papers/ RoutedAmping.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,“可用的路线襟翼阻尼”,PAM 2011:被动和主动测量会议,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路线襟翼阻尼”,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,“边境网关协议4(BGP-4)”,RFC 42712006年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,“成熟路由工作组关于路由襟翼阻尼的建议”,成熟378,2006年5月<http://www.ripe.net/ripe/docs/ripe-378>.

9.2. Informative References
9.2. 资料性引用

[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-BGP回顾年”,2006年12月52日<http://meetings.ripe.net/ripe-52/presentations/ ripe52全体会议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调查】Tsuchiya,S.,Kawamura,S.,Bush,R.,和C.Pelsser,“路线襟翼阻尼部署状态调查”,正在进行的工作,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,“协调路线襟翼阻尼参数的成熟路线工作组建议”,1998年2月,成熟路线178<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.,和R.Evans,“路线襟翼阻尼的成熟路线工作组建议”,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

Cristel Pelsser互联网倡议日本三井金宝町,千代田区神田金宝町1-105号,东京101-0051 JP

   Phone: +81 3 5205 6464
   EMail: cristel@iij.ad.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水晶泉班布里奇岛,华盛顿98110美国

   EMail: randy@psg.com
        
   EMail: randy@psg.com
        

Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US

美国加利福尼亚州圣何塞塔斯曼大道西170号凯尔帕特尔思科系统公司,邮编95134

   EMail: keyupate@cisco.com
        
   EMail: keyupate@cisco.com
        

Pradosh Mohapatra Sproute Networks 41529 Higgins Way Fremont, CA 94539 US

Pradosh Mohapatra Sproute Networks 41529 Higgins Way Fremont,加利福尼亚州,美国94539

   EMail: mpradosh@yahoo.com
        
   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
        
   Phone: +44 115 714 0042
   EMail: o@maennel.net