Subject: Re: OSPF WG Charter Proposal

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 7 Nov 2002 23:31:49 -0500

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

Please let me know where you disagree.

Thanks,
Vishwas

---

From: Dave Katz <[email-masked]>
Date: Thu, 7 Nov 2002 23:51:42 -0800

Given that most of this stuff is not subject to standardization, it's
unlikely that there will be a "standard" way, for what that's worth.

The issue is whether the more complex stuff is worth doing, particularly
if the implementation is already robust enough to not collapse under load.

Actually, flooding based on RTT can certainly be done without "fiddling
with the protocol" (assuming that you mean a normative change.)  As long
as the packets look right, you can do a whole lot without torquing the
standard.

---

From: Rohit Dube <[email-masked]>
Date: Fri, 8 Nov 2002 11:55:49 -0500

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.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 8 Nov 2002 12:35:11 -0500

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

--
Acee