Mailing List Archive

Aggressive route flap dampening
Can aggressive route flap dampening replace the need for /19 prefix filtering?
For instance, could the old Class C space be filtered on the /24 boundary
if this sort of flap dampening was put in place? Here is Paul Ferguson's
comments from the pagan mailing list:

>Again, I mention the fact that aggressive route-flap dampening
>could be used in the place of prefix length traffic filters, but
>someone/something needs to educate the latter group to implement
>a less draconian method of protecting themselves from misbehaving
>announcements. If I am not remiss, the predominate reasoning for
>filtering on /19's and longer was an assumption that smaller
>announcements were responsible for the majority of the routing
>instability, and that simply blocking these announcements at
>an arbitrary prefix length would be the simplest way to 'fix'
>the problem. This may be true, but an alternate method of
>approach for this problem could solve all of this squabbling
>once and for all, at least in regard to this issue.

********************************************************
Michael Dillon voice: +1-415-482-2840
Senior Systems Architect fax: +1-415-482-2844
PRIORI NETWORKS, INC. http://www.priori.net

"The People You Know. The People You Trust."
********************************************************
Re: Aggressive route flap dampening [ In reply to ]
Michael,
I believe the primary purpose of the /19 filtering was to reduce the
size of the route table. The increased stability this caused was just
a happy side affect.


>
> Can aggressive route flap dampening replace the need for /19 prefix filtering?
> For instance, could the old Class C space be filtered on the /24 boundary
> if this sort of flap dampening was put in place? Here is Paul Ferguson's
> comments from the pagan mailing list:
>
> >Again, I mention the fact that aggressive route-flap dampening
> >could be used in the place of prefix length traffic filters, but
> >someone/something needs to educate the latter group to implement
> >a less draconian method of protecting themselves from misbehaving
> >announcements. If I am not remiss, the predominate reasoning for
> >filtering on /19's and longer was an assumption that smaller
> >announcements were responsible for the majority of the routing
> >instability, and that simply blocking these announcements at
> >an arbitrary prefix length would be the simplest way to 'fix'
> >the problem. This may be true, but an alternate method of
> >approach for this problem could solve all of this squabbling
> >once and for all, at least in regard to this issue.
>
> ********************************************************
> Michael Dillon voice: +1-415-482-2840
> Senior Systems Architect fax: +1-415-482-2844
> PRIORI NETWORKS, INC. http://www.priori.net
>
> "The People You Know. The People You Trust."
> ********************************************************
>
>

--
Rusty

---------------------------------------------------------------------
| MCI Communications rusty@mci.net |
| Internet MCI note the Reply-to |
| PGP Key: DB183CA5 |
---------------------| http://infopage.mci.net |---------------------
Re: Aggressive route flap dampening [ In reply to ]
| Can aggressive route flap dampening replace the need for /19 prefix filtering?
| For instance, could the old Class C space be filtered on the /24 boundary
| if this sort of flap dampening was put in place?

In an abstract fashion filtering is the ultimate in aggressive
flap dampening. Dampening, extreme or not, is a form of routing
announcement settlement: a prefix+path is given N flaps per time period,
with a (theoretically) understood value for N depending on where
in the unicast address space and how much of the space is covered.

I have explained a couple ideas for adjusting the "N" above
based on a cost + profit charging scheme. Fundamentally, if you
want to have less stringent antidampening applied to your prefix(es),
you pay money. If you don't want to pay money then you do the
normal things: keep very stable or aggregate into a stable block.

The "N" should be reduced (or the time period lengthened) and the
cost of increasing that ratio should increase with the length of
the prefix, in order to encourage topologically sound aggregation
either through traditional means or through NAT and NAT-like boxes
such as the one described and implemented by Paul Vixie.

The point at which the price of increasing "N" becomes infinite
would be up to the marketplace based on available and deployed
technology. Whether or not /24s or /25s or /26s could be seen
in the important parts of the Internet was the topic of a series
of long arguments during walks along some beaches in Southern
California somoe time ago. Some say categorically no, that is,
you could never guarantee universal reachability for very long
prefixes indefinitely. On the other hand, a model which allows
for flexible adjustment of dampening policy applied against specific
chunks of address space is very attractive, and seems tractable.

Micropayments accompanying NLRI, with payees being attached to
prefix announcements much in the same way BGP community attributes
are, is an attractive scheme for me. It would then be up to various
providers to adjust dampening policy based on these payment attributes
much as routing announcement policies are adjusted. (cf RFC 1997-1998)

There are bookkeeping difficulties involved that should be familiar
to most telephone companies who do international settlements, but
which may be perceived as challenging to small fry used to
an environment with no settlements, and annoying to people who are
unusued to debugging flappy networks.

