Re: OSPF WG Charter Proposal

"Ash, Gerald R (Jerry), ALASO" <gash@ATT.COM> Thu, 07 November 2002 20:01 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 PAA08660 for <ospf-archive@LISTS.IETF.ORG>; Thu, 7 Nov 2002 15:01:21 -0500 (EST)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.007B8430@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 15:00:54 -0500
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330826 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 15:00:53 -0500
Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 15:00:53 -0500
Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gA7JwtLt023186 for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 7 Nov 2002 15:00:50 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B56050102234D; Thu, 7 Nov 2002 15:00:49 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic: OSPF WG Charter Proposal
Thread-Index: AcKGi8DilqBL5JahS+yzto+1AiJPogACU04A
Message-ID: <28F05913385EAC43AF019413F674A0170167B233@OCCLUST04EVS1.ugd.att.com>
Date: Thu, 07 Nov 2002 15:00:48 -0500
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Ash, Gerald R (Jerry), ALASO" <gash@ATT.COM>
Subject: Re: OSPF WG Charter Proposal
Comments: To: Rohit Dube <rohit@XEBEO.COM>
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA08660

Rohit,

> > The problem *was* in the flooding storm that was triggered 
> > in all the failures 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.

So we've both observed flooding storms and their bad effects.  They can be started in many different ways, but sometimes bring the network down and take hours or days to recover (that is the problem we want to solve).
 
> 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.

I certainly agree with you, Dave, Joel, Tony (thanks all!) that excellent implementation and testing is essential, and that adding complexity and more bugs surely isn't the goal.  I too have experience designing/testing/implementing new routing methods in large-scale applications, and well appreciate these points.  

Summary: We've identified a problem and the problem isn't solved entirely by good implementation/testing/operation, we feel some protocol extensions are necessary.

Thanks,
Regards,
Jerry