Dear Routing WG members, sorry for not having had the opportunity to participate in the last few meetings. I'm trying hard for the January meeting ! In the meantime let me initiate an e-mail discussion wrt route flap dampening (I'm appending the relevant part of the minutes of the Sept. meeting, where further discussion was requested). Recently, following a scheduled router-maintenance on an Ebone backbone router, I had problems to communicate with NORDUnet (haven't explicitely tried PIPEX ;-) from /24 networks for about 2 hours ! This reminded me of the "progressive route flap dampening" discussion, and increased my motivation for throwing my 0.02 EUROs into the routing-wg list: - I can't beleive that it's really necessary and reasonable to kill a network (regardless of prefix-length) for two hours if it's flapping twice maybe within half an hour but not more frequently within a month ! - Imagine you're SW-upgrading a router and (very unlikely, as we all know ;-} detect that you have to step back ... BINGO, it's perfectly and innocently electrocuted :-( - I'd suggest that dampening (regardless of prefix length) shouldn't start before AT LEAST three flaps are happening in a row (let's say within half an hour). - Dampening should lockout real network instabilities not make worse even scheduled maintenance ! - Besides, I know applications where it might be perfectly reasonable to announce a single *providerindependent* /24 and where it's contraproductive and politically incorrect to include it into an ISP aggregate ! A solution could be to ask Internic/RIPE to define "PI" address-ranges which can and should be excluded from the /24 hostility acts. Kind regards Christian ===== Following quoted from = = RIPE 25, Amsterdam = Routing Working Group = Report of Meeting, 23rd September 1996 = = [...] = =6. Progressive BGP route flap dampening = ftp://ftp.ripe.net/ripe/presentations/ripe-m25-tbarber-bgp-damp.html = = Tony Barber gave a presentation on the strategies used by = UUnet-Pipex to reduce the effects of route flapping and to = try to prevent router table overflow. These were: = = - route dampening = - prefix filtering = - more router memory = = They had encountered many instabilities from peers and found = that many ISPs had not deployed CIDR; this gave rise to more = flapping as more routes, and particularly more specific ones, = were advertised. = = Tony explained the parameters used for route dampening on a = Cisco router. He had arrived at the following re-use times = for various route sizes: = = /24 and greater ~160 minutes = /23 and /22 ~60 minutes = /21 and less ~30 minutes = = He recommended filtering out all prefixes more specific than /24. = = While route dampening consumed router memory, this was more or = less balanced by a reduction in routing CPU cycles. = = He recommended that if route dampening was to be widely = deployed in Europe, consistency was important. In this sense, = the Routing WG should agree on guidelines for parameters to = be used. = = In discussion, the following points were made: = = - aggregation works in reducing router load and route = flapping. = = - route flapping is often a feature of certain autonomous = systems rather than a function of prefix length. = = - much instability was due to configuration changes and = errors as distinct from link failures. = = - making dampening dependent on prefix length could = penalise many stable /24s. = = - it might be useful to discriminate against /24s in the = 192.0.0.0/8 block (the swamp). = = - the focus should be on keeping noise out of the system = rather than trying to mitigate against it once in the = system. = = In summary, it was agreed that route dampening was an = important topic and that more discussion was needed. = ===== End quote