Subject: [manet] Why the WG Reactive Protocol to be Compatible with another?

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 20 Feb 2013 12:03:58 +0100

Hi Folks,

I am not sure why we will make effort of AODVv2 compatible with
LOADng, I am trying to find a good reason mentioned in the WG. I seen
the intention by some participants, but not sure was it intention to
merge DYMO+LOADng without compatibility (with either DYMO or LOADng)
or with percentage of compatibility. Do you think it is good way to
make the reactive protocol and then try to make it compatible?  Please
advise,

I will have to agree with the below proposal, that if the WG is
agreeing to make compatible with LOADng, then why not go for 100%
compatibility, just change the name title.

AB

Sub:Re: [manet] Reactive protocol decision process, for the record thoughts
On 2/16/13, Ulrich Herberg <[email-masked]> wrote:
> Justin,
>
> I very much agree with you, Justin. One point I would like to add is
> that the WG will now spend a lot of time making the new AODVv2
> compatible with LOADng (which is claimed in the current DYMO draft);
> that is, in my opinion, a wasted effort since the LOADng draft is per
> definition 100% compatible with LOADng (had that been the starting
> point).
> Ignoring a document that has multiple interoperable implementations,
> deployments, MIB document, as well a support from at least a dozen
> MANET participants (not only LOADng authors) without giving rational
> was a disappointment for me.
>
> Best regards
> Ulrich
>

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Wed, 20 Feb 2013 15:26:32 +0000

Hi AB,

This is critical topic and I cannot agree more with you; the objective is in my opinion to come up with the best protocol for the IETF.
Let's be clear: the objective of the IETF is to produce qualitative protocols for the best of the IETF community and industry, not to make
X or Y happy. Every single good ideas borrowed from Load should in my opinion be adopted by AODVv2, if there is a consensus. On the
other hand, trying to design AODVv2 with the constraint of making it compatible with another protocol is a COMPLETE non sense.

Thanks.

JP.

On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote:

Hi Folks,

AB

Sub:Re: [manet] Reactive protocol decision process, for the record thoughts
On 2/16/13, Ulrich Herberg <[email-masked]<mailto:[email-masked]>> wrote:
Justin,

Best regards
Ulrich

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

---

From: Henning Rogge <[email-masked]>
Date: Wed, 20 Feb 2013 16:53:07 +0100

One great idea of LOADng was to have a compact core document which
describes the the basic protocol (fully functional on its own) and put
additional features into companion documents.

This would also give people a way to describe which "optional"
features a software implementation supports.

"We implemented the core plus the RFC xyz and abc."

Documents with lots of "optional features" in the core quickly become
non-interoperable with each other because different people implement
different subsets of the options and all are just "standard
compliant".

Henning Rogge

On Wed, Feb 20, 2013 at 4:26 PM, JP Vasseur (jvasseur)
<[email-masked]> wrote:
> Hi AB,
>
> This is critical topic and I cannot agree more with you; the objective is in
> my opinion to come up with the best protocol for the IETF.
> Let's be clear: the objective of the IETF is to produce qualitative
> protocols for the best of the IETF community and industry, not to make
> X or Y happy. Every single good ideas borrowed from Load should in my
> opinion be adopted by AODVv2, if there is a consensus. On the
> other hand, trying to design AODVv2 with the constraint of making it
> compatible with another protocol is a COMPLETE non sense.
>
> Thanks.
>
> JP.
>
> [email-masked]
> [email-masked]

-- 
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 20 Feb 2013 08:28:15 -0800

Hello Henning,

I don't think it makes sense to spread optional features into new
documents just because they're optional.  If there is any ambiguity
about which are the "core features", then that is a defect of the
specification, not a result of co-location in a document together.

Otherwise, even a simple flag might need a new document.

Anyway, if you find that some parts of the AODVv2 document do
not clearly delineate core versus optional features, please let us
know so we can fix it to be more accurate.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 20 Feb 2013 17:49:05 +0100

Hi JP,

