Subject: [manet] OLSRv2 interoperable experience

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 6 Mar 2014 23:31:49 +0100

Hello Thomas,

I asked a question in the last meeting IETF 89 about the tests of OLSRv2
and experience as it was presented and mention many tests. I asked just for
technical summary, showing advise or possible errors detected in some
deployment and interoperability work of this protocol. Please help.

Best Regards,

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 7 Mar 2014 00:01:02 +0100

Dear Abdussalam,

> On 6 mars 2014, at 23:31, Abdussalam Baryun <[email-masked]> wrote:
> 
> Hello Thomas,
> 
> I asked a question in the last meeting IETF 89 about the tests of OLSRv2 and experience as it was presented and mention many tests. I asked just for technical summary, showing advise or possible errors detected in some deployment and interoperability work of this protocol. Please help. 
> 

These are really two different things, that you are asking about.

Interoperability implies that independent implementations of the protocols are able to interoperate: correctly parse and interpret each other's messages, and "do the right processing" as a consequence. As indicated, and as indicated in the shepherd write-up for OLSRv2 prior to publication, several known implementations exist and have demonstrated this through numerous interoperability tests over the years. 

Demonstrated interoperability of independent implementations (the operative word being "independent", as in "developed by different teams/institutions, without any conferring outside of reading the same specification") really serve as the litmus test of the quality of a specification, and are - in my not so humble opinion - indispensable prior to publishing a protocol specification on standards track. I am sure you will agree, the reason for which standards are written is to enable independent implementors to write interoperable code, so standards need to be written to enable exactly that.

Deployment experiences are hugely dependent on the scenarios that you are deploying in, specifically (but not exclusively) the L2 you are using. Mobility, topology densities, ..., all play a role here, too. As far as I know, for MANETs there are many different scenarios and L2 in use. I know of MANETs that are deployed over (perfectly reliable, high-capacity) Ethernet point-to-point links, and of other MANETs that are deployed over (highly lossy, low-capacity, time-varying) wireless links -- and, even, MANETs which have both kinds of links at the same time. 

To try to make a general observation that seem commonly (but not universally) valid, the biggest "lesson learned" from deployments probably is, that hop-count metrics aren't the most appropriate metric to use in many wireless scenarios; Henning and Emmanuel's I-D (that was called for, for WG adaptation recently) is an alternative metric that  is based on the deployment experiences of Henning and Emmanuel and which - in their deployments, at least, is advantageous. I strongly encourage those efforts, of documenting operational experiences, and which metrics are found to be viable. I know that NRL has been successful with different metrics (different from the Henning/Emmanuel proposal, that is) for their scenarios/L2's, and that's wonderful also - their scenarios and L2's are very different. Indeed, that is the reason why OLSRv2 does not recommend a specific metric, but leaves the flexibility for a deployment and L2 to use an appropriate (or, multiple appropriate) metrics.

Best,

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Mar 2014 07:36:06 +0100

Hi Thomas,

Thanks a lot.  so could I understand that when implementing OLSRv2 and when
people gathered testing OLSRv2 (as you pictures of gatherings in
your presentation in MANET WG IETF89) the process of test had no single
minor error in coding or error in routing process in that gathering or what
were the learning main issues/points developed. Sorry if my question
was not explained well,

AB

On Thursday, March 6, 2014, Thomas Heide Clausen wrote:

> Dear Abdussalam,
>
> > On 6 mars 2014, at 23:31, Abdussalam Baryun <[email-masked]<javascript:;>>
> wrote:
> >
> > Hello Thomas,
> >
> Interoperability implies that independent implementations of the protocols
> are able to interoperate: correctly parse and interpret each other's
> messages, and "do the right processing" as a consequence. As indicated, and
> as indicated in the shepherd write-up for OLSRv2 prior to publication,
> several known implementations exist and have demonstrated this through
> numerous interoperability tests over the years.
>
> Demonstrated interoperability of independent implementations (the
> operative word being "independent", as in "developed by different
> teams/institutions, without any conferring outside of reading the same
> specification") really serve as the litmus test of the quality of a
> specification, and are - in my not so humble opinion - indispensable prior
> to publishing a protocol specification on standards track. I am sure you
> will agree, the reason for which standards are written is to enable
> independent implementors to write interoperable code, so standards need to
> be written to enable exactly that.
>
> Deployment experiences are hugely dependent on the scenarios that you are
> deploying in, specifically (but not exclusively) the L2 you are using.
> Mobility, topology densities, ..., all play a role here, too. As far as I
> know, for MANETs there are many different scenarios and L2 in use. I know
> of MANETs that are deployed over (perfectly reliable, high-capacity)
> Ethernet point-to-point links, and of other MANETs that are deployed over
> (highly lossy, low-capacity, time-varying) wireless links -- and, even,
> MANETs which have both kinds of links at the same time.
>
> To try to make a general observation that seem commonly (but not
> universally) valid, the biggest "lesson learned" from deployments probably
> is, that hop-count metrics aren't the most appropriate metric to use in
> many wireless scenarios; Henning and Emmanuel's I-D (that was called for,
> for WG adaptation recently) is an alternative metric that  is based on the
> deployment experiences of Henning and Emmanuel and which - in their
> deployments, at least, is advantageous. I strongly encourage those efforts,
> of documenting operational experiences, and which metrics are found to be
> viable. I know that NRL has been successful with different metrics
> (different from the Henning/Emmanuel proposal, that is) for their
> scenarios/L2's, and that's wonderful also - their scenarios and L2's are
> very different. Indeed, that is the reason why OLSRv2 does not recommend a
> specific metric, but leaves the flexibility for a deployment and L2 to use
> an appropriate (or, multiple appropriate) metrics.
>
> Best,
>
> Thomas
>
>
> > Best Regards,
> >
> > AB
> >
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 7 Mar 2014 10:05:50 +0100

