one could claim that this wasn't a bug, but an optimization. that argument has legitimacy even if it's a bug, what is the result? an almost immeasurable impact on cpu. and, more importantly, absolutely no effect on route selection but when the behavior was discovered and cisco was told, they changed it so now it's up to the providers to deploy the code. if i were a provider, then i might deploy it if i had more than just this reason, but i very seriously doubt i would bounce a router for this feature alone .. it's just not worth it while i think it's a good thing in general to get rid of excessive withdrawls, i think this thread is a good example of us chasing numbers in statistics, purely for the sake of the numbers, without really thinking about their significance /jws
OK, I've read the article, and it's not very good. The author doesn't understand the terminology.
Never-the-less, this is supposed to be a cooperative operations group, and we should be doing some operations!
I've looked at the Cisco page, and a search on "BGP, withdrawals" does not find any mention of the bug fix release. So, I have some pointed questions!
1) What release fixes the problem?
2) Is the release free?
3) Where has Cisco announced the release?
And, bringing the operations closer to home:
4) Has Merit installed the release?
5) Has CICnet installed the release?
6) Has MCI installed the release?
7) Have all the peers at Ameritech NAP installed the release?
Once that is done, Craig will be able to see the effect of the bug fix at one NAP, and compare with other NAPs during the same time frame.
Then, we will know if it was a Cisco problem....
WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2