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

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 1 Feb 2008 17:43:00 +0530

Overall I think the document is in good shape.

I have included my detailed comments on the document below.

Ian Chakeres

Note: I have a few other issues that I will raise in separate emails.

===
Please qualify all uses of - this/these. In several places these words
(this/these) are left hanging with an object.

3rd paragraph of Section 1 is redundant.

Address, with prefix length, should be added to the terminology. This
change would result in less redundancy within the text.

Section 3 - I found the applicability statement a little hard to read
given its bulletized form, but generally agree with the content.

I think bullets 3 can be cut.

Bullet 4 - I feel that this specification should recommend using UDP, and not
specify using the IP protocol number. As Teco has brought up - passing
PacketBB packets directly over IP will likely require some additional
functionality.

Bullet 5 - the second sentence can be cut.

Section 4

/is,/is/

cut " of which ... may be a part"

/Discovers links from adjacent nodes/Discover adjacent nodes/ OR
/Discover links between adjacent nodes/

I am not sure if there is a difference between signaling and
exchanging control messages. Either way, it might be good to remove
signaling or define it.

Section 4.1. I think the last paragraph can be cut.

Section 4.1. I think the term "configured" interface should be
added/referenced. Essentially, I see no reason why NHDP needs to
participate on all possible MANET interfaces. I also see no reason
why NHDP needs to advertise all its interfaces. I think the NHDP
process should be cap cable of operating on less than all physical
interfaces if so configured. This may affect text in other locations.

Section 4.3.1 - When would jittering of hello messages be
"appropriate". Perhaps "SHOULD be used if appropriate" could simply be
removed.

Section 4.3.1 last sentence. I feel the last sentence could be cut.

Section 4.3.2 - Can a default value for VALIDITY TIME be set on nodes
themselves or does it need to be included in every message?

/thsi/this - I think this was reported before

Section 4.3.3 - In several places within the document the constraints
have been placed inline. Why are the constraints for this section
placed in an appendix?

Section 5.4 seems useless. I think C should be defined early on,
perhaps with discussion of VALIDITY_TIME and INTERVAL_TIME.

Section 9.2 last sentence, please place "Afterward," before the start
of the sentence.

Section 9.3 last sentance, please place "Afterward," before the start
of the sentance.

Section 10. I think that bullets 3&4 should be deleted.

The document should specified that the IP.TTL/HopLimit of the
containing packet be set to 255. GTSM methods (RFC 5082) should also
be used for HELLO packets.

Again, I think we should recommend using UDP right now. In the future
we can specify some additional mechanisms for moving packetbb packets
directly over an IP protocol number.

Section 10.1.1 - Please remove or explain the purpose of UNSPEC_IF.

Please change places that say 8-bits to 1-octet. I believe packetbb
only allows octet based values.

If valid messages are received, but they contain duplicate information
how should they be handled? For example, they contain the same address
twice. Perhaps, I missed the mention of handling well-formed but
bad-content messages.

Section 12 is the order of performing the various updates described in
this section important?

Section 13.1 - there is a hanging "are removed." please pull this up
with the previous sentance. I think that sentance can even be pulled
up with the one above it.

Section 13. I became a little confused by the bullets and their
depth. Is there a common scheme to the various bullet styles used? For
example, numbers ordered checks, + secondary checks, - set something,
o event.

Section 13.2 please add OR or AND following "contained in
N_neighbor_iface_addr_list;".

Section 14. I support Omprakash's proposed addition regarding using
unicast success/failure rates.

Section 14.3 - the last sentance in this section is contained in
parenthesis is very complex and not well structured. Please revise it.

Section 14.6 - it might be nice to reference
VALIDITY_TIME/INTERVAL_TIME and the TimeTLV spec in this section. I
think it would be good to explicitly say that C MUST be set the same
on all nodes here.

Section 16, I was confused about how appendix C provides protection. I
think we discussed this briefly once, but I think a little more text
could help.

Section 16. I think there should be some mention of authentication as
all the information contained in HELLO messages should likely be
authenticated in more secure environments.

Section 17.2. Why are all Type extensions reserved? I think these
should be left open for allocation via standard actions. I believe
that is what is recommended, but the term RESERVED seems to indicate
otherwise. I would suggest removing these RESERVED spaces.

Appendix B - /by IP/by the IP header/

Appendix C in the list following Lost Neighbor Table - the third
bullet has some spacing problems - please fix if possible, since "==
true" falls onto the next page.

Appendix D - I think that this section should be re-named "HELLO message
Generation Rate" and be elevated to a normal section.
===

On Jan 18, 2008 12:16 PM, Ian Chakeres <[email-masked]> wrote:
> 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]
http://www.ietf.org/mailman/listinfo/manet

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 1 Feb 2008 13:56:07 +0100

