Subject: [manet] ODMRP new draft (was Re: IETF89 preliminary minutes

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 10 Mar 2014 17:48:39 +0100

Hi Axel,

Thanks for your presentation. I had a question at meeting but there was no
time. From the presentation (still I did not done review), there was one
slide showing two paths to its destination, so does this multicast protocol
use multipath to reach all its demanded destinations? And how does it
optimise overhead?

AB

On Monday, March 10, 2014, Axel Colin de Verdière wrote:

> Hi all,
>
> We did not in fact request WG adoption for ODMRP and ODMRP_ASYM at this
> time, but we felt that the drafts were in good enough shape to ask for your
> comments and move in that direction.
>
> Axel
>
> Le 10 mars 2014 à 17:08, Abdussalam Baryun <[email-masked]> a
> écrit :
>
> Hi Thomas,
>
> Thanks for the update. I don't think the latest multicast draft was
> requested to be adopted in the meeting, but Ulrich did request his it for
> his draft, and I am waiting for announce on the list for DLEP plan and
> all adoption request in WG meeting.
>
> AB
>
> On Monday, March 10, 2014, Thomas Clausen wrote:
>
> Ulrich,
>
> Thank you for prompt posting of minutes.
>
> A couple of things that I would like to make more precise, all the same,
> in the minutes:
>
> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>
> <SNIP>
>
> Teco: Why not make this document standards track?
> CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's the case.
> TC: I do not think as a working group that we should go down the standards track document without many implementations as that has happened in other places within the IETF and document quality has suffered.
>
> I honestly do not think that Chris would make that typo, even when
> speaking ;)
>
> CD: If it gets stuck in the queue for 4 years we may have enough experience that we may want to push for standards track.
> Rick Taylor: Is there any record of this for this draft being experimental and then changing to standards track later down the line?
> CD: We will post something up on the list.
> TC: I think that experimental should have an explanation on what the experiment is and what the successful experiment is and what the conclusion is.
> Ulrich: Do you have intention to add a description of what those experiments are and what will make them successful?
> Adrian Farrel: Yes, he does have that intention.
>
> As it reads in the above, it sounds as if I'm making a demand, that Adrian is committing Chris to satisfy. That's not exactly how it went down, so perhaps we should clarify that in the minutes?
>
> I'd like to go on record here, that I did not say that it "should have an
> explanation" to cater to my whim, but that I (as I actually stated at the
> mike) I was reciting what I had heard was an IESG statement/requirement
> (so: I thought it was the IESGs whim to be satisfied).
>
> Adrian then clarified this, that it was not an "IESG
> statement/requirement" as such, but that the current routing ADs (which
> include him, so his whim) who require this"
>
> <SNIP>
>
>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>
> <SNIP>
>
> Henning: It will also not break anything if different values are used as the values are unit-less so the routes might be crazy but they will work.
>
> TC: I think experimental is exactly the place for this document
> Emmanuel: I would like to comment to Rick's earlier comment about if this is related to OLSRv2.  It uses building blocks such as sequence numbers in RFC5444 and missed NHDP HELLO messages to calculate the metric, so in that regard it could be used with other protocols and is not only tied to OLSRv2.
> CD: There needs to be a section describing the experiments. TC: I think this draft should be focused to OLSRv2 (and not other protocols) and not make it something overly broad and have it stall out.Henning: For AODV this metric would be a problem as there isn't normally control traffic or any unicast traffic on a link, so there is nothing to measure.
>
>
> I believe that what I said was that my experience with both proactive and
> reactive protocol deployments leave me to believe that metrics "make sense
> in very different ways in these two protocol families", and therefore would
> need to be considered separately. Specifically, constructing an "experiment
> for a metric for a proactive protocol" (which, as this is going
> Experimental, is a requiremen
>
>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 10 Mar 2014 20:32:26 +0100

Dear Abdussalam,

> On 10 mars 2014, at 17:48, Abdussalam Baryun <[email-masked]> wrote:
> 
> Hi Axel,
> 
> Thanks for your presentation. I had a question at meeting but there was no time. From the presentation (still I did not done review), there was one slide showing two paths to its destination, so does this multicast protocol use multipath to reach all its demanded destinations? And how does it optimise overhead?
> 

Having now reviewed the document in detail, let me venture a reply ;)

I believe that, no, multiple paths to the same destination are not sought nor used. Of course, to multiple destinations, multiple paths (but with common path segments, as possible) result.

I am interested, Abdussalam, have you read the document, and what are your detailed comments?

