IETF Logo Mail Archive

Re: OSPF WG Charter Proposal

Rohit Dube <rohit@XEBEO.COM> Thu, 07 November 2002 18:27 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05318 for <ospf-archive@LISTS.IETF.ORG>; Thu, 7 Nov 2002 13:27:52 -0500 (EST)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.007B81A2@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 13:30:22 -0500
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330538 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 13:30:21 -0500
Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 13:30:21 -0500
Received: (qmail 20965 invoked from network); 7 Nov 2002 18:30:21 -0000
Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 7 Nov 2002 18:30:21 -0000
Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id NAA30968 for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 7 Nov 2002 13:30:21 -0500
X-Mailer: exmh version 2.1.1 10/15/1999
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <200211071830.NAA30968@bigbird.xebeo.com>
Date: Thu, 07 Nov 2002 13:30:21 -0500
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Rohit Dube <rohit@XEBEO.COM>
Subject: Re: OSPF WG Charter Proposal
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: Message from "Ash, Gerald R (Jerry), ALASO" <gash@ATT.COM> of "Thu, 07 Nov 2002 13:14:34 EST." <28F05913385EAC43AF019413F674A01701B6569F@OCCLUST04EVS1.ugd.att.com>
Precedence: list

Jerry,

On Thu, 7 Nov 2002 13:14:34 -0500 "Ash, Gerald R (Jerry), ALASO" writes:
[snip]
=>> The problem here is _not_ in the flooding.
=>
=>The problem *was* in the flooding storm that was triggered in all the failure
>s cited, and the inability to recover.

We may be talking about different incidents. The one that I was involved in,
was a clear implementation mistake (a case was missed) which was the root
cause. It should have been caught in testing if somebody had bothered to
look at why certain LSAs were being generated. The excessive flooding was
simply the result.

I couldn't say this better than Tony/Joel : "at a certain point adding
more code to an implementation introduces more bugs than the performance
gain is worth".  I (like most developers) can attest to this from first
hand experience.

Regards,
--rohit.

v2.23.0 | Report a Bug | By Email