Subject: [manet] Some general comments for dymo-23/24

From: Jiazi YI <[email-masked]>
Date: Wed, 7 Nov 2012 10:37:26 -0500

Hi, 

I had a detailed review of dymo-23 draft. Because the editor is still working on dymo-24, and there are many changes on the text between those two revisions, I'm just putting some general comments. 

Those comments are mainly based on observations of dymo-23, but I think they still hold after a quick reading through of dymo-24 http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24d.txt

1. It's not clear how metric are used and calculated, and how different metrics can be supported (according to the specification, only hop-count metric can be used). 

2. Don't know how uni-directional links should be handled. There is some text mentioning blacklist, etc, but no specification on the details. 

3. No full RFC5444 compliance. Especially there are violations between the IP layer and RFC 5444 message layer. In the meantime, the use of TLVs is unclear, and I don't know how to map some of the fields to RFC5444 TLVs. 

4. How to use jitter is not specified. 

5. Although there is a short section 5.9 declaring DYMO can be used with multiple interfaces, the specification is in lack of text & information bases to support it. 

6. The protocol says that it maybe operate at different layers, but the whole specification is bind to IP. 

7 . Too much SHOULD in the text, without further explanation why not MUST.  

8. The whole specification is full of different optional features (intermediate RREP, blacklist, message aggregation, etc...), without further information when to use them, and how to do with them. 

best

Jiazi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 07 Nov 2012 07:52:53 -0800

Hello folks,

The AODVv2 specification has certain optional features; each
one is in the current specification for pretty good reasons.
I believe that once these optional features are completed,
and modified according to WG consensus, it is likely that no
other optional features will be included.  If there is WG consensus
for removing some of the optional features, that is also fine
of course; as yet another alternative, a feature could be moved
to another document.

The exception would be to allow for alternate metrics.
I have a proposal for that, which I will propose to the list
shortly by way of raising an issue on the issue tracker.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 07 Nov 2012 08:06:17 -0800

Hello Jiazi,

Congratulations on your field goal last night :-)

Thanks for your general comments.  I'll just make some general
follow-up.  I am continuing to work on bringing consistency and
clarity to the document, and your comments are helpful.

On 11/7/2012 7:37 AM, Jiazi YI wrote:
>
> 1. It's not clear how metric are used and calculated, and how 
> different metrics can be supported (according to the specification, 
> only hop-count metric can be used).

My proposal is to replace all existing metric calculation and 
description in the
document to be specifically about HopCount, and to make the appropriate
changes to terminology (so, for instance, replace Route.Dist by 
Route.HopCount).

>
> 2. Don't know how uni-directional links should be handled. There is 
> some text mentioning blacklist, etc, but no specification on the details.

There is some specification now about blacklist.  More about this 
below.  While more
could be added to the specification, it is more of a layer-2 feature and 
any layer-3
support should be considered optional.

>
> 3. No full RFC5444 compliance. Especially there are violations between 
> the IP layer and RFC 5444 message layer. In the meantime, the use of 
> TLVs is unclear, and I don't know how to map some of the fields to 
> RFC5444 TLVs.

I think that one could probably "guess right" given the current information
in the specification, but I agree this is an urgent area for 
improvement.  My
intention to make this crystal clear, hopefully today.

> 4. How to use jitter is not specified.

I'm open to suggestion on this.  Should I take a look at LOADng and follow
the example from that document?  Previous versions of AODV have not
been very precise on this point.

>
> 5. Although there is a short section 5.9 declaring DYMO can be used 
> with multiple interfaces, the specification is in lack of text & 
> information bases to support it.

Actually, I don't see what else needs to be done.  I believe that with 
proper
IP address management, there is little else that is required.  But I 
know that
OLSR has in the past paid a lot of attention to this, and I am open to 
suggestion.

> the whole specification is bind to IP.

It has been suggested that I simply remove that text.  It's not really
normative, and only meant to inspire people who might wish to make
the appropriate modifications for their layer.  For instance, I think you
could do the same protocol with some modifications for overlay
routing :-)

> 7 . Too much SHOULD in the text, without further explanation why not 

I agree.  Once the specification is stable, I will attend each one of these
details.

>
> 8. The whole specification is full of different optional features 
> (intermediate RREP, blacklist, message aggregation, etc...), without 
> further information when to use them, and how to do with them.

Point noted...  For each optional feature, I will include more description
about when it might be useful.  Thanks for your additional motivation to
get this done.  In particular, blacklisting should be optional because
in many situations AODVv2 can rely on layer-2 information describing
whether or not the link is bidirectional.

-- 
Regards,
Charlie P.

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Wed, 7 Nov 2012 16:07:33 +0000

Hi Charlie,

I carefully looked at these options and I do think that we should be careful not adding any more
indeed, although I could not find options that we should a priori remove. But may be should we 
do the exercise of the looking at them one by one and discuss on whether to keep them or not ?

Thanks.

JP.

On Nov 7, 2012, at 10:52 AM, Charles E. Perkins wrote:

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