Re: OSPF WG Charter Proposal

["Joel M. Halpern" <[e-mail]>]

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.

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.

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.

Yours,
Joel M. Halpern

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