Re: [Manet-dt] OLSRv2 NHDP comments

["Samita Chakrabarti" <[e-mail]>]

Catching up with the mails on this list...

Regarding a generic framework for MANET neighborhood discovery sounds
like a great idea. For naming, I'd say NHD or NHDP will be good
enough to distinguish itself from IPv6 ND protocol.

I hope for generic framework, the protocol would be a little simpler
with hooks for OLSRv2 and MANET for example. I am not quite
sure how it gets neighbor info from 2hops away since HELLO is
only for single hop. Is it the info on the second MANET interface
of the HELLO sender interface?  Also, the protocol seems a bit
complex with symmetric, assymtetric times and interfaces - perhaps
it's because it needs to support OLSRv2.
I wonder whether it can be simplified to deal with only MANET interfaces?

I assume, 2 hop restriction is because of OLSRv2 support as the nodes
are assumed to be multi-interfaced. Without that, it might be simple to
go for only link-local discovery of  MANET nodes. Is there any particular
advantage of knowing neighbors more than two hops away ?

Thanks,
-Samita



On 4/18/06, Ian Chakeres <[e-mail]> wrote:
> Name = NHDBB - Seems like NHD is an agreed upon acronym and BB is our
> acronym for  common building blocks. It ain't pretty, but it is there.
>
> HELLO - If people like HELLO, I can learn to like it.
>
> MIN_INTERVAL - Chris has given me the freedom to set MIN_INTERVAL
> arbitrarily small. So I'm ok with MUST.
>
> Is removing the 2-hop (limiting) statement important to anyone?
>
> Ian
>
> On 4/18/06, Dearlove, Christopher (UK) <[e-mail]> wrote:
> >
> > Thomas
> > > I feel that having an upper limit on the control traffic, which a
> > given
> > > protocol is able to generate, is very useful. Without restricting the
> > > interval between subsequent transmissions of HELLO messages, I could
> > > easily envision an implementation which would NOT be doing the right
> > > thing and end up eating all available bandwidth in a region.
> >
> > Agreed so far.
> >
> > > however I strongly believe that such MUST be imposed as a MUST.
> >
> > That doesn't totally convince me that SHOULD isn't acceptable. SHOULD
> > does after all mean something stronger than just "if you feel like it".
> >
> > However in one sense the argument is academic. A node may have a
> > minimum interval, and it may absolutely respect it. But if we allow
> > a node to set its own values (as discussed elsewhere) then the node
> > could set that interval to zero (or if zero isn't allowed, as close
> > to zero as makes no difference). And I can't see that we have the
> > knowledge to provide absolute constraints on the minimum interval.
> >
> > On that basis, I'm happy with MUST, as (assuming that a node's
> > parameters must be available in some sense - device documentation
> > for example if fixed) this gets most of the best of the two
> > (MUST/SHOULD) options.
> >
> >
> > ********************************************************************
> > This email and any attachments are confidential to the intended
> > recipient and may also be privileged. If you are not the intended
> > recipient please delete it from your system and notify the sender.
> > You should not copy it or use it for any purpose nor disclose or
> > distribute its contents to any other person.
> > ********************************************************************
> >
>
> _______________________________________________
> Manet-dt mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/manet-dt
>

_______________________________________________
Manet-dt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/manet-dt