idnits 2.17.1 draft-ietf-idr-rfd-usable-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 11, 2013) is 3812 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Pelsser 3 Internet-Draft R. Bush 4 Intended status: Standards Track Internet Initiative Japan 5 Expires: April 14, 2014 K. Patel 6 Cisco Systems 7 P. Mohapatra 8 Cumulus Systems, Inc. 9 O. Maennel 10 Loughborough University 11 October 11, 2013 13 Making Route Flap Damping Usable 14 draft-ietf-idr-rfd-usable-04 16 Abstract 18 Route Flap Damping (RFD) was first proposed to reduce BGP churn in 19 routers. Unfortunately, RFD was found to severely penalize sites for 20 being well-connected because topological richness amplifies the 21 number of update messages exchanged. Many operators have turned RFD 22 off. Based on experimental measurement, this document recommends 23 adjusting a few RFD algorithmic constants and limits, to reduce the 24 high risks with RFD, with the result being damping a non-trivial 25 amount of long term churn without penalizing well-behaved prefixes' 26 normal convergence process. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 32 be interpreted as described in RFC 2119 [RFC2119] only when they 33 appear in all upper case. They may also appear in lower or mixed 34 case as English words, without normative meaning. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 14, 2014. 53 Copyright Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 3. RFD Parameters . . . . . . . . . . . . . . . . . . . . . . . 3 73 4. Suppress Threshold Versus Churn . . . . . . . . . . . . . . . 4 74 5. Maximum Penalty . . . . . . . . . . . . . . . . . . . . . . . 4 75 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 81 10.2. Informative References . . . . . . . . . . . . . . . . . 6 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Suggested Reading 86 It is assumed that the reader understands BGP, [RFC4271] and Route 87 Flap Damping, [RFC2439]. This work is based on the measurements in 88 the paper [pelsser2011]. A survey of Japanese operators' use of RFD 89 and their desires is reported in 90 [I-D.shishio-grow-isp-rfd-implement-survey]. 92 2. Introduction 93 Route Flap Damping (RFD) was first proposed (see [ripe178] and 94 [RFC2439]) and subsequently implemented to reduce BGP churn in 95 routers. Unfortunately, RFD was found to severely penalize sites for 96 being well-connected because topological richness amplifies the 97 number of update messages exchanged, see [mao2002]. Subsequently, 98 many operators turned RFD off, see [ripe378]. Based on the 99 measurements of [pelsser2011], [ripe580] now recommends that RFD is 100 usable with some changes to the parameters. Based on the same 101 measurements, this document recommends adjusting a few RFD 102 algorithmic constants and limits, with the result being damping of a 103 non-trivial amount of long term churn without penalizing well-behaved 104 prefixes' normal convergence process. 106 Very few prefixes are responsible for a large amount of the BGP 107 messages received by a router, see [huston2006] and [pelsser2011]. 108 For example, the measurements in [pelsser2011] showed that only 3% of 109 the prefixes were responsible for 36% percent of the BGP messages at 110 a router with real feeds from a Tier-1 and an Internet Exchange Point 111 during a one week experiment. Only these very frequently flapping 112 prefixes should be damped. The values recommended in Section 6 113 achieve this. Thus, RFD can be enabled, and some churn reduced. 115 The goal is to, with absolutely minimal change, ameliorate the danger 116 of current RFD implementations and use. It is not a panacea, nor is 117 it a deep and thorough approach to flap reduction. 119 3. RFD Parameters 121 The following RFD parameters are common to all implementations. Some 122 may be tuned by the operator, some not. There is currently no 123 consensus on a single set of default values. 125 +-------------------------+----------+-------+---------+ 126 | Parameter | Tunable? | Cisco | Juniper | 127 +-------------------------+----------+-------+---------+ 128 | Withdrawal | No | 1000 | 1000 | 129 | Re-Advertisement | No | 0 | 1000 | 130 | Attribute Change | No | 500 | 500 | 131 | Suppress Threshold | Yes | 2000 | 3000 | 132 | Half-Life (min) | Yes | 15 | 15 | 133 | Reuse Threshold | Yes | 750 | 750 | 134 | Max Suppress Time (min) | Yes | 60 | 60 | 135 +-------------------------+----------+-------+---------+ 137 Default RFD Paramaters of Juniper and Cisco 139 Table 1 141 4. Suppress Threshold Versus Churn 143 By turning RFD back on with the values recommended in Section 6 churn 144 is reduced. Moreover, with these values, prefixes going through 145 normal convergence are generally not damped. 147 [pelsser2011] estimates that, with a suppress threshold of 6,000, the 148 BGP update rate is reduced by 19% compared to a situation without RFD 149 enabled. With this 6,000 suppress threshold, 90% fewer prefixes are 150 damped compared to use of a 2,000 threshold. I.e. far fewer well- 151 behaved prefixes are damped. 153 Setting the suppress threshold to 12,000 leads to very few damped 154 prefixes (1.7% of the prefixes damped with a threshold of 2,000, in 155 the experiments in [pelsser2011] yielding an average hourly update 156 reduction of 11% compared to not using RFD. 158 +-----------------+-----------------+-------------+-----------------+ 159 | Suppress | Damped | % of Table | Update Rate | 160 | Threshold | Instances | Damped | (one hour bins) | 161 +-----------------+-----------------+-------------+-----------------+ 162 | 2,000 | 43342 | 13.16% | 53.11% | 163 | 4,000 | 11253 | 3.42% | 74.16% | 164 | 6,000 | 4352 | 1.32% | 81.03% | 165 | 8,000 | 2104 | 0.64% | 84.85% | 166 | 10,000 | 1286 | 0.39% | 87.12% | 167 | 12,000 | 720 | 0.22% | 88.74% | 168 | 14,000 | 504 | 0.15% | 89.97% | 169 | 16,000 | 353 | 0.11% | 91.01% | 170 | 18,000 | 311 | 0.09% | 91.88% | 171 | 20,000 | 261 | 0.08% | 92.69% | 172 +-----------------+-----------------+-------------+-----------------+ 174 Damped Prefixes vs. Churn, from [pelsser2011]. Note overly- 175 aggressive current default Suppress Threshold 177 Table 2 179 5. Maximum Penalty 181 It is important to understand that the parameters shown in Table 1, 182 and the implementation's sampling rate, impose an upper bound on the 183 penalty value, which we can call the 'computed maximum penalty'. 185 In addition, BGP implementations have an internal constant which we 186 will call the 'maximum penalty' which the current computed penalty 187 may not exceed. 189 6. Recommendations 191 Use of the following values is recommended: 193 Router Maximum Penalty: The internal constant for the maximum 194 penalty value MUST be raised to at least 50,000. 196 Default Configurable Parameters: In order not to break existing 197 operational configurations, existing BGP implementations 198 including, the examples in Table 1, SHOULD NOT change their 199 default values. 201 Minimum Suppress Threshold: Operators wishing damping which is much 202 less destructive than current, but still somewhat aggressive 203 SHOULD configure the Suppress Threshold to no less than 6,000. 205 Conservative Suppress Threshold: Conservative operators SHOULD 206 configure the Suppress Threshold to no less than 12,000. 208 Calculate But Do Not Damp: Implementations MAY have a test mode 209 where the operator could see the results of a particular 210 configuration without actually damping any prefixes. This will 211 allow for fine tuning of parameters without losing reachability. 213 7. Security Considerations 215 It is well known that an attacker can generate false flapping to 216 cause a victim's prefix(es) to be damped. 218 As the recommendations merely change parameters to more conservative 219 values, there should be no increase in risk. 221 In fact, the parameter change to more conservative values should 222 slightly mitigate the false flap attack. 224 8. IANA Considerations 226 This document has no IANA Considerations. 228 9. Acknowledgments 230 Nate Kushman initiated this work some years ago. Ron Bonica, Seiichi 231 Kawamura, and Erik Muller contributed useful suggestions. 233 10. References 235 10.1. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, March 1997. 240 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 241 Flap Damping", RFC 2439, November 1998. 243 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 244 Protocol 4 (BGP-4)", RFC 4271, January 2006. 246 [mao2002] Mao, Z. M., Govidan, R., Varghese, G., Katz, R., "Route 247 Flap Damping Excacerbates Internet Routing Convergence", 248 In Proceedings of SIGCOMM , August 2002, . 252 [pelsser2011] 253 Pelsser, C., Maennel, O., Mohapatra, P., Bush, R., Patel, 254 K., "Route Flap Damping Made Usable", Passive and Active 255 Measurement (PAM), March 2011, 256 . 258 [ripe378] Panigl, P. Smith, P., "RIPE Routing Working Group 259 Recommendations On Route-flap Damping", 2006, 260 . 262 10.2. Informative References 264 [I-D.shishio-grow-isp-rfd-implement-survey] 265 Tsuchiya, S., Kawamura, S., Bush, R., and C. Pelsser, 266 "Route Flap Damping Deployment Status Survey", draft- 267 shishio-grow-isp-rfd-implement-survey-05 (work in 268 progress), June 2012. 270 [huston2006] 271 Huston, G., "BGP Extreme Routing Noise", RIPE 52 , 2006, 272 . 275 [ripe178] Barber, T., Doran, S., Karrenberg, D., Panigl, C., 276 Schmitz, J., "RIPE Routing-WG Recommendation for 277 Coordinated Route-flap Damping Parameters", 2001, 278 . 280 [ripe580] Pelsser, C., Bush, R., Maennel, O., Patel, K., Mohapatra, 281 P., Kuhne, M., Evans, R., "RIPE Routing-WG Recommendation 282 for Route-flap Damping", 2013, 283 . 285 Authors' Addresses 287 Cristel Pelsser 288 Internet Initiative Japan 289 Jinbocho Mitsui Buiding, 1-105 290 Kanda-Jinbocho, Chiyoda-ku, Tokyo 101-0051 291 JP 293 Phone: +81 3 5205 6464 294 Email: cristel@iij.ad.jp 296 Randy Bush 297 Internet Initiative Japan 298 5147 Crystal Springs 299 Bainbridge Island, Washington 98110 300 US 302 Email: randy@psg.com 304 Keyur Patel 305 Cisco Systems 306 170 W. Tasman Drive 307 San Jose, CA 95134 308 US 310 Email: keyupate@cisco.com 312 Pradosh Mohapatra 313 Cumulus Systems, Inc. 314 2672 Bayshore Parkway, Suite 515 315 Mountain View, CA 94043 316 US 318 Email: pmohapat@cumulusnetworks.com 320 Olaf Maennel 321 Loughborough University 322 Department of Computer Science - N.2.03 323 Loughborough 324 UK 326 Phone: +44 115 714 0042 327 Email: o@maennel.net