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

["Madhavi W. Chandra" <mchandra at CISCO.COM>]

On Mon, Aug 16, 2004 at 09:50:55PM -0700, Richard Ogier wrote:
> 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 N bit is set to indicate that "the TLVs included in this
Hellos are being sent persistently...and there is more state
associated with this Hello that is not being sent persistently".  This
would be used to send partial-state persistently.  If you are sending
full state persistently (as in TBRPF), then you simply send the same
SCS number WITHOUT the N bit set for k number of times.  So, it's the
same behavior as TBRPF.  It DOES NOT depend on receiving the first
Hello with a certain SCS number.  I guess I thought it was implicit in
the draft, but I can surely clearly state it.

The Request/Reply mechanism gives you flexibility.  A Hello reply is
nothing more than a Full Hello.

-Madhavi

P.S.  By the way, isn't this a discussion that we should be having on
the Design Team?  I'm fine either way, but I thought that's why the
design team was formed.



> 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