Re: Comments on draft-spagnolo-manet-ospf-design-00.txt

[Richard Ogier <ogier at EARTHLINK.NET>]

Madhavi W. Chandra wrote:

>
> Actually, our mechanism is flexible.  We have the ability to send
> all data in a Hello for k consecutive Hellos (persistently)...or only
> partial data in k consecutive Hellos (for example, neighbors that are
> being dropped)...or send data only in one Hello.  This coupled
> with the reply/request mechanism provides flexibility.
>
> Although we haven't been able to run simulations yet, its seems that
> sending data in k consecutive Hellos in a low-rate-of-change network is
> excessive.  So, it may not be the case that a flat 'send in k
> consecutive Hellos' is an optimum approach.

My first thought is that in a low-rate-of-change network, there
won't be many changes to report! So, reporting each (infrequent)
change in 3 consecutive Hellos would add very little overhead.
Even if there is one neighbor change per Hello, reporting
each change 3 times adds only about 8 bytes (2 router IDs) per Hello
(compared to reporting each change only once). However, we also have
to consider the probability that (in your Hello protocol) some
neighbors will not hear the Hello reporting the change and will
thus unicast a Hello request, which also results in a reply to
the request. Even if there are only 20 neighbors, and even if
only 10% of Hellos are missed, then on average 2 neighbors will
send a Hello request, which, being a separate unicast packet, would
result in much more overhead than 2 router IDs. Please correct me
if I am missing something.

[I should clarify that TBRPF does not report every neighbor change
3 (or k) times, but AT MOST 3 (or k) times. A node stops reporting
a neighbor change if it is clear the the neighbor already knows
about the change.]

I agree that your protocol can report each change
k times (persistently, with the N bit set), but you still
require the initial Hello (with the N bit NOT set) to be
received, so that doesn't help in terms of avoiding Hello
replies. Maybe you are now saying that your protocol can
report each change k times with the N bit NOT set, but your
draft does not mention that possibility. Perhaps a MAY or SHOULD
should be added to make the reader aware of this possibility.

The nice thing about the TBRPF Hello protocol is that it shows
that Hello replies are not needed. Unless simulations show
that using Hello replies results in a significant overhead
reduction, then it might be best to simplify the protocol
and omit Hello replies.

Richard