Subject: [manet] Router's Implemetation and Running Code

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Jan 2013 11:32:58 +0100

Was: Sub:Re: [manet] Hares technical question 1: Design of sequence
numbers (warning long post)
http://www.ietf.org/mail-archive/web/manet/current/msg14618.html
++++++++++++++++++++++++++++++++++++++++++++++++

Sub:Router's Implemetation and Running Code

Hi Timothy,

I agree that; independent parties make different implementations
following same specification.

I diagree that: independent parties make independednt implementations
following same specification.

Therefore;
Four routers with independent implementations, COULD NOT work together
because their behavior are independent. Specification describe
behavior of such protocol implementation.

Four routers with different implementations, COULD work together if
they have same specification.

AB

On 1/15/13, Timothy J. Salo <[email-masked]> wrote:
>> Yes in your understanding it is ok, which I think any one on the list
>> will think, but does thoes 4 routers with independent implementation
>> can work together in same network. In my opinion if understanding
>> independent the way you defined then they should work together as long
>> they are following the same IETF draft specification.
>
> It is generally expected that "independent implementations" will
> interoperate.  In particular, see RFC 2026, "Internet Standards
> Process", which includes the following:
>
>    Thus, a candidate specification must be implemented and tested for
>    correct operation and interoperability by multiple independent
>    parties and utilized in increasingly demanding environments, before
>    it can be adopted as an Internet Standard.
>
> (Having said that, there appears to be a range of views as to what
> "interoperable" means.  For some, it means: if your implementation
> conforms to the specification, it is assured of interoperating with
> any other conforming implementation.  For others, it seems to mean:
> if you implement the same options that I do, then our implementations
> will interoperate; if you implement different options, then well...)
>
> -tjs
>
++++++
Yes in your understanding it is ok, which I think any one on the list
will think, but does thoes 4 routers with independent implementation
can work together in same network. In my opinion if understanding
independent the way you defined then they should work together as long
they are following the same IETF draft specification.

In other understandning of independent, which I think that poster ment
by *independent*, that they cannot work together, because they yes
follow the specification but they are implemented in different
architecture layers. So to say they follow the specification but not
all 4 implementation use the RFC5444's assigned port.

However, I may be wrong, but just making sure I understand the meaning :)

AB
+++
On 1/15/13, Susan Hares <shares at ndzh.com> wrote:
> AB:
>
> What I mean by independent implementations is that 4 different people took
> the specification, and wrote the code from the specification.  The four
> people did not share their code with each other.
>
> This is different than 4 people taking one code base and modifying it.
>
> Sue
>
> -----Original Message-----
> From: Abdussalam Baryun [mailto:abdussalambaryun at gmail.com]
> Sent: Monday, January 14, 2013 1:45 PM
> To: Jiazi Yi
> Cc: Susan Hares; manet at ietf.org
> Subject: Re: [manet] Hares technical question 1: Design of sequence numbers
> (warning long post)
>
> On 1/14/13, Jiazi Yi <ietf at jiaziyi.com> wrote:
>> For LOADng, which make use of this sequence number rotation, has at
>> least 4 independent implementations. As far as I can see, I didn't notice
> any issue.
>>
>
> Do you mean four different implementation or independent implementation. I
> understand the independent cannot work together (not interoperable), or am
> I
> wrong,
>
> AB
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Jan 2013 12:14:08 +0100

As you agree with RFC2026, I can understand you mean that the 4
implementation you refered to previously are interoperable, please
confirm, and that they may work together,

AB

On 1/15/13, Jiazi Yi <[email-masked]> wrote:
> RFC 2026:
>
>  In general, an Internet Standard is a specification that is stable
>    and well-understood, is technically competent, has multiple,
>    independent, and interoperable implementations with substantial
>    operational experience, enjoys significant public support, and is
>    recognizably useful in some or all parts of the Internet.
>
> Jiazi
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 15 Jan 2013 12:25:54 +0100

> confirm, and that they may work together,

Maybe this will answer your question? I think this document was already 
mentioned on this list.

http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report-04

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Jan 2013 12:26:51 +0100

RFC2026
>>    recognizably useful in some or all parts of the Internet.

Ok, I agree with the text; that IETF standards need to be *multiple+
independent+interoperable* implementations.

I agree that Standards and Specifications in IETF, implementations
SHOULD be interoperable if independently implemented.

I disagree that one standard have independednt implementations,
without mentioning interoperability. It should be tested after all by
the community,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Jan 2013 12:34:57 +0100

Hi Henning,

thanks alot, but I think the tests reported by the doc is only for one
implementation, not all 4 LOADng implementations, however, I will
contact the authors of the doc, thanks,

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 15 Jan 2013 12:37:41 +0100

