Subject: [manet] draft-ietf-manet-nhdp - WGLC - ends Feb 3rd

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 18 Jan 2008 12:16:03 +0530

This note announces the WG Last Call for comments on
draft-ietf-manet-nhdp-05.txt, "MANET Neighborhood Discovery Protocol
(NHDP)".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-05.txt .

The document is intended to be submitted for publication as a proposed
standard document.

Please review the document carefully and send your comments to the
MANET list and document authors ASAP.

This last call will end Sunday Feb 3rd.

Thanks,
Ian Chakeres

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Thu, 17 Jan 2008 23:08:02 -0800

There were two recent emails about using information from the link
layer to do better link quality estimation in 802.15.4. If the authors
are waiting for 802.11 based results before they consider the merit of
that argument, EAR (Mobicom 2006) might be a good paper to read. This
paper makes a similar argument that we made (as far as link quality
estimation is concerned), but based on 802.11.

Based on the work by these two groups, it is clear that NHDP-like
protocol does not use the best known methodology for neighborhood
discovery/link quality estimation. I request the authors to consider
the results from these findings.

- om_p

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Sun, 20 Jan 2008 11:05:41 -0800

Based on my assumption that section 13 also covers changes to
Information Base from systems external to NHDP, my modest proposal is
to include an example on how Packet Acknowledgement can trigger 13.1
and 13.2. The idea is using packet acknowledgement information, a link
"incorrectly" thought to be symmetric link can be tagged as
asymmetric, or a link "incorrectly" thought to be asymmetric link can
be tagged as symmetric.

The best way to address this might be to add a short section just like
section 14 for link quality and mentioning packet acknowledgement in
the list in section 13. This would be optional just like link quality.
I will be happy to contribute this section if the WG thinks this is
worthwhile.

- om_p

---

From: "Ulrich Herberg" <[email-masked]>
Date: Mon, 21 Jan 2008 10:35:34 +0100

I am about to implement NHDP at the moment, and I think that the
specification is very clear. I only have one rather minor comment on the
terminology used in NHDP: I wonder why you use the terms
N_neighbor_iface_addr_ list, L_neighbor_iface_addr_list etc. In my opinion,
it should rather be called N_neighbor_iface_addr_set. This would imply that
addresses are (i) unique within the set and (ii) not in any order. This
becomes important when comparing these "lists", for example in section
12.1"If the N_neighbor_iface_addr_list of the matching Neighbor Tuple
is not
equal to the Neighbor Address List". If I compare two lists [a,b,c] and
[c,b,a] they would be different while the sets {a,b,c} and {c,b,a} are
equal.

Best regards,
Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 30 Jan 2008 11:44:53 +0100

All, here some remarks. 
I had time restrictions for reviewing, so comments are not complete.
Regards, Teco.

General:

MANET_ID:
I know this idea is proposed only recently. I think it touches NHDP.
If MANET_ID is implemented only in DYMO (as there were some 
negative responses from the OLSR corner), the MANET protocols
drift from each other. I think this was not our intention.

Link metrics:
I highly prefer usage of L1/L2 metrics in the MANET routing
protocols. 
dearlove-olsrv2-metrics suggests support for metrics can be
added to OLSR without touching NHDP.
IMHO link metrics is related to neighborhood discovery, e.g. 
state is to be maintained in the NHDP Interface Information Base 
Link Set.
NHDP currently describes Link Quality, which is strongly related 
with L1/L2 metrics. But it does not exactly provide what is needed.
OLSRv2 already extends NHDP, so further extending would not be 
a problem ... OLSRv2:
>> The OLSRv2 neighborhood discovery protocol using HELLO messages is
>> specified in [4]; note that all references to MANET interfaces in [4]
>> refer to OLSRv2 interfaces when using [4] as part of OLSRv2.
<skip>
>> This neighborhood discovery protocol, which also uses [1], 
>> is extended in this document by the addition of MPR information.

On the tekst:

Page 5:
Used terminology is very specific to this document e.g.:
 Node  - A MANET Router which ...)
 Link  - A pair of MANET interfaces ....

Page 7:
>> Can use the link local multicast address and either the "manet"
>> UDP port or the "manet" IP protocol number specified in [2].
My old comment: True, but this breaks compatibility between routers 
using the two different options. And it affects rules for message 
aggregation. And the missing UDP fields length and checksum when 
running over IP.

Page 12:
thsi -> this

Page 28:
>> All addresses in a node's Local Interface Set (i.e. in any
>> I_local_iface_addr_list) MUST be included in the address blocks in
>> all generated HELLO messages with the following exception.
Why MUST? Using a single address for NHDP and a summary prefix for TC 
would work and is more efficient.

Page 33:
On receiving hello messages, do we need a check on sender address, 
that there is at least a matching prefix assigned on the receiving
interface?

When using maximum prefix length (32 bits IPv4), are we sure there is no 
problem with other protocols (e.g. ARP)?I don't think so.