Dear Abdussalam,,

> On 7 mars 2014, at 07:36, Abdussalam Baryun <[email-masked]> wrote:
> 
> Hi Thomas,
> 
> Thanks a lot.  so could I understand that when implementing OLSRv2 and when people gathered testing OLSRv2 (as you pictures of gatherings in your presentation in MANET WG IETF89) the process of test had no single minor error in coding or error in routing process in that gathering or what were the learning main issues/points developed. Sorry if my question was not explained well, 
> 

Interops have as objective to verify interoperability of independent implementations of the same specification - as a way to measure the quality of a specification prior to standardization. That's what a standards developing organization is interested in, and not the quality of code from one organization or another. 

I believe that the OLSR/OLSRv2 interops were successful, in that we had numerous independent and complete implementations participating successfully over the years.

Interops do not really have as goal to test the ability of an individual or an organization to write bug-free code, and so it is not really in my place to report if person X came along with code that segfaulted, or if the code of organization Y had a memory leak. In fact, I'd probably make myself highly unpopular if I did hang out person X or organization Y, by divulging which flaws their code had.

Also, mind you, some of the interops were as much as 10 years ago....given that, on some days, I have a hard time remembering what I had for breakfast ;)  I probably would not remember such details correctly anyways: as they were not relevant to the interop, they were not recorded.

Best,

Thomas

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Mar 2014 10:23:19 +0100

Thanks Thomas, I was not interested in names, but experiencing OLSRv2. I
just needed an answer from you because the gathering was mentioned in
IETF89 and I did not benefit from knowing that there was such gathering.
Now I understand that there was no technical summary published for
OLSRv2 of such gathering.

AB

On Friday, March 7, 2014, Thomas Heide Clausen wrote:

> Dear Abdussalam,,
>
> On 7 mars 2014, at 07:36, Abdussalam Baryun <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>
> Hi Thomas,
>
> Thanks a lot.  so could I understand that when implementing OLSRv2 and
> when people gathered testing OLSRv2 (as you pictures of gatherings in
> Interops have as objective to verify interoperability of independent
> implementations of the same specification - as a way to measure the quality
> of a specification prior to standardization. That's what a standards
> developing organization is interested in, and not the quality of code from
> one organization or another.
>
> I believe that the OLSR/OLSRv2 interops were successful, in that we had
> numerous independent and complete implementations participating
> successfully over the years.
>
> Interops do not really have as goal to test the ability of an individual
> or an organization to write bug-free code, and so it is not really in my
> place to report if person X came along with code that segfaulted, or if the
> code of organization Y had a memory leak. In fact, I'd probably make myself
> highly unpopular if I did hang out person X or organization Y, by divulging
> which flaws their code had.
>
> Also, mind you, some of the interops were as much as 10 years ago....given
> that, on some days, I have a hard time remembering what I had for breakfast
> ;)  I probably would not remember such details correctly anyways: as they
> were not relevant to the interop, they were not recorded.
>
> Best,
>
> Thomas
>
> AB
>
>> > I asked a question in the last meeting IETF 89 about the tests of
>> OLSRv2 and experience as it was presented and mention many tests. I asked
>> just for technical summary, showing advise or possible errors detected in
>> some deployment and interoperability work of this protocol. Please help.
>> >
>>
>> Interoperability implies that independent implementations of the
>> protocols are able to interoperate: correctly parse and interpret each
>> other's messages, and "do the right processing" as a consequence. As
>> indicated, and as indicated in the shepherd write-up for OLSRv2 prior to
>> publication, several known implementations exist and have demonstrated this
>> through numerous interoperability tests over the years.
>>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 7 Mar 2014 10:29:01 +0100

Dear Abdussalam,

Have you tried googeling for OLSR Interop?

Also, we have (when found appropriate by the chairs) both advertised these events in advance to the WG, and reported back. Looking through the minutes and proceedings from previous IETF meetings should provide you with such information.

Of course, the very best plan would be for you to implement OLSRv2 yourself, so that you would have a reason for participating in a future such event. Do let us know, if you go down that path, when you have running code?

Best,

Thomas

Sent from my iPad

> On 7 mars 2014, at 10:23, Abdussalam Baryun <[email-masked]> wrote:
> 
> 
> Thanks Thomas, I was not interested in names, but experiencing OLSRv2. I just needed an answer from you because the gathering was mentioned in IETF89 and I did not benefit from knowing that there was such gathering. Now I understand that there was no technical summary published for OLSRv2 of such gathering. 
> 
> AB
>