<html><head></head><body bgcolor="#FFFFFF"><div>Joaquín, </div><div><br></div><div>Al pie de -todos- los correos de la lista tienes el enlace a través del cual te de-suscribes tu mismo.</div><div><br></div><div>Slds</div><div><br></div><div>Carlos<br><br>Sent from my iPad</div><div><br>On Jul 28, 2012, at 4:57 PM, Joaquin Emiliano Cortabarria <<a href="mailto:joaqquin@gmail.com">joaqquin@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div>POR FAVOR, NO QUIERO RECIBIR MAS E-MAILS DE ESTA LISTA.</div><div><br></div><div>GRACIAS</div><div><br></div><div><br></div><div><br></div><br clear="all"><br><br><div class="gmail_quote">2012/7/28 Christian O'Flaherty <span dir="ltr"><<a href="mailto:christian.oflaherty@gmail.com" target="_blank">christian.oflaherty@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">En la sesión de Lacnog en Mayo (Lacnic Quito) hubo una propuesta y una<br>
discusión en el micrófono sobre el uso de dampening.<br>
Yo sigo pensando que las experiencias no fueron buenas y por eso se<br>
dejó de usar...<br>
Me gustaría saber cuanto aporta nuestra región en ese "ruido" en la<br>
tabla global.<br>
Además, si nuestra región tuviera algún proveedor que tiene mucho<br>
route flap es mas facil trabajar con ese proveedor y resolverlo en<br>
lugar de proponer a todo el mundo que empiece a penalizar.<br>
Se podrá conseguir información sobre los ASs responsables?<br>
<br>
Christian<br>
<br>
On Thu, Jul 26, 2012 at 5:42 PM, Arturo Servin <<a href="mailto:aservin@lacnic.net">aservin@lacnic.net</a>> wrote:<br>
><br>
> No se si muchos de los operadores en LAC usen Route Flap Damping, pero para<br>
> los que lo usen esto puede ser interesante.<br>
><br>
> Slds<br>
> as<br>
><br>
> Begin forwarded message:<br>
><br>
> From: Rob Evans <<a href="mailto:rhe@nosc.ja.net">rhe@nosc.ja.net</a>><br>
> Subject: [routing-wg] Route flap damping considered usable<br>
> Date: 26 July 2012 10:11:10 GMT-03:00<br>
> To: <a href="mailto:routing-wg@ripe.net">routing-wg@ripe.net</a><br>
><br>
> All,<br>
><br>
> Those of you that were in Ljubljana will have seen Randy Bush's presentation<br>
> 'Route Flap Damping Made Useful.'<br>
><br>
> Based on the work behind this, Randy, Cristel Pelsser, Mirjam Kuehne and<br>
> myself have produced the following document which we'd like to publish as a<br>
> document of this working group. Please have a look and discuss on this<br>
> list.<br>
><br>
> I'd also like to remind you that we'll be meeting nine weeks from today in<br>
> Amsterdam at RIPE65. I should be allowed out for this meeting, so if you<br>
> have any suggestions for what you'd like to see on the working group's<br>
> agenda, please send it to Joao and myself via <<a href="mailto:routing-wg-chairs@ripe.net">routing-wg-chairs@ripe.net</a>>.<br>
><br>
> Hope you're having a good summer!<br>
><br>
> Rob<br>
><br>
><br>
> RIPE Routing Working Group<br>
> Recommendations on Route Flap Damping<br>
><br>
> Introduction<br>
><br>
> Route Flap Damping (RFD) [1] is a mechanism for BGP speaking routers<br>
> that penalises prefixes that exhibit a large number of updates<br>
> (‘flapping’), and suppresses a route when the accumulated penalty<br>
> exceeds a given threshold. The penalty decays over time until it<br>
> reaches a lower threshold at which point the route is unsuppressed.<br>
> RFD is intended to improve the overall stability of the Internet<br>
> routing table and reduce the load on BGP speaking routers. In<br>
> ripe-378 [2] it was stated that due to the dynamics of BGP, especially<br>
> a phenomenon called ‘path hunting,’ the default configurations of<br>
> flap damping can do more harm than good as it may suppress a prefix<br>
> after it has only flapped a few times. Consequently RFD was deprecated<br>
> due to the problem of over damping (see [2] for more details).<br>
><br>
> A small number of prefixes on the Internet continue to flap rapidly<br>
> and cause a disproportionate number of updates to BGP and load on<br>
> BGP speaking routers, this document uses experimental data gathered<br>
> from an operational environment to suggest changes to the RFD<br>
> parameters to suppress the prefixes that flap the most, while<br>
> minimising the suppression of other prefixes.<br>
><br>
> This document suggests parameters which would make RFD usable and<br>
> is based around the work of Cristel Pelsser, Olaf Maennel, Pradosh<br>
> Mohapatra, Randy Bush, and Keyur Patel presented at PAM2011[3].<br>
><br>
> History and Background<br>
><br>
> In the early 1990s the accelerating growth in the number of prefixes<br>
> being announced to the Internet (often due to inadequate prefix<br>
> aggregation), the denser meshing through multiple inter-provider<br>
> paths, and increased instabilities started to cause significant<br>
> impact on the performance and efficiency of some Internet backbone<br>
> routers. Every time a routing prefix altered state because of a<br>
> single line-flap, the withdrawal was advertised to the whole<br>
> BGP-Speaking Zone (BSZ) and handled by every router that carried<br>
> the full Internet routing table.<br>
><br>
> The load this processing placed on the control planes of routers<br>
> caused further instability as the routers were not able to process<br>
> other BGP updates or they dropped traffic transiting the device.<br>
> This could produce cyclic crashing behaviour.<br>
><br>
> To overcome this situation RFD was developed in 1993 and has since<br>
> been integrated into most router BGP software implementations. RFD<br>
> is described in detail in RFC 2439[1].<br>
><br>
> When RFD was first implemented in commercial routers, vendor<br>
> implementations had different default values and different<br>
> characteristics. As this inconsistency would result in different<br>
> rates of flap damping, and therefore introduce inconsistent path<br>
> selection and behavior that was hard to diagnose, the operator<br>
> community introduced a consistent set of recommendations for flap<br>
> damping parameters, so that ISPs deploying RFD would treat flapping<br>
> prefixes in the same way.<br>
><br>
> This call for consistency resulted in the RIPE Routing Working Group<br>
> producing first ripe-178, then ripe-210, and finally the ripe-229<br>
> documents [2a]. The parameters documented in ripe-229 were considered,<br>
> at time of publication in 2001, the best current practice. In 2006,<br>
> this was reviewed again and resulted in ripe-378 [2] which recommended<br>
> to disable RFD because it created more harm than good.<br>
><br>
> Analysis<br>
><br>
> In the work by Pelsser et al [3], it is shown that 3% of all prefixes<br>
> cause 36% of BGP updates, and just 0.01% of the prefixes cause 10%<br>
> of the BGP updates. The aim is to only penalise those prefixes<br>
> with excessive numbers of updates.<br>
><br>
> The default values used in current implementations of RFD apply a<br>
> penalty of 1000 each time a route flaps, and suppresses the prefix<br>
> when the penalty exceeds a figure in the region of 2000 (Cisco IOS)<br>
> or 3000 (Juniper JunOS).<br>
><br>
> The table shows the percentage of prefixes above the suppress<br>
> threshold and the percentage reduction in BGP churn for various<br>
> values of suppress threshold. The current default suppress value<br>
> of 2000 reduces BGP churn by 47%, but it suppressed 14% of the<br>
> prefixes at some point over the lifetime of the experiment.<br>
> Significantly larger values of suppress threshold such as 12000,<br>
> 15000 or 18000 still reduced BGP churn, but suppressed far fewer<br>
> prefixes which it is believed reduces the risk of penalising otherwise<br>
> well-behaved prefixes.<br>
><br>
> Suppress % prefixes % reduction in BGP churn<br>
> Threshold suppressed compared with no damping<br>
> 2000 14 47<br>
> 4000 4.2 26<br>
> 6000 2.1 19<br>
> 12000 0.63 11.26<br>
> 15000 0.44 9.51<br>
> 18000 0.32 8.12<br>
><br>
><br>
> Recommendations<br>
><br>
> In order to punish the biggest offenders - those prefixes that flap<br>
> the most – yet without punishing others, the RIPE Routing-WG<br>
> recommends vendors raise the maximum suppress threshold in router<br>
> implementations to 50,000 and operators configure a suppress threshold<br>
> value of at least 6,000. The vendors might also change the default<br>
> suppress threshold to 6,000. But this might surprise operators who<br>
> use the defult.<br>
><br>
> This has a number of advantages:<br>
> • it is easy to implement<br>
> • it will reduce the churn compared to the situation we have<br>
> now where no RFD is applied<br>
> • it spares the smaller offenders.<br>
><br>
> Changing the default suppress threshold could result in an increase<br>
> in forwarding table size or announcement rate for operators who use<br>
> RFD with the default settings. This warrants further discussion.<br>
><br>
> References<br>
> [1] Curtis Villamizar, Ravi Chandra, Ramesh Govindan<br>
> RFC2439: BGP Route-flap Damping (Proposed Standard)<br>
> <<a href="ftp://ftp.ietf.org/rfc/rfc2439.txt" target="_blank">ftp://ftp.ietf.org/rfc/rfc2439.txt</a>><br>
> [2] Most recent RIPE Document<br>
> <<a href="ftp://ftp.ripe.net/ripe/docs/ripe-378.txt" target="_blank">ftp://ftp.ripe.net/ripe/docs/ripe-378.txt</a>><br>
><br>
> [2a] Older RIPE Documents<br>
> <<a href="ftp://ftp.ripe.net/ripe/docs/ripe-178.txt" target="_blank">ftp://ftp.ripe.net/ripe/docs/ripe-178.txt</a>><br>
> <<a href="ftp://ftp.ripe.net/ripe/docs/ripe-210.txt" target="_blank">ftp://ftp.ripe.net/ripe/docs/ripe-210.txt</a>><br>
> <<a href="ftp://ftp.ripe.net/ripe/docs/ripe-229.txt" target="_blank">ftp://ftp.ripe.net/ripe/docs/ripe-229.txt</a>><br>
><br>
> [3] Cristel Pelsser, Olaf Maennel, Pradosh Mohapatra, Randy Bush<br>
> and Keyur Patel. "Route Flap Damping Made Usable". PAM 2011, March<br>
> 2011.<br>
> <<a href="http://www.iij-ii.co.jp/en/lab/researchers/cristel/publications/Pelsser-RFD-PAM2011.pdf" target="_blank">http://www.iij-ii.co.jp/en/lab/researchers/cristel/publications/Pelsser-RFD-PAM2011.pdf</a>><br>
><br>
> [4] Zhouqing Mao, Ramesh Govindan, George Varghese, Randy Katz<br>
> Route-flap Damping Exacerbates Internet Routing Congerence SIGCOMM 2002<br>
> <<a href="http://www.eecs.umich.edu/~zmao/Papers/sig02.pdf" target="_blank">http://www.eecs.umich.edu/~zmao/Papers/sig02.pdf</a>><br>
><br>
> [5] Randy Bush, Tim Griffin, Zhouqing Mao Route-flap Damping: Harmful?<br>
> NANOG 26<br>
> <<a href="http://www.nanog.org/mtg-0210/ppt/flap.pdf" target="_blank">http://www.nanog.org/mtg-0210/ppt/flap.pdf</a>><br>
><br>
> [6] Craig Labovitz, Abha Ahuja, Abhijit Bose, Farnam Jihanian<br>
> Delayed Internet Routing Convergence<br>
> SIGCOMM 2000<br>
> <<a href="http://www.acm.org/sigs/sigcomm/sigcomm2000/conf/paper/sigcomm2000-5-2.pdf" target="_blank">http://www.acm.org/sigs/sigcomm/sigcomm2000/conf/paper/sigcomm2000-5-2.pdf</a>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> LACNOG mailing list<br>
> <a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br>
> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
><br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
</blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>LACNOG mailing list</span><br><span><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a></span><br><span><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a></span><br></div></blockquote></body></html>