> contact the authors of the doc, thanks,

I believe that you should read the document before stating something 
like this... *facepalm*

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 15 Jan 2013 09:35:19 -0800

AB,

these are four different implementations, implemented by different people
solely based on the LOADng draft. They have been successfully tested in
these multiple interop tests.

Best regards
Ulrich

On Tue, Jan 15, 2013 at 3:34 AM, Abdussalam Baryun <
[email-masked]> wrote:

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 Jan 2013 09:40:26 +0100

No, it is for 4 different, independent implementations. As the I-D that Henning cites clearly states.

Thomas

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Jan 2013 20:41:23 -0500

AB and Henning: 

Let me confirm - these results are one implementation ported to four
devices?  

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Abdussalam Baryun
Sent: Tuesday, January 15, 2013 6:35 AM
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] Router's Implemetation and Running Code

Hi Henning,

thanks alot, but I think the tests reported by the doc is only for one
implementation, not all 4 LOADng implementations, however, I will contact
the authors of the doc, thanks,

AB

On 1/15/13, Henning Rogge <[email-masked]> wrote:
> Maybe this will answer your question? I think this document was 
> already mentioned on this list.
>
> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, 
> Germany

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 16 Jan 2013 18:14:29 -0800

Sue,

these are four different implementations, developed independently from
different companies / universities.

Best regards
Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 17 Jan 2013 08:57:40 +0100

Thanks Sue for your input,

That was my understanding when read inteop-loadng draft before, just
to add to you text *four different devices*, but will read again when
I can. The authors confirmed that they documented it correctly,

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 17 Jan 2013 09:18:07 +0100

Abdussalam,

This is really incredible; did you actually _read_ the Interoperability report? Please do so, before jumping to assumptions.

For each interoperability event, there is a section "Participating Implementations". Here's an example, snipped from the draft from the _first_ interop test (when there were just 3 implementations - the latter tests had 4). It is explicitly mentioned that in that test, there's one Java implementation, one C implementation for an embedded platform and one C++ implementation for MacOS.

> 4.3.  Participating Implementations
> 
> 
>    The following implementations were used to perform the
>    interoperability tests this section, listed alphabetically:
> 
>    Ecole Polytechnique: "LIX" -  This implementation was jointly
>       developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg and
>       Thomas Clausen of Ecole Ploytechnique's networking team.  It
>       consists of approximately 6000 lines of JAVA code running in a Mac
>       OS environment.  It supports RREQ, RREP, RREP-ACK and RERR
>       generation, processing, forwarding and transmission.
> 
>    Hitachi YRL 1: "Hitachi 1" -  This implementation was fully developed
>       by Yuichi Igarashi of Hitachi YRL.  It consists of 1589 lines of C
>       code running in the Hitachi proprietary micro OS environment
>       embedded in a 16MHz H8 micro processor.  It supports RREQ, RREP,
>       RREP-ACK and RERR generation, processing, forwarding and
>       transmission.
> 
>    Hitachi YRL 2: "Hitachi 2" -  This implementation was jointly
>       developed by Nobukatsu Inomata of Hitachi ULSI Systems and Yoko
>       Morii of Hitachi YRL.  It consists of 1987 lines of C++ code
>       running in a Mac OS environment.  It supports RREQ, RREP, RREP-ACK
>       generation, processing, forwarding and transmission, and RERR
>       processing.

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 17 Jan 2013 09:52:58 +0100

Hi Thomas,

sorry for my understandning, but as you may know my English is not the
first language and I am new in the IETF vocabulary, I like to learn
and make things better, I beleive there are alot like me in the market
that like your work and have some feedback, which I am doing my best.
However, my comments/feedback in line,

On 1/17/13, Thomas Heide Clausen <[email-masked]> wrote:
> Abdussalam,
>
> This is really incredible; did you actually _read_ the Interoperability
> report? Please do so, before jumping to assumptions.

yes read quickly but not assuming what I understood it was realy what
I felt, and just stated the fact of my first reading. I agree that I
need to improve :)

>
> For each interoperability event, there is a section "Participating
> Implementations". Here's an example, snipped from the draft from the _first_
> interop test (when there were just 3 implementations - the latter tests had
> 4). It is explicitly mentioned that in that test, there's one Java
> implementation, one C implementation for an embedded platform and one C++
> implementation for MacOS.

So my understanding from your reply that the test were done within 4
different languages and environments. What about the implementor, were
they in contact and followed a same director/advisor, were there an
independance in implementing the understanding of specification. I
think not documented so far in my reading.

I may be wrong, please advise,

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 17 Jan 2013 10:48:06 +0100

