Re: OSPF WG Charter Proposal

"Ash, Gerald R (Jerry), ALASO" <gash@ATT.COM> Thu, 07 November 2002 13:25 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 IAA22416 for <ospf-archive@LISTS.IETF.ORG>; Thu, 7 Nov 2002 08:25:13 -0500 (EST)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.007B752B@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 8:27:39 -0500
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 329278 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 08:27:39 -0500
Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 08:27:39 -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 gA7DQeLs019553 for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 7 Nov 2002 08:27:39 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B560500FF1B9F; Thu, 7 Nov 2002 08:27:38 -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: AcKGJKSDPLqgP488Qqq6VGZ3CAKnOQANcfpQ
Message-ID: <28F05913385EAC43AF019413F674A0170167B229@OCCLUST04EVS1.ugd.att.com>
Date: Thu, 07 Nov 2002 08:27:38 -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: Dave Katz <dkatz@JUNIPER.NET>
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA22416

Dave,

> > 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
> implementers.  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.

I think you should review the ample evidence presented in http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt that the protocols need to be enhanced to better respond to congestion collapse:

- Section 2: documented failures and their root-cause analysis, across multiple service provider networks (also review the cited references)
- Appendix B: vendor analysis of a realistic failure scenario similar to one experienced as discussed in Section 2 (perhaps you would like to provide your own analysis of this scenario based on your OSPF implementation)
- Appendix C: simulation analysis of protocol performance (other I-D's being discussed provide analysis of proposed protocol extensions)

To say that network collapse in *every* case is due to *naive design choices* ignores the evidence/analysis presented.  Based on the evidence/analysis, there is clearly room for the protocols to be improved to the point where networks *never* go down for hours or days at a time (drawing unwanted headlines & business impact).

Jerry