Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
draft-ietf-manet-olsrv2-multipath-15

I am not a MANET person, and know very little about the Optimized Link State Routing Protocol, however I found this document to be very vague and poorly worded in many places. At some point I simply gave up trying to understand it, but have concerns that it is not sufficiently clear for independent implementations. 

I almost made these a DISCUSS, but, as I said, I'm not a OLSR person, and so I'm trusting Alvaro to know if it is deployable / implementable

Comments: 
S1.1: 
"The multi-path extension for OLSRv2 is expected to be revised and improved to the Standard Track," - I'm not sure an extension can be "improved to the Standard Track" - perhaps you mean that the documents will be improved and published as Standards track? Or that once implementations are more stable they will be documented on Standards Track?

"Although with existing experience, multiple paths can be obtained even with such partial information,  the calculation might be impacted, depending on the MPR selection algorithm used." - I don't understand the "with existing experience", and this sentence is a fragment. I suspect that removing " with existing experience," would make this cleaner, but I don't really understand what you are trying to say...

"Different algorithms to obtain multiple paths, other than the default Multi-path Dijkstra algorithm introduced in this specification." - this should have a reference to somewhere in the document.


5.1:
 "CUTOFF_RATIO   The ratio that defines the maximum metric of a path
 compared to the shortest path kept in the OLSRv2 Routing Set. For
  example, the metric to a destination is R_metric based on the
  Routing Set." - I don't understand what the last sentence is trying to say. 

 "CUTOFF_RATIO MUST be greater than or
      equal to 1.  Note that setting the value to 1 means looking for
      equal length paths, which may not be possible in some networks."
  -- surely setting it to 2 (or any other number) will also end up looking for paths which might not be possible?
  E.g:
        ┌──┐  ┌──┐  ┌──┐  ┌──┐        
  ┌────▶│R1│─▶│R2│─▶│R3├─▶│R4│─────┐  
  │     └──┘  └──┘  └──┘  └──┘     ▼  
┌───┐            ┌──┐            ┌───┐
│ S │───────────▶│R6│───────────▶│ D │
└───┘            └──┘            └───┘

"SR_HOLD_TIME_MULTIPLIER  The multiplier to calculate the minimal time
      that a SR-OLSRv2 Router Tuple SHOULD be kept in the SR-OLSRv2
      Router Set. It is the value of the Message TLV with Type =
      SOURCE_ROUTE." - this is vague / confusing. I think that you need a reference to Sec 6.1.1. 


 9.  Configuration Parameters
 "the users of this protocol
   are also encouraged to explore different parameter setting in various network environments, and provide feedback."  -- where?


12.  "IANA Considerations
   This section adds one new Message TLV, allocated as a new Type
   Extension to an existing Message TLV."
  -- this section seems to be missing some important information, like which registry this updates Message Type 7 in.




Nits: 
S1.1:

"Because the packet drop is normally bursty in a path" -- "Because packet drops on a path are normally bursty"...

"Other than general experiences including the protocol specification and interoperability with base OLSRv2 implementations, the experiences in the following aspects are highly appreciated:"
s/ experiences including/ experiences, including / (grammar)
s/ the experiences / experiences / (grammar)

"Although with existing experience,  multiple paths can be obtained even with such partial information,  the calculation might be impacted, depending on the MPR selection algorithm used."
s/Although with existing experience/Although, with existing experience/ (grammar)

"In scenarios where the length of the source routing header is critical, the loose source routing can be considered."
s/ the loose source /  loose source /

"for  example, the paths with lower metrics (i.e., higher quality) can transfer more datagrams compared to paths with higher metrics." -- nit:  many people (perhaps incorrectly) associate 'datagram' with 'UDP' - you might want to clarify (or just say packet)

S3:
"MP-OLSRv2 is designed for networks with dynamic topology by avoiding single route failure." - this makes it sound like it was *designed* by avoiding single route failure.

"in IPv4 networks the interoperability is achieved by using loose source routing header;" - in IPv4 networks interoperability is achieved using loose source routing headers;" (or "by using the loose...")

S4:
"The reactive operation is local in the router" - "local to the router" 

S5.1: 
"All the intermediate routers MUST be included in the source routing header, which makes the number of hops to be kept a variable."
 -- I don't understand how the "the number of hops to be kept" is "a variable"; this makes it sound like I can set the number of hops to be kept. Perhaps you meant "a variable number of hops" or "the number of hops changes"?

I reviewed the -12 version of this document, and had a comment I was going to make about dropping packets when no contiguous path of source-routing capable routers existed between the endpoints; but when I went to quote the offending text, discovered that it has been fixed in the ink-is-still-wet -13 version of the document, dropped one day before the telechat.

To highlight for anyone else who has similarly reviewed the -12 version: the only other non-editorial change I find is that avoiding fragmentation has been demoted from normative to non-normative (see the last two paragraphs of section 8.4). My intuition is that fragmentation is sufficiently disruptive that normative language is called for here, but I don't feel strongly about it.

Thanks for addressing my discuss and my comments!

I find it really strange that this document uses an experimental Routing header type codepoint (254) but requires the processing to be same as the RPL Routing header (Type 3). Is there a reason things are done this way instead of just using the Type 3 header as is?