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