idnits 2.17.1 draft-jakma-mrai-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 322. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2008) is 5638 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: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing P. Jakma 3 Internet-Draft Sun Microsystems 4 Expires: April 24, 2009 October 21, 2008 6 Revised Default Values for the BGP 'Minimum Route Advertisement 7 Interval' 8 draft-jakma-mrai-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 24, 2009. 35 Abstract 37 This document briefly examines what is known about the effects of the 38 BGP MRAI timer, particularly on convergence. It highlights published 39 work which suggests the MRAI interval as deployed has an adverse 40 effect on the convergence time of BGP. 42 It then recommends revised, lower default values for the MRAI timer, 43 thought to be more suited to today's Internet environment. 45 Table of Contents 47 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 48 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1. The MRAI Timer . . . . . . . . . . . . . . . . . . . . . . 3 50 2.2. Known effects of the MRAI timer on convergence . . . . . . 3 51 2.3. Interaction with Flap-Damping . . . . . . . . . . . . . . . 4 52 2.4. Current Status of the MRAI . . . . . . . . . . . . . . . . 4 53 3. Risk Evaluation in the Choice of MRAI Time . . . . . . . . . . 5 54 4. Recommended values for the MRAI . . . . . . . . . . . . . . . . 5 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 60 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 Intellectual Property and Copyright Statements . . . . . . . . . . 8 64 1. Requirements Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 2. Background 72 The proper functioning of the [BGP] routing protocol is of great 73 importance to the Internet. Issues regarding matters of its 74 stability and convergence have been documented widely, such as in 75 [BGP-STAB], [bgp-converge] and [Potaroo0607]. 77 One such issue is the effect of 'Minimum Route Advertisement 78 Interval' (MRAI). 80 2.1. The MRAI Timer 82 The Minimum Route Advertisement Interval (MRAI) timer is specified in 83 RFC4271 [BGP]. This timer acts to rate-limit updates, on a per- 84 destination basis. [BGP] suggests values of 30s and 5s for this 85 interval for eBGP and iBGP respectively. The MRAI must also be 86 applied to withdrawals according to RFC4271 [BGP], a change from the 87 earlier RFC1771. 89 Some implementations apply this rate-limiting on a per-peer basis, 90 presumably an adequate approximation. Some implementations apply it 91 to withdrawal methods (often called "WRATE" in the literature). Some 92 implementations do not apply MRAI at all. 94 2.2. Known effects of the MRAI timer on convergence 96 The MRAI timer serves to suppress messages which BGP would otherwise 97 send out to describe transitory states, and so allow BGP to converge 98 with significantly fewer messages sent. This beneficial effect of 99 the MRAI timer, in terms of # of messages, increases as the timer is 100 increased until an optimum value is reached, after which the 101 beneficial effect stabilises. [bgp-converge] [mrai-final] 103 In terms of convergence time, a similar beneficial effect is seen as 104 the MRAI increases to the same optimum value. However as the timer 105 value is increased past the optimum, the convergence time increases 106 again linearly - the scale of this increase is worse with WRATE. 107 [bgp-converge] [mrai-final] 109 The optimum MRAI timer value is dependent on several factors, most 110 particularly the topology in its layout and propagation times. The 111 optimum value will differ between different subsets of the Internet. 112 [mrai-final] 114 It is believed to be infeasible to try directly calculate this value. 115 However a useful approximation can be made from the diameter of the 116 topology if it is known, along with some assumptions about the the 117 topology, such as the latency between nodes. [mrai-internet] 119 The interaction between extensions to BGP designed to improve 120 convergence, such as those that allow propagation of additional 121 and/or backup paths, and the MRAI timer is as yet unknown. However, 122 it seems reasonable to speculate these extensions might have the 123 effect of leading to a lower optimum MRAI than would be indicated by 124 an approximation based on the diameter of the BGP topology. Further 125 work on these questions would be useful. 127 2.3. Interaction with Flap-Damping 129 As the MRAI helps eliminate some updates, it interacts with flap- 130 damping [BGP-DAMP]. The lower the MRAI timer, the greater the risk 131 of crossing below the threshold of the optimum value. If that 132 threshold is crossed, there will be an increased number of updates 133 somewhere within the BGP system, and hence an increased risk of paths 134 being dampened, which otherwise would not. 136 So, in presence of significant flap-damping deployment and given the 137 uncertainty of what the optimum is, it is reasonable to err towards 138 selecting a value of the MRAI timer significantly higher than the 139 optimum. 141 However, given that flap-damping increasingly is discouraged 142 [RIPE-378] in Internet routing, this particular need to be 143 conservative in the choice of MRAI timer value may be less important. 145 2.4. Current Status of the MRAI 147 The current recommended value of 30s may be far higher than is 148 optimal for the Internet, based on observations of certain parameters 149 related to its topology. In [mrai-final] it is suggested that the 150 optimal value may be between 5s ('semi-safe') to 15s ('safe'). The 151 estimation of the 'safe' value here is of no relevance if WRATE is 152 universally deployed, as in such a case the 'semi-safe' value and 153 'safe' value are the same. Further empirical work by the same 154 authors [mrai-internet] suggests that the optimal, Internet MRAI may 155 be below 5s. 157 Further, [BGP-STAB] and [Potaroo0607] argue that operational 158 conditions (e.g. different routers using different MRAI values) mean 159 the MRAI is having an adverse effect even on the number of messages 160 sent, and so further exacerbating convergence problems in the global 161 BGP system, such as path hunting. The [BGP-STAB] document goes 162 further still and argues that MRAI be deprecated in favour of some 163 better way of damping BGP UPDATES, however there are no clear 164 proposals before the IDR as of this writing for such changes to BGP. 166 3. Risk Evaluation in the Choice of MRAI Time 168 Though there is an optimum value for the MRAI, it's unlikely that it 169 can be determined empirically or otherwise for the general Internet. 170 It may even not be possible, as the optimum MRAI will differ for 171 different subsets of the Internet. Some degree of guesstimation at a 172 reasonable value for the MRAI is required, which is an exercise in 173 risk; whether to err towards fast convergence at the risk of a 174 disproportionate increase in BGP messaging, or to err to the side of 175 an optimal number of messages at the expense of convergence. 177 Arguably, economising on bandwidth and control-plane processing power 178 is today less important than the convergence time of BGP, than in 179 times past. Presuming this, any new recommendations for the MRAI 180 should seek to err slightly to the side of convergence, rather than 181 erring towards minimising BGP traffic. 183 Further, if we assume most implementations apply the MRAI to 184 withdrawals, then the Internet BGP topology effectively is WRATE- 185 enabled, and [mrai-final] suggests there is even less benefit to 186 erring toward a higher MRAI. 188 The most definite risk of lowering the MRAI is the increased risk of 189 flap-damping, if the value is set too much below the optimum. 190 Therefore, taking into account estimations of that optimum is 191 required. That said, at least one BGP implementation by default does 192 not apply any MRAI at all. 194 4. Recommended values for the MRAI 196 The suggested default values for the 197 MinRouteAdvertisementIntervalTimer given in RFC4271 [BGP] are hereby 198 revised to be 5s or less for eBGP connections, and 1s or less for 199 iBGP connections, for use on Internet topologies. 201 These values may not be suitable for topologies which differ from the 202 internet, be that in scale, arrangement or otherwise. Such non- 203 internet, BGP topologies very likely would have significantly lower 204 optimum values, assuming they are always significantly smaller in 205 scale than the Internet BGP topology. 207 5. IANA Considerations 209 There are no requests made to IANA in this document. 211 6. Security Considerations 213 This document raises no new security considerations. 215 7. Acknowledgements 217 The author would like to thank Manav Bhatia for his helpful review 218 and comments; as well as Robert Raszuk and Samita Chakrabarti for 219 their useful comments. 221 The authors of the cited documents are thanked for their 222 contributions to the understanding of BGP, of which this document is 223 a simple summary. 225 8. References 227 8.1. Normative References 229 [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 230 Protocol 4 (BGP-4)", RFC 4271, January 2006. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", RFC 2119, BCP 14, February 2001. 235 8.2. Informative References 237 [BGP-STAB] 238 Li, T. and G. Huston, "BGP Stability Improvements", 239 I-D draft-li-bgp-stability, June 2007. 241 [BGP-DAMP] 242 Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 243 Flap Damping", RFC 2439, November 1998. 245 [Potaroo0607] 246 Huston, G., "Damping BGP", June 2007, 247 . 249 [RIPE-378] 250 Smith, P. and P. Panigl, "RIPE RRG: Recommendations on 251 Route-flap Damping", May 2006, 252 . 254 [bgp-converge] 255 Griffin, T. and B. Premore, "An Experimental Analysis of 256 BGP Convergence Time", In Proceedings of ICNP pages 53-61, 257 November 2001, 258 . 260 [mrai-final] 261 Qiu, J., Hao, R., and X. Li, "An Experimental Study of the 262 BGP Rate-limiting Timer", Bell Labs Technical Memo ITD-03- 263 44604H, June 2003, 264 . 267 [mrai-internet] 268 Qiu, J., Hao, R., and X. Li, "The Optimal Rate-Limiting 269 Timer of BGP for Routing Convergence", IEICE TRANS. 270 Comm. Vol.E88-B, No. 4, April 2005, 271 . 273 Author's Address 275 Paul Jakma 276 Sun Microsystems 277 Springfield 278 Linlithgow, West Lothian EH49 7LR 279 Scotland 281 Phone: +44 1506 673150 282 Email: paul.jakma@sun.com 284 Full Copyright Statement 286 Copyright (C) The IETF Trust (2008). 288 This document is subject to the rights, licenses and restrictions 289 contained in BCP 78, and except as set forth therein, the authors 290 retain all their rights. 292 This document and the information contained herein are provided on an 293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 295 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 296 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 297 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 300 Intellectual Property 302 The IETF takes no position regarding the validity or scope of any 303 Intellectual Property Rights or other rights that might be claimed to 304 pertain to the implementation or use of the technology described in 305 this document or the extent to which any license under such rights 306 might or might not be available; nor does it represent that it has 307 made any independent effort to identify any such rights. Information 308 on the procedures with respect to rights in RFC documents can be 309 found in BCP 78 and BCP 79. 311 Copies of IPR disclosures made to the IETF Secretariat and any 312 assurances of licenses to be made available, or the result of an 313 attempt made to obtain a general license or permission for the use of 314 such proprietary rights by implementers or users of this 315 specification can be obtained from the IETF on-line IPR repository at 316 http://www.ietf.org/ipr. 318 The IETF invites any interested party to bring to its attention any 319 copyrights, patents or patent applications, or other proprietary 320 rights that may cover technology that may be required to implement 321 this standard. Please address the information to the IETF at 322 ietf-ipr@ietf.org.