Hmmm....
So returning to the illustration Rodney gave Randy about the .foo
domain, are we saying that if the .foo domain's DNS is anycast,
then as (just from statistics of multiple paths) prefix flaps (as
opposed to flaps of individual paths) are going to be more likely [*],
route dampening adversely affects such (anycast) sources more than
straight unicast?
Or, looking at it the other way around, if in a heavily plural
anycast domain prefix route changes (as opposed to route changes
of individual paths) are more common than "normal" routes [*] (albeit
without - dampening aside - affecting reachability), does this mean
route dampening disproportionately harms such routes?
i.e. is the answer to Randy "because such networks [might] have
a higher tendency to use anycast.
* = note untested assumption
Alex
This would be an argument in favor of either asking peers to tag
anycast-learned routes no-export, as F-root does, or using anycast
prefixes which are short enough that they won't make it through many
people's filters, and advertising the aggregate from your tunnel-hub
(which is presumed to be stable), as we do.
I suspect that a stand-alone prefix, advertised with equal mask length
from all instances, without no-export, would be relatively more vulnerable
to dampening, as Alex suggests. Topologically, it appears little
different than a massively peered or massively multi-homed network of
any other sort, as the papers Randy is citing describe.
-Bill
What about the ccTLD prefixes? There are a lot more of them. And the
gTLDs? And exchange points? And Microsoft Update servers? Where do you
stop?
-Bill
Bill Woodcock <woody@pch.net> writes:
What about the ccTLD prefixes? There are a lot more of them. And the
gTLDs? And exchange points? And Microsoft Update servers? Where do you
stop?
If you simply don't dampen (hooray for adequate CPUs), then you are
not only honoring the "golden networks", you aren't setting yourself
up for annoyance.
---Rob
<snip>
Pay me to treat your prefixes more nicely? 1/2 
Isn't that the difference between transit and peering?
Does anyone dampen people who are paying them?
Some facts:
"RIPE" is an operator forum, comparable to NANOG, APRICOT, AFNOG, ....
(Strictly speaking RIPE pre-dates all of the others if one disregards
that NANOG started as the NSFnet regional network meetings. 
"RIPE NCC" is a Regional Internet Registry, comparable to ARIN, APNIC, LACNIC, AFRINIC, ....
(The RIPE NCC is the first of the regional registries.)
RIPE is the public forum where RIPE NCC policies and procedures are set;
they describe how the RIR allocates and assigns internet numbers.
RIPE NCC policies and procedures are *extremely* careful not to prescribe
any inter-domain routing practises and go out of their way to stress that
operators have the authority about that.
RIPE also makes general recommendations, which have nothing to do with the
RIPE NCC. The "golden networks" recommendations are in this category.
They are also just that: recommendations.
In article <20040906090324.GC3641@reifa.local>, Daniel Karrenberg <daniel.karrenberg@ripe.net> writes
RIPE NCC policies and procedures are *extremely* careful not to prescribe
any inter-domain routing practises and go out of their way to stress that
operators have the authority about that.
RIPE also makes general recommendations, which have nothing to do with the
RIPE NCC. The "golden networks" recommendations are in this category.
They are also just that: recommendations.
I think Rodney was worried that RIPE-NCC wasn't following the rule, which he thought odd if RIPE-NCC was part of RIPE. We've had several attempts, including yours just now, to debunk the latter.