Re: [manet] draft-ietf-olsrv2-multipath-09

["Dearlove, Christopher (UK)" <[e-mail]>]

I think this is really a comment for Jiazi. I’m not suggesting adding a reference to RFC 6554, that reference is already in the draft.

I’m saying that if you reference RFC 6554, you’re referencing something that doesn’t apply unless and until you add some text to make it apply.

Whether that is a terrible awful thing that should not be done (not my words - in fact I don’t recall commenting on that aspect of AODVv2) is up to the community to judge.

But input from the people who have implemented this draft would be useful. Did they find RFC 6554 already in place? Already implemented and portable to in place? Had to write in from scratch? Didn’t actually use RFC 6554 but something else (e.g. deprecated RH0)? Only implemented for IPv4?

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

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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: Ratliff, Stanley [mailto:[e-mail]]
Sent: 23 June 2016 15:02
To: Dearlove, Christopher (UK); MANET IETF
Subject: RE: [manet] draft-ietf-olsrv2-multipath-09


*** 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>.
Chris,

I see your point on RFC 6554. But didn’t we *just* go through an exercise with AODVv2 where that draft attempted to reference a RPL RFC, and the consensus of the WG was that this was a “terrible, awful thing that should not be done”?????

Regards,
Stan

From: manet [mailto:[e-mail]] On Behalf Of Dearlove, Christopher (UK)
Sent: Thursday, June 23, 2016 9:50 AM
To: MANET IETF <[e-mail]<mailto:[e-mail]>>
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

Digging further, there was a draft-reitzel-ipv4-source-routing-is-evil-00 that pointed out that IPv4 source routing had exactly the same problems as the deprecated RH0 IPv6 source routing, and recommended deprecating that. But the draft never preceded further. I don’t know why. I have seen it indicated that most operators drop such packets, so maybe it wasn’t felt necessary.

As for why RFC 6554 avoids the RH0 problem, essentially it defines it away: “a RPL router drops datagrams that include multiple addresses assigned to any interfaces on that router to avoid forwarding loops” Note that’s not as simple as dropping datagrams with duplicate addresses, it also includes dropping datagrams with two addresses of the same interface - which only that router can do.

So, in order to use RFC 6554 source routing here, we need to (a) say that a required condition is that the MANET routers support RFC 6554, because that RFC itself only specifies this for RPL routers, and (b) that they must support the required features in particular the datagram suppression noted above.

But, I wouldn’t expect a typical router currently to do this, because it won’t be “an RPL router” - here input from people who have done this hands on would be useful, did they have to add this functionality?

And for IPv4, need (loose) source routing to be supported within the MANET, which again it may or may not be.

(Note that RFC 6554 source routing isn’t the same as RH0 source routing, because RFC 6554 source routing includes compression.)

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

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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:[e-mail]] On Behalf Of Dearlove, Christopher (UK)
Sent: 23 June 2016 10:39
To: Jiazi YI; Christopher Dearlove
Cc: MANET IETF
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09


*** 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>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Coincidentally, I was reading about IPv6 source routing, and the deprecation of RH0 in RFC 5095. RFC 6554 that you refer to claims to have resolved the security concerns that led to that deprecation. Part of that is that RFC 6554 is only defined as working in an RPL domain. Now that can probably be generalised to a MANET - but I don’t think you’ve done that, and so I think that needs doing.

I’m then left wondering if the security threat described in RFC 5095 applies to IPv4 source routing. (I’m afraid I haven’t had time to dig into this, the coincidence has only just happened, and I thought better to get an incomplete question out.) RFC 5095 doesn’t discuss IPv4 at all, but the basic problem (repeating an address in a source route as an attack) would appear to still apply. I haven’t understood yet how RFC 6554 avoids this. It’s possible that RFC 5095 doesn’t consider IPv4 on the basis that most people have given up on it, or just it wasn’t of interest to the authors.

At the minimum I think the draft needs to comment on extending RFC 6554 to MANETs not RPL domains. Ideally (this may or may not cause added security considerations) someone with a better knowledge of this area (practical as well as theoretical) will comment on the above.

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

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Jiazi YI
Sent: 21 June 2016 22:24
To: Christopher Dearlove
Cc: Dearlove, Christopher (UK); MANET IETF
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09


*** 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>.
We will add some text to make it more precise.

best

Jiazi

On Tue, Jun 21, 2016 at 1:02 AM, Christopher Dearlove <[e-mail]<mailto:[e-mail]>> wrote:
"Because the encoded blocks are unordered for FEC" is, at best, only applicable to some FEC methods, it's definitely not universal.

--
Christopher Dearlove

On 20 Jun 2016, at 23:41, Jiazi YI <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

On Mon, Jun 20, 2016 at 5:56 PM, Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>> wrote:
Comments below.

Short version, still some points I think can be improved. Down to one sticking point, on deciding on how to handle changes to, and cessation of, the reactive set. (Longer text below.) I think this is a real issue. Take a look at what you do in your implementation - now see if someone could work out to do that from the text. I don’t think they can.


we clarified this in the draft. Please check the our detailed reply below.

<snip>

Page 5, second bullet. How does FEC help with packet re-ordering?

Normally, the packets are coded in different "blocks" and those blocks are transmitted in different paths. The arriving order of those "blocks" is less important.

CMD> I still don’t see how it helps with packet re-ordering.

