Re: Draft of Route-Flap Dampening Paper

[Curtis Villamizar <]

In message <19970923205326.10979.qmail@localhost>, Tony Barber writes:
> 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 ?

Only if you can substantiate it.  Looks to me like alternate paths
would be used by some providers.  No big deal.

> >>     Further, after successful repair of the problem the access-provider ca
> n
> >>     easily clear the flap-dampening for his customer on his local router
> >>     instead of needing to contact upstream NOCs all over the Internet to g
> et
> >>     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.

For a direct customer we would disable dampenning completely.  If a
customer is part of an aggregate that is a purely local issue.  If
not, we'd expect to keep connectivity to our paying customer and only
enable damping if they requested it.  If others want to damp, we'd
just encourage our customer to number into an aggregate.  If they were
single homed then statics would be a consideration but we'd prefer the
customer was part of an aggregate.

> >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.

If the /24 flaps, that prefix had better be part of a larger
aggregate.  The two or more direct providers can agree to exchange the
/24 with little or no damping so the backup from the rest of the world
is to follow the aggregate.  The aggregator would then forward the
traffic to the working attachment.  When damping restrictions are
lifted, the path might just be more optimal.

Better yet, the /24 should **always** not be announced outside of some
aggregation boundary beyond which there would be no change in the path
regardless of which provider attachment was in use.  (ie: routing from
one continent to a multihome on another continent).

> >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.

Yep.  That's their choice.  When their /16 gets damped we can only
remind them that it was their choice.  We recommend that they dual
home their /16 to the same provider (us of course:) so they don't get
damped.  Since we got rid of the last of our Cisco routers in our
backbone very little route flap originates from ANS so that is a very
safe thing to do (of course some flap does come from ANS but if you
look at the AS paths you can see that the vast majority of it reflects
our redistributing flap we heard from transit customers).

> >> 3.2 Is dampening of customer route-flaps a good idea ?
> >> 
> >>     As already explained in section 1.3 flap-dampening is at its best valu
> e
> >>     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 :-?

I don't favor providing my customer consistency if that means no one
at all can reach them to be consistent with a number of providers on
another continnent not willing to put up with their prefix flapping.
I have yet to meet a customer that thought this would be a better way
to meet their needs.  I doubt other providers have.

> >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.

If the customer renumbers into a provider aggregate, then the rest of
the Internet has one less flapping prefix.  The customer prefix
disappears into the aggregate and is no longer part of the DFZ.

If this is a dual home across providers, then it's also OK for the
more specific to get damped as long as the providers can keep the more
specific from being damped.  If some subset of nearby providers can
manage not to announce the more specific beyond some boundary (and do
it reliably), then all the better.

Curtis