Subject: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-07.txt

From: Ulrich Herberg <[email-masked]>
Date: Mon, 7 Jan 2013 19:40:59 -0800

Hi,

we have submitted a new revision of LOADng. Here is a summary of the
changes:

- many editorial improvements
- better characterization of applicability of LOADng (describing the
constraints/traffic flows etc. instead of listing a number of use cases)
- some parameters that have been router parameters are now interface
parameters, which allows for using different settings for different
interface types
- RREQ/RREP/RERR include hop-limit for scope limitations (mostly for
allowing extensions as companion document, e.g. expanding ring search)
- RERR also includes the originator address
- definition of a FLAGS TLV instead of the ackrequired TLV
- pre-allocation of two metrics in the IANA registries

Best regards
Ulrich

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Jan 7, 2013 at 7:33 PM
Subject: New Version Notification for draft-clausen-lln-loadng-07.txt
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked]

A new version of I-D, draft-clausen-lln-loadng-07.txt
has been successfully submitted by Ulrich Herberg and posted to the
IETF repository.

Filename:        draft-clausen-lln-loadng
Revision:        07
Title:           The Lightweight On-demand Ad hoc Distance-vector Routing
Protocol - Next Generation (LOADng)
Creation date:   2013-01-07
WG ID:           Individual Submission
Number of pages: 67
URL:
http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt
Status:          http://datatracker.ietf.org/doc/draft-clausen-lln-loadng
Htmlized:        http://tools.ietf.org/html/draft-clausen-lln-loadng-07
Diff:
http://www.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-07

Abstract:
   This document describes the Lightweight Ad hoc On-Demand - Next
   Generation (LOADng) distance vector routing protocol, a reactive
   routing protocol intended for use in Mobile Ad hoc NETworks (MANETs).

The IETF Secretariat

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 8 Jan 2013 13:11:47 +0100

Hi Herberg,

You did not involve us or me in the work of amending your work, how
can I review it while you did not ask for my opinion in the first
place. I was interested to join the work after you presented the work
to MANET WG and I asked questions but no one likes to reply, now you
want me to review and reply, how can this happen. Please talk us
through the work you done so I can know what is happend. Please note
that working alone is not the practice of IETF, if I understand the
practice of WG well.

I look forward to review the new draft after you explain to me what is
my position am I just review our private work without I know what was
discussed outside the IETF, or is my position ok I will tell you every
thing you need to know, and please review my work and suggest your
ideas. Please note that I am lost, to understand the situation with
this draft, even though I know that the WG have accepted to discuss
the work, but don't see that the authors accepted to join us into
their discussions.

Thanking you for updating the you work in IETF,

Take care,
AB

---

From: Jiazi Yi <[email-masked]>
Date: Tue, 8 Jan 2013 13:51:27 +0100

Hi AB, 

LOADng is certainly not working alone. There are 10~ authors of it,  providing significant improvements in each new revision, which are based on the feedback from the working group and problems we encountered in the tests. 

As far as I can see, the LOADng authors participated actively in those technical discussions. For other issues, WG chairs and AD have already briefed them, and I don't want to repeat here. 

I'm not sure that I understood what you are trying to say in your second paragraph with my crappy English, but I can't agree that  "don't see that the (LOADng) authors accepted to join us into their discussions." Everyone is welcome to give comments to the document, and LOADng authors are looking forward to discuss them. 

best

Jiazi

On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun <[email-masked]> wrote:

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 8 Jan 2013 15:01:40 +0100

Hi Jiazi,

I thank you for reply, I need to know how to participate in such work,
I was promissed before by some authors of replying to some quest but
they did not take it serious,

comments inline;

On 1/8/13, Jiazi Yi <[email-masked]> wrote:
> Hi AB,
>
> LOADng is certainly not working alone. There are 10~ authors of it,
> providing significant improvements in each new revision, which are based on
> the feedback from the working group and problems we encountered in the
> tests.

I always believe that authors are same as a one author alone. So you
confirm that the 10 authors cooperate and discuss the work through,
but am I able to ask questions as why an input was changed from
previous draft? if yes, then I will be happy to review, otherwise, I
will be lost or ignored from the process,

> As far as I can see, the LOADng authors participated actively in those
> technical discussions. For other issues, WG chairs and AD have already
> briefed them, and I don't want to repeat here.

I respect your viewes but it seems I had another point of view
regarding my situation with this work, because I am not an author,