> -----Oorspronkelijk bericht-----
> Van: Ian Chakeres [mailto:[email-masked]]
> Verzonden: vrijdag 18 januari 2008 7:46
> Aan: manet
> CC: Christopher Dearlove; Thomas Heide Clausen (work)
> Onderwerp: [manet] draft-ietf-manet-nhdp - WGLC - ends Feb 3rd
>

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Wed, 30 Jan 2008 23:27:04 -0800

I don't know if the authors intend to reply at the end of the comment
period, but here it is again something that I posted 10 days ago:

"

- om_p

"

- om_p

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 31 Jan 2008 14:10:10 -0000

> MANET_ID:

MANET_ID isn't part of NHDP, it isn't even a WG item (and neither
should it be unless we've had a problem statement and consideration
of why a TLV solution is required, rather than the technically
superior when applicable approach of address filtering that avoids
the need to parse packets).

> Link metrics:
Link metrics depend on what you want to use them for. For
OLSRv2, that's linked to MPRs, and that you need to split
the concepts of relaying and advertising, and also the
directionality issues. Thus if (and it's still an if) we
add metrics for OLSRv2, in the OLSRv2 document is the
appropriate place. Some potential applications of NHDP
may not want metrics, and putting them (even if agreed)
in NHDP is therefore potentially burdoning it with stuff
that not everyone will want.

>  Link  - A pair of MANET interfaces ....

We need something specific to the problems here. And link
here is the link in link state protocol, i.e. it has a
perfectly good pedigree.

> using the two different options.

As NHDP isn't a full protocol, this should be devolved to the
protocol using it. Really this is a higher level WG issue, the
whole "what is the architecture?" that draft-iana didn't cover.

> And it affects rules for message aggregation.

That I don't see at all. Message aggregation is quite separate from
what transports the packetbb structure.

> And the missing UDP fields length and checksum when running over IP.

You're not missing length - IP has a length field. If you've chosen
to give up the checksum, it should be because you don't need it -
on a wireless system I would expect the physical and data link layers
to include coding likely to be a lot better than the crude UDP
checksum.

> thsi -> this

Yes.

>would work and is more efficient.

First, TC messages aren't part of NHDP, so you can't build an
NHDP that relies on TC messages to work. Second, be very careful
of "would work". A lot of ideas that appear to work actually don't,
especially with multiple interfaces. (Thomas has an unpublished
half a dozen ways to do multiple interfaces that superficially
appear to work, but actually don't.)

> that there is at least a matching prefix assigned on the receiving

Well, we use the sender address in lieu of a single interface address.
Yes, we could check that otherwise is the sender address covered by
one of the sent local interface adddresses with THIS_IF. That may
be a good idea. We could check sender addresses even more rigorously,
are they appropriate to the subnet that the receiving node thinks its
on. That's an alternative to MANET_ID. I don't think NHDP is the right
place to mention this, except possibly as a MAY aside to checking
sending address.

> problem with other protocols (e.g. ARP)?I don't think so.

I'm not aware of a problem here.

********************************************************************
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.
********************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 31 Jan 2008 14:21:13 -0000

> and 13.2.

I believe this is not appropriate. The NHDP model is simply that all
information from lower layers is collected in one metric, which is a
general interface. You can calculate that figure however you want,
using a weighted, or non-linear, combination of all the information
you can get hold of should you wish. Packet acknowlegements are just
another source of information from the link layer (not all link layers
need provide one - especially not for broadcast packets as may be used
for NHDP HELLO messages). It would probably be appropriate in 14.4 to
add link layer acknowledgements as well as signal to noise ratio in the
first bullet point however.

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Thu, 31 Jan 2008 10:27:31 -0800

> general interface. You can calculate that figure however you want,

I wasn't proposing an interface change. The users of the NHDP
information don't see any change, they would use the same interface as
it exists now.

> you can get hold of should you wish.

Correct and this should not be specified in the document.

> Packet acknowlegements are just
> for NHDP HELLO messages).

You are right about the broadcast packets. But I was taking about the
acks from unicast packets.

> It would probably be appropriate in 14.4 to

We use a lot of real estate talking about things like hysteresis
(something that people can average however they want and probably
should not be specified in detail in this document). Talking about
acks in one paragraph would put information in this document that is
crucial (I would say far more crucial) for these networks to work
efficiently - at least based on experiments with multihop protocols on
802.15.4 and 802.11 radios in the last couple years.

- om_p

---

From: Philip Levis <[email-masked]>
Date: Thu, 31 Jan 2008 10:51:03 -0800

> 802.15.4 and 802.11 radios in the last couple years.

I'd agree with that. There's a lot of time and effort spent on  
mechanisms which are fairly irrelevant in practice, such as last- 
heard timeouts, while those that turn out to be very important, such  
as direct feedback from the data plane, are mentioned not at all.

Phil