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