Another aspect is that progressive damping might increase the awareness of aggregation needs, however, it has to be accompanied by a careful design which does not force a rush to request and assign more address space than needed. 1.5 Aggregation versus damping Of course, if a customer is just using Provider Aggregatable addresses, the aggregating upstream provider doesn't need to apply damping on these prefixes towards his customer, because instabilities of such prefixes wouldn't propagate into the Internet. However, if a customer insists on announcing prefixes which can't be aggregated by its provider, damping should be applied for the reasons given in Section 1.4. Even though damping is strongly recommended, in some cases it may make sense to exclude certain networks or even individual hosts from damping. This is especially true if damping would cut off the access to vital infrastructure elements of the Internet.
Most prominent examples are root name servers.
At least in principle, there should be enough redundancy for root name servers. We might consider this for a new version of the recommendation. Still, these must be exceptions resulting from strong needs - the rule should be to apply coordinated route flap damping throughout. It was agreed that a recommendation from RIPE would be desirable. Those suggestions in mind, Tony Barber designed the following set of route-flap damping parameters which have proved to work smoothly in his environment for a couple of months.