Re: [Gen-art] Gen-ART Telechat review of draft-ietf-manet-olsrv2-metrics-rationale-03.txt

["Dearlove, Christopher (UK)" <[e-mail]>]

Thank you for this, some comments below, marked CD> (Generally, where I haven't commented, I think the point is good.)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: [phone] |  Fax: [phone]
[e-mail] | http://www.baesystems.com

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: Suresh Krishnan [mailto:[e-mail]] 
Sent: 23 April 2013 23:03
To: [e-mail]; General Area Review Team
Subject: Gen-ART Telechat review of draft-ietf-manet-olsrv2-metrics-rationale-03.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-manet-olsrv2-metrics-rationale-03.txt
Reviewer: Suresh Krishnan
Review Date: 2013/04/23
IESG Telechat date: 2013/04/25

Summary: This document is almost ready for publication as an
Informational RFC but I do have some comments you may wish to address.

Major
=====

* Section 5.6 Link Metrics

I had a hard time understanding this section as a whole and specifically
the metric calculation. Intuitively, it was clear to me that you cannot
squeeze 2^24 values into 12 bits :-). So the question immediately became
what values get left out.

If I understand correctly for a given value of b, each increment of a
increases the metric value by 2^b. If my understanding is correct (my
apologies if it is not), please consider modifying the text to clarify
the following

-> The compressed metric is lossy and is not capable of representing
*all* metric values in the range 2^24-2^m. The larger the value of b
more the values that cannot be represented.
-> Two metric values that are different can result in the same
compressed metric and hence cannot be really compared for equality as
described in the section. e.g. metric value 821 and 822 would be mapped
into the same compressed metric and a comparison will conclude that they
are equal.
-> Describe a short algorithm for converting a metric value into a
compressed metric. i.e. Given a metric value x, how to obtain a and b
from it. e.g.

b=log2(x+256)-9

CD> Such an algorithm is already in the OLSRv2 draft, it does not seem necessary to repeat it. It could of course be referred to.

* To achieve interoperability and to avoid loops, the values of e and m
need to be the same across the network. The following sentence seems to
allow for other values of e and m ("An appropriate pair..."). Suggest

OLD:
The required 24 bit limit can be achieved if 2^e+m = 24. An appropriate
pair of values to achieve this is e = 4, m = 8.

NEW:
The required 24 bit limit can be achieved if 2^e+m = 24. Since e+m=12,
solving for e and m will lead to e = 4, m = 8.

CD> The NEW text is incorrect, because it assumes e+m = 12 was an input to the process. Rather those possible pairs that satisfied 2^e+m = 24 were considered, and the preferred (e.m) pair selected, which conveniently gave e+m=12. (I remember when first doing this, and the satisfaction that it gave 12, which left the 4 bits we wanted, but up to that point were doing differently, was great - sometimes things do work out well.) So while the point that this is fixed is good (but clearly in OLSv2 a single choice is used) different alternative wording would be needed.

Minor
=====

* It is unclear to me how the metrics can be configured to handle the
privileged relay aerial router case described in Section 4. Assume there
is a cost metric on the link to/from the aerial router, would this be
set to low or high (I would assume high)? If the metric is set high, the
ground routers may route through several low quality links which seem to
have a lower path metric but may end up underusing the aerial link. Are
there any guidelines in this regard?

CD> Clearly you set the aerial link metric high. If you want to ensure it is only used when absolutely necessary, you could set it to maximum. If you want to allow it in some cases rather than multiple ground links, you set it accordingly - if you want to use an aerial link rather than N ground links with metric 1, set it to N/2 (up and down). It's more complicated if ground links have variable metrics. But guidance on how to do this is beyond the scope of this document, which describes what has been done, and that would not be that. (There is a gap the authors are aware of for a broader informational document -ID/RFC or other format - on use of options in OLSRv2, not just on metrics. Unfortunately so far we haven't had the available time to do so, and can't see that time being available soon.)

Thanks
Suresh



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