Re: OSPF WG Charter Proposal

["Manral, Vishwas" <[e-mail]>]

Hi Joel,

> There seem to be multiple things mixes together in this discussion,
> some of which are nicely separated in the draft below.

> One set of things are behaviors like pacing link start, pacing
> flooding, marking critical packets, etc.  These have a number
> of useful properties.  They improve the overall result without
> changing the basic mechanisms.  They do not introduce
> significant risk of interaction between mechanisms.
I agree totally.

> A second set of things mentioned are issues like hitless
> restart.  While these have more impact, they have benefits in a
> number of different regards, and can be evaluated on their own
> merits.

> Then there are manual mechanisms to help flooding in very meshy
> topologies.  While somewhat dangerous, these have proved
> necessary.  Because they are manual, they can be applied with
> sensitivity to their overall topology impact.
I agree here too.

> Then there are automatic information distribution change
> mechanisms. This covers such things as automatic area change
> and alternative flooding algorithms.  These are extremely dangers.
> They interact very strongly with the basic robustness mechanisms
> of OSPF.  They introduce significant additional complexity in
> many regards.  I strongly suggest that we stay away from any such
> behaviors, and ensure that our charter keeps us away from them.
I do agree stuff like area change etc would be dangerous. Could you point to
the section you are referring for this one? Besides the flooding algos
present in the draft as "Related Solution Methods" can be removed if they
are causing a problem. I do not think there is any mention to using the
methods, just methods used in other protocols that could help in this case.

Thanks,
Vishwas

At 08:27 AM 11/7/2002 -0500, Ash, Gerald R (Jerry), ALASO wrote:
>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-contro
l-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