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

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

On 5/1/15, 7:06 AM, "Dearlove, Christopher (UK)" <[e-mail]<mailto:[e-mail]>> wrote:

Christopher:

Hi!

. . .


  1.  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.
First, I don’t agree that there will always be the possibility of non-MT nodes. Plenty of MANETs will be closed systems (cryptographically enforced even) and then we will have complete control over whether there are non-MT nodes. So that is a real case.

Yes.  I think that the text needs to tightened so that it doesn’t talk about “any possibility”, but characterizes better the fact that in many networks non-MT nodes won’t be present.  Maybe the text should be more along the lines of “if present”…

But so also is the mixed case, so we need to handle that (if we didn’t, we’d have a different design).
Yes, with the mixed case, the only metric is that type. Which means that only packets that use that metric type are universally transportable and deliverable. That poses two issues. The first is whether the network is connected using the MT-only nodes. You note one possibility, location/movement restriction. There are at least two more: a dense network so that the MT nodes themselves are sufficient, and where MT nodes are most of the nodes. I can see use cases in the latter two cases.
The second is that some nodes can’t receive packets of those additional types. Again I can see use cases. If packets are from high capacity streams then no use going to nodes that can’t handle those. There could also be a use to separate different levels of trust (though that has some implications on revealing that). I’m sure there are others.

Again, it would be good to include this type of discussion.

This second possibility doesn’t make me feel too good.  On one hand, we could say that it is just too bad that these nodes can’t receive some of the traffic..but on the other, what if they need to?  This is related to the comment below about the NMS having to make sure the network works..


  1.  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.
I (we) clearly need to look at those sections. The rules is clear, you can only forward packets consistently. I think that those points are really meant to address cases that shouldn’t happen (what if you address a packet to someone who can’t receive it?) and should probably be clearer that the role of management is to prevent the wasted resources of partly doing that. That said, right this second (when I haven’t re-read that text in detail) I’m not sure when that happens.
I think the principles should be: first, forwarding restrictions to prevent looping. Second, given how things are, manage what you try to do so as to not waste resources on what isn’t going to work. Third, try to organise things so that you aren’t in that position. In that order.

Right.  Again, some more text clarifying would be helpful.  As is, the text gives the impression that you’re talking about the general case, where explaining a little about destinations not on a specific topology and how they can’t possibly be reachable (for example) would go a long way.


  1.  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.
I think here we have two different levels being considered. This is considering what the restrictions are within the protocol. You’re considering operational considerations of what you deploy. We can make that clearer.

Thanks!  In the end I think the text just needs some clarification.

. . .


  1.  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.
If I read this correctly, you’re saying take out the reasonable length of time and as soon as possible phrases and just say after stuff is done. Fine by me.

Yes.


I think we have a path forward: make the text clearer (specially in sections 4 and 12).

I’ll go ahead and issue the IETF Last Call.

Thanks!

Alvaro.