>
> I'm not sure that I understood what you are trying to say in your second
> paragraph with my crappy English, but I can't agree that  "don't see that

To explain the paragraph you missed is : a question as, Will any
volunteering effort input/review be respected to get a knowledge
reply/respond.

> the (LOADng) authors accepted to join us into their discussions." Everyone
> is welcome to give comments to the document, and LOADng authors are looking
> forward to discuss them.

<Discussion is two way communication with equal power, I view a one way only>

What about the authors' input/change/update hope they are welling to
discuss their input into our WG, not only my/any comment about such
input? However, your reply seems to agree that there is welling to
discuss, which I will try to assume from now,

Regards
AB

>>> Status:
>>> http://datatracker.ietf.org/doc/draft-clausen-lln-loadng

---

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

Hi Jiazi and Herberg,

> constraints/traffic flows etc. instead of listing a number of use cases)

Is it ok if you give at least one example use case, please reply?

> parameters, which allows for using different settings for different

Do you mean ALL router parameters or MOST router parameters are now
interface parameters? Is this a MUST for the protocol or a SHOULD? ,
please reply?

Best Regards

Abdussalam Baryun
University of Glamorgan, UK
+++++++++++++++++++++++++
Note: If this message not replied by any author, it will be sent to
the AD to get a response from the authors.
+++++++++++++++++++++++++

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 8 Jan 2013 15:10:55 +0000

Hi Jiazi,

I think that the frustration is coming from the fact that this I-D not being a WG document, it "belongs" to their authors, and the process
by which you make changes is opaque. Changes may come from experiments, field trials, … but without background, it is difficult
indeed to understand the rationale for this changes, improvements, … Let's see if at some point we get one WG document, being *the*
WG document, that will be subject to discussion with the participation of the entire WG.

Thanks.

JP.

On Jan 8, 2013, at 1:51 PM, Jiazi Yi wrote:

Hi AB,

best

Jiazi

On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

Hi Herberg,

Take care,
AB