> > IP & UDP as transport:
> 
> 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.
> 
[Teco:] 
When one protocol uses IP and the other UDP, and we want to use commonly
NHDP and message aggregation and even sharing the same message by adding
TLV, thinks are getting complex.

> > And the missing UDP fields length and checksum when running over IP.
> 
> You're not missing length - IP has a length field.
[Teco:] 
OK. Not as straightforward as UDP length, but it works.

> >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.
> 
> 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.)
[Teco:] 
Assume I want to use NHDP and OLSRv2.
I want to reduce overhead as much as possible.
I assign an address block to the router, each interface has one or more
subnets from the assigned block.
I want to advertise a single aggregation, as this is assigned to the router.
--> OLSRv2 needs support for aggregation
--> NHDP needs a tool for reducing sending lots of prefixes.
NHDP does not use Router Identifiers, correct? 
NHDP neighbors are identified by all their addresses, correct? Is this the
reason for _MUST_?
What about anycast?

> 
> 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?
> 
> 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.
[Teco:] 
Maybe NHDP assumes there is a link, but user traffic cannot make use of it
because addresses are not on same subnet.

> 
> > 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.
> 
> I'm not aware of a problem here.
[Teco:] 
Many IPv4 stacks have a restriction on using /32 mask on multi-access
interfaces.
I verified on well known OS and router equipment.

And when configured, protocols could assume that an interface with only a
/32 mask cannot have a link to another host.
I saw problems like this with /32 on a Linux 2.4 IP stack.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 1 Feb 2008 13:02:47 -0000

Comments inline below as >> 

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 01 February 2008 12:13
To: manet
Cc: Joe P Macker (home); Dearlove, Christopher (UK); Thomas Heide
Clausen (work); Justin Dean (work)
Subject: Re: draft-ietf-manet-nhdp - WGLC - ends Feb 3rd

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Ian Chakeres

===

>> Almost. The reference to [1] needs to be saved.

>> Agree, although a little care needs to be taken because of
>> protocols (such as OLSRv2) which also use addresses (for
>> OLSRv2 originator addresses) without prefix lengths.

>> No, I don't agree. Bullet 3 is saying something (two things
>> in fact) important that should be in this section, and isn't
>> in any of the other bullets.

Bullet 4 - I feel that this specification should recommend using UDP,
and not
specify using the IP protocol number. As Teco has brought up - passing
PacketBB packets directly over IP will likely require some additional
functionality.

>> What's the point of our having defined the protocol in
>> draft-iana if we never use it? I agree there's a compatibility
>> issue, and this is part of a whole architecture discussion we
>> haven't had. I disagree with Teco's point and have said so.

>> Do you mean bullet 6? I think the second sentence adds something
>> that matters for example when using NHDP as part of OLSRv2 (or
>> a DYMO extension).

Section 4

/is,/is/

>> If you mean in the first line, I don't agree.

>> Don't agree. Or at least this is an important point to be made
>> somewhere related to this.

>> I would suggest Discover links with adjacent nodes. Discovering
>> nodes isn't enough, and the between version isn't clear that this
>> is one of those nodes.

>> I think there's no difference, and one term for one thing is good.

>> Definitely not, this is important.

>> That wants further thought. Note that if you don't advertise an
>> interface, then to all intents and purposes it doesn't exist
>> externally - you can't get to it. Of course outside NHDP there
>> are alternatives (using TC messages in OLSRv2 for example) but
>> these have a cost (making nodes send TC messages unnecessarily,
>> which is bad).

>> When the physical/data link layers need it (802.11 for example).
>> I don't agree with the suggested change, but may want to think
>> about the sentence.

>> No, that's important. It's a question an implementor may very
>> well ask, that needs an answer.

>> Needs to be in every message. That's a deliberate design, which
>> dates back to OLSRv1.

>> Everyone's favourite correction. I think we first got it before
>> leaving Vancouver, and I think we're up to about half a dozen
>> spottings. Proves people read it though.

>> This is different. This doesn't specify the constraints, it says
>> that if you follow the instructions then the constraints will be
>> maintained.

>> I think 5.4 is presenting this information in the right place.
>> There's a clear development in the document of parameters,
>> data structures, messages, processing, and this is the right
>> place. We also don't intend to discuss the two TLVs in detail
>> - we put them into a separate document to avoid doing that
>> here and again in OLSRv2. But this section also needs an
>> addition to discuss signalled values (HEARD etc.) and PENDING.

>> I don't like that exact way of achieving your point, but I agree
>> that it should be clarified this is afterward.

>> I don't agree, especially for bullet 4.

>> I'll reserve comment for now.

>> See comment above.

>> Definitely not removing it - we need it in OLSRv2, and defining it
>> without this, then adding it in OLSRv2 would be a real nuisance.
>> But we can explain (without explicit reference to OLSRv2).

>> The latter is true, and I think this is a good change.

