Re: withdrawal propagation (was E.E. Times?)

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

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

On Mon, 13 Jan 1997, William Allen Simpson wrote:
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!
Perhaps because this wasn't a bug?
And, bringing the operations closer to home: 5) Has CICnet installed the release?
Since you asked, yes. A long time ago.
Then, we will know if it was a Cisco problem....
Gee, and you where so quick to assign blame just a moment ago: "We _know_ (based on your research and Cisco's admission) that Cisco's have/had this bug. Therefore, it is at least Cisco's "fault"." Bill, what you're doing doesn't help. But since you are at it, why don't you help us out and define for us what _exactly_ the problem is and why it's happening? We are waiting with bated breath. -dorian

you forgot: 0) Is this a bug, does it cause any problem whatsoever? Jeff Young young@mci.net
From: "William Allen Simpson" <wsimpson@greendragon.com> Message-ID: <5605.wsimpson@greendragon.com> To: nanog@merit.edu Subject: Re: withdrawal propagation (was E.E. Times?) Sender: owner-nanog@merit.edu Content-Type: text Content-Length: 1074
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

0) Is this a bug, does it cause any problem whatsoever?
If I'm not mistaken, lots of routers have had performance problems caused by excessive rates of routing updates. Or did I misread various previous messages to this list?
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

excessive rates of bona fide routing updates *can* be a problem. it's called route flap. and we've got route flap dampening to reduce the scope of such events what we've been talking about very recently on this list is the high rate of withdrawls that have been seen. specifically, e.g., withdrawls from RouterA to RouterB for networks that RouterA never announced to RouterB. this is not a route flap .. it is just a superfluous withdrawl and causes no operational problems. however, some folks were tracking the number of withdrawls and didn't like the large number, so the vendor was informed and the code was changed. it's a good and appropriate thing that the behavior was changed, but that doesn't mean that it was a bug and doesn't mean that it was causing any problems /jws
0) Is this a bug, does it cause any problem whatsoever?
If I'm not mistaken, lots of routers have had performance problems caused by excessive rates of routing updates.
Or did I misread various previous messages to this list?
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

On Tue, 14 Jan 1997, John W. Stewart III wrote:
excessive rates of bona fide routing updates *can* be a problem. it's called route flap. and we've got route flap dampening to reduce the scope of such events
what we've been talking about very recently on this list is the high rate of withdrawls that have been seen. specifically, e.g., withdrawls from RouterA to RouterB for networks that RouterA never announced to RouterB. this is not a route flap .. it is just a superfluous withdrawl and causes no operational problems. however, some folks were tracking the number of withdrawls and didn't like the large number, so the vendor was informed and the code was changed. it's a good and appropriate thing that the behavior was changed, but that doesn't mean that it was a bug and doesn't mean that it was causing any problems
Can you specify the bug/fix number for Cisco so we all can check to see that we have it installed? -Hank
/jws
0) Is this a bug, does it cause any problem whatsoever?
If I'm not mistaken, lots of routers have had performance problems caused by excessive rates of routing updates.
Or didI misread various previous messages to this list?
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

On Tue, 14 Jan 1997, Jon Zeeff wrote:
0) Is this a bug, does it cause any problem whatsoever?
If I'm not mistaken, lots of routers have had performance problems caused by excessive rates of routing updates.
Those are not necessarily the same things. -dorian
participants (6)
-
Dorian R. Kim
-
Hank Nussbacher
-
Jeff Young
-
John W. Stewart III
-
jon@branch.net
-
William Allen Simpson