Subject: Re: [manet] #55 (olsrv2-multitopology): Maintaining Multiple Routing Sets

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 21 Sep 2014 13:53:50 +0200

Section 11 and subsection 6.8 need more specification details for routing
maintenance.

On Saturday, August 23, 2014, Christopher Dearlove wrote:

> ....
>
> Yes, the draft does describe creating multiple routing sets. See Section
> 11. If familiar with OLSRv2, that's all you need - because OLSRv2 describes
> how a Routing Set is calculated and when it needs to change.

Already seen section 11 when reviewed but is not enough. Regarding RFC7181
(which section refers to) it is only for single topology, so for MT we need
a fresh maintenance paragraph at least. In subsection 6.8 it does not
describe how is the separation. In section 11 it does not describe how the
calculation separates routing sets. The is a need to add an element in
routing set for metric type. All maps are done with metric type
reference, but in the routing sets there is no element for metric type or
reference.

How do we go from changes occurring to updating the routing sets? In non-MT
is easy because all update is single topology.  MT has replaced in 7181 all
sets' elements are replaced with maps but for Routing Set the draft
says only routing set is separated by metric type (subsection 6.8), which
is only in draft-words not in specification of the routing sets.

> How are things separated? By metric type, as is clearly said more than
> once. Metric types are defined in OLSRv2.

Only one type is defined in OLSRv2 which is in LINK_METRIC_TYPE. This MT
draft replaced/adds other parameters which is not much linked to separate
Routing Sets. I will give suggestions.

AB

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 21 Sep 2014 13:09:20 +0100

This is a proactive routing protocol. There's nothing special about routing maintenance.

If you think something specific is wanted, you should say so, instead of vague comments. If you don't understand, ask. Not make assertions without any presented foundation.

It seems everyone else understand. But if there's something specific not said that everyone has assumed, say what it is.

I would also refer you to the first paragraph of Section 4 and the third bullet point in Section 12. Note that this protocol's job is to create and maintain the Routing Sets. What to do with them is a task outside this protocol (though strongly suggested by this protocol, with a big warning about mixing sets in that bullet point).

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

> On 21 Sep 2014, at 12:53, Abdussalam Baryun <[email-masked]> wrote:
> 
> Section 11 and subsection 6.8 need more specification details for routing maintenance. 
> 
>> Yes, the draft does describe creating multiple routing sets. See Section 11. If familiar with OLSRv2, that's all you need - because OLSRv2 describes how a Routing Set is calculated and when it needs to change.
> 
> Already seen section 11 when reviewed but is not enough. Regarding RFC7181 (which section refers to) it is only for single topology, so for MT we need a fresh maintenance paragraph at least. In subsection 6.8 it does not describe how is the separation. In section 11 it does not describe how the calculation separates routing sets. The is a need to add an element in routing set for metric type. All maps are done with metric type reference, but in the routing sets there is no element for metric type or reference. 
> 
> How do we go from changes occurring to updating the routing sets? In non-MT is easy because all update is single topology.  MT has replaced in 7181 all sets' elements are replaced with maps but for Routing Set the draft says only routing set is separated by metric type (subsection 6.8), which is only in draft-words not in specification of the routing sets. 
> 
>> 
>> How are things separated? By metric type, as is clearly said more than once. Metric types are defined in OLSRv2. 
> 
> Only one type is defined in OLSRv2 which is in LINK_METRIC_TYPE. This MT draft replaced/adds other parameters which is not much linked to separate Routing Sets. I will give suggestions. 
> 
> AB

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Sun, 21 Sep 2014 17:12:22 +0000

Abdussalam,

On Sep 21, 2014, at 7:53 AM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

I want to reinforce what Chris Dearlove said in another email. The text above implies (at least to me) that you have a specific deployment scenario in mind, and that when looking at the text of the draft, you conclude that your scenario won't work. If that is the case, describe the scenario - I'm not able to follow your concerns, above some vague notion that "this won't work". Without the necessary detail, I can only conclude that consensus exists to progress the draft, and you are "in the rough".

