Re: OSPF WG Charter Proposal

Dave Katz <dkatz@JUNIPER.NET> Thu, 07 November 2002 06:09 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 BAA24837 for <ospf-archive@LISTS.IETF.ORG>; Thu, 7 Nov 2002 01:09:47 -0500 (EST)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007B6E0D@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 1:12:16 -0500
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 328277 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 01:12:15 -0500
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 01:12:15 -0500
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA76CFS89288 for <OSPF@DISCUSS.MICROSOFT.COM>; Wed, 6 Nov 2002 22:12:15 -0800 (PST) (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id gA76CEm66637; Wed, 6 Nov 2002 22:12:14 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net)
References: <28F05913385EAC43AF019413F674A01701B65690@OCCLUST04EVS1.ugd.att.com>
Message-ID: <200211070612.gA76CEm66637@cirrus.juniper.net>
Date: Wed, 06 Nov 2002 22:12:14 -0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: OSPF WG Charter Proposal
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: <28F05913385EAC43AF019413F674A01701B65690@OCCLUST04EVS1.ugd.att.com> (gash@ATT.COM)
Precedence: list

   Such failures are not the fault of the service provider operation or the vendor/equipment implementation.  They are due to shortcomings in the link-state protocols themselves -- thus the need for the enhancements proposed in the draft.

I strongly disagree with this statement.  While the design of the
protocols can make it challenging, there is ample room in
implementation to provide stable and scalable networks.

When a network collapses, the fault lies at the feet of the
implementors.  In every case I've seen (too many), the collapse was
inevitable sooner or later, due to naive design choices in software,
but at the same time was quite nonlinear in its onset (making any
predictive or self-monitoring approach pretty hopeless.)

There are some things that would make the job easier, at the cost
of additional complexity, but pointing at network collapses and blaming
the protocols is disingenuous.

--Dave