Last Call Review of draft-ietf-manet-olsrv2-metrics-rationale-02

Request Review of draft-ietf-manet-olsrv2-metrics-rationale
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-03-11
Requested 2013-02-28
Draft last updated 2013-03-11
Completed reviews Genart Last Call review of -02 by Suresh Krishnan (diff)
Genart Telechat review of -03 by Suresh Krishnan (diff)
Secdir Last Call review of -02 by Stephen Kent (diff)
Assignment Reviewer Suresh Krishnan
State Completed
Review review-ietf-manet-olsrv2-metrics-rationale-02-genart-lc-krishnan-2013-03-11
Reviewed rev. 02 (document currently at 04)
Review result Ready with Issues
Review completed: 2013-03-11


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see


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.


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


* 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

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.

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.


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