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