withdrawal propagation (was E.E. Times?)
John W. Stewart III
jstewart at metro.isi.edu
Mon Jan 13 20:07:16 UTC 1997
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
but when the behavior was discovered and cisco was told, they
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
> 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
> 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 at UMich.edu
> Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
> BSimpson at MorningStar.com
> Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
More information about the NANOG