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

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 1 May 2015 11:06:35 +0000

Alvaro

Thanks for your comments.

Comments inline below. Not yet discussed with co-author.

Christopher

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: 30 April 2015 16:51
To: [email-masked]
Cc: [email-masked]
Subject: [manet] AD Review of draft-ietf-manet-olsrv2-multitopology

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
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.
I suspect that we didn't use MUST as that was outside this protocol.  But I have no problem with this being a MUST.

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

  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.

  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.
Conceptually, his is nothing new. Without MT we can build a MANET using two frequencies, equip some nodes to use A, some to use B and some to use A and B. We use the multi-interface capabilities of OLSRv2. It's all legal OLSRv2. It also won't work if you do it badly (in particular not enough dual channel nodes). We need to sensibly equip and deploy. That's true here (though the rules aren't the same).

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.
XXXX appears in just two places, one is the top left of the document, the other matches it in the abstract. Neither is a reference, and we can't do that in the top left one.

  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. Thomas, can you shed any light here since you know people using this?
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
Thanks.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 1 May 2015 21:00:32 +0000

On 5/1/15, 7:06 AM, "Dearlove, Christopher (UK)" <[email-masked]<mailto:[email-masked]>> 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.