Sent from my iPad

> first language and I am new in the IETF vocabulary, I like to learn

Nor is English my first language ;)

> I felt, and just stated the fact of my first reading. I agree that I

I recommend that, if you want to comment on a document, you read it carefully. It's not efficient to have to repeat things, which are already well documented and in detail.

> think not documented so far in my reading.

As the implementations were done by different (and, in some cases, competing) corporate entities/companies, I would be quite surprised if the different engineers had the same "director/advisor".

This is also documented in the report (companies, and even people).

Thomas

---

From: Yuichi IGARASHI <[email-masked]>
Date: Thu, 17 Jan 2013 20:18:21 +0900

Hi Abdussalam,

We have two different independent implementations. Even in my company, 
we had no director among implementors, because our main purpose was to 
confirm the interoperability of LOADng spec.

Best regards,
Yuichi

(2013/01/17 18:48), Thomas Heide Clausen wrote:
>
>
> Sent from my iPad
>
> On 17 janv. 2013, at 09:52, Abdussalam Baryun<[email-masked]>  wrote:
>
>> Hi Thomas,
>>
>> On 1/17/13, Thomas Heide Clausen<[email-masked]>  wrote:
>>> Abdussalam,
>>>

-- 
  Hitachi, Ltd., Yokohama Research Laboratory
  IGARASHI Yuichi
  Mail： [email-masked]
  Tel ： +81-(0)45-860-3083
  FAX ： +81-(0)45-860-1673

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Sat, 19 Jan 2013 11:10:01 +0000

That being said I'd rather now focus on the new WG I-D AODVv2

---

From: Henning Rogge <[email-masked]>
Date: Mon, 21 Jan 2013 08:08:45 +0100

> That being said I'd rather now focus on the new WG I-D AODVv2

We know thats your opinion...

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 21 Jan 2013 12:47:12 +0100

Hi Henning,

The interesting point in these LOADng-implemented codes that they were
implemented differently and then tested together and reported in IETF,
which I think is rare from companies/organisations to do that. IMHO, I
think the test/report of interoperability of different and independent
implementations is very important for router users and the market. I
thank all who explained for me this including you, because I don't
think it was discussed/understood before,

Best Regards,
AB

---

From: Henning Rogge <[email-masked]>
Date: Mon, 21 Jan 2013 12:58:20 +0100

> think it was discussed/understood before,

Yes, it is...

at the moment I am not even sure there is a single DYMO-25 compatible 
implementation.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 21 Jan 2013 14:15:24 +0100

Hi Henning,

Regarding the interop-testing, was there tests for interoperability
for OLSRv1 or OLSRv2, as it is our completed standard. I am wondering
if the Funkfeuer and Freifunk routers implemented differently and
independetly, if yes it will be interesting to know if that test was
done. Please advise,

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 21 Jan 2013 14:18:54 +0100

Try the link below:

	http://lmgtfy.com/?q=OLSR+Interop

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 21 Jan 2013 15:11:07 +0100

Hi Thomas, and Henning,

ok I found tests reports for OLSRv1, but what about OLSRv2, just found
workshops but did not find results/report. Could you give me a point
to these reports,

Thanking you,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 21 Jan 2013 15:34:27 +0100

Hi Henning

The below draft explains how OLSRv2 is used in funkfeuer, but not sure
of interoperability with other routers; please advise,

http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01

AB

---

From: Henning Rogge <[email-masked]>
Date: Mon, 21 Jan 2013 15:36:26 +0100

On 01/21/2013 02:15 PM, Abdussalam Baryun wrote:
> for OLSRv1 or OLSRv2, as it is our completed standard.

I think there were quite a few OLSRv1 interop tests done in the past.

> I am wondering

Freifunk/Funkfeuer (and most of the Wireless Community Mesh Networks) 
use the Olsr.org OLSR implementation with the proprietary ETX metric 
implementation.

The problem is that without a metric extension, most routing protocols 
are nearly unusable in a MANET. There are two "well known" OLSRv1 
implementation with ETX, one is the Olsr.org implementation and the 
other one is from the NRL.

Both use their own way to encode the metric, so they are not compatible 
in ETX mode.

OLSRv2 implementations are still "work in progress", but I did some 
preliminary interop tests of NHDP between my own and the NRL 
implementation and plan to extend this this year (as soon as I stop 
finding bugs/problems in my own NHDP implementation ^^).

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Mon, 21 Jan 2013 15:37:47 +0100

> http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01

I suggest reading the document.

Its NOT about how OLSRv2 is used in Funkfeuer.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 21 Jan 2013 21:01:35 +0100

Thanks alot, I will follow your advise,

AB