Re: OSPF WG Charter Proposal

[Tony Przygienda <[e-mail]>]

Manral, Vishwas wrote:

>Hi Dave,
>
>   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.
>
>>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.
>>
>
>I agree and we did ponder over this approach. However from a previous note
>of urs, such failures are non-linear, and using the average RTT's prevents
>it from responding appropriately to such non-linear storms. Besides there
>are some other issues, I could discuss with you if you think the approach is
>worth pursuing.
>
>Thanks,
>Vishwas
>
Last one from me to the IMHO slightly over-excited crowd that tries to
protect
protocol-implementors and deployments from themselves by giving them
gratuitous
amounts of soaped rope (aka. congestion notification):

There is an Occam's razor to _routing protocol standardization_ (vs.
e.g. implementor agreements' or
recommendation group):

If you can't observe, quantify and prove it based purely on _white-box_
approach, you cannot
standardize it! Lots of the stuff you try to do is impossible to prove
on an implementation, e.g.
Hello priotization/congestion avoidance cannot be proven to work to your
desired specs
 unless you have probes into queues/CPU usage/link-loss
of a system. Summa, you cannot standardize it, you can only recommend it
via a BCP or maybe
informational draft. Compare this discussion to the bashing Naiming got
for the proposal of
optional time-stamps and hello sequence numbers on ISIS list (albeit it
was for my taste a
border case) [footnote: e.g. in contrast, Alex's LSA reorigination
spread or even timer jitters can be
measured and observed so there are certain recommendations that can be
'standardized' but
even then they are mostly just BCP].

I personally think any workgroup chair worth his salt will not let you
make this congestion avoidance thingy go into
anything close to a standards track, maybe informational but even then,
I think your stuff will
cause possibly more trouble than gain as a working group item in a
_protocol standardization_ working group.

And a tad more humility would help a long way as well instead of
claiming to save the world here,
lots of these stuff is research on shaky simulations following deployed
reality, I remember learning stuff
like hello priotization and much more from simulations and looking at
other people's code 1995 or so.  And
ultimately for all of us, lots of this stuff is known in theory of
non-linear control systems since quite a while, just most people
get scared by the math on the few first pages.

    thanks  & tony out

    -- tony