>> Duplicate information is ill-formed, see packetbb.

>> Yes. Your obvious implication, that section 12.0 (to use an
>> obvious notation) should say so, is correct.

>> I'm not going to say yes or no to this one right now, I can see both
>> why it is as it is, and why you may not like it.

>> It's what xml2rfc gives you, no human control. I have absolutely
>> no idea what algorithm it uses, except different levels have
>> different symbols.

>> Good catch. I think it's AND, but will confirm.

>> It's appropriate to add it as an example in the first bullet
>> of 14.4, but not more.

>> Comment noted.

>> I don't have a 14.6. If you mean 15.6, I think it's appropriate
>> to reference [3], but not the TLVs explicitly. But that C is the
>> same for all nodes - see Section 2.

>> Appendix C is there not for NHDP as implemented by this specification
>> (although it may be informative). It's there because people (from
>> NRL in particular) wanted to be able to modify the protocol sets
based
>> on other information. That permission is there (I'm not going to look
>> for the section). But unrestrained modification could really mess
things
>> up, and Appendix C is there to say "if you change the sets don't do
that".

>> I'll reserve comment for now.

>> See the last sentence in section 17.2.

>> Not fussed either way myself.

>> That's what automated tools do for you.

>> Everything significant said is already specified in the main
>> sections. This is essentially just a commentary on those, and
>> as such I think an Appendix is right.

********************************************************************
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: [email-masked]
Date: Sun, 3 Feb 2008 01:51:47 +0100

Dear Manet WG members,

after all comments already posted on the mailing list, there is not  
much I can add. I would just comment on the link metric and the  
MANET_ID, and node metric.

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

I agree that the link metrics depend on what you want to use them for.  
For OLSRv2, it is very specific and so is the debate. That is yet out  
of scope of the present document.

Yet, I would say that it is not because some applications may not want  
link metrics that NHDP should not specify any. To the contrary, as the  
objective is to standardize a protocol, we would like to avoid  
different teams, or compagnies, to implement in their own ways how to  
share and use link metrics. I would rather see (but it is not a new  
debate) it specified as an option. If someone does not need it, it  
does not use it. But in the contrary, well there will be a  
specification for it.

Actually, I would say that NHDP, as the central neighborhood  
discovery/maintenance procedure of a MANET protocol is a right place  
to gather and exchange link metrics, for example for congestion  
control. The use itself is of course out of scope of the document.

MANET_ID:

We are here at a important point: if using a MANET_ID makes sense from  
the "preliminary" problem statement in the introduction part of Ian's  
draft (whether we need his draft or another solution, actually), some  
changes should be added to NHDP before the end of the Last Call. If  
not, we can move on.

So, the question would really be: Even without a problem statement, is  
it worth working on it, and possibly delaying NHDP ?

As I mentioned in my previous mail on MANET_ID, I think that it is  
worth studying the problem before "closing" the discussion on  
NHDP....But it is the WG's call

Finally, it is a old debate (that was actually more of a monologue, or  
a personal concern), but I would ask a last time if it would make  
sense to add an "optional" field in the node information base  
containing the location of its neighbors along with their address ?  
This is a node metric, not a link metric, but there are also  
appplication that would require a node metric in general, and the  
position of a node in particular.

Just my two cents,

Regards,

Jerome

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Sun, 3 Feb 2008 23:16:26 -0800

> does not use it. But in the contrary, well there will be a

Although, in theory, it might seem like most applications won't use
link metrics, I am going to argue that if you don't use link metrics
(we are talking about BER type link metric), those applications might
not work either. The notion of not using link metrics seems like a
holdover from the wired world where you might use metrics unrelated to
BER to describe a link. If most applications will use link metrics, it
makes sense to think and write about them.

The question that is harder to answer is if the link metrics should be
part of NHDP. My answer is YES because link quality is an integral
part of knowing about the neighborhood in wireless network. Talking
about neighborhood without link quality does not make much sense. And
although we might talk about it, we are inevitably and implicitly
talking about the metrics. The answer also depends on whether there
can be a metric that many implementations are able to compute based on
variety of hardware/software platforms they run on and if the metric
as defined can be used by many implementations. As far as I know,
metrics like ETX or PRR can be computed on all platforms based on
variety of information and can be used by many implementations in
their own ways.

So to me it makes sense to define a link metric and also describe how
they are exchanged.

- om_p

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 4 Feb 2008 16:37:45 +0100

Dear Omprakash,

Thank you for your email. I believe that the authors are well aware  
of the benefits from using information from lower layers for link  
quality estimation, and the body of literature on this subject -- and  
that this is reflected in the I-D.

Essentially, the philosophy has been to say "Using a link-quality is  
a good idea. If a lower layer provides something useful, by all  
means, use it. However if not (e.g. due to proprietary hardware/ 
drivers/os), here's something that's better than a simple binary value".

