Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-08 WGLC finished

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 1 Jun 2016 14:21:41 +0000

I will at some point find my editorial comments.

While the below is generally as discussed, I don’t think the SR_TC_INTERVAL point captures all of my concern.

We have some routers putting out infrequent TCs. This must mean they have long validity times. But there is nothing inherently different about those links, they can be chosen by pot luck.

(Example, four routers in a square, all sides are links, diagonals are not. Each will pick one neighbour as an MPR. Each link will have a 1/2 chance of being advertised in each direction, all else being equal.)

So why can we accept some links having long durations? If any link could, then why not have a long TC_INTERVAL everywhere? (If worried about convergence, set either a short initial value or a short minimum interval.) If not, then consider a non-MP router. To it, those are just links like any other. And may have long validity time but short useful lifetime (that’s the situation we’ve reached here). Which is bad.

You note simulations done. But what simulations have been done on scenarios with mixed MP and non-MP routers, mobility such that basic TC_INTERVAL is appropriate but not overshort, and scenarios/density where there are MP routers not picked as MPRs? Because that’s the problem case here.

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

From: manet [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 30 May 2016 22:25
To: manet
Subject: [manet] draft-ietf-manet-olsrv2-multipath-08 WGLC finished

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

Hi all,

The WGLC of draft-ietf-manet-olsrv2-multipath-08 has finished. We got valuable comments from Chris -- thanks very much!

Based on the comments received, a new revision will be submitted soon with following updates:

   - Make the style more consistent with other OLSRv2-RFC suite.

   - Make the reactive multipath calculation optional. Both proactive and reactive calculation can be used. Such modification won't impact interoperability.

   - Clarify the use of SR_TC_INTERVAL.

   - Clarify the generation/update of Multi-path routing Set (this is related to reactive/proactive calculation also)

   - Clarify the use of fp and fe in the multipath Dijkstra algorithm

   - Chris raised the concern about impact partial topology map on multipath calculation. As indicated in https://www.ietf.org/mail-archive/web/manet/current/msg19038.html , with non-trival amount of studies performed, no issue related to this has been reported yet. As it's related to the MPR-selection algorithm used, we can put it as one of the experimental points to make people pay attention to it, so that new issues can be reported.

regards

Jiazi
********************************************************************
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: Wed, 1 Jun 2016 22:58:52 +0200

Hi Chris,

> I will at some point find my editorial comments.

Thanks very much.

>
>
> While the below is generally as discussed, I don’t think the
> SR_TC_INTERVAL point captures all of my concern.
>

In fact, as I mentioned in my previous post, the longer SR_TC_INTERVAL
doesn't imply that the related links have longer validity time. All the
MP-OLSR routers have to generate TC messages as required by OLSR.

The SR_TC_INTERVAL is mainly for MP-OLSR routers to advertise SOURCE_ROUTE
TLV (so that the other routers can learn that the originators support
source routing), in case they are not required to generate TC messages.

best

Jiazi

>
>
> We have some routers putting out infrequent TCs. This must mean they have
> long validity times. But there is nothing inherently different about those
> links, they can be chosen by pot luck.
>
>
>
> (Example, four routers in a square, all sides are links, diagonals are
> not. Each will pick one neighbour as an MPR. Each link will have a 1/2
> chance of being advertised in each direction, all else being equal.)
>
>
>
> So why can we accept some links having long durations? If any link could,
> then why not have a long TC_INTERVAL everywhere? (If worried about
> convergence, set either a short initial value or a short minimum interval.)
> If not, then consider a non-MP router. To it, those are just links like any
> other. And may have long validity time but short useful lifetime (that’s
> the situation we’ve reached here). Which is bad.
>
>
>
> You note simulations done. But what simulations have been done on
> scenarios with mixed MP and non-MP routers, mobility such that basic
> TC_INTERVAL is appropriate but not overshort, and scenarios/density where
> there are MP routers not picked as MPRs? Because that’s the problem case
> here.
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> www.baesystems.com/ai
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Jiazi YI
> *Sent:* 30 May 2016 22:25
> *To:* manet
> *Subject:* [manet] draft-ietf-manet-olsrv2-multipath-08 WGLC finished
>
>
>
>
>
> **** 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 ******
> The WGLC of draft-ietf-manet-olsrv2-multipath-08 has finished. We got
> valuable comments from Chris -- thanks very much!
>
>
>
>    - Make the reactive multipath calculation optional. Both proactive and
> reactive calculation can be used. Such modification won't impact
> interoperability.
>
>
>
>    - Clarify the generation/update of Multi-path routing Set (this is
> related to reactive/proactive calculation also)
>
>
>
>    - Chris raised the concern about impact partial topology map on
> multipath calculation. As indicated in
> https://www.ietf.org/mail-archive/web/manet/current/msg19038.html , with
> non-trival amount of studies performed, no issue related to this has been
> reported yet. As it's related to the MPR-selection algorithm used, we can
> put it as one of the experimental points to make people pay attention to
> it, so that new issues can be reported.
>
>
>
> regards
>
>
>
> Jiazi
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 2 Jun 2016 08:45:58 +0000

OK, if the purpose is just to advertise SOURCE_ROUTE TLV, then perhaps some guidance on what it should advertise as neighbours.

I think if advertising at a slower rate, advertising any addresses either gets into the trap I described, or alternatively advertised with a short validity time then those links will be transient, which is a bad idea.

I think what you want is something like (this is not actual suggested words) if SR_TC_INTERVAL is much greater than TC_INTERVAL (someone will nitpick over much greater, so perhaps in terms of the appropriate hold time) then the TC message SHOULD NOT report any addresses [unless the links are known to be exceptionally stable] - the bit in [] could be included or excluded. It’s basically an indication of when the SHOULD NOT can be broken sensibly. Known to be stable can be taken from local link information, supplied by neighbour, plus local knowledge. But that may be too much detail to go into.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 01 June 2016 21:59
To: Dearlove, Christopher (UK)
Cc: manet
Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-08 WGLC finished

*** WARNING ***

On Wed, Jun 1, 2016 at 4:21 PM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
I will at some point find my editorial comments.

Thanks very much.

In fact, as I mentioned in my previous post, the longer SR_TC_INTERVAL doesn't imply that the related links have longer validity time. All the MP-OLSR routers have to generate TC messages as required by OLSR.

The SR_TC_INTERVAL is mainly for MP-OLSR routers to advertise SOURCE_ROUTE TLV (so that the other routers can learn that the originators support source routing), in case they are not required to generate TC messages.

best

Jiazi

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

From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jiazi YI
Sent: 30 May 2016 22:25
To: manet
Subject: [manet] draft-ietf-manet-olsrv2-multipath-08 WGLC finished

*** WARNING ***

Hi all,

regards

Jiazi

---

From: Jiazi YI <[email-masked]>
Date: Fri, 3 Jun 2016 22:25:12 +0200

On Thu, Jun 2, 2016 at 10:45 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> OK, if the purpose is just to advertise SOURCE_ROUTE TLV, then perhaps
> some guidance on what it should advertise as neighbours.
>
>
>
> I think if advertising at a slower rate, advertising any addresses either
> gets into the trap I described, or alternatively advertised with a short
> validity time then those links will be transient, which is a bad idea.
>
>
>
> I think what you want is something like (this is not actual suggested
> words) if SR_TC_INTERVAL is much greater than TC_INTERVAL (someone will
> nitpick over much greater, so perhaps in terms of the appropriate hold
> time) then the TC message SHOULD NOT report any addresses [unless the links
> are known to be exceptionally stable] - the bit in [] could be included or
> excluded. It’s basically an indication of when the SHOULD NOT can be broken
> sensibly. Known to be stable can be taken from local link information,
> supplied by neighbour, plus local knowledge. But that may be too much
> detail to go into.
>

Is it necessary to specify that the router "SHOULD NOT report addresses" in
this case? I think it will be an "empty" TC message anyways? Because if a
router doesn't generate TC message with TC_INTERVAL, it generally means
that there is no link to report.

Jiazi

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Jiazi
> YI
> *Sent:* 01 June 2016 21:59
> *To:* Dearlove, Christopher (UK)
> *Cc:* manet
> *Subject:* Re: [manet] draft-ietf-manet-olsrv2-multipath-08 WGLC finished
>
>
>
>
>
> **** WARNING ****
>

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 3 Jun 2016 22:04:49 +0100

Here we're into the subtleties of advertised neighbours versus MPR selectors.

The point is to make sure people don't send rare TCs, then decide because they are sending them they might as well advertise some addresses (because that's allowed, see the point above). But those advertisements can be positively harmful.

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

> On 3 Jun 2016, at 21:25, Jiazi YI <[email-masked]> wrote:
> 
> 
> 
>> On Thu, Jun 2, 2016 at 10:45 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
> Is it necessary to specify that the router "SHOULD NOT report addresses" in this case? I think it will be an "empty" TC message anyways? Because if a router doesn't generate TC message with TC_INTERVAL, it generally means that there is no link to report. 
> 
> Jiazi
>  
>>  
>> 
>> --
>> 
>> Christopher Dearlove
>> 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 Wed, Jun 1, 2016 at 4:21 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.
>> 
>> *** WARNING ***
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Christopher Dearlove <[email-masked]>
Date: Sat, 4 Jun 2016 08:04:40 +0100

Actually, as I should have thought earlier, what's the use of advertising just the source route TLV?

A router that doesn't advertise any neighbours in TC messages can't be an intermediate router on a route. (Exception for two hop routes constructed using HELLO messages, but those should only be transient.)

So what's the use case for this feature?

-- 
Christopher Dearlove

---

From: Jiazi YI <[email-masked]>
Date: Sat, 4 Jun 2016 22:15:12 +0200

As long as a router has more than two neighbors in the "topology graph"
constructed, it can be an intermediate router on a route, right?

An MP-OLSR router that doesn't advertise any neighbors in its own TC
message will be advertised in other router's (or routers') TC messages.
Of course, the router receiving such TC messages won't be able to know the
neighbors are MP-OLSR enabled or not.
Having the MP-OLSR originating TC message carrying the SRC_ROUTE TLV can
provide such information.

Other than being intermediate routers, it's important to know a destination
is MP-OLSR enabled, if we want to use multi-path routing to such
destination.

best

Jiazi

On Sat, Jun 4, 2016 at 9:04 AM, Christopher Dearlove <
[email-masked]> wrote:

> A router that doesn't advertise any neighbours in TC messages can't be an
> intermediate router on a route. (Exception for two hop routes constructed
> using HELLO messages, but those should only be transient.)
>
> Is it necessary to specify that the router "SHOULD NOT report addresses"
> in this case? I think it will be an "empty" TC message anyways? Because if
> a router doesn't generate TC message with TC_INTERVAL, it generally means
>> The SR_TC_INTERVAL is mainly for MP-OLSR routers to advertise
>> SOURCE_ROUTE TLV (so that the other routers can learn that the originators
>> support source routing), in case they are not required to generate TC
>> messages.
>>
>>
>>
>> best
>>
>>
>>
>> Jiazi
>>
>>
>>
>>
>>
>>
>>

---

From: Jiazi YI <[email-masked]>
Date: Sun, 5 Jun 2016 00:39:42 +0200

On Sun, Jun 5, 2016 at 12:23 AM, Christopher Dearlove <
[email-masked]> wrote:

> Being advertised in other routers' messages doesn't help - you need to
> look at the directionality of the links, links in TC messages are outgoing,
> not incoming.
>
> If you need to know destinations are MP that's another matter. But why?
> All a destination needs to do is receive packets.
>

There is a source routing header in the packets, the destination needs to
know how to deal with it. Or else, the behaviour would be unpredictable.

>
> However suppose that it is needed, no need to advertise other addresses.
> Which is back at the point I was making about not advertising other
> addresses. Not needed, even harmful, in the cases I indicated.
>

I would agree with not advertising other addresses.

Jiazi

>
>
> --
> Christopher Dearlove
>
> On 4 Jun 2016, at 21:15, Jiazi YI <[email-masked]> wrote:
>
> Other than being intermediate routers, it's important to know a
> destination is MP-OLSR enabled, if we want to use multi-path routing to
> such destination.
>
> best
>
> Jiazi
>
>>> I think if advertising at a slower rate, advertising any addresses
>>> either gets into the trap I described, or alternatively advertised with a
>>> short validity time then those links will be transient, which is a bad idea.
>>>
>>>
>>>
>>> We have some routers putting out infrequent TCs. This must mean they
>>> have long validity times. But there is nothing inherently different about
>>> those links, they can be chosen by pot luck.
>>>
>>>
>>>
>>> So why can we accept some links having long durations? If any link
>>> could, then why not have a long TC_INTERVAL everywhere? (If worried about
>>>    - Make the reactive multipath calculation optional. Both proactive
>>> and reactive calculation can be used. Such modification won't impact
>>> interoperability.
>>>
>>>
>>>
>>> https://www.ietf.org/mail-archive/web/manet/current/msg19038.html ,
>>> with non-trival amount of studies performed, no issue related to this has
>>> been reported yet. As it's related to the MPR-selection algorithm used, we
>>> can put it as one of the experimental points to make people pay attention
>>> to it, so that new issues can be reported.
>>>
>>>
>>>
>>> regards
>>>
>>>
>>>
>>> Jiazi
>>>

---

From: Christopher Dearlove <[email-masked]>
Date: Sat, 4 Jun 2016 23:42:24 +0100

Being advertised in other routers' messages doesn't help - you need to look at the directionality of the links, links in TC messages are outgoing, not incoming.

If you need to know destinations are MP that's another matter. But why? All a destination needs to do is receive packets.

However suppose that it is needed, no need to advertise other addresses. Which is back at the point I was making about not advertising other addresses. Not needed, even harmful, in the cases I indicated.

-- 
Christopher Dearlove

> As long as a router has more than two neighbors in the "topology graph" constructed, it can be an intermediate router on a route, right?
> 
> An MP-OLSR router that doesn't advertise any neighbors in its own TC message will be advertised in other router's (or routers') TC messages. 
> Of course, the router receiving such TC messages won't be able to know the neighbors are MP-OLSR enabled or not. 
> Having the MP-OLSR originating TC message carrying the SRC_ROUTE TLV can provide such information. 
> 
> Other than being intermediate routers, it's important to know a destination is MP-OLSR enabled, if we want to use multi-path routing to such destination. 
> 
> best
> 
> Jiazi 
> 
>> On Sat, Jun 4, 2016 at 9:04 AM, Christopher Dearlove <[email-masked]> wrote:

---

From: Christopher Dearlove <[email-masked]>
Date: Sat, 4 Jun 2016 23:53:15 +0100

There we need to know what behaviour is. But there's no need for the destination to care - the packet is for it, it's not being forwarded, who cares if there's a source routing header or not? Or at least that's a sensible way to implement. What do real implementations do?

But that's an aside from the point I made about indicating about not advertising neighbours. Which you challenged, but I think are now indicating you can see why.

In fact I think I understated it. 

Advertising addresses in such a TC message is almost never of any use. Almost never? If other routers only advertise MPR selectors, never useful. If they might advertise other links, possibly useful. Except likely damaging if with a significantly longer interval.

Which reinforces an earlier made point that discussing advertised links is something this draft should do, and doesn't. In addition to these extra TC messages not advertising links if at a significantly longer interval.

--  
Christopher Dearlove

> On 4 Jun 2016, at 23:39, Jiazi YI <[email-masked]> wrote:
> 
> 
> 
>> On Sun, Jun 5, 2016 at 12:23 AM, Christopher Dearlove <[email-masked]> wrote:
> There is a source routing header in the packets, the destination needs to know how to deal with it. Or else, the behaviour would be unpredictable. 
>  
>>

---

From: Jiazi YI <[email-masked]>
Date: Sun, 5 Jun 2016 01:16:50 +0200

On Sun, Jun 5, 2016 at 12:53 AM, Christopher Dearlove <
[email-masked]> wrote:

> There we need to know what behaviour is. But there's no need for the
> destination to care - the packet is for it, it's not being forwarded, who
> cares if there's a source routing header or not? Or at least that's a
> sensible way to implement. What do real implementations do?
>

It's *possible* that the destination doesn't understand the source routing
header and dropped it directly. It really depends on the implementation. To
make sure that the packet is delivered, we use multipath only to the
SRC_ROUTE supported routers -- or else, falling back to single path.

>
> But that's an aside from the point I made about indicating about not
> advertising neighbours. Which you challenged, but I think are now
> indicating you can see why.
>
> Advertising addresses in such a TC message is almost never of any use.
> Almost never? If other routers only advertise MPR selectors, never useful.
> If they might advertise other links, possibly useful. Except likely
> damaging if with a significantly longer interval.
>
> Which reinforces an earlier made point that discussing advertised links is
> something this draft should do, and doesn't. In addition to these extra TC
> messages not advertising links if at a significantly longer interval.
>

We will add some text about that.

best

Jiazi

>> Of course, the router receiving such TC messages won't be able to know
>> the neighbors are MP-OLSR enabled or not.
>>> A router that doesn't advertise any neighbours in TC messages can't be
>>> an intermediate router on a route. (Exception for two hop routes
>>> constructed using HELLO messages, but those should only be transient.)
>>>

---

From: Jiazi YI <[email-masked]>
Date: Sun, 5 Jun 2016 11:52:38 +0200

Here is the text that we proposed:

TC message are generated according to the Section 16.1 of [RFC7181]. As
least one TC message MUST be generated by an MP-OLSRv2 Routing Process
during SR_TC_INTERVAL. Please note that the TC message generation based on
SR_TC_INTERVAL does not replace the ordinary TC message generation
specified in [RFC7181] and does not carry any address. This is due to the
fact that not all routers will generate TC messages based on OLSRv2. The TC
generation based on SR_TC_INTERVAL serves for those routers to advertise
SOURCE_ROUTE TLV so that the other routers can be aware of the source-route
enabled routers so as to be used as destinations of multipath routing. The
SR_TC_INTERVAL is normally set to a longer value than TC_INTERVAL.

I aslo have a -09alpha revision attached. We will submit a new revision
soon. If there are any further comments, please let us know.

regards

Jiazi

On Sun, Jun 5, 2016 at 1:16 AM, Jiazi YI <[email-masked]> wrote:

>> Which reinforces an earlier made point that discussing advertised links
>> is something this draft should do, and doesn't. In addition to these extra
>> TC messages not advertising links if at a significantly longer interval.
>>
>
>>>> Is it necessary to specify that the router "SHOULD NOT report
>>>> addresses" in this case? I think it will be an "empty" TC message anyways?
>>>> Because if a router doesn't generate TC message with TC_INTERVAL, it
>>>> generally means that there is no link to report.
>>>>
>>>> Jiazi
>>>>
>>>>
>>>>>
>>>>>
>>>>> *-- *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> attachments or reply. For information regarding **Red Flags** that
>>>>> you can look out for in emails you receive, click here
>>>>> attachments or reply. For information regarding **Red Flags** that
>>>>> you can look out for in emails you receive, click here