[manet] AD Review of draft-ietf-manet-olsrv2-multitopology

["Alvaro Retana (aretana)" <[e-mail]>]

Hi!

I have some concerns about the operation in a mixed environment of MT-OLSRv2  and non-MT-OLSRv2 routers as explained in Sections 4 and 12.  In short, the operation in a mixed environment needs to at least be clarified probably using stronger language in some places, but there may be some parts where it has to be rethought (see my comments below).  It may be beneficial to have a live conversation about this topic as it may be slower through e-mail (and it may be that I need help seeing things clearer) — if you want to, please give me some options and we’ll then summarize for the list.

I would like to have at least an agreement from the authors about the path forward before starting the IETF Last Call.

Thanks!

Alvaro.


Major:

  1.  Section 3. "It is assumed, but outside the scope of this specification, that the network layer is able to choose which topology to use for each packet…This selection of topology must be consistent, …This is necessary to avoid the possibility of a packet "looping" in the network.”  While how the selection is done may be out of scope, being a little stronger about the need for consistency (s/must/MUST) would be nice.
  2.  Sections 4 and 12.  4 reads: “..the single link metric used by these non-MT-OLSRv2 routers must be included in the set of link metrics for each OLSRv2 interface of an MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non-MT-OLSRv2 router in the MANET”, and then 12 adds "Note that if there is any possibility that there are any routers not implementing MT-OLSRv2, then the MANET will be connected, to the maximum extent possible, using the link metric type LINK_METRIC_TYPE.”   I would think that there is always a possibility that non-MT-OLSRv2 routers exist..does this then mean that the only metric type would be LINK_METRIC_TYPE everywhere?  I guess that theoretically you can constrain the movement of nodes so that they only may be  present in a subset of the MANET, but their existence in a network (as characterized: "any possibility that there are any routers not implementing MT-OLSRv2”) would then seem to cause a specific behavior.
  3.  Section 12: Related to the consistency in making forwarding decisions, the text in the last bullet implies that different topologies may be used to forward a packet in some cases.  Even though you also wrote  that "All routers must make the same decision for the same packet."
     *   For example, “..then routing may work if the first router implementing MT-OLSRv2 to receive the packet supports the appropriate link metric type”.  Just saying that “routing may work” doesn’t provide a lot of confidence.  What about the other routers in the path?  Didn’t you say before that the topology selection must be consistent?  How do you prevent looping if the topology used in the first couple of hops may not exist elsewhere?
     *   "If such a router is the destination, then the packet will never reach its destination, as the source will not have a suitable routing table entry for the destination.  Network management may be required to ensure that the MANET still functions in these cases.”  How would network management ensure that the MANET still works?  The obvious answer is to ensure that the “base topology” exist everywhere, which goes back to my question above about using the link metric type LINK_METRIC_TYPE everywhere.
  4.  Section 4: "If all routers in the MANET implement MT-OLSRv2, then there are no restrictions on how these sets of link metrics are selected.”  Isn’t a minimum restriction the fact that they should somehow be consistent across interfaces?  If not then the packets will either not reach their destination or be forwarded using different topologies.

Minor:

  1.  For clarity while others review it, please change “RFC XXXX” to the draft-ietf-manet-tlv-naming reference.  The RFC Editor should take care of fixing the references.
  2.  Section 1.1 "This specification is published to facilitate collecting such experience, with the intent that in a reasonable period of time after the acceptance of this specification as an Experimental RFC (as soon as possible after experimental evidence is collected), an OLSRv2 Multi-Topology Routing Extension will be proposed for advancement onto Standards Track.”  How long are a “reasonable period” and “as soon as possible”?  I understand what the intent is here, defining the experiment in terms of collection of experience is fine, but bounding it with ill-defined (and prone to all kinds of interpretation) terms doesn’t help anyone.  I would rather you focus on what you want to do (collect experience) and then we can think about changing the status whenever we’re ready to do so.

Nits:

  1.  Section 1. s/However in some MANETs it would be desirable to be route packets/However in some MANETs it would be desirable to be able to route packets