The basic text in section 14 specifies (in simple terms) two  
thresholds parameters and a quality value, stipulating the protocol  
actions when the quality crosses either threshold from either  
direction. This, I believe, is what is required for correct  
functioning regardless of how the threshold parameters and/or link  
quality value are set.

Section 14.4 further states that if lower-layer information is  
available, it can be used. However this I-D is not making any  
assumptions as to this, that or the other specific link-layer. It  
should be noted, however, that any choice of how to set the threshold  
parameters in a node or the quality value for a link is compatible  
(thanks to section 14.0-14.3) with any other such choice.

I agree entirely that the exercise of "how to pick good hysteresis  
parameters and how to set the link quality value for a given link" is  
something that is important -- but that doing so correctly requires  
detailed understanding of the underlying layer and the concrete  
deployment. The document is written to be accommodating to this  
effect, and (owing to the fact that we do not know all possible  
current and future lower layers and deployments) does specifically  
not attempt to mandate that this, that or the other specific  
information from a lower layer be used in a specific way.

I'd be happy to add to 14.4 something akin to "any other way that one  
may determine lower-layer information useful can be used", if that  
helps -- but I'd specifically not want to suggest or mandate one  
specific way over another.

Thomas

On Jan 18, 2008, at 8:05 AM, Omprakash Gnawali wrote:

> 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
>
> On Jan 17, 2008 10:46 PM, Ian Chakeres <[email-masked]> wrote:
>> https://www1.ietf.org/mailman/listinfo/manet
>>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 4 Feb 2008 16:46:54 +0100

On Jan 31, 2008, at 7:27 PM, Omprakash Gnawali wrote:

> On Jan 31, 2008 6:21 AM, Dearlove, Christopher (UK)
> <[email-masked]> wrote:
>>
>>> 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.
>>
>> 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,
>
> 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.
>
>> using a weighted, or non-linear, combination of all the information
>> you can get hold of should you wish.
>
> Correct and this should not be specified in the document.
>
>> 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).
>
> You are right about the broadcast packets. But I was taking about the
> acks from unicast packets.

That may, of course, be used to your hearts content ;) However the  
specific way of doing so would (i) depend on the underlying layer and  
(ii) on the ratio (if any) of unicast traffic -- hence somewhat  
scenario specific.

I note that this is, indeed, among the possibilities that sec. 14  
would allow.

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

Sorry, I disagree. The hysteresis discussion, and the protocol  
actions when crossing a threshold from one or the other direction are  
exactly what allows different mechanisms for setting/determining link  
quality to function, AND to remain interoperable even if run  
concurrently.

I could be happy to include other examples of lower-layer information  
that could be considered, however it's a potentially non-terminating  
list of non-normative stuff, so we've got to be careful.

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 4 Feb 2008 16:51:20 +0100

On Jan 20, 2008, at 8:05 PM, Omprakash Gnawali wrote:

> Information Base from systems external to NHDP, my modest proposal is

I feel that this would be inappropriate. Such should not trigger  
directly 13.1/13.2, but should change the value of L_quality, which  
could then trigger the appropriate actions. An example, if you  
determine that lack of an ACK would be a fatal error, you could (a  
simplified example) simply consider L_quality={0,1} and stick the  
threshold at 0.5 and you'd get the desired actions.

The idea is to allow this, plus other, such lower layer information  
to be used, without having to rewrite the document for each such bit  
of information.

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

Can you not do something to this effect by setting your thresholds  
and L_quality of section 14 appropriately? It seems to me that one can.

Thomas

> 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: Thomas Heide Clausen <[email-masked]>
Date: Mon, 4 Feb 2008 18:53:15 +0100

All,

> Comments inline below as >>

Chris, it'd help in the readability department if you could make the  
quoted text start by >, rather than your text -- I constantly find  
myself confused ;)

Comments below - mostly stating my agreement.

<SNIP>

>>> Almost. The reference to [1] needs to be saved.

Agreed.

>>> OLSRv2 originator addresses) without prefix lengths.

Yup, but we should be able to handle that.

>>> in any of the other bullets.

I agree with Chris here, this bullet is important and not redundant.

>>> haven't had. I disagree with Teco's point and have said so.

Chris has a good point, which is that an architectural discussion of  
how the different pieces of the MANET wg deliverables fit together,  
and what complications exist, belongs somewhere. The thing is, that  
this is not the place. Nor do I know where would be a good place,  
unfortunately.

But, the above is not the spirit of this bullet-point anyways: what  
this bullet says is, simply, "an implementation of this protocol can  
live entirely in user-space, using nothing other than the ability to  
transmit and receive broadcast packets".

