Subject: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 12 Jul 2016 09:56:19 +0000

I haven't got to the end yet, but there are some points to make as far as I have got, and in order not to wait until finished. In particular I have a significant issue in Section 8.2.

Section 1.1 third bullet. As those scenarios haven't been established, I suggest "may" before "require". And perhaps "Some" rather than "Certain".

Section 1.1 fourth bullet, I don't see anything in the draft supporting this (delay).

Page 4, first paragraph "and" after "specification".

Page 4, third bullet, not sure what "co-relation" means.

Page 4, fifth bullet, should indicate IPv4.

Page 5, second bullet ("The disjoint ..."). I'm not sure what "by definition" means here. Obviously lost packets have no ordering. But the order of those packets left usually matters.

Page 5, last bullet. I think it's important to note that there's no work yet defining how (or indeed if) MT and MP OLSRv2 can interoperate.

Page 6 "in the air". I don't this this helps. I think we usually say "TLV Type" - I would (in due course) check that the RFC Editor makes consistent with RFC 5444 - though it can't hurt to do that as well.

Page 7, second bullet. I think it's useful to note that the reactive work is local, there are no message transmission delays introduced by it.

Section 5.1, MAX_SRC_HOPS. Why must it be set to 0 in an IPv6 network? And for IPv4 networks it must be less than 11 - but not 0. (0 is less than 11!)

CUTOFF_RATION "greater than or equal" is more idiomatic.

Section 6 first paragraph I think mixes discussion of signalling and data packets that could be clearer.

Section 6.1, first line. I think "use" is better than "share".

Section 7.1 SR_time - Tuple, not Tuples.

Section 7.2 PT_addresses. If n is the number of intermediate routers, then the hop count is n+1.

Section 8.1 "Please note that" is odd wording.

Section 8.1 "does not carry". Need normative wording. Previous discussion on why this should be "MUST NOT" (I think better than "SHOULD NOT". But then the problem is there's no explanation, and it's really easy for someone to say "why not just add ..." without an appreciation of why not.

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful to allow routers to independently pick parameters - it's why messages have validity times. This breaks that, by using a local SR+HOLD_TIME for the validity time of remote information (SR_addr). This is not acceptable. This needs to be either the validity time of the HELLO or TC message or some other mechanism. (I have not yet checked if there are any other such cases.)

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

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

********************************************************************
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: Jiazi YI <[email-masked]>
Date: Tue, 12 Jul 2016 15:55:25 +0200

Hi Chris,

Thanks for your comments. On the issue related to section 8.2 first:

On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> I haven’t got to the end yet, but there are some points to make as far as
> I have got, and in order not to wait until finished. In particular I have a
> significant issue in Section 8.2.
>
>
>
<snip>

>
>
> Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful to
> allow routers to independently pick parameters - it’s why messages have
> validity times. This breaks that, by using a local SR+HOLD_TIME for the
> validity time of remote information (SR_addr). This is not acceptable. This
> needs to be either the validity time of the HELLO or TC message or some
> other mechanism. (I have not yet checked if there are any other such cases.)
>

Actually, the SR_HOLD_TIME depends on the TC_INTERVAL, which is not local
and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?

best

Jiazi

>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> www.baesystems.com/ai
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 12 Jul 2016 16:01:34 +0000

No, that’s missing the point.

The pattern is parameter (e.g. T_HOLD_TIME) sets field in message (validity time in TC message). Expiry times in Tuples are set from validity times in messages.

Using a local parameter to set a hold time for received information is broken. You’ll see that if the parameter values are different. (Try long values at node A, short values at node B, and watch if you use B’s parameter than the information will expire before being refreshed.)

This is a must change detail.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 12 July 2016 14:55
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10

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

On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
I haven’t got to the end yet, but there are some points to make as far as I have got, and in order not to wait until finished. In particular I have a significant issue in Section 8.2.

<snip>

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful to allow routers to independently pick parameters - it’s why messages have validity times. This breaks that, by using a local SR+HOLD_TIME for the validity time of remote information (SR_addr). This is not acceptable. This needs to be either the validity time of the HELLO or TC message or some other mechanism. (I have not yet checked if there are any other such cases.)

Actually, the SR_HOLD_TIME depends on the TC_INTERVAL, which is not local and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?

best

Jiazi

T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Jiazi YI <[email-masked]>
Date: Tue, 12 Jul 2016 22:34:18 +0200

OK. Generally speaking, because the SR-OLSRv2 Router Set only servers for
identifying the source-route enabled routers (which won't change
frequently), the hold time of tuples in the set only need to be "reasonably
long enough".

To make it's more consistent with the OLSRv2 style, we will make the
SR_time depend
on the "validity time" from the TC message received (for example, current
time + 10*validity time). Is that OK?

best

Jiazi

On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> The pattern is parameter (e.g. T_HOLD_TIME) sets field in message
> (validity time in TC message). Expiry times in Tuples are set from validity
> times in messages.
>
>
>
> Using a local parameter to set a hold time for received information is
> broken. You’ll see that if the parameter values are different. (Try long
> values at node A, short values at node B, and watch if you use B’s
> parameter than the information will expire before being refreshed.)
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Jiazi
> YI
> *Sent:* 12 July 2016 14:55
> *To:* Dearlove, Christopher (UK)
> *Cc:* [email-masked]
> *Subject:* Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10
>
>
>
>
>
> **** 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 Chris,
>
>
>

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 12 Jul 2016 23:23:15 +0100

No, I'm not happy with that, I don't like the arbitrary 10. It fails the careful design principles we have for OLSRv2, because the receiver is making assumptions about the transmitter that may not be appropriate - because it doesn't know.

This needs more thought. I can think of some options, among them giving this TLV a value field with a validity time 5497 style. But maybe someone has a better idea.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 12 Jul 2016, at 21:34, Jiazi YI <[email-masked]> wrote:
> 
> OK. Generally speaking, because the SR-OLSRv2 Router Set only servers for identifying the source-route enabled routers (which won't change frequently), the hold time of tuples in the set only need to be "reasonably long enough". 
> 
> To make it's more consistent with the OLSRv2 style, we will make the SR_time depend on the "validity time" from the TC message received (for example, current time + 10*validity time). Is that OK?
> 
> best
> 
> Jiazi
> 
>> On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>> T:  +44 (0)1245 242194  |  E: [email-masked]
>> 
>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>> If you feel the email is suspicious, please follow this process.
>> 
>> Hi Chris, 
>> 
>>  
>> 
>> On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>> 
>> T:  +44 (0)1245 242194  |  E: [email-masked]
>>

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 12 Jul 2016 23:42:12 +0100

Slightly better idea (I think). Make the value field a multiplier of the validity time rather than a time itself. Still not totally happy, but I think better.

Unless someone can do better still.

> On 12 Jul 2016, at 23:23, Christopher Dearlove <[email-masked]> wrote:
>

---

From: Jiazi YI <[email-masked]>
Date: Wed, 13 Jul 2016 10:03:27 +0200

I prefer having a 1-octet multiplier value field for the SOURCE_ROUTE TLV.

Jiazi

On Wed, Jul 13, 2016 at 12:42 AM, Christopher Dearlove <
[email-masked]> wrote:

> Slightly better idea (I think). Make the value field a multiplier of the
> validity time rather than a time itself. Still not totally happy, but I
> think better.
>
> No, I'm not happy with that, I don't like the arbitrary 10. It fails the
> careful design principles we have for OLSRv2, because the receiver is
> making assumptions about the transmitter that may not be appropriate -
> because it doesn't know.
>
> This needs more thought. I can think of some options, among them giving
> this TLV a value field with a validity time 5497 style. But maybe someone
> has a better idea.
>
> --
> Christopher Dearlove
> SR_time depend on the "validity time" from the TC message received (for
> example, current time + 10*validity time). Is that OK?
>
> best
>
> Jiazi
>
>> Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful
>> to allow routers to independently pick parameters - it’s why messages have

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 13 Jul 2016 09:16:43 +0100

> On 13 Jul 2016, at 09:03, Jiazi YI <[email-masked]> wrote:
> 
>> On Wed, Jul 13, 2016 at 12:42 AM, Christopher Dearlove <[email-masked]> wrote:

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 13 Jul 2016 09:18:12 +0100

So do I. (Open to anyone with a better idea of course.)

[I might have accidentally sent an empty message before this one. If so, apologies.]

-- 
Christopher Dearlove