Yes that was my first discussion approach (the best technical features
to be adopted in the WG protocol), but seen some inputs that our
reactive protocol to be compatible to another, and I thought why the
other don't be compatible to this which I needed an answer. I agree
that we will waste time if we choose to make our work compatible to
other reactive protocol or as you mention it will be non sense. In
addition, it needs to use RFC5444 (was discussed) and also to be
compatible to NHDP,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 20 Feb 2013 17:55:06 +0100

Hi Charlie,

I may undersatnd from Henning input that it is important to read the
core function in a light specification and/or if we get many optional
feature within a specification, it is recommended to have other
documents, as I understand you done for iRREP-draft,

AB

---

From: Jiazi Yi <[email-masked]>
Date: Wed, 20 Feb 2013 18:22:48 +0100

Hi AB, JP:

I also have doubts why the editor of DYMO declares that it will be compatible with LOADng, and how it can be achieved. 

Although those two protocols share the general idea, the packet format and message processing details are very different. As one who participated in all LOADng interop tests and know dymo draft relatively well, I can say that a lot of effort are needed to make DYMO and LOADng compatible, not to mention the interop tests needed to verify the compatibility (at this point, I have no idea if there is DYMO implementation, so I'm not even sure if such test is possible). 

btw, 

> the objective of the IETF is to produce qualitative protocols for the best of the IETF community and industry, not to make X or Y happy

I can't agree more. 

best

Jiazi

---

From: Henning Rogge <[email-masked]>
Date: Wed, 20 Feb 2013 18:40:02 +0100

On Wed, Feb 20, 2013 at 4:26 PM, JP Vasseur (jvasseur)
<[email-masked]> wrote:
> X or Y happy.

We ALL agree on this... we just might disagree who is X and Y.

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 20 Feb 2013 10:01:37 -0800

Hello Jiazi,

I do not agree that the protocols are all that different.

I did not declare that AODVv2 will be compatible with LOADng. Instead,
what I have said all along is that we should make the effort to achieve
compatibility.  This means to make the comparison and to resolve
differences.  I have agreed to make a comparison draft, and I have tried
to enlist the aid of another LOADng author in the effort.  Once the
comparison is made, we can have a discussion about each point of
difference, to decide upon the best resolution.  I am pretty sure that,
if we do this with honest effort, we will get a better result overall.

Do you want to help?

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 20 Feb 2013 20:52:35 +0000

Jiazi, 

> I also have doubts why the editor of DYMO declares that it will be compatible with LOADng, and how it can be achieved. 

It probably won't be achieved - especially if you and the other LOADng co-authors decide not to help us, taking the position of standing back and lobbing emails like this one into the fray. If this is a desirable, then I would say "suggest some alternatives, help us out". If not, then let us as a working group declare it a dead issue, and move on. 

> Although those two protocols share the general idea, the packet format and message processing details are very different. As one who participated in all LOADng interop tests and know dymo draft rel…

OK. Going on (yet another) "micro-cosmic trip through MANET reactive protocol history", I'll note that AODV compatibility with LOADng was something that the co-chairs mandated from the combined author teams when we thought that merging the two documents was something that could actually be accomplished. The rationale there was to not exclude existing LOADng implementations from being able to say they were compliant with the RFC - something that *no one* on the author teams (including yourself) complained about *at the time*. 

So to restate, the fundamentals of the issue have changed - the effort to merge the documents was a total, miserable failure. At this juncture it is fair to ask if LOADng compatibility is even something that is desirable. The general trend of comments I'm reading on the list indicates that it is not. Are there other opinions? 

Stan

---

From: Jiazi Yi <[email-masked]>
Date: Wed, 20 Feb 2013 23:03:14 +0100

Hi, 

Please check inline (I'm just speaking on behalf of myself, not the LOADng author team) :

> It probably won't be achieved - especially if you and the other LOADng co-authors decide not to help us, taking the position of standing back and lobbing emails like this one into the fray. If this…

In the last 2~years, the LOADng co-authors have spent huge amount of effort in reactive protocols. For me personally, it's the core of my research project, and I invested most of my time in it. Hopefully it won't be regarded as "not willing to help". 

> OK. Going on (yet another) "micro-cosmic trip through MANET reactive protocol history", I'll note that AODV compatibility with LOADng was something that the co-chairs mandated from the combined aut…

Since the Taipei IETF, the starting point agreed by the authors teams was always LOADng, as indicated in Ulrich's mail to the chairs. 
In that context, all the authors agree that companion documents can be developed, so that the dymo functions can be supported to be compatible. 
Thanks for adding the note. 
The issue of starting point didn't come out until several months before Atlanta IETF. If I knew that the document would be based on DYMO, it would be a totally different issue. 

> So to restate, the fundamentals of the issue have changed - the effort to merge the documents was a total, miserable failure. At this juncture it is fair to ask if LOADng compatibility is even some…

I agree that the fundamentals of the issue have changed, since the starting point and the design principle (slim core + companion document) were changed. 
As far as I can see, LOADng has no intention to be changed to "get closer to DYMO". Having DYMO be compatible with LOADng would need great effort and add extra complexity to the protocol -  starting from scratch probably would be easier to make a clear specification and be compatible with LOADng. 
I have spent days and nights in the interop tests of LOADng. Producing ONE clear specification with limited options, and making it able to interoperable among independent implementations are already hard enough. Having TWO specifications, and one of them is a super set with all those additional options which are not specified clearly, would be a nightmare. Awful among of iterations and tests would be required. 

Therefore, personally, I would say LOADng compatibility is not desirable. 

best

Jiazi

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 21 Feb 2013 01:25:45 +0000

> In the last 2~years, the LOADng co-authors have spent huge amount of effort in reactive protocols. For me personally, it's the core of my research project, and I invested most of my time in it. Hop…

FWIW, here's how I look at it: The past history is what it is. The AD made the decision he made. We are where we are. The operative question is whether or not any given working group participant is willing to help the WG move forward., *from where we are*, to the best reactive protocol we can specify. Any and all assistance and ideas are welcome, and contributors will be acknowledged. 

> The issue of starting point didn't come out until several months before Atlanta IETF. If I knew that the document would be based on DYMO, it would be a totally different issue. 

We can quibble about the exact timing of when "the starting point" came out - my memory is that the requirement was clearly stated to the parties involved in YVR. However, my point is that it did come out, has been out "for a while", and no dissent was received. So any implication that this popped up out of the blue is incorrect.

Stan

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 26 Feb 2013 20:32:16 +0000

I do agree with you Stan - I also miss the point of trying to get back at what happened, why, ... as opposed to spending our energy making it right and more forward for the best of our community.
Cheers.

JP.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 26 Feb 2013 21:00:18 +0000

> "We implemented the core plus the RFC xyz and abc."

As I recall, that was the wonder of the OSI protocols. They did it with options within the documents, but you could say that you did TP-4 with options this and that, and you could describe SDLC NRM, LAP, LAPB, LAPF, LAPM, and IEEE 802.2 as all implementing the same protocol with different options.

The only real problem was that none of the implementations had the same option set as any of the others, which meant that none of them could actually interoperate.

Is interoperation a requirement?

---

From: Henning Rogge <[email-masked]>
Date: Tue, 26 Feb 2013 22:05:08 +0100

> Is interoperation a requirement?

Yes, it is...

but as long as we have a useful core that everyone has to implement
according to specs it should be okay.

What we must not allow is that the core becomes useless. Options and
extensions are fine as long as everyone one has a common feature set
that is still useful.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 26 Feb 2013 22:14:48 +0100

Fred,

[working my way through your recent batch of OSPF and IS-IS doc's...comments to follow, I am intrigued but will bug Mark on that before bugging you]

> Is interoperation a requirement?

Not really sure what to answer here.

Speaking as somebody who writes the odd line of code in a protocol implementation, I am no fan of options: each option tends to lead to code branches, and each code branch to a doubling of the size of the test suite.

In std. track documents, this, especially, if said option set is there without operational/experimental justification.

There're several deployments of LOADng out there. That protocol was designed to be exactly that which was operationally justified (and nothing beyond that), minimizing options.  It's unfortunate if the IETF/IESG isn't considering "running code" as part of its credo any more.

Best,

Thomas

---

From: Jiazi Yi <[email-masked]>
Date: Tue, 26 Feb 2013 22:51:43 +0100

Hi, 

My understanding is that , the core just define the basic functions that are required in all general scenarios. 

The role of option Z is: If you want to improve performance X in scenario Y, then do Z. 

Therefore, for a document, it is important to define such "core" that has been proven to be working, with operational experience. The options that only for specified scenarios shouldn't be taken into the core, which only increase the overall complexity. 
By separating the core document and optional documents, the core document is imperatively implemented. By doing so, the engineers would know the interoperability can be guaranteed as long as the core is there, even with other implementations with core + options. 

If we made a large document with various options by using SHOULD, MAY, the dangerous part is:
	o the document would be much more complex, hard to understand, and with much more redundancy; 
	o different implementation wouldn't be in the same option set, unless they specify another subset of the protocol by defining "let's do section x.y, paragraph z, the second SHOULD" etc. This is exactly what you described. 

best

Jiazi

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 27 Feb 2013 01:34:14 +0100

Hi Fred,

I may try to answer you question but would like to know your opinion
as well. I think the answer depend on the protocol applicability. The
answer can be Yes and can be No. The answer may depend on the designer
approach or the user's application as well. However, mostly the user
side or the use-cases. Options for the protocol is interesting as we
have DYMO and LOADng both are AODV, but as you refer to options, both
reactive have different options, and they don't need to be
interoperable. Different designers and different users may use
different options. IETF documents don't do that kind of one protocol
with options to produce many protocol uses (my assumption or
understanding).

Usually in MANET interoperability of different implementation of each
manet protocol SHOULD be required, because mostly this WG covers
general purpose protocols or wider use-case. Even the approach of
using one MANET packet format in this WG maybe hint to getting options
closer to protocols to become working together sometime in future,

Thanks
AB

On 2/26/13, Fred Baker (fred) <[email-masked]> wrote:
> As I recall, that was the wonder of the OSI protocols. They did it with
> options within the documents, but you could say that you did TP-4 with
> options this and that, and you could describe SDLC NRM, LAP, LAPB, LAPF,
> LAPM, and IEEE 802.2 as all implementing the same protocol with different
> options.
>
> The only real problem was that none of the implementations had the same
> option set as any of the others, which meant that none of them could
> actually interoperate.
>

---

From: "Dowdell, John" <[email-masked]>
Date: Wed, 27 Feb 2013 10:20:06 +0000

Lets be clear what we mean by compatible here, since I am reading this in more than one area just now in relation to routing protocols.

Considering ITU specifications, PBX vendors that implemented the Q.931 inter-PBX protocol all had to conduct case-by-case bilateral interoperability tests because the message and action sequences in their implementations were all hard-wired and different, even though they were written on the same standard. All were compatible and yet not.

Is, say, OSPF compatible with iBGP? They can co-exist on the same network, thanks to the IANA registries, but an OSPF parser will not understand iBGP, nor should it. Can a single router understand both? That is up to the designer of the router. Should MANET routing protocols use common building blocks? Absolutely, where it makes sense to do so. AODVv2 is using RFC5444 for message transport, but AODVv2 does a different job to OLSRv2, so the AODVv2 messages are likely to be different to those of OLSRv2.

Personally I am in favour of a well-written core protocol and as few options as possible, but if the final WG consensus for AODVv2 is for a small core and many options then that is what will be written. Vendors claim compliance with a single RFC document so we must seek to reduce the scope for incompatible implementations of the same protocol.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 27 February 2013 00:34
To: Fred Baker (fred)
Cc: [email-masked]
Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another?

Hi Fred,

Thanks
AB

_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 27 Feb 2013 10:43:28 +0000

Hi John,

I agree with you but not sure about one below;

On Wed, Feb 27, 2013 at 10:20 AM, Dowdell, John
<[email-masked]>wrote:

> Lets be clear what we mean by compatible here, since I am reading this in
> more than one area just now in relation to routing protocols.
>
> Considering ITU specifications, PBX vendors that implemented the Q.931
> inter-PBX protocol all had to conduct case-by-case bilateral
> interoperability tests because the message and action sequences in their
> implementations were all hard-wired and different, even though they were
> written on the same standard. All were compatible and yet not.
>
> Is, say, OSPF compatible with iBGP? They can co-exist on the same network,
> thanks to the IANA registries, but an OSPF parser will not understand iBGP,
> nor should it. Can a single router understand both? That is up to the
> designer of the router. Should MANET routing protocols use common building
> blocks? Absolutely, where it makes sense to do so. AODVv2 is using RFC5444
> for message transport, but AODVv2 does a different job to OLSRv2, so the
> AODVv2 messages are likely to be different to those of OLSRv2.
>
> Personally I am in favour of a well-written core protocol and as few
> options as possible,

agree

> but if the final WG consensus for AODVv2 is for a small core and many
> options then that is what will be written.

What do you mean by *options*, are they protocol operation options, or
information options? from Henning and Fred input I understood it meant
operation options.

> Vendors claim compliance with a single RFC document so we must seek to
> reduce the scope for incompatible implementations of the same protocol.
>
> agree

> The information contained within this e-mail and any files attached to
> this e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient
> only and therefore if you wish to disclose the information contained within
> this e-mail or attached files, please contact the sender prior to any such
> disclosure. If you are not the intended recipient, any disclosure, copying
> or distribution is prohibited. Please also contact the sender and inform
> them of the error and delete the e-mail, including any attached files from
> your system. Cassidian Limited, Registered Office : Quadrant House, Celtic
> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
> http://www.cassidian.com
>

---

From: "Dowdell, John" <[email-masked]>
Date: Wed, 27 Feb 2013 11:01:09 +0000

Well let's consider something in AODVv2 which is present in the current draft. It is mandatory for routers to multicast RREQ messages to a nominated multicast address. However there is an option for routers to send by unicast to the next hop. I will not debate this topic here, you'll have to read the draft, but:

Core - receiving routers MUST listen on a specified multicast address for incoming RREQ messages
Option - receiving router MAY listen for same message on its unicast address.

Thus the option is a different behaviour (or operation if you wish) from the core specification. The implementation requires core functionality, plus whichever options the implementer feels necessary to achieve their objective. An implementation that does not listen on the Unicast address for RREQs would not receive them, but could still claim compliance with the specification.

John

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 27 February 2013 10:43
To: Dowdell, John
Cc: Fred Baker (fred); [email-masked]
Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another?

Hi John,

I agree with you but not sure about one below;
On Wed, Feb 27, 2013 at 10:20 AM, Dowdell, John <[email-masked]<mailto:[email-masked]>> wrote:
Lets be clear what we mean by compatible here, since I am reading this in more than one area just now in relation to routing protocols.

Personally I am in favour of a well-written core protocol and as few options as possible,

agree

but if the final WG consensus for AODVv2 is for a small core and many options then that is what will be written.

What do you mean by *options*, are they protocol operation options, or information options? from Henning and Fred input I understood it meant operation options.

Vendors claim compliance with a single RFC document so we must seek to reduce the scope for incompatible implementations of the same protocol.
agree
John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Abdussalam Baryun
Sent: 27 February 2013 00:34
To: Fred Baker (fred)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another?

Hi Fred,

Thanks
AB

On 2/26/13, Fred Baker (fred) <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Feb 20, 2013, at 7:53 AM, Henning Rogge <[email-masked]<mailto:[email-masked]>> wrote:
>