On 1/8/13, Ulrich Herberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Best regards
Ulrich

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jan 7, 2013 at 7:33 PM
Subject: New Version Notification for draft-clausen-lln-loadng-07.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>,
[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>,
[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>,
[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Abstract:

The IETF Secretariat

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

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 08 Jan 2013 09:08:04 -0800

Hello folks,

It has been my strong wish for a long time to have a merged document.
To this end, I have brought the WG document into RFC 5444 compliance,
and (at request of the LOADng authors) put Intermediate RREP into a
separate document.  I've responded to suggestions about readability,
and various other technical details.

By now the WG document is in considerably better shape.

Previously, the LOADng author team expressed concerns that the WG
document was not (in their opinion) readable.  I believe those concerns
can be safely laid to rest, and if there are additional measures I can take
for further improvement I will not hesitate to do so.  I look forward to
the discussion.

LOADng properly belongs as a set of parameter and optional
behavior choices for a merged WG document.  By now, the merge will
be quite straightforward because LOADng has become more like the
WG document, and I have taken direct measures to make the WG
document more adaptable to fit the needs of LOADng.

Since releasing the ...-25.txt revision for the AODVv2 specification, I have
noticed some typos, and as mentioned earlier there are several minor
issues that, once resolved, could result in changes to the specification.
I'll submit those to the list and the issue tracker today.

Regards,
Charlie P.

On 1/8/2013 7:10 AM, JP Vasseur (jvasseur) wrote:
> Hi Jiazi,
>
> I think that the frustration is coming from the fact that this I-D not 
> being a WG document, it "belongs" to their authors, and the process
> by which you make changes is opaque. Changes may come from 
> experiments, field trials, ... but without background, it is difficult
> indeed to understand the rationale for this changes, improvements, ... 
> Let's see if at some point we get one WG document, being *the*
>>  providing significant improvements in each new revision, which are 
>> based on the feedback from the working group and problems we 
>> encountered in the tests.
>>
>> As far as I can see, the LOADng authors participated actively in 
>> those technical discussions. For other issues, WG chairs and AD have 
>> already briefed them, and I don't want to repeat here.
>>
>> I'm not sure that I understood what you are trying to say in your 
>> second paragraph with my crappy English, but I can't agree 
>> that  "don't see that the (LOADng) authors accepted to join us 
>> into their discussions." Everyone is welcome to give comments to the 
>> document, and LOADng authors are looking forward to discuss them.
>>
>> best
>>
>> Jiazi
>>
>> On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> Hi Herberg,
>>>
>>>> From: <[email-masked] <mailto:[email-masked]>>
>>>> To: [email-masked] <mailto:[email-masked]>
>>>> Cc: [email-masked] <mailto:[email-masked]>, [email-masked] 
>>>> <mailto:[email-masked]>, [email-masked] 
>>>> <mailto:[email-masked]>,
>>>> [email-masked] <mailto:[email-masked]>, 
>>>> [email-masked] <mailto:[email-masked]>, 
>>>> [email-masked] <mailto:[email-masked]>,
>>>> [email-masked] 
>>>> <mailto:[email-masked]>, 
>>>> [email-masked] 
>>>> <mailto:[email-masked]>,
>>>> [email-masked] <mailto:[email-masked]>, 
>>>> [email-masked] <mailto:[email-masked]>
>>>>
>>>>
>>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

-- 
Regards,
Charlie P.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 8 Jan 2013 09:10:21 -0800

Hi Abdussalam,

> Is it ok if you give at least one example use case, please reply?

The rationale for the change was that rather than claiming that the
protocol is useful for particular use cases, we describe the applicability
of the protocol for certain network/traffic properties. This is similar to
other MANET protocols we have standardized.

> interface parameters?

As you can easily see from the rfcdiff (
http://tools.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-07.txt), not
all parameters are now interface parameters, only RREQ_MAX_JITTER and
USE_BIDIRECTIONAL_LINK_ONLY.
MANET routers may have multiple interfaces with different properties (e.g.,
one wireless interface, one Ethernet interface). In such cases, it is
advantageous to allow for more flexibility of the parameters per interface.

> Is this a MUST for the protocol or a SHOULD? ,
>

I don't understand that question.

Best regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 8 Jan 2013 09:41:24 -0800

Hi,

as it has been requested, I will provide some rationale for the changes in
the latest revision:

> - many editorial improvements

The document is better to read now, and is better aligned with other WG
documents / RFCs in MANET.

> parameters, which allows for using different settings for different

RREQ_MAX_JITTER and USE_BIDIRECTIONAL_LINK_ONLY are now interface
parameters.
MANET routers may have multiple interfaces with different properties (e.g.,
one wireless interface, one Ethernet interface). In such cases, it is
advantageous to allow for more flexibility of the parameters per interface.
RREQ_RATELIMIT has been replaced by RREQ_MIN_INTERVAL, which determines the
minimum interval between two consecutive RREQs. The purpose is the same,
but it is easier to implement and better aligned with other MANET RFCs.

> allowing extensions as companion document, e.g. expanding ring search)

As said, this allows for limiting the scope of messages. Before, we only
had hop-count, which in theory could also be used to limit the scope.
However, a problem arises when different routers in the MANET have
different settings of MAX_HOP_COUNT; a router could receive a message with
a hop-count greater than its MAX_HOP_COUNT. More severe than that, the
originator of that message has no control of the scope when different
MAX_HOP_COUNTs may appear in the network. A decreasing hop-limit avoids
that problem.

> - RERR also includes the originator address

This is mostly for extensibility and security purposes. Also, we allow for
different error codes in an RERR, again for future extensions in companion
documents.

> - definition of a FLAGS TLV instead of the ackrequired TLV

The ackrequired TLV did not have a value and would therefore be removed by
intermediate routers along a route if they did not require a RREP_ACK. This
would make end-to-end security even more difficult than it already is for
reactive protocols. Therefore, we proposed to always include the TLV and to
give it a value (1 for ackrequired, 0 for not required). That means that
while the message content may change in the TLV value, the position of the
TLV value and the length of the message do not change, making integrity
protection easier.
Since we already use the one byte for the 1-bit value, we instead specify a
FLAGS TLV with 7 bits than can be used by extensions in companion documents.

> - pre-allocation of two metrics in the IANA registries

We defined the hop-count metric, which is only a fallback if an
intermediate router does not know the metric-type of an incoming routing
message. It will then set the TLV value to the maximum value (filled with
all '1's) and change the metric-type to hop-count, then the routers can use
the information from the routing message and use the msg-hop-count field
instead of the metric value.
Another predefined metric is a dimensionless metric (similar to OLSRv2)
with a float as value. We thought about using the same encoding for the
metric as used in OLSRv2, section 6.2. However, that is used for a single
link; we would need 8 more bits (255 hops maximum), which would make
alignment difficult. Also, route-metric is included only once in the
message, whereas the link metric in OLSRv2 is included per neighbor,
therefore saving one or two extra bytes is more important in OLSRv2 than
for LOADng.
Any other metrics can still be added to the registry at any time.

Ulrich

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 8 Jan 2013 18:01:00 +0000

Hello WG participants, 

It is a good thing that both of the reactive protocol documents have updated versions; I would like to thank the authors of both docs for continuing to progress the state of the art. 

That being said, let us endeavor to, for the moment, keep the discussion focused on the technical aspects, shying away from the purely editorial. We have active involvement from the ADs; a path forward will hopefully emerge. Any discussion about stylistic or purely editorial content of the two documents is, IMHO, "beating a dead horse". Those judgements are inherently subjective, therefore, it is easy for people to reach different conclusions.

One other item I feel compelled to mention with regard to this debate: I believe strongly that "Honorable people can disagree honorably." I think that the some of the email threads surrounding the reactive protocols (and no, I will not be more specific than that) sometime lose sight of that notion. So I ask you to please remember this, and think before you post. 

Regards,
Stan

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 8 Jan 2013 19:23:07 +0100

Hi Herberg,

> I don't understand that question.

Is thoes parameters that are now added to interfaces a MUST for the
interface to have for the protocol purposes?

Regards
AB

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 8 Jan 2013 10:35:23 -0800

Abdussalam,

I think that listing the parameters does not require the use of RFC2119
language (see RFC2119 section 6). We followed the same way that other MANET
RFCs (e.g. RFC6130) use parameters/constants. RFC2119 language is used in
the appropriate sections when the parameters are used, e.g., section 12: "
Two consequent RREQs generated on an interface of a LOADng Router SHOULD be
separated at least RREQ_MIN_INTERVAL."

Best regards
Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 8 Jan 2013 19:43:27 +0100

Hi Stan,

Thanks for reminder. I agree with you, but not only reactive proto., I
had confusions with the proactive protocol as well, few participants
don't reply friendly/clearly as I understood, there was confusion with
DLEP once we got no much replies to some enquiries (but now solved).
However, I will try my best to follow your advise. Therefore, as a
participant I will need that the WG chair or co-chair remind us from
time to time to reply/comment/input to make this WG progress. As from
my reading experience of other WGs that WG chair's frequent input on
the list makes the WG participants more able to make new
input/decisions.

Thanks for your input,

AB

On 1/8/13, Stan Ratliff (sratliff) <[email-masked]> wrote:
> Hello WG participants,
>
> It is a good thing that both of the reactive protocol documents have updated
> versions; I would like to thank the authors of both docs for continuing to
> progress the state of the art.
>
> That being said, let us endeavor to, for the moment, keep the discussion
> focused on the technical aspects, shying away from the purely editorial. We
> have active involvement from the ADs; a path forward will hopefully emerge.
> Any discussion about stylistic or purely editorial content of the two
> documents is, IMHO, "beating a dead horse". Those judgements are inherently
> subjective, therefore, it is easy for people to reach different
> conclusions.
>
> One other item I feel compelled to mention with regard to this debate: I
> believe strongly that "Honorable people can disagree honorably." I think
> that the some of the email threads surrounding the reactive protocols (and
> no, I will not be more specific than that) sometime lose sight of that
> notion. So I ask you to please remember this, and think before you post.
>
> Regards,
> Stan

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 8 Jan 2013 21:46:27 +0100

Hi Herberg,

I try to separate not the use of 2119 but the functions of LOADng and
its interfaces. I don't mean the 2119 use but its affects. So I was
thinking that if an interface of LOADng failed to have thoes
parameters will the protocol LOADng still perform. I think your answer
is yes.

AB

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 8 Jan 2013 13:21:43 -0800

Hi Abdussalam,

> parameters will the protocol LOADng still perform. I think your answer

An implementer may choose to not use such parameters, to rename them, or to
implement the internal processing as he/she wants to. However, all the
normative part that affect interoperability must follow the RFC2119
notation. So in the example I mentioned, ("Two consequent RREQs generated
on an interface of a LOADng Router SHOULD be separated at least
RREQ_MIN_INTERVAL."), it is irrelevant how the parameter RREQ_MIN_INTERVAL
is implemented, as long as no two consecutive RREQ are generated within
less than RREQ_MIN_INTERVAL.

Best regards
Ulrich