(One could also think of this as a small fee for the equivalent
of typing "clear ip bgp damp prefix mask" at routers, which think
should already be charged for.)

There are other (mostly bilateral) flap-settlement/dampening-modification
schemes which have been talked about here and there (piara comes to mind),
but the micropayments scheme has the advantages that the footwork needs
to be done by the announcers longer prefixes to determine whether they
want or need to pay particular providers for having their routes remain
visible (or be visible at all).

In other words, this is an easy way of making it *possible* to announce
even /32s nearly globally, although doing so obviously could be very expensive
and certainly would involve determining which of the potentially
large numbers of networks would need to be paid to make the /32s
in question reachable in their routing domains.

[long prefix]
| >announcements were responsible for the majority of the routing
| >instability, and that simply blocking these announcements at
| >an arbitrary prefix length would be the simplest way to 'fix'
| >the problem.

It fixed two problems simultaneously: firstly, there is lots of flap
and flap is most irritating when relatively unimportant (and statistically
small is likely to be less important than large) NLRI is responsible for
a disproportionally large amount of it. Secondly, there are lots of
networks which really ought to be aggregated. When a single up/down or
up/down/up flap makes the network unusable for an hour or two, people
generally become motivated either to be very very stable or to aggregate
even adjacent aggregatable /24s in order to suffer fewer disconnectivities.

| >This may be true, but an alternate method of
| >approach for this problem could solve all of this squabbling
| >once and for all, at least in regard to this issue.

Sure. It's a race between the potential buckets of revenues
in getting a flap/route settlement scheme in place in the face
of people screaming who have long prefixes and unstable networks --
in a sense _charging for the consumption of a currently scarce resource_ --
and eliminating the scarcity by doing aggressive large scale
involuntary NAT on one's peers (or customers or both), aggressive
proxy aggregation, and the like.

Sean.
Re: Aggressive route flap dampening [ In reply to ]
| Michael,
| I believe the primary purpose of the /19 filtering was to reduce the
| size of the route table. The increased stability this caused was just
| a happy side affect.

This matches my memory.

I believe filtering predated the implementation of flap dampening
in IOS, but I could be wrong.

The idea of using very strict dampening as a means of accomplishing
the same goals as filtering was a later development, and came with
the expectation of crunchy routers being able to handle large stable
routing tables and distribute and process large amounts of NLRI in
reasonable amounts of time.

Sean.
Re: Aggressive route flap dampening [ In reply to ]
(I will not include Sean's comments here.)
I like what Sean has proposed here a great deal, even with the dificulties
it may introduce. Interestingly, some of the PI/PA multihome arguement goes
away with this scheme. If you want a PA multihome, you pay for the more
specific of the PA block and for teh advertisements of the other blocks. If
you damp the longer prefix, the PA block will still work. If you are stable
but the PA block above you flaps, you are still OK as long as they don't
cause you to flap (which would be fairly likely.)

I can see no disadvantage to this over PI blocks other than renumbering.
Either way you pay to get the undamped advertisement.

jerry
Re: Aggressive route flap dampening [ In reply to ]
Sean's scheme is quite interesting, but it violates one of my
test rules: "Never attempt to change society when you can
change technology to achieve the same result".

For one, i do not see any practical way to introduce the
micropayment based routing anytime soon.

Second, if and when it'll be introduced, an alternative
technology for scalable routing will become available.
Guess which one will win.

--vadim
Re: Aggressive route flap dampening [ In reply to ]
smd@clock.org (Sean M. Doran) writes:

> The "N" should be reduced (or the time period lengthened) and the
> cost of increasing that ratio should increase with the length of
> the prefix, in order to encourage topologically sound aggregation
> either through traditional means or through NAT and NAT-like boxes
> such as the one described and implemented by Paul Vixie.

Here's where we part company. Varying the 'charge', either monetary or in
flap penalty creates an incorrect incentive: folks are incented to use a
shorter prefix. Note that this is distinct from aggregation in that they
may simply use a shorter prefix and not actually use more address space,
thus hurting netwide utilization.

The 'correct' incentive is a charge for flapping and a charge for
announcement. Both have real costs, directly traceable to processor and
memory costs.

> It fixed two problems simultaneously: firstly, there is lots of flap
> and flap is most irritating when relatively unimportant (and statistically
> small is likely to be less important than large) NLRI is responsible for
> a disproportionally large amount of it. Secondly, there are lots of
> networks which really ought to be aggregated. When a single up/down or
> up/down/up flap makes the network unusable for an hour or two, people
> generally become motivated either to be very very stable or to aggregate
> even adjacent aggregatable /24s in order to suffer fewer disconnectivities.

Note that both of these are 'fixed' without a length restriction: the per
prefix charge incents folks to aggregate. The per flap charge incents them
to stability. Direct cause and effect, without harmful side effects. ;-)

Tony