It should go without saying, but I'll say it anyway - everyone on this list is interested in producing the highest-quality draft possible. There have been multiple reviews, by people who are intimately familiar with the technology. To my thinking, the multiple reviews make it highly unlikely (but not impossible) that some technical detail has been missed. At this stage of the process with this document, the WG needs a fully-documented failing case in order to understand, and correct, any deficiency in the draft. Therefore, please refrain from general "that is not enough" or "that won't work" descriptions, and provide sufficient detail for us to recognize the issue you believe you have encountered. For example, some description that starts out "Assume the following physical topology, with the following multiple routing sets. When Router 1 does XYZ, Router 2 (or Router 3 or whatever system in the topology) is incapable of distinguishing the action between the multiple routing sets because of <whatever the perceived error is>". The more detail, the better.

Regards,
Stan

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 26 Sep 2014 15:55:41 +0200

Hi

On Sunday, September 21, 2014, Stan Ratliff (sratliff) wrote:

>  Abdussalam,
>
>  On Sep 21, 2014, at 7:53 AM, Abdussalam Baryun <
> [email-masked]> wrote:
>
>  Already seen section 11 when reviewed but is not enough. Regarding
> RFC7181 (which section refers to) it is only for single topology, so for MT
> we need a fresh maintenance paragraph at least. In subsection 6.8 it does
> not describe how is the separation. In section 11 it does not describe how
> the calculation separates routing sets. The is a need to add an element in
>  I want to reinforce what Chris Dearlove said in another email. The text
> above implies (at least to me) that you have a specific deployment scenario
> in mind, and that when looking at the text of the draft, you conclude that
> your scenario won't work. If that is the case, describe the scenario
>

That is not the case, the scenarios are general purpose of MANET or as
RFC7181. The case is the draft reader did not understand and is discussing
to clarify the issues. The reader is referring to texts in the draft
related to updating routing sets. Generally, the case is that some of my
questions are not getting clear answers. It is good that reader reviewing
and commenting on draft and sharing his/her understanding
or misunderstanding. I want to implement the work then will think about
scenarios.

> - I'm not able to follow your concerns, above some vague notion that "this
> won't work". Without the necessary detail, I can only conclude that
> consensus exists to progress the draft, and you are "in the rough".
>

 I never said it does not work. I want the draft to be clear to readers how
protocol works. Does your message mean stop discussing because your in
the rough? Or stop because you have no scenario detail (usually my scenario
is the draft scenario). The WG is small in size so maybe 10% participants
don't understand the work. The IETF is not about only consensus, but about
publishing readable work that full community can understand and implement.

AB

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 26 Sep 2014 18:07:09 +0100

The chair has pointed out this discussion should stop. And strictly I'm violating that. But find another person, one who understands OLSRv2 but not MT-OLSRv2, then there may be something to say.

> On 26 Sep 2014, at 14:55, Abdussalam Baryun <[email-masked]> wrote:
> 
> Hi
> 
>>> On Sep 21, 2014, at 7:53 AM, Abdussalam Baryun <[email-masked]> wrote:
>>> 
>> I want to reinforce what Chris Dearlove said in another email. The text above implies (at least to me) that you have a specific deployment scenario in mind, and that when looking at the text of the draft, you conclude that your scenario won't work. If that is the case, describe the scenario 
> 
> 
> That is not the case, the scenarios are general purpose of MANET or as RFC7181. The case is the draft reader did not understand and is discussing to clarify the issues. The reader is referring to texts in the draft related to updating routing sets. Generally, the case is that some of my questions are not getting clear answers. It is good that reader reviewing and commenting on draft and sharing his/her understanding or misunderstanding. I want to implement the work then will think about scenarios. 
> 
>   
>> - I'm not able to follow your concerns, above some vague notion that "this won't work". Without the necessary detail, I can only conclude that consensus exists to progress the draft, and you are "in the rough". 
> 
>  I never said it does not work. I want the draft to be clear to readers how protocol works. Does your message mean stop discussing because your in the rough? Or stop because you have no scenario detail (usually my scenario is the draft scenario). The WG is small in size so maybe 10% participants don't understand the work. The IETF is not about only consensus, but about publishing readable work that full community can understand and implement. 
> 
> AB
>