idnits 2.17.1 draft-ietf-idr-rfd-usable-01.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 (December 17, 2012) is 4147 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: June 20, 2013 K. Patel 6 P. Mohapatra 7 Cisco Systems 8 O. Maennel 9 Loughborough University 10 December 17, 2012 12 Making Route Flap Damping Usable 13 draft-ietf-idr-rfd-usable-01 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 any 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 June 20, 2013. 51 Copyright Notice 53 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. RFD Parameters . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Suppress Threshold Versus Churn . . . . . . . . . . . . . . . . 5 72 5. Maximum Penalty . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 6 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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 experimental 98 measurements, this document recommends adjusting a few RFD 99 algorithmic constants and limits, with the result being damping of a 100 non-trivial amount of long term churn without penalizing well-behaved 101 prefixes' normal convergence process. 103 Very few prefixes are responsible for a large amount of the BGP 104 messages received by a router, see [huston2006] and [pelsser2011]. 105 For example, the measurements in [pelsser2011] showed that only 3% of 106 the prefixes were responsible for 36% percent of the BGP messages at 107 a router with real feeds from a Tier-1 and an Internet Exchange Point 108 during a one week experiment. Only these very frequently flapping 109 prefixes should be damped. The values recommended in Section 6 110 achieve this. Thus, RFD can be enabled, and some churn reduced. 112 The goal is to, with absolutely minimal change, ameliorate the danger 113 of current RFD implementations and use. It is not a panacea, nor is 114 it a deep and thorough approach to flap reduction. 116 3. RFD Parameters 118 The following RFD parameters are common to all implementations. Some 119 may be tuned by the operator, some not. 121 +-------------------------+----------+-------+---------+ 122 | Parameter | Tunable? | Cisco | Juniper | 123 +-------------------------+----------+-------+---------+ 124 | Withdrawal | No | 1000 | 1000 | 125 | Re-Advertisement | No | 0 | 1000 | 126 | Attribute Change | No | 500 | 500 | 127 | Suppress Threshold | Yes | 2000 | 3000 | 128 | Half-Life (min) | Yes | 15 | 15 | 129 | Reuse Threshold | Yes | 750 | 750 | 130 | Max Suppress Time (min) | Yes | 60 | 60 | 131 +-------------------------+----------+-------+---------+ 133 Default RFD Paramaters of Juniper and Cisco 135 Table 1 137 4. Suppress Threshold Versus Churn 139 By turning RFD back on with the values recommended in Section 6 churn 140 is reduced. Moreover, with these values, prefixes going through 141 normal convergence are generally not damped. 143 [pelsser2011] estimates that, with a suppress threshold of 6,000, the 144 BGP update rate is reduced by 19% compared to a situation without RFD 145 enabled. With this 6,000 suppress threshold, 90% fewer prefixes are 146 damped compared to use of a 2,000 threshold. I.e. far fewer well- 147 behaved prefixes are damped. 149 Setting the suppress threshold to 12,000 leads to very few damped 150 prefixes (1.7% of the prefixes damped with a threshold of 2,000, in 151 the experiments in [pelsser2011] yielding an average hourly update 152 reduction of 11% compared to not using RFD. 154 +---------------+--------------+-------------+----------------------+ 155 | Suppress | Damped | % of Table | Update Rate (one | 156 | Threshold | Instances | Damped | hour bins) | 157 +---------------+--------------+-------------+----------------------+ 158 | 2,000 | 43342 | 13.16% | 53.11% | 159 | 4,000 | 11253 | 3.42% | 74.16% | 160 | 6,000 | 4352 | 1.32% | 81.03% | 161 | 8,000 | 2104 | 0.64% | 84.85% | 162 | 10,000 | 1286 | 0.39% | 87.12% | 163 | 12,000 | 720 | 0.22% | 88.74% | 164 | 14,000 | 504 | 0.15% | 89.97% | 165 | 16,000 | 353 | 0.11% | 91.01% | 166 | 18,000 | 311 | 0.09% | 91.88% | 167 | 20,000 | 261 | 0.08% | 92.69% | 168 +---------------+--------------+-------------+----------------------+ 170 Damped Prefixes vs. Churn, from [pelsser2011] 172 Note overly-aggressive current default Suppress Threshold 174 Table 2 176 5. Maximum Penalty 178 It is important to understand that the parameters shown in Table 1, 179 and the implementation's sampling rate, impose an upper bound on the 180 penalty value, which we can call the 'computed maximum penalty'. 182 In addition, BGP implementations have an internal constant which we 183 will call the 'maximum penalty' which the current computed penalty 184 may not exceed. 186 6. Recommendations 188 The following changes are recommended: 190 Router Maximum Penalty: The internal constant for the maximum 191 penalty value MUST be raised to at least 50,000. 193 Default Configurable Parameters: In order not to break existing 194 operational configurations, BGP implementations SHOULD NOT change 195 the default values in Table 1. 197 Minimum Suppress Threshold: Operators wishing damping which is much 198 less destructive than current, but still somewhat aggressive 199 SHOULD configure the Suppress Threshold to no less than 6,000. 201 Conservative Suppress Threshold: Conservative operators SHOULD 202 configure the Suppress Threshold to no less than 12,000. 204 Calculate But Do Not Damp: Implementations MAY have a test mode 205 where the operator could see the results of a particular 206 configuration without actually damping any prefixes. This will 207 allow for fine tuning of parameters without losing reachability. 209 7. Security Considerations 211 It is well known that an attacker can generate false flapping to 212 cause a victim's prefix(es) to be damped. 214 As the recommendations merely change parameters to more conservative 215 values, there should be no increase in risk. 217 In fact, the parameter change to more conservative values should 218 slightly mitigate the false flap attack. 220 8. IANA Considerations 222 This document has no IANA Considerations. 224 9. Acknowledgments 226 Nate Kushman initiated this work some years ago. Ron Bonica, Seiichi 227 Kawamura, and Erik Muller contributed useful suggestions. 229 10. References 231 10.1. Normative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 237 Flap Damping", RFC 2439, November 1998. 239 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 240 Protocol 4 (BGP-4)", RFC 4271, January 2006. 242 [mao2002] Mao, Z. M., Govidan, R., Varghese, G., and Katz, R., 243 "Route Flap Damping Excacerbates Internet Routing 244 Convergence", In Proceedings of SIGCOMM , August 2002, . 248 [pelsser2011] 249 Pelsser, C., Maennel, O., Mohapatra, P., Bush, R., and 250 Patel, K., "Route Flap Damping Made Usable", Passive and 251 Active Measurement (PAM), March 2011, 252 . 254 [ripe378] Panigl, P. and Smith, P., "RIPE Routing Working Group 255 Recommendations On Route-flap Damping", 2006, 256 . 258 10.2. Informative References 260 [I-D.shishio-grow-isp-rfd-implement-survey] 261 Tsuchiya, S., Kawamura, S., Bush, R., and C. Pelsser, 262 "Route Flap Damping Deployment Status Survey", 263 draft-shishio-grow-isp-rfd-implement-survey-05 (work in 264 progress), June 2012. 266 [huston2006] 267 Huston, G., "BGP Extreme Routing Noise", RIPE 52 , 2006, < 268 http://meetings.ripe.net/ripe-52/presentations/ 269 ripe52-plenary-bgp-review.pdf>. 271 [ripe178] Barber, T., Doran, S., Karrenberg, D., Panigl, C., and 272 Schmitz, J., "RIPE Routing-WG Recommendation for 273 Coordinated Route-flap Damping Parameters", 2001, 274 . 276 Authors' Addresses 278 Cristel Pelsser 279 Internet Initiative Japan 280 Jinbocho Mitsui Buiding, 1-105 281 Kanda-Jinbocho, Chiyoda-ku, Tokyo 101-0051 282 JP 284 Phone: +81 3 5205 6464 285 Email: cristel@iij.ad.jp 286 Randy Bush 287 Internet Initiative Japan 288 5147 Crystal Springs 289 Bainbridge Island, Washington 98110 290 US 292 Phone: +1 206 780 0431 x1 293 Email: randy@psg.com 295 Keyur Patel 296 Cisco Systems 297 170 W. Tasman Drive 298 San Jose, CA 95134 299 US 301 Email: keyupate@cisco.com 303 Pradosh Mohapatra 304 Cisco Systems 305 170 W. Tasman Drive 306 San Jose, CA 95134 307 US 309 Email: pmohapat@cisco.com 311 Olaf Maennel 312 Loughborough University 313 Department of Computer Science - N.2.03 314 Loughborough 315 UK 317 Phone: +44 115 714 0042 318 Email: o@maennel.net