Hi Zvezdelin, Thanks for your feedback. Appendix 3 was simply an example to show how the damping worked on a router. And yes, as you point out, the 30 minutes in the parameters is a typographical error. I checked the tests from when I did them and I did indeed use the recommended RIPE-229 parameters. So I agree, we should get that fixed although they do not impact the core recommendations at all. As for the implementations by different vendors, after much discussion, we chose not to mention vendor specific details in the main RIPE-229 document. Nor have we included any vendor specific configuration. However, the fact that JunOS penalises on withdraw and announce is noted in the configuration snippet that Juniper provided us with at http://www.golden-networks.net/. Maybe we should add for the Cisco and Foundry configs that those two implementations only penalise on withdraw. And finally, as wider comment to the rest of the working group, Christian and I would really welcome ideas on how we should, or if we should, do anything with RIPE-229. There has been recent discussion that route flap damping can be harmful, yet I still see several service providers using vendor defaults, or and yet more doing nothing at all. Hopefully we will have some time at next week's RIPE meeting to discuss this, so either drop us an e-mail, or come prepared to help with the discussion. thanks! philip -- At 10:40 27/04/2004 +0300, Zvezdelin Vladov wrote:

Dear All,

I would like to point to you a major mistake throughout this recomendation that might lead to unexpected results, if exactly following the proposed parameters in the RIPE-229.

Here they are:

1. At A3.1.1 it is said:

"A.3.1.1 For /24s

Parameters used are "set dampening 15 820 3000 30" 1st flap 1000 decay to 966, 982 at update 2nd flap 1966 decay to 1894, 1926 at update 3rd flap 2894 decay to 2787, 2846 at update 4th flap 3280 decay to 3165, 3226 at update"

Although the comment futher states:

"Maximum possible penalty is 3280 as defined by the flap parameters, so the penalty at the 4th flap was only incremented from 2787 to 3280, not 3787 as might have been expected. At the 4th flap the prefix was marked as being suppressed for 59 minutes when the update message was received. If the update after the 4th flap was not received within 4 minutes and 20 seconds, the penalty dropped below 3000, and the prefix was not suppressed."

Please note the first line after the A.3.1.1, it is said: "set dampening 15 820 3000 30" And actually it is spoken of dampening parameters such as: "set dampening 30 820 3000 60" Please note the "59 minutes" on the 4th row from the last comment, counting from above to the bootom of the paragpraph.

Configuring "15 820 3000 30" gives max penalty 3280, max suppresion time 30 minutes, instead of 60, which is in contradiction with the recomendations made at section 2. of the document. 2.2 Description of recommended damping parameter:

Basically the recommended values do the following with harsher treatment for /24 and longer prefixes:

* don't start damping until the 4th flap * /24 and longer prefixes: max=min outage 60 minutes

2. On the example configs actually given at http://www.golden-networks.net for the Cisco IOS config, the parameters for /24 are: "set dampening 30 820 3000 60", i.e. the correct values are in the config.

So, I suggest correcting this document.

One more suggestion is to note the standard dampening parameters for Cisco and Juniper, and especially the different penalty assigment policy - Cisco - on withdraw only, Juniper on withdraw AND readvertisement.

Zvezdelin Vladov

-- Zvezdelin Vladov Admin IP Network & Security Mobikom RTC Sofia Bulgaria AS8795 Ph:+359 2 9743804