Re: OSPF WG Charter Proposal

[Acee Lindem <[e-mail]>]

Vishwas, Rohit,

I'm in complete agreement with Rohit on the issue of
adding alternate flooding techniques to the charter.
We really need to clean up some of the pending work
items as our top priority. I feel it is alright to
discuss flooding changes but we really don't have
a strong enough requirement to add them to the charter.
Note that we currently have a draft which reduses LSA
refresh overhead using the OSPF demand circuit extensions.

With respect to specification and Internet Drafts that are
targeted as standards track, I would like to maintain
the same high quality of specification as previous OSPF
WG documents (such as RFC 2328). Hence, if we were to decide
to standardize a different flooding mechanism, any drafts
should specify precisely protocol state machine changes,
packet transmission changes, packet reception changes,
precisely when flooding will be blocked, etc.
IMHO, we should not place loose recommendations in the
standards track category.

Thanks,
Acee


Rohit Dube wrote:
> 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.
>


--
Acee