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