Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009

[teco at inf-net.nl]

OK, I am looking forward to an updated NHDP document, that
better specifies when to include an address. And the handling
of duplicate addresses on distinct media.

I think there is at a minimum a need for a single address, this
is the identifier. I do not see a reason for other addresses,
and these secondary may be anycast addresses and NHDP can't have
knowledge of this. So adding these secondary addresses is dangerous.
What was the reason for _all addresses_? Smooth handling of updated
addresses (e.g. RFC4941)? For OLSR?
If it was for OLSR, the secondary addresses are in TC messages
also, why adding it in NHDP?

Let us not mix up anycast with multicast. I think multicast
addresses has little to do with this discussion.

Teco.


|-----Oorspronkelijk bericht-----
|Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove at baesystems.com]
|Verzonden: vrijdag 18 september 2009 11:38
|Aan: Justin Dean; Thomas Heide Clausen; Teco Boot; Henning Rogge;
|manet at ietf.org
|Onderwerp: RE: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th
|2009
|
|First, my apologies, I'm going to just drop a couple of comments,
|then won't see any responses for a week.
|
|> Metrics are not currently part of NHDP the way you might be thinking.
|There
|> are up threshold/metric concepts along with state machines which
|dictate
|> behavior with regard to these and bringing links up and down but there
|is no
|> prebuilt way for calculating these link metrics.  I believe that
|OLSRv2 will
|> have some method of doing this (easily done on a two hop basis with
|> packetbb/NHDP methods)
|
|See the latest version of draft-dearlove-olsrv2-metrics for how
|we are planning to add metrics to OLSRv2, including to HELLO
|messages. Fundamentally we report direct and best metrics to an
|address, the latter possibly using another link. But this is
|OLSRv2, not NHDP. Other users of MHDP may not need metrics, and
|thus should not be burdened with them.
|
|We are working on the addrssing issue. Basically, without the
|need for on the wire interface IDs, as long as a router can map
|a HELLO message to the corresponding Interface Information
|Base (which may use an interface ID, but NHDP doesn't need to get
|into that detail, it just needs the concept I just mentioned)
|then duplicate addresses on different interface are possible
|IF messages from these interfaces cannot be received by the same
|neighbour interface. This is the case in Stan's example, and is
|the case for e.g. a node with two 802.11 interfaces (and possibly
|Ethernet interfaces also) if the 802.11 interfaces use different
|channels. This I think gets the gain in the cases of real interest
|without added complexity and bandwidth.
|
|With regard to how many addresses to advertise, there is an NHDP
|and an OLSRv2 answer. For pure NHDP use, each interface needs
|at least one address, and also to report any address that it may
|use as the source address of an IP datagram carrying NHDP information.
|(In practice you can probably ensure the same address is always used.)
|For OLSRv2 use that needs to be extended to also include any addresses
|the router wants to make globally available as a destination. (Stronger
|requirements, that result in added information, is explicitly noted
|as permitted, it has to be in order to build e.g. OLSRv2 or SMF.)
|
|Fundamentally, all that needs to change in NHDP is
|- A relaxation of address reuse, but with the important caveat above.
|- A relaxation of required address inclusion, with the condition
|  noted above.
|
|(There are of course details to get right, as ever.)
|
|********************************************************************
|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.
|********************************************************************