>>> that matters for example when using NHDP as part of OLSRv2 (or

I think that it is important to keep in mind that this functionality  
is inheritance from packetbb, which explicitly is designed to allow  
this. That said, I feel that it is useful to repeat since -- indeed  
-- the specification respects that inheritance.

<SNIP -- I'll leave the native English speakers determine the correct  
usage of punctuation and such>

>>> Definitely not, this is important.

Agree with Chris here, this is very important.

>>> these have a cost (making nodes send TC messages unnecessarily,

Hmm...I think that I know what Ian is saying, or at least aiming at,  
here. The short answer is that "all IP addresses that one wants ones  
neighbours to know about should be advertised", be that MANET or  
other interfaces.  Yup, therefore said that for an interface that one  
does not want seen in that MANET, one simply does not advertise its  
addresses. I guess that Ian is thinking about the "running-multiple- 
protocol-instances-on-a-node" issue here?

I think that a reasonable resolution could be akin to saying (this is  
not proposed text, just the spirit): "all IP addresses of interfaces  
that one wants to be known within the MANET are recorded in the Local  
Interface base" ?

>>> I don't agree with the suggested change, but may want to think

I'm not crazy about the suggested change. I definitely think that it  
needs be there -- and I think that a reference to draft-ietf-manet- 
jitter might be what's needed, not additional explanations here?

>>> well ask, that needs an answer.

The question has been explicitly asked and so I agree with Chris that  
the answer given by that sentence is important.

>>> Needs to be in every message. That's a deliberate design, which

agreed.

>>> spottings. Proves people read it though.

I actually like thsi better than this...but it seems that the  
overwhelming hum in the WG disfavours creative spelling, so I'll bend  
to consensus on thatone ;)

>>> that if you follow the instructions then the constraints will be

I agree with Chris -- but maybe we can make this a notch more clear  
by adding a phrase to this effect?

>>> addition to discuss signalled values (HEARD etc.) and PENDING.

Agree with Chris on this matter -- it's part of the inheritance from  
that-other-document.

>>> that it should be clarified this is afterward.

Agree with Chris.

>>> I don't agree, especially for bullet 4.

I think that both 3&4 are important. They may be obvious when knowing  
the protocols / documents, but I think that they are helpful to avoid  
mistakes. I'd want to keep those.

>>> I'll reserve comment for now.

I'd like to ask if Ian could educate me as to why you think that this  
is necessary? I'm not disagreeing, I'm trying to form an informed  
opinion ;)

> directly over an IP protocol number.

Whoops, no, I think that this would be premature to do so.

>>> But we can explain (without explicit reference to OLSRv2).

Agree. Can't remove, will explain ;)

>>> The latter is true, and I think this is a good change.

Agreed, good catch - thanks.

<SNIP>

>>> obvious notation) should say so, is correct.

Again, good catch -- thanks!

>>> why it is as it is, and why you may not like it.

I'd vote for "as-is". I can see both arguments, but it's more  
coherent with the way the rest is written as it is.

>>> no idea what algorithm it uses, except different levels have

I'd add to that that we're sticking to feeding xml2rfc basic xml- 
stuff, and that the rfc-editor when converting to nroff (they still  
do that, right?) make sure that things are coherent. We try to use as  
simple/standard xml to feed xml2rfc since it's easier for our rfc- 
editor-friends to process stuff automatically that way.

>>> Good catch. I think it's AND, but will confirm.

AND, I think,....thanks!

>>> It's appropriate to add it as an example in the first bullet

I agree that it can be added among the examples, but as I have  
indicated in another email, an exhaustive list of examples can become  
very very very long.....and not appropriate. If it's just that  
example then sure, why not?

> parenthesis is very complex and not well structured. Please revise it.

I'll leave that to our professional Englishman (that'd be you, Chris)  
to deconvolute that.

>>> same for all nodes - see Section 2.

Agreed.

>>> up, and Appendix C is there to say "if you change the sets don't do

The way I think of App. C is to say that "iff you do something other  
than what comes from the message exchange in this specification, then  
you must ensure that the following is respected -- or you'll  
definitely break stuff".

>>> I'll reserve comment for now.

I think that we need to, on the one hand, cross blades with the sec  
ADs / sec-dir, and on the other hand consider the comments the sec- 
dir had to packetbb.

>>> See the last sentence in section 17.2.

I believe that it is right as it is, as per [6].

>>> Not fussed either way myself.

I'll leave this to the native English-speakers ;)

>>> That's what automated tools do for you.

I guess that we'll note this, sit on it for now, and make sure to  
check that with the RFC editor down the line.

>>> as such I think an Appendix is right.

Agree with Chris.

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 04 Feb 2008 12:45:37 -0800

Hello folks,

Here are some comments on the NHDP specification.
I'm about 40% finished, but wanted to get this part
in for discussion.  I'll try to finish the rest
today and tomorrow.

Regards,
Charlie P.

=========================================================================

