Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale
draft-ietf-manet-olsrv2-metrics-rationale-04

I like this type of rationale document. This is something that the IETF generally doesn't do, with the consequence that resolved issues are revisited on regular basis. I wish I had this document at the time of reviewing draft-ietf-manet-olsrv2. It could have been an appendix in draft-ietf-manet-olsrv2 btw.

-
There is no "manageability considerations section". http://tools.ietf.org/html/rfc5706#appendix-A for a list of questions.
Specifically regarding the metrics, the following question comes to mind: what about connecting different MANET networks together, if the metric convention (for a lack of a better word) is not the same. For example: delay, hop count. Note that this metric "convention" is only the operator head AFAIK.

   In a well-designed network, all routers will use the same metric
   type.  It will not produce good routes if, for example, some link
   metrics are based on data rate and some on path loss (except to the
   extent that these may be correlated).  How to achieve this is an
   administrative matter, outside the scope of OLSRv2. 

Yes, there is the above sentence, but that's all there is in terms of manageability and operations.
Topics such as merging network, potential notification or polling) for metric mismatch (*), etc..
Maybe that's fine because it's a rational document, that's something that should be solved in the manageability draft http://tools.ietf.org/html/draft-nguyen-manet-management-00 ?

(*) 

   Note that, using directional metrics, if router A defines the metric
   of the link from router B to router A, then router B must use router
   A's definition of that metric on that link in that direction.
   (Router B could, if appropriate, use a bad mismatch between
   directional metrics as a reason to discontinue use of this link,
   using the link quality mechanism in [RFC6130].)

- terminology

   All terms introduced in [RFC5444], including "message" and "TLV", are
   to be interpreted as described there.

   All terms introduced in [RFC6130], including "MANET interface",
   "HELLO message", "heard", "link", "symmetric link", "1-hop neighbor",
   "symmetric 1-hop neighbor", "2-hop neighbor", "symmetric 2-hop
   neighbor", and "symmetric 2-hop neighborhood", are to be interpreted
   as described there.

   All terms introduced in [OLSRv2], including "router", "OLSRv2
   interface", "willingness", "MultiPoint Relay (MPR)", "MPR selector",
   and "MPR flooding" are to be interpreted as described there.

This is a typical example where not using capitalized terms (when specified in the terminology section), is a problem.
Specifically because of the common terms such as heard, link, message, willingness, etc...
Let's take the 3 "heard" instances in the paragraph below. Which one(s) is/are a definition coming from RFC 6130?

    When a router reports a 1-hop neighbor in a HELLO message, it may do
    so for the first time with link status HEARD.  As the router is
    responsible for defining and reporting incoming link metrics, it must
    evaluate that metric, and attach that link metric to the appropriate
    address (which will have link status HEARD) in the next HELLO message
    reporting that address on that OLSRv2 interface.  There will, at this
    time, be no outgoing link metric available to report, but a router
    must be able to immediately decide on an incoming link metric once it
    has heard a 1-hop neighbor on an OLSRv2 interface for the first time.


-
A couple of acronyms must be expanded on the first occurrence: TC message, MPR. Potentially others

I believe the mail exchange between Suresh and Cristopher has been useful, and should result in some document changes. It looks the authors have this under control, but I'm hoping the thread finishes before the document is cast in stone.

- intro, "legacy OLSRv2 routers" is an odd phrase, I think I
know what you mean but maybe try clarify. What I think you
mean is "routers that implement OLSRv2 without the putative
link-metrics extension"

- section 4, last para: I hope that some other doc also says
that link metrics should change slower than that update rate.
If not, then this is being a bit more than just background
informational stuff. (Just checking in case it got lost or
something.)

- 5.5, "unless link quality indicates otherwise" seems odd.
You're explaining link metrics via "link quality"?  If that's
not another well known OLSR term, maybe better to just say
"unless the implementation decides otherwise" or something?

- 6.1, s/produce produce/produce/

- section 8: I'm a bit surprised there's nothing to say since
I would have thought that telling lies about metric values
provides another way in which an OLSR router can do bad
things, such as ensure traffic is sent the way the bad router
wants. If that's the case then maybe saying so and how it
doesn't make things worse really would be good. If that's not
the case, the saying why would be good. 

- section 8: Just a query: has there been any (good) work on
using routing metrics as a countermeasure? E.g., gossiping
about node reputations? If there were something good along
those lines, here might be a fine place to note that (even if
it wasn't part of the WG discussion).

It would have been useful to the reader if MPR had been defined, or at least expanded in the draft.