Thomas

>> We did not in fact request WG adoption for ODMRP and ODMRP_ASYM at this time, but we felt that the drafts were in good enough shape to ask for your comments and move in that direction.
>> 
>> Axel
>> 
>>> Le 10 mars 2014 à 17:08, Abdussalam Baryun <[email-masked]> a écrit :
>>> 
>>> Hi Thomas,
>>> 
>>> Thanks for the update. I don't think the latest multicast draft was requested to be adopted in the meeting, but Ulrich did request his it for his draft, and I am waiting for announce on the list for DLEP plan and all adoption request in WG meeting. 
>>> 
>>> AB
>>> 
>>> A couple of things that I would like to make more precise, all the same, in the minutes:
>>> 
>>> I honestly do not think that Chris would make that typo, even when speaking ;)
>>> I'd like to go on record here, that I did not say that it "should have an explanation" to cater to my whim, but that I (as I actually stated at the mike) I was reciting what I had heard was an IESG statement/requirement (so: I thought it was the IESGs whim to be satisfied).
>>> 
>>> 
>>> 
>>> 
>>> Adrian then clarified this, that it was not an "IESG statement/requirement" as such, but that the current routing ADs (which include him, so his whim) who require this"
>>> 
>>> 
>>> 
>>> 
>>> <SNIP>
>>> 
>>>> CD: There needs to be a section describing the experiments. 
>>>> TC: I think this draft should be focused to OLSRv2 (and not other protocols) and not make it something overly broad and have it stall out.
>>>> Henning: For AODV this metric would be a problem as there isn't normally control traffic or any unicast traffic on a link, so there is nothing to measure.
>>> 
>>> 
>>> I believe that what I said was that my experience with both proactive and reactive protocol deployments leave me to believe that metrics "make sense in very different ways in these two protocol families", and therefore would need to be considered separately. Specifically, constructing an "experiment for a metric for a proactive protocol" (which, as this is going Experimental, is a requiremen
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Axel Colin de Verdière <[email-masked]>
Date: Mon, 10 Mar 2014 23:00:27 +0100

Hi Abdussalam, Thomas,

Thank you for your comments. Indeed there are no multiple paths involved. Can you point me to the slide you're referring to? What do you mean by "optimise overhead"?

Axel

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 11 Mar 2014 01:03:10 +0100

Slide 11 and 18. In the draft page 4 it mentions that ODMRP maintains
multiple paths. Regarding overhead, do you mean there is no overhead in
this routing and if there is with higher mobility how does it optimise it.

AB

On Monday, March 10, 2014, Axel Colin de Verdière wrote:

> Hi Abdussalam, Thomas,
>
> Thank you for your comments. Indeed there are no multiple paths involved.
> Can you point me to the slide you're referring to? What do you mean by
> "optimise overhead"?
>
> Axel
>
> Le 10 mars 2014 à 20:32, Thomas Heide Clausen <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> a écrit :
>
> Dear Abdussalam,
>
>
> I believe that, no, multiple paths to the same destination are not sought
> nor used. Of course, to multiple destinations, multiple paths (but with
> common path segments, as possible) result.
>
> (so: I thought it wa

---

From: Axel Colin de Verdière <[email-masked]>
Date: Tue, 11 Mar 2014 09:37:05 +0100

Hi Abdussalam,

Slide 11 mentions that there is no *additional* overhead incurred by ODMRP_ASYM when there is no unidirectional link, not that there isn't any overhead with ODMRP. Slide 18 does not show multiple paths, it shows the way ODMRP_ASYM finds a detour paths to forward the Join Reply.
As for page 4 of the ODMRP draft, can you point me to the line where it says ODMRP maintains multiple paths? Last time I read it there was no such statement...
As for the overhead related to mobility, ODMRP does not incur any extra overhead when mobility is higher, except if you shorten ROUTE_REFRESH_INTERVAL to refresh the multicast overlay more often to increase delivery rates.

Axel

Le 11 mars 2014 à 01:03, Abdussalam Baryun <[email-masked]> a écrit :

> Slide 11 and 18. In the draft page 4 it mentions that ODMRP maintains multiple paths. Regarding overhead, do you mean there is no overhead in this routing and if there is with higher mobility how does it optimise it. 
> 
> AB
> 
>>>> I'd like to go on record here, that I did not say that it "should have an explanation" to cater to my whim, but that I (as I actually stated at the mike) I was reciting what I had heard was an IESG statement/requirement (so: I thought it wa
>>>> 
>