I have noted before that NHDP approximately doubles the size
of signaling messages compared with other approaches.  This
is very bad for networks where the additional signaling overhead
can cause serious performance degradation.  As one example
where it matters, we have measured this effect (as reported at
previous IETFs) to counteract some of the performance improvement
which otherwise would be gained from path accumulation.

Thus, I would like to see another bullet added to section 3
(Applicability Statement):

    o Is applicable to networks in which the additional signaling
      overhead represented by these HELLO messages will not add
      unacceptable levels of congestion or cause unacceptable
      performance degradation.

Below, ">" indicates text from the existing specification.

 >   o  Does not require any changes to the format of IP datagrams, thus
 >      any existing IP protocol stack can be used as is.

What is the point of this?  I cannot remember reading another
protocol specification where avoiding modifications to IP was
billed as a feature of the protocol?  I think this should be
deleted.

 >   o  Uses the packet and message formats specified in [1].  Such
 >      packets may contain messages specified by this protocol as well as
 >      other protocols.

The second sentence does not add anything and should be deleted.

 >   o  A HELLO message MUST include a VALIDITY_TIME message TLV that
 >      indicates the length of time for which the message content is to
 >      be considered valid, and included in the receiving node's
 >      Interface Information Base.

I have asked before about having a default value for this
field, and thus avoiding the need for yet another useless TLV
to be transmitted over and over again.  Another alternative might
be to define a VALIDITY_REFRESH time which is a lot longer than
the other REFRESH_INTERVAL.  Or a receiving node could signal
its desire to receive the information.  But either of these
are just details and neither one would be necessary.

In section 5.1.1:

 >                                                                     In
 >      all intervals of length REFRESH_INTERVAL, a node MUST include all
 >      1-hop neighbor information which it is specified as sending in at
 >      least one HELLO message on this MANET interface.

and then below:

 >   For a node to employ this protocol in a purely responsive manner on a
 >   MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be
 >   set to a value such that a responsive HELLO message is always
 >   expected in a shorter period than this.

This raises several questions:
-- What is "this" (in the last sentence)?
-- What is a "purely responsive" manner of working
    the protocol?  Does it mean that a node does not
    proactively disseminate periodically scheduled HELLO
    messages?  If not, then what?

I can imagine a very nice purely responsive mode
of operation, but it isn't described in the document
as far as I have seen.  If there is interest in
creating this, please let me know.

In section 5.1.2:

 >      L_HOLD_TIME can be set to zero if accelerated information removal
 >      is not required.

Wouldn't zero imply the "maximum" acceleration?

In section 5.1.3, there should be a cross reference to
section 4.4 in the first sentence.

If HYST_REJECT < INITIAL_QUALITY < HYST_ACCEPT, does
INITIAL_PENDING have a value?

Why should there be any difference between HP_MAXJITTER
and HT_MAXJITTER??  If made to guess, I suspect that
the latter would be chosen to be smaller, but then I'm
having a hard time believing it would matter at all
unless there is really a huge factor of difference.

 > 5.4.  Constants
 >
 >    The constant C is used as specified in [3].

It would be nice if you could put in just a couple
of words to identify "C".  For example:

    The constant C (i.e., time granularity) is used as specified in [3].

That doesn't bloat the spec too much :-)

 >                                                           This
 >   protocol responds to changes to this Local Information Base which
 >   MUST reflect corresponding changes in the node's interface
 >   configuration.

Better:

    If a node's interface configuration changes, then the Local
    Information Base must reflect the changes, and these changes
    typically trigger protocol operations to advertise the changes.

Section 7:

 >   A MANET interface address can be present in both the Link Set and as
 >   of a symmetric 2-hop neighbor.

I'm thinking this sentence does not parse.

 >                        Two addresses are considered equal if and only
 >   if their associated prefix lengths are also equal.

It seems to me that this sentence should be deleted.
Two addresses are equal if they're equal, and why not??

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 05 Feb 2008 13:17:33 -0800

Hello Chris,

Dearlove, Christopher (UK) wrote:
> I do not agree with this.

You didn't say why.  And, if you read what I suggested, it is
practically a tautology so that you cannot disagree with the
truth of it.  Perhaps you disagree that the matter needs discussion
at all in the spec.  However, the results I have shown indicate
persuasively that the size of HELLO messages _does_ matter, and
this has motivated a lot of my effort.  So, what is wrong with
informing protocol designers that the large size of the HELLO messages
specified in this document does need to be considered?

> Disagree. When running NHDP as part of, for example, OLSRv2, it's
> important to allow HELLO and TC messages to share a packet, and NHDP
> needs to permit that.

But, NHDP is _not_ permitting it.  PacketBB is permitting it.

>> to be transmitted over and over again.
> 
> I don't agree, because there is no natural default. I can see the
> motivation, but it's not enough as I see it.

