Re: OSPF WG Charter Proposal

[Rohit Dube <[e-mail]>]

Vishwas,

Some (final) comments inline -

On Thu, 7 Nov 2002 23:31:49 -0500 "Manral, Vishwas" writes:
=>Hi Rohit,
=>
=>> 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.
=>I disagree. Would you say pacing isn't essential, and you could do without
=>it? If so I think you may not be right there. It is known(atleast from what
=>I read) that not pacing can be very very dangerous to the network, and I
=>would prefer no one ventures without such mechanisms.

I am simply stating what I saw - unless you something different at the
same meltdown, there is nothing to disagree with!

=>
=>> 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 dont agree here either.
=>a) As Jerry stated earlier, a lot of these things have already been done in
=>a proprietry way by vendors. I would want to know how you feel having a
=>standard way would clutter the code while a non-standard way would not?

Yes. But then stretching the logic one would specify the use of data
structures and algorithms in an implementation.  OSPF could mandate
that everybody should use "splay trees".  And one could prove that
splay trees are better than say red-black and avl-trees using specific
simulation runs. This would make for a fine conference paper and
would qualify as  a "standard way of cluttering the code".

I don't see why the WG would be in this business.

=>b) I think we have made it clear that we do not intend to fiddle with the
=>protocol in the normal case, that is why we have not followed an approach of
=>basing the flooding on RTT unlike some other protocols.

This is not a compelling argument to add something to a protocol. For
any protocol spec - it is usually the case that protocol extensions, even
in the "non-normal" case effect "normal" processing. Often both in code
and in operations.

=>c) I think the matter has an operational requirement and there have been
=>implementations of it(although proprietry) for it, and if read your earlier
=>mail correctly these are a few things you said you are looking for before
=>expanding the charter.

This is correct. We would be looking for operational input to expand the
charter. This is a neccessary but not a sufficient condtion.

Regardless, something along these lines _could_ be included in a future
revision of the charter (say 6 months from now). Personally I am inclinded
towards clearing the deck off the listed charter items before adding
items whose inclusion doesn't have a clear consensus.

=>
=>Please let me know where you disagree.
=>
=>Thanks,
=>Vishwas

Regards,
--rohit.