When FEC is applied, the encoder takes one or several packets and produce several coded blocks (denoted block-1, block-2, ... block-n). Those blocks are forwarded as IP datagrams in the disjoint paths. Because the encoded blocks are unordered for FEC, the arriving order of the encoded blocks of the same packet(s) doesn't really matter.


<snip>
Page 6, first paragraph. I still disagree with characterising as low data rate links. At most the protocol multiplies capacity by a small factor, not the orders pf magnitude that link capacities span.

We won't claim that there will be orders of magnitude that link capacities span, but it would be beneficial to have aggregated throughput and load balancing.

So what do you think of:

MP-OLSRv2 is designed for networks with dynamic topology by avoiding single route failure. It can also provide higher aggregated throughput and load balancing, which is beneficial for low data rate links.

CMD> Still not convinced by the phrase low data rate links. The issues are ones of load relative to network capacity, and in particular if there are underutilised parts of the network. Plus of course a redundancy issue if packets do not all need to arrive. These can all occur in high data rate networks as much as low data rate ones.


It makes sense. I'm OK with removing the text related to low data rate links.

<snip>

PT_… What about hop count? Elsewhere in OLSRv2 we record that as well (e.g Routing Set).

Actually, the number of the items in the array PT_address[1...n] already gives the hop count -- is it necessary to repeat the information with an additional field? It is not used anyways.

CMD> That it’s there could be called out. It gets used in OLSRv2 as a suggested tie-breaker, and some tools might use it. I thought I’d made a comment to say what n is, which I don’t see here. This can combine with that

Yes. we added some text on what "n" is.

<snip>
A major omission is discussion of expiry of new Tuples without expiry times. If proactive you can (but don’t) discuss when supporting sets change.
If reactive it’s rather a mess (a reason I dislike the reactive mechanism). When to discard? When to recreate? If dependent on packet flow then that’s another interaction with IP to document - and implement.

The update of the the Multi-path routing set is described in section 8.6. The expiry timers are removed since -07 based on the comments received. One of the reasons is to be consistent with the OLSRv2 routing set, in which no expiry timer is used.
Generally speaking, in proactive mode, it follows the same mechanism as OLSRv2: when ever there is a need to update the OLSRv2 routing set, the multi-path routing set is updated.
In reactive mode, all the Multi-path routing tuples are removed when the "topology graph" is changed.  The new tuples are recreated "on-demand".

CMD> OK, let’s think about that in the reactive case. (Proactive is easy, but it needs to be said, which it isn’t.) You want a set, you generate it on demand. There is a change to the Topology Graph. So do you recalculate the set?

No, at this point, we only clear the entire Multi-path Routing Set.

If not then you introduce a stutter, as the packets are flowing and the set disappears and you need to trigger it again.

Yes, it necessary to trigger the calculation again. But the time required is trivial, because this is only local: no additional message exchange with other routers is required.

Which means monitoring for that throughout a flow, not just at its start.

We don't actually have the concept "flow" in this extension. For each datagram, yes, it's necessary to check if a tuple exist or not. There is no much difference from checking the FIB for IP.

If you do (recalculate the set when the graph changes) how do you know when to stop calculating it? That depends on knowing when the flow stops.
And “the Topology Graph changes” is more than is required - some changes to the graph would have no effect (for example the increase in metric of a link not being used). But it’s hard to specify.

For the moment, we simply take "the topology graph changes", because even links that not used might matters: for example, the decrease in metric of a not used metric that introduces a better path.
It's true that it's possible that it's more than required and could be optimised in the future, but considering it's a reactive approach, I believe it's acceptable.

On this point (which changes) some sort of permissive wording to indicate that you can avoid making changes when you know they don’t matter is probably right. The when do you stop calculating question is more important - and needs text discussing it.


You could when acting reactively forward by usual means in all cases while waiting.

The actual packet forwarding by round-robin is an IP process, not this protocol. Needs to not be buried in 8.4. And if it’s an IP process, why mandate exactly how it’s used?

Choosing which path to put in the source routing header is olsrv2-multipath specific, because there are multiple of them. Of course, using round-robin is not mandatory -- using other schedulers won't impact the compatibility. Actually, we put it as one of the experiment points also:

 Different path-selection schedulers.  By default, Round-Robin
      scheduling is used to select a path to be used for datagrams.  In
      some scenarios, weighted scheduling can be considered: for
      example, the paths with lower metrics (i.e., higher quality) can
      transfer more datagrams compared to paths with higher metrics.

CMD> This is missing my point. It’s not the round-robin that matters, it’s that IP needs to do anything. That’s what needs not to be buried. Putting together a clear “what IP needs to do” section early on, perhaps in the applicability section, is needed.


We added the following text in the applicability statement:

MP-OLSRv2 supports two different, but interoperable multi-path calculation approaches: proactive and reactive. In the proactive calculation, the paths to all the destinations are calculated before needed. In the reactive calculation, only the paths to desired destination(s) are calculated on demand. The proactive approach requires more computational resources than the reactive one. The reactive approach requires the IP forwarding plan to trigger the multi-path calculation.

MP-OLSRv2 forwards datagrams using the source routing header. As there are multiple paths to each destination, MP-OLSRv2 requires the IP forwarding plan to be able to choose which source route to be put in the source routing header based on the path scheduler defined by MP-OLSRv2. For IPv4 networks, implementation of loose source routing is required following [RFC0791]. For IPv6 networks, implementation of strict source routing is required following [RFC6554].

As usual, an updated draft is attached, in case needed.

regards

Jiazi



<draft-ietf-manet-olsrv2-multipath.txt>


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

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________