For any particular deployment, there is likely to be a natural
default.

> No. L_HOLD_TIME is how long you retain the information that
> is put in HELLO messages to accelerate removal. The longer
> you leave it in, the more often you let other nodes know
> in order to allow for lost messages etc. With it zero the
> information is never retained, never put in HELLO messages
> and there is no accelerated removal.

According to your explanation, this is not accelerated
removal.  It is, instead, more reliable removal.  So, I
would suggest changing the terminology.

> Yes. For convenience INITIAL_PENDING is always defined,
> but this is the case that really needs it.

What is it?  Where is it specified?  From the
description, it seems to me that in the range
under discussion, INITIAL_PENDING could have
either value.  And, if all the quality measurements
are in the intermediate range, no assignment to
INITIAL_PENDING is specified that I could find.
I "guess" it is a boolean variable, so at least
a random choice might be correct 50% of the time.

>> and HT_MAXJITTER??
> I think in practice there usually won't be, but I can see
> there may be circumstances where it might make sense.
> We have adopted the policy that we don't use the same
> parameter for two different jobs, and these are different.
> 
>> If made to guess, I suspect that
> I think in practice people will set them the same, and the
> suggested values are the same.

This is not a very convincing argument for what could be
characterized as gratuitous complexity.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 05 Feb 2008 13:56:47 -0800

Hello folks,

Here are some more comments.

In section 8.1:

>    A node's Neighbor Set records all interface addresses of each 1-hop
>    neighbor.  It consists of Neighbor Tuples, each representing a single
>    1-hop neighbor:
> 
>       (N_neighbor_iface_addr_list, N_symmetric)

I reckon this means that the same neighbor could be
neighboring by way of multiple network interfaces
(and therefor links).  But each interface would have
independent determination of whether the link was
symmetric.  Thus, the N_symmetric flag is somehow
the logical conjunction of each individual link's
"symmetry flag".

In section 9.3:

>    1.  The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list
>        contains the added address, are removed.
> 
...
> 
>    4.  Any 2-Hop Tuples whose N2_2hop_iface_addr is the added address,
>        are removed.

Why would there be such tuples as described in 1--4,
that already contain the added address?  Isn't the
address supposed to uniquely belong to the manet
node?  If the address already exists and belongs
to a neighbor, it seems to me that there are major
problems already and the removal tasks mandated here
are not going to come close to fixing them.

In section 10:

>    o  HELLO messages MAY be included in multi-message packets as
>       specified in [1].

Does every specification using PacketBB have to give permission
for PacketBB to bundle with other messages?  Please tell me
"no"!

In that case, this bullet should be removed.

Also,

>    o  Received HELLO messages MUST be parsed in accordance with [1].  A
>       HELLO message which is not in conformance with [1] MUST be
>       discarded.

If NHDP is going to use PacketBB, is there really any chance
that someboy might "not" use PacketBB, therefore necessitating
to mandate this behavior to even more assuredly use PacketBB?

Worse, if a node wishes to make use of two different HELLO
protocols, why should NHDP be so selfish as to require the
node to discard the other information it has?

In section 10.1:

>    A HELLO message MUST contain:
> 
>    o  A VALIDITY_TIME message TLV as specified in [3], representing
>       H_HOLD_TIME for the transmitting MANET interface.  The options
>       included in [3] for representing zero and infinite times MUST NOT
>       be used.

This is a really bad idea.  I thought there was agreement
before to make this optional.

>    A HELLO message which is transmitted periodically SHOULD contain, and
>    otherwise MAY contain:

If a HELLO message is not periodic, then the HELLO_INTERVAL
is really wrong to include.  Especially because one would
expect that this is a case where the VALIDITY is finally
useful for the purpose.

>    A HELLO message MAY contain:
> 
>    ...
> 
>    o  Other message TLVs.

Does this mean, as defined in subsequent protocol documents?

But then, back at the beginning of Section 10:

>                                            TLVs of other types, and
>       of these types but without Type Extension == 0, are ignored by
>       this protocol.

is wrong.  In fact, I'd say this should be deleted, since
future protocol documents should be allowed to specify
whatever they need to for best operation.  In point of fact,
anything not defined in NHDP should be ignored by an
implementation of NHDP conforming to this specification,
which is practically a tautology.

In section 10.1.1, there is discussion about advertising
link status indications.  What happens to a link that makes
a transition from SYMMETRIC to asymmetric but is not lost?
If an asymmetric neighbor is made to be "LOST", then how
long are the incoming advertisements suppressed?  There
needs to be a time after which the asymmetric neighbor
advertisements are once again represented as new data by
the node somehow, because the link might have become once
again symmetric.

Anyway I find the discussion in this section a bit
confusing so I need to study it some more.

Back to another point in a previous discussion:

> The point is that you need the prefix lengths to be equal as well
> as the pure address part. But I think the right place for any such
> comment (not necessarily in those exact words) is in the Terminology
> section, said once and move on.

Thinking more about this, I now believe it is a really bad
and not just an inconvenience.  For instance, it actively
prohibits any improvement in the ability to aggregate addresses
to save space in the Address TLVs.  And, up until now, I have
not seen even one single benefit for the restriction.

Can you explain any reasons for this requirement?

In fact, if there aren't any good reasons, I think the spec
could be improved dramatically by eliminating discussions
about the prefixes.  The address aggregation encouraged by
PacketBB does not have to be tied in any way to routing
prefixes and so on.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 05 Feb 2008 14:11:29 -0800

> the logical conjunction of each individual link's
Here, I should have said, "logical disjunction".  Please
excuse the error, as well as my poor spelling.

Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 6 Feb 2008 09:35:12 -0000

> truth of it.

I can disagree with the appropriateness of it as a comment,
and do.

> But, NHDP is _not_ permitting it.  PacketBB is permitting it.

Packetbb permits multiple messages. It doesn't explicitly
permit messages from more than one protocol - it can't.

> What is it?  Where is it specified?

In section 5.1.3.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 6 Feb 2008 11:05:51 -0000

> (and therefor links). 

Yes.

> But each interface would have
> symmetric.

Yes.

> Thus, the N_symmetric flag is somehow

Yes.

And the protocol ensures that.

> are not going to come close to fixing them.

I haven't checked the exact cases you've indicated,
but the general philosophy is that when something
happens that indicates a major problem, first priority
is ensuring you maintain consistency of the local
information bases, and then drop conflicting information
(old and new). If it's conflicting you don't know what
to use, so don't use any of it and stick with what isn't
causing problems.

> In that case, this bullet should be removed.

The last such bullet I commented on, as I recall, note that
HELLO messages could share packets with messages from other
protocols. That I think is important, and should be said once.
This doesn't seem to be that once. But right now I don't have
time to check it.

> to mandate this behavior to even more assuredly use PacketBB?

packetbb doesn't specify what action to take if an entity is
malformed, it leaves it to the using protocol, which this is.
Thus this is needed.

> node to discard the other information it has?

That's a completely different point, and furthermore not the
case. If running another protocol, it's not covered by this
paragraph, it's not a malformed NHDP HELLO message, it's
something else. And there is explicit permission to add other
information to NHDP's data.

> before to make this optional.

No, there was agreement to make it optional in timetlv, so that
e.g. DYMO could use those values. NHDP really hates zero validity
times (we'd have to change some significant details in the spec)
and hence it's not allowed.

> expect that this is a case where the VALIDITY is finally

The actual meaning of INTERVAL_TIME is how long (worst case)
until the next message (as is specified) - which is meaningful
even if messages aren't regular. VALIDITY_TIME is always
needed.

> is wrong.

They are ignored by _this_ protocol, i.e. NHDP. A protocol using
NHDP may use them. Example - MPR TLV as defined in OLSRv2. OLSRv2
uses it, NHDP ignores it.

> a transition from SYMMETRIC to asymmetric but is not lost?

If a node stops hearing itself being advertised by a neighbour,
then the link status changes from SUMMETRIC to HEARD, and is
advertised as such, and the protocol handles that.

> to save space in the Address TLVs.

I think this misses the point.

All this says is that (using IPv4 examples only because
they are easier to write) if a node advertises
10.0.0.0/24 and 10.0.0.0/28 then these are different.
(And will presumably use longest prefix matching.)
Frankly most nodes won't do it, but if they do, they are
treated separately. This avoids various possible
unpleasantnesses. If a more sensible node just uses
an address with whatever prefix length it likes, fine.
Note that if a node _did_ use 10.0.0.0/24 and
10.0.0.0/28 they would compress very efficiently
(the prefix length isn't part of the compression).

More realistically address prefixes are more likely
to be used in IPv6.

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Wed, 6 Feb 2008 12:09:15 -0800

> threshold at 0.5 and you'd get the desired actions.

There can be one step or multiple steps between a lost ACK and
triggering 13.1. I don't think we should specify that lack of ACK must
change L_quality or anything like that, all we need to do is
acknowledge there might be different ways to get to 13.1 from a lost
ACK.

> (ii) on the ratio (if any) of unicast traffic -- hence somewhat

I would not say it is scenario specific because you have ACKs and the
only thing that changes with different ratios of unicast and broadcast
traffic is the granularity/accuracy/bootstrapping properties of a
subset of links.

> quality to function, AND to remain interoperable even if run

I think this is an over-specification of this protocol. What makes a
protocol like NHDP interoperable is not how you compute some numbers
but a clear definition of what the numbers are and how those numbers
are exchanged. I suggest we make that as our goal rather than
describing how a particular implementation might work.

- om_p