Subject: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT)

From: Suresh Krishnan <[email-masked]>
Date: Tue, 09 May 2017 19:49:05 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-manet-olsrv2-multipath-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I find it really strange that this document uses an experimental Routing
header type codepoint (254) but requires the processing to be same as the
RPL Routing header (Type 3). Is there a reason things are done this way
instead of just using the Type 3 header as is?

---

From: Jiazi Yi <[email-masked]>
Date: Wed, 10 May 2017 11:29:43 +0200

Dear Suresh, 

Thanks very much for the comments. 
Alvaro raised the same issue before — we will use the type 3 header in the next revision. 

best

Jiazi

> On 10 May 2017, at 04:49, Suresh Krishnan <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 11 May 2017 11:22:55 -0400

> On May 10, 2017, at 5:29 AM, Jiazi Yi <[email-masked]> wrote:
> 
> Dear Suresh, 
> 

Sounds good Jiazi. I did not see this in Alvaro’s ballot and that is why I commented. I saw version -13 has already fixed this. Thanks for this.

Regards
Suresh

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 14 May 2017 13:51:26 +0200

This protocol can be mixing between reactive and proactive processings
which is not stable which is not reliable, see the draft mentions:
Routers in the same network may choose either proactive or reactive multipath
calculation independently according to their computation resources.

I think the protocol must only support one calculation for each path,
making mixed reactive and proactive per path is not stable. While we know
that OLSRv2 is a proactive protocol so if we use source routing as in this
protocol it should do only reactive calculation that makes it stable in the
dynamic-networks like manet. IMHO, using reactive and proactive
independently seems strange in manet routing environment. I advise to look
into conditions of its theories because it seems that this multipath
routing in for fixed-wireless-networks not for manets.

AB

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 14 May 2017 14:43:14 +0100

The reactivity is local, unlike the reactivity of, say, AODV. So while it introduces a delay (and possible issues of buffering, and possible effects on, say, TCP) it does not introduce any routing instability. It's not mixing two ways to calculate a path (which would not be good).

(If the calculation is fast enough, you wouldn't even know it had happened.)

(Personally I wouldn't have introduced the reactive complication, but the designers/implementers wanted it.)

--  
Christopher Dearlove
[email-masked]
[email-masked] is dead

> On 14 May 2017, at 12:51, Abdussalam Baryun <[email-masked]> wrote:
> 
> This protocol can be mixing between reactive and proactive processings which is not stable which is not reliable, see the draft mentions:
> 
> Routers in the same network may choose either proactive or reactive multipath calculation independently according to their computation resources.
> 
> making mixed reactive and proactive per path is not stable. While we know that OLSRv2 is a proactive protocol so if we use source routing as in this protocol it should do only reactive calculation that makes it stable in the dynamic-networks like manet. IMHO, using reactive and proactive independently seems strange in manet routing environment. I advise to look into conditions of its theories because it seems that this multipath routing in for fixed-wireless-networks not for manets.
> 
> AB
> 
>

---

From: Jiazi Yi <[email-masked]>
Date: Mon, 15 May 2017 09:50:39 +0200

Hi AB, 

As Chris said, reactive/proactive approach has nothing to do with stability you mentioned. It’s totally a router’s internal process — the outsiders won’t even know the difference. 

best

Jiazi

> On 14 May 2017, at 13:51, Abdussalam Baryun <[email-masked]> wrote:
> 
> On Wed, May 10, 2017 at 11:29 AM, Jiazi Yi <[email-masked] <mailto:[email-masked]>> wrote:
> Dear Suresh,
> 
> > On 10 May 2017, at 04:49, Suresh Krishnan <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 19 May 2017 14:43:01 +0200

What do you mean by local reactive, I did not understand. Is our routing
having local and not local, if yes then why don't we say in the draft local
reactivity?

AB

On Sun, May 14, 2017 at 3:43 PM, Christopher Dearlove <
[email-masked]> wrote:

> The reactivity is local, unlike the reactivity of, say, AODV. So while it
> introduces a delay (and possible issues of buffering, and possible effects
> on, say, TCP) it does not introduce any routing instability. It's not
> mixing two ways to calculate a path (which would not be good).
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 19 May 2017 14:46:38 +0200

Hi Jiazi,

Routing processes are in all  routers (do you mean other than that?), so
what you mean by internal, do you mean there is routing process outside the
router???, or as you may mean external process from routers. I think all
processes happen in the routers. I am sorry that I got confused,,,,

AB

On Mon, May 15, 2017 at 9:50 AM, Jiazi Yi <[email-masked]> wrote:

> Hi AB,
>
> As Chris said, reactive/proactive approach has nothing to do with
> stability you mentioned. It’s totally a router’s internal process — the
> outsiders won’t even know the difference.
>
> best
>
> Jiazi
>

---

From: Jiazi Yi <[email-masked]>
Date: Mon, 22 May 2017 09:28:49 +0200

Hi AB, 

I think we have already made it clear in the draft:

> The reactive operation is local to the router and no additional routing control messages exchange is required. 

best

Jiazi

> On 19 May 2017, at 14:46, Abdussalam Baryun <[email-masked]> wrote:
> 
> Hi Jiazi,
> 
> Routing processes are in all  routers (do you mean other than that?), so what you mean by internal, do you mean there is routing process outside the router???, or as you may mean external process from routers. I think all processes happen in the routers. I am sorry that I got confused,,,,
> 
> AB
> 
> On Mon, May 15, 2017 at 9:50 AM, Jiazi Yi <[email-masked] <mailto:[email-masked]>> wrote:
> Hi AB, 
> 
>> On 14 May 2017, at 13:51, Abdussalam Baryun <[email-masked] <mailto:[email-masked]>> wrote:
>>