Re: Draft of Route-Flap Dampening Paper

[Tony Barber <]

Curtis Villamizar wrote:
>
>
>This is not true.  If route flap damping is only applied to EBGP
>routes there are no problems except long secondary paths getting used.
>Some more specifics will be blocked in a few places and not in others
>and they will follow whatever route remains.  If all of the more
>specifics are lost an aggregate will be followed and either blackholed
>at the aggregator or it will get to the dest.
>
>I don't see any opportunity for routing loops.  I don't see any issue
>at all with less specifics being withdrawn and more specifics
>remaining as described above (I assume you meant the opposite).
>

Curtis

Maybe it is better to say that inconsistent routing can occur ?

>>     Further, after successful repair of the problem the access-provider can
>>     easily clear the flap-dampening for his customer on his local router
>>     instead of needing to contact upstream NOCs all over the Internet to get
>>     the dampening cleared.
>
>This would be an argument in favor of very aggressive damping of ones
>own customer routes which is unlikely to be a good idea.

Why,there should be no reason to do anything different on the customer access
point than is done on the inter ISP peerings.

>>     It was agreed that a recommendation from RIPE would be desirable.  Given
>>     that the current allocation policies are expected to hold for the
>>     foreseeable future, it was suggested that all /19's or shorter prefixes
>>     are not penalised harder than current Cisco default dampening does.
>>     
>>     Those suggestions in mind Tony Barber designed the following set of
>>     route-flap dampening parameters which have prooved to work smoothly in
>>     his environment for a couple of months.
>
>Why is a /24 being announced globally?  Our private peerings use a
>prefix taken from one of the provider's aggregates.
>

Normally that would be the case. In many multihomed scenarios there is a 
requirement *not* to aggregate this /24 (or whatever longer prefix)
This is why we should be seeing such small aggregates leaked out.

>The answer to this problem is to arrange things so the rest of the
>world doesn't need to know about a /24 that can be taken up and down
>by the software upgrade of a single router.  That's what route flap
>damping can encourage and it seems to have worked in this case except
>the message didn't register.
>

This isn't always possible Curtis :-(
Also remember that many of your customers do not want to renumber into your
PA, they may have class Bs for instance.


>> 3.2 Is dampening of customer route-flaps a good idea ?
>> 
>>     As already explained in section 1.3 flap-dampening is at its best value
>>     and most consistent and helpful if applied as near to the source of
>>     the problem as possible.  Therefore flap-dampening should not only be
>>     applied at peering boundaries but even more at customer boundaries !
>
>This is highly unreasonable.  Do you really expect to shut off peer
>route damping every where and ask [insert irresponsible and clueless
>ISP name here] to damp at the customer attachment?
>
>Don't damp the customer attachment.  Aggregate!
>

Yes, but it's not always going to achieve anything, see above. I think that
Christians assertion is highly reasonable. In an ideal world you would not
dampen but aggregate if the downstream is in your PA. If not you would
dampen. What is the best mode of attack and the gives consistency ?
This will be down to ISP opinion probably. In your last sentence you agree
with it :-?


>If the customer's connectivity gets hosed a few times, be very
>persistent in reminding them that renumbering into an aggregate is an
>option that will solve that problem.  Then the rest of the Internet
>has less flapping routes to damp.
>
>Curtis

I don't understand this last sentence as it seems to contradict your previous
paragraph re Aggregate!, sorry.

Regards

--Tony