Subject: [manet] Notifications from the IETF tools Issue Tracker

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 09 Jan 2013 14:44:55 -0800

Hello folks,

I've added several issues to the Issue Tracker.  I look forward to 
discussion
on the issues.  You can simply reply to the list, and I can add the 
substantive
points from email to the issue tracker.  Or you can go to the IETF tools 
page:
http://trac.tools.ietf.org/wg/manet/trac/query?status=new&status=assigned&status=reopened&component=dymo

The Trac wiki syntax requires putting in '!' escapes preceding the
mixed-case variable names.  This unfortunately appears also in Trac's emails
to the WG list, and deTracs from readability.  I'll try to figure out how
to report this bug to the IETF tools team, to see if they have any interest
in fixing it.

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 10 Jan 2013 08:35:04 +0100

> to report this bug to the IETF tools team, to see if they have any interest

I would also like to put an issue on the tracker that AODV2 use the 
position and structure of the RFC5444 addresses as protocol information 
at the moment, I feel this might become a major headache in the future.

Both AODVv1 and OLSRv1 used binary network messages where the position 
in the message provided information about the data itself.

With RFC5444 OLSRv2 stepped away from this, using the TLVs to mark the 
type of information within the message stream. This makes the message 
much easier to extend.

AODVv2 is a BAD step backward compared to OLSRv2 because it mixes the 
TLV-based format of RFC5444 with implicit demands on the internal 
structure and order of the address blocks and its addresses.

If AODVv2 uses a message for information type X, it should mark this 
with a TLV.

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: "Charles E. Perkins" <[email-masked]>
Date: Wed, 09 Jan 2013 23:42:40 -0800

Hello Henning,

I'll put the issue on the Issue Tracker tomorrow.

However, there have been many protocols using positional information
for lists (of addresses, etc) without impairment of extensibility.
This is especially true when extensions go at the end.  Do you have
any particular example in mind where RFC 5444 somehow creates
a problem with this?

Regards,
Charlie P.

On 1/9/2013 11:35 PM, Henning Rogge wrote:
> position and structure of the RFC5444 addresses as protocol 
> information at the moment, I feel this might become a major headache 
> in the future.
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 11 Jan 2013 08:03:05 +0100

> any particular example in mind where RFC 5444 somehow creates

With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because 
I can just add whatever I want to the protocol message, as long as I use 
new TLVs.

New addresses? No problem, regardless on the position.

New TLVs on existing addresses? No problem too.

Why use a pure TLV format if we put parts of the information into the 
order and structure of the format and do NOT use TLVs for it?

The restriction of the order of addresses and the mandatory split into 
multiple address blocks is also a problem for address compression. The 
order and split have a huge influence on the compression efficiency, 
demanding a specific split/order will make AODVv2 messages larger in 
some cases.

Henning Rogge

---

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

I agree with Henning. A protocol using RFC5444 should not mandate a certain order or a split into address blocks for the reasons Henning mentioned. The RFC5444 parser/generator can be independent of the protocol that uses it (in my LOADng code that's the case), and used by several protocol implementations and extensions concurrently. The protocols and extensions may not necessarily have the information about positions or split into address blocks.

In LOADng, no such knowledge is required.

Regards
Ulrich

On Jan 10, 2013, at 23:03, Henning Rogge <[email-masked]> wrote:

> With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because I can just add whatever I want to the protocol message, as long as I use new TLVs.
> 
> Why use a pure TLV format if we put parts of the information into the order and structure of the format and do NOT use TLVs for it?
> 
> The restriction of the order of addresses and the mandatory split into multiple address blocks is also a problem for address compression. The order and split have a huge influence on the compression efficiency, demanding a specific split/order will make AODVv2 messages larger in some cases.
> 
> Henning Rogge
> 
> 
> --

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Jan 2013 15:23:26 +0000

>
> With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because I
> can just add whatever I want to the protocol message, as long as I use new
> TLVs.
>
> Yes that is an advantage of LOADng, but is the extend issue necessary for
any 5444 message or protocol,

> demanding a specific split/order will make AODVv2 messages larger in some
> cases.
>
>
I know that this issue of 5444 order/filling was not specified by the MANET
WG yet, so do you think we SHOULD specify it, if yes, we need someone to
write the ID. I remember this discussion was raised in DLEP messages as
well,

AB

---

From: Henning Rogge <[email-masked]>
Date: Fri, 11 Jan 2013 17:26:57 +0100

> any 5444 message or protocol,

If not we are wasting a lot of the capabilities of a TLV-based format.
In addition to this the artificial split-up into multiple Address
Blocks will make address compression much harder... which wastes bytes
to be transferred over the MANET.

Henning Rogge
-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 11 Jan 2013 17:50:03 +0100

In complete agreement with Ulrich here. 

Associating semantics to ordering of TLVs or addresses in 5444 removes the ability for generic parsers and generators. That would be a very unfortunate design, given that 5444 was designed exactly to be generic.

Thomas

Sent from my iPad

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Jan 2013 18:34:23 +0100

Hi Thomas,

 I like RFC5444 that it is named general format so that any protocol
uses it the way best for the protocol's functions. This is why I see
advantages also in AODVv2 use of the 5444, and also the DLEP use of
5444. However, still the WG did not specify how to use the 5444
messaging in a general protocol.
 I remember this was discussed between you and Teco in one meeting,
regarding security issues of RFC5444 and that the co-chair asked if
one is welling to specify the 5444 format filling methods for the WG.

AB

On 1/11/13, Thomas Heide Clausen <[email-masked]> wrote:
> Associating semantics to ordering of TLVs or addresses in 5444 removes the
> ability for generic parsers and generators. That would be a very unfortunate
> design, given that 5444 was designed exactly to be generic.
>
> Thomas
>
> Sent from my iPad
>
>> I agree with Henning. A protocol using RFC5444 should not mandate a
>> certain order or a split into address blocks for the reasons Henning
>> mentioned. The RFC5444 parser/generator can be independent of the protocol
>> that uses it (in my LOADng code that's the case), and used by several
>> protocol implementations and extensions concurrently. The protocols and
>> extensions may not necessarily have the information about positions or
>> split into address blocks.
>>
>> On Jan 10, 2013, at 23:03, Henning Rogge
>> <[email-masked]> wrote:
>>
>>> can just add whatever I want to the protocol message, as long as I use
>>> new TLVs.
>>>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Jan 2013 18:38:24 +0100

Hi Henning,

There are always reasons for the way AODVv2 was done, however, I think
the authors of AODVv2 will explain better why such way, for me I only
checked the protocol functions, but interested to know more and if it
can be improved, thanks,

AB

On 1/11/13, Henning Rogge <[email-masked]> wrote:
>>> I
>>> new

---

From: Henning Rogge <[email-masked]>
Date: Fri, 11 Jan 2013 18:42:50 +0100

> checked the protocol functions, but interested to know more and if it

The only reason I can see (but do NOT agree upon) is that a full
RFC5444 design is a little bit more difficult to parse. But the higher
flexibility and the chance for a better compression should easily
compensate for this.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 15 Jan 2013 13:22:19 +0000

To my mind, a critical question is whether an RREQ or an RREP might, at some point, carry more than one address in what is the main address category.

Could an RREQ carry more than one address "I'm looking for A and/or B"? (and/or, as I could see either being a possibility).
Could an RREP carry more than one address - either "you asked for A, I am A. I'm also B, C and D" or with IRREPs "I also route to B, C and D".

This sort of information could be flagged with TLVs. Positionally it's much harder - especially if we may want to add such cases later.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
Sent: 11 January 2013 16:50
To: Ulrich Herberg
Cc: [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Thomas

Sent from my iPad

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

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

Hi Chris,

I agree that your right that it will be harder if want to add such
cases later. However both cases of RREP and RREQ of more than one
address reporting are done by address blocks in dymo, do you think
there is a disadvantage?

AB

On 1/15/13, Dearlove, Christopher (UK) <[email-masked]> wrote:
> To my mind, a critical question is whether an RREQ or an RREP might, at some
> point, carry more than one address in what is the main address category.
>
> Could an RREQ carry more than one address "I'm looking for A and/or B"?
> (and/or, as I could see either being a possibility).
> Could an RREP carry more than one address - either "you asked for A, I am A.
> I'm also B, C and D" or with IRREPs "I also route to B, C and D".
>
> This sort of information could be flagged with TLVs. Positionally it's much
> harder - especially if we may want to add such cases later.
>
> --
> Christopher Dearlove

---

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

Hello Chris,

I don't think it's hard at all to do the extension you suggest.

On the other hand, in all the years I've been in manet, this is the
first time anyone suggested it might be useful...

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 15 Jan 2013 16:52:54 +0000

On Jan 15, 2013, at 11:34 AM, Charles E. Perkins wrote:

> first time anyone suggested it might be useful…

I for one can see the utility, regardless of how long it took the idea to come up. 

Regards,
Stan

---

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

Hello Chris,

small follow-up:

> Could an RREQ carry more than one address "I'm looking for A and/or B"? (and/or, as I could see either being a possibility).

Presumably you would never want exclusive "or"...?

> Could an RREP carry more than one address - either "you asked for A, I am A. I'm also B, C and D" or with IRREPs "I also route to B, C and D".

That would not be iRREP.  In AODVv2 it would be handled by the 
AdditionalNode AddrBlk.
> This sort of information could be flagged with TLVs. Positionally it's much harder - especially if we may want to add such cases later.

There's no conflict between positional and TLV usage.  The design of
the TLV would depend on whether the address list had positional
requirements.

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 15 Jan 2013 18:04:03 +0000

My point is that 5444 was designed for flexibility. (It tried a compromise also with efficiency and simplicity, but that's another matter.)  The "all information needs a TLV" approach maintains, and even extends, that flexibility. My point is not that those specific items are definitely good (though I tried to pick at least plausible ones) but that you may not know now what you want later.

With regard to cost, allowing flexibility of ordering might save what having a TLV cost you. though it might not. Not forcing more than one address block will save you more than it cost you in any but unusual circumstances.

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 15 January 2013 16:53
To: Charles E. Perkins
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

On Jan 15, 2013, at 11:34 AM, Charles E. Perkins wrote:

> first time anyone suggested it might be useful.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 15 Jan 2013 19:44:45 +0100

> With regard to cost, allowing flexibility of ordering might save what having a TLV cost you. though it might not. Not forcing more than one address block will save you more than it cost you in any…

I completely agree to this.

Henning Rogge

---

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

Hello Charlie,

> I don't think it's hard at all to do the extension you suggest.

I agree with chris, that it is hard to extend when we are having in
our design function a general manet packet format and fix position
reactive message format, because I don't have a good knowledge of
future, nor the best ways of using manet message formats, but the
thing is that;

 Could the RFC5444 general format now be suitable for reactive routing
future if routing was extended? or/and Should the manet format itself
need to be extended for reactive routings?

> first time anyone suggested it might be useful...

That is maybe because the protocols were not implemented widely.
however, It is good that we now think in that direction for future
protocols in IETF.

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 15 Jan 2013 20:22:58 +0100

> need to be extended for reactive routings?

Saying "we do not need to make it easy to extend a protocol" sounds
like a good way to make a protocol obsolete quickly.

> however, It is good that we now think in that direction for future

I have quite a few extensions planned for OLSRv2, all of them easy to
do because of the TLV format.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Jan 2013 20:37:47 +0100

> like a good way to make a protocol obsolete quickly.

I didn't say that, but I like your respond (similar to what I agreed
about Chris comment) because it was what I wanted to say. However, I
ment to add also, we never should forget that any RFC the WG produces
may make things easy or difficult depending on how we use them in
other/future works.

> do because of the TLV format.

extending the routing function maynot mean changing the routing
information format,

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Jan 2013 11:59:53 -0800

Hello Abdussalam,

> future, nor the best ways of using manet message formats, but the

On the one hand, it's probably true that placing positional constraints
on top of RFC 5444 constraints makes future designs harder (that is
almost a tautology).  Similarly, placing RFC 5444 constraints has itself
made future designs more difficult.

On other hand, there's a lot of protocols out there that have positional
constraints (at all layers!) and we know how to do that.  In particular,
AODV (the experimental protocol) did not seem to encounter any
difficulty with extensions, many of which never made it to the IETF,
and I don't remember any complaint about the positional nature of
AODV parameters in the message formats until this discussion.

So, for all practical purposes, the argument that "positional == bad"
simply does not match my experience.  As in many situations, each
design deserves its own consideration.  If positional designs make the
packets smaller, that deserves to be considered, especially for wireless.

I remember some recent discussion that there are more processor
cycles than battery lifetime, which would motivate saving bytes over
the air.  It is always a tradeoff.

> however, It is good that we now think in that direction for future

If this is a serious feature that is needed before we go forward with
next steps, I can try to compose some specification language for it.
I don't think it's too hard to do.

-- 
Regards,
Charlie P.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 15 Jan 2013 12:36:59 -0800

Hello Charlie,

I agree with Chris and Henning on this matter. You mention extensions for
AODV where no problems have been observed. I think part of the reasons is
that they (presumably) did not have to interoperate with other
implementations that did not support that extension (no multiple vendors /
multiple implementations in the same network). Henning mentioned to me once
that his OLSR.org (OLSRv1) implementation has some extensions by having a
different message type (I am sure he has more details). Sure, that works
fine, as long as there are no other routers in the network that do not use
the extension, and that therefore cannot know about the new message type.
The problem with fixed positions and lengths is that it's hard to extend,
and to remain backwards compatible / interoperable, which is a very nice
feature about OLSRv2. You can still interoperate routers that only speak
the "base" OLSRv2 and others that have extensions and attach new addresses
and TLVs in any order or position or address block they want. You can use a
common RFC5444 parser and generator for all of them. The flexibility and
extensibility of OLSRv2 was one of the main reasons for developing it
(compared to OLSR"v1"), and one of the main reasons the MANET WG
standardized RFC5444.
I have from my implementation experience, both for LOADng and OLSRv2 for
which I developed multiple extensions, always appreciated this design
choice. It made it very easy to develop in a very modular style, and not
care much about backward compatibility.

I think it would be useful to have a BCP for RFC5444 on that matter.

Best regards
Ulrich

On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins
<[email-masked]>wrote:

> ______________________________**_________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/manet<https://www.ietf.org/mailman/listinfo/manet>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Jan 2013 21:41:17 +0100

Hi Herberg,

I think your design/approach of specifying the format for the LOADng
and OLSRv2 will be great for hybrid routing scenarios, but is it the
best design for most/all scenarios,

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Jan 2013 16:39:34 -0800

Hello Ulrich,

Continuing the discussion...

On 1/15/2013 12:36 PM, Ulrich Herberg wrote:
> Hello Charlie,
>
>      .....   You mention extensions for AODV where no problems have 
> been observed. I think part of the reasons is that they (presumably) 
> did not have to interoperate with other implementations that did not 
> support that extension (no multiple vendors / multiple implementations 
> in the same network).

In very few words, this presumption is not correct.  To expand further:

There are many protocols that have to deal with unknown extensions.
Dealing with positional information is irrelevant if the type of the 
AddrTLVs
or even more so the message type is unknown.  Unless I am missing
something, the positional information in the RteMsg AddrBlk is just
not relevant to extensibility.  Even in a further extension, it would not
be relevant as long as (a) the semantics for skipping unknown extensions
is clear and (b) it's possible to know the length of the unknown extension.
No amount of TLVs will help implementations to deal with such matters
if the above points are not obeyed.

>
> The problem with fixed positions and lengths is that it's hard to 
> extend, and to remain backwards compatible / interoperable, which is a 
> very nice feature about OLSRv2.

Can you illustrate this claim given the existing AODVv2 AddrBlk and TLV 
structure?

>
> I have from my implementation experience, both for LOADng and OLSRv2 
> for which I developed multiple extensions, always appreciated this 
> design choice. It made it very easy to develop in a very modular 
> style, and not care much about backward compatibility.

I understand this to mean that you could use the same parser.
Am I missing something?

> I think it would be useful to have a BCP for RFC5444 on that matter.

Or maybe it's time for rfc5444bis -- but I don't want to tackle that
problem until the light at the end of the current tunnel gets closer.

Regards,
Charlie P.

> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Hello Abdussalam,
>
>
>     [email-masked] <mailto:[email-masked]>

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 16 Jan 2013 04:01:07 +0100

> if the above points are not obeyed.

So far I see that the above is convencing me. However, I understand
that you confirm that extending the AODVv2 with interoperable can be
done without changing or using the way Chris and Henning explained.

Best Regards

AB
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In the future some participants will say have you discussed this
issue, we may even forget, or forget where was it written, with
unrelated reference subject title no one can search or find such
stored info. Is this thread discussing tools/tracker?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 16 Jan 2013 09:46:06 +0000

Charlie
> Similarly, placing RFC 5444 constraints has itself made future designs more difficult.

In what ways?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: 15 January 2013 20:00
To: Abdussalam Baryun
Cc: [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

Hello Abdussalam,

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 16 Jan 2013 12:14:17 +0100

>> Similarly, placing RFC 5444 constraints has itself made future designs

IMO, RFC5444 made future manet-messaging design more flexible, and
more interoperable, but the protocol design more difficult. No
advantages come free I think,

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 16 Jan 2013 09:49:14 -0800

Hello Chris,

Short question -- potentially very long answer.

But the question cannot be answered to your satisfaction unless
we are measuring "difficulty" by using the same metric, and
considering designs from the same solution space.

For instance if I say that RFC 5444 makes designs *of a certain
class* more difficult, and you say those designs are *inadmissible*,
did we get anywhere?

So, measuring by difficult of understanding the design space,
there is no doubt that RFC 5444 makes designs harder
to understand.

We've already covered the difficulty of avoiding header bloat.
Remember SMURF?  RFC 5444 imposed a ~40% header tax
when address compression was unavailable -- at that time we
were all dealing mostly with IPv4.

The goal of address compression has been compromised by the
unwritten expectation of conformance to existing parser constraints,
so much so that now LOADng seems willing to forego the benefit.

Which kind of difficulty were you most interested in?

I can also write about how RFC 5444 makes things easier, but
you didn't ask that question.

-- 
Regards,
Charlie P.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 16 Jan 2013 18:06:47 +0000

> so much so that now LOADng seems willing to forego the benefit.

And this, IMO, is the crux of the issue in front of the WG. There is an existing implementation (4 interoperable implementations, based on another thread) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444 use, those implementations become non-compliant. So I think the real question(s) should be: 

- Do we as a WG want to force utilization of RFC5444 for the reactive protocol, thereby losing the advantage of the existing interoperable implementations? 
- Or, is there a reasonable hybrid approach?

To be honest, I'm much less concerned about header taxes, or how a given parser scheme makes things easier in some ways, but harder in others.

Regards,
Stan

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 16 Jan 2013 10:21:10 -0800

Stan,

both Fujitsu's implementation and the one from LIX use RFC5444 in the way
LOADng specifies it. I let Hitachi speak for their implementation.

Do we really want to reopen the consensus of the WG to use RFC5444 for
MANET routing protocols, and thus need to obsolete RFC5498? I think that
would be a huge mistake.

Best regards
Ulrich

On Wed, Jan 16, 2013 at 10:06 AM, Stan Ratliff (sratliff) <
[email-masked]> wrote:

> And this, IMO, is the crux of the issue in front of the WG. There is an
> existing implementation (4 interoperable implementations, based on another
> thread) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444
> use, those implementations become non-compliant. So I think the real
> question(s) should be:
>
> - Do we as a WG want to force utilization of RFC5444 for the reactive
> protocol, thereby losing the advantage of the existing interoperable
> implementations?
> To be honest, I'm much less concerned about header taxes, or how a given
> parser scheme makes things easier in some ways, but harder in others.
>
> Regards,
> Stan
>
> >

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 16 Jan 2013 18:39:22 +0000

Ulrich,

Oh, good. I didn't realize a couple of the existing implementations use RFC 5444. That pretty much solves my problem.

Regards,
Stan

On Jan 16, 2013, at 1:21 PM, Ulrich Herberg wrote:

Stan,

both Fujitsu's implementation and the one from LIX use RFC5444 in the way LOADng specifies it. I let Hitachi speak for their implementation.

Do we really want to reopen the consensus of the WG to use RFC5444 for MANET routing protocols, and thus need to obsolete RFC5498? I think that would be a huge mistake.

Best regards
Ulrich

On Wed, Jan 16, 2013 at 10:06 AM, Stan Ratliff (sratliff) <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Stan

> [email-masked]<mailto:[email-masked]>

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

---

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

> - Do we as a WG want to force utilization of RFC5444 for the reactive protocol, thereby losing the advantage of the existing interoperable implementations?

I think instead of loosing the flexibility of RFC5444 in on the
protocol level, we should have a look at XML schema based compression.
I think we can adapt this approach to RFC5444 based MANET protocols,
which would allow to further compress the packets down based on the
necessities of the deployments.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 16 Jan 2013 19:59:50 +0000

Henning, 

> necessities of the deployments.

That's an interesting idea. Also, since Ulrich pointed out that the existing LOADng implementations are indeed based on RFC 5444, I don't have an issue - I'd vote for full 5444 compliance, since that's already mandated for *routing protocols* (referencing our earlier DLEP discussion), and the reactive protocol definitely applies. 

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 16 Jan 2013 21:26:35 +0100

On Wed, Jan 16, 2013 at 8:59 PM, Stan Ratliff (sratliff)
<[email-masked]> wrote:
> That's an interesting idea.

Thank you. We plan to write it down (maybe as a IETF draft) and get a
prototype. I think this has the potential to reduce RFC5444 packets
even more without the need to touch the protocol (or maybe even the
implementation!).

> Also, since Ulrich pointed out that the existing LOADng implementations are indeed based on RFC 5444, I don't have an issue - I'd vote for full 5444 compliance, since that's already mandated for *routing protocols* (referencing our earlier DLEP discussion), and the reactive protocol definitely applies.

*nod*

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 17 Jan 2013 00:07:17 +0100

Hi Henning,

I am not sure I understand the example you made, could you give a
suggestion of better design of RREQ and RREP for AODVv2 so we can
reasonably go through the protocol functionality.

Giving general exmples will not produce protocols for our WG, even the
RFC5444 is flexibile but let us go through the reactive protocol
messaging and its reflection on the function, not just giving
interesting things outside the function, as compressing,

AB

---

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

Hi stan,

> That's an interesting idea. Also, since Ulrich pointed out that the existing
> LOADng implementations are indeed based on RFC 5444, I don't have an issue -
> I'd vote for full 5444 compliance, since that's already mandated for
> *routing protocols* (referencing our earlier DLEP discussion), and the
> reactive protocol definitely applies.

Do you mean that DYMO document is not full compliant of 5444 and
LOADng is full complaint, please explain, because I disagree,

AB

---

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

Chris:

Have you discussed these scenarios at an IETF or on the list?  If so, can you point me to the IETF presentation or list day. 
If not, there is considerable complexity behind your suggestion.  

Have you or the group done a literature search on algorithms from sensor and manet that examine this? I'm a bit out of date on sensors and mobility (2-3 years on DC switches), but there used to be a lot of challenge in these algorithms.  

Charlie and Thomas used to entertain me with ideas a few years ago. 

I'm not saying that considering this wouldn't be fun though,

Cheers, 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: Tuesday, January 15, 2013 8:22 AM
To: Thomas Heide Clausen; Ulrich Herberg
Cc: [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

--
Christopher Dearlove
Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124 [email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
Sent: 11 January 2013 16:50
To: Ulrich Herberg
Cc: [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Thomas

Sent from my iPad

On 11 janv. 2013, at 08:25, Ulrich Herberg <[email-masked]> wrote:

>>> any particular example in mind where RFC 5444 somehow creates a 
>>> problem with this?
>> 
>> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, 
>> Germany

********************************************************************
This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
********************************************************************

---

From: Henning Rogge <[email-masked]>
Date: Thu, 17 Jan 2013 08:22:58 +0100

> interesting things outside the function, as compressing,

I was talking about a potential new Draft for this working group which 
defines a transparent compression/decompression scheme for RFC5444 messages.

I think this is "in scope" of this WG.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 17 Jan 2013 09:51:34 +0000

I'm afraid I don't see anything concrete there. And when you say "there is no doubt" I definitely don't agree. It's a matter of presentation.

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: 16 January 2013 17:49
To: Dearlove, Christopher (UK)
Cc: Abdussalam Baryun; [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

Hello Chris,

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 17 Jan 2013 09:55:34 +0000

We as a WG have already made a decision, ratified by the IESG etc., it's in RFC 5498. I view with dismay some people's apparent attempts to unroll this, and make yet more here unagreed.

(Strictly, that decision applies only to protocols using the manet port/protocol. But there it is necessary to be retained.)

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 16 January 2013 18:07
To: Charles E. Perkins
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 17 Jan 2013 10:15:05 +0000

No, I have not, and my point is not these examples. My point is that one may, at some point, wish to add additional forms of behaviour. These are just plausible (I'll take Stan's comments as agreeing they reach at least that low bar) examples of the sort of thing that might be added. But it's that you don't know what you might add that is the point - the specific examples in that sense obscure the point. A more flexible design now allows easier extension later.

A specific example is the evolution of use of TLVs in attaching to addresses in OLSRv2's TC messages. You could actually manage without one of its TLVs by (in effect) saying "all addresses without a TL attached are assumed to act as if this information applies to that address". But then you can't add new addresses with new properties - and people have some ideas there (not published as far as I know). Similarly if you say "the first address has property , all other addresses have property Y" you can't have a second address with property X. Or addresses with property Z (but not Y). Or even no addresses with property X (but some addresses with property Y).

It all depends on how extensible you plan to be. But there are already plenty of suggestions for AODVv2 extensions floating around.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: 17 January 2013 01:49
To: Dearlove, Christopher (UK); 'Thomas Heide Clausen'; 'Ulrich Herberg'
Cc: [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

Chris:

Cheers, 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
Sent: 11 January 2013 16:50
To: Ulrich Herberg
Cc: [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

Thomas

Sent from my iPad

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 17 Jan 2013 10:27:28 +0000

I will say that OLSRv2 split into five documents (not counting metrics rationale, MIB, or future security documents). In my ideal world in which I (and my co-suthors) had unlimited time, I would have had two more, one of which would have been a separation between a message specification in terms of addresses and attributes, and a mapping of the latter to 5444. (The other, just for interest, is that OLSRv2's processing and forwarding engine is potentially reusable outside OLSRv2.) Whether XML is the best intermediate form could be debated - and it might be important to understand whether the XML is being used as a presentational approach, or really intended for use. It has drawbacks in both cases, as well as advantages. The major dangers I see are people thinking you must use XML in your implementation - really you shouldn't even hint that - and taht the XML might itself obscure matters in that intermediate step. Arguably XML isn't that intermediate step, but another thing that the abstract "addresses and attributes" could be coded as.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 17 January 2013 07:23
To: [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 17 Jan 2013 11:31:48 +0100

On 01/17/2013 11:27 AM, Dearlove, Christopher (UK) wrote:
> I will say that OLSRv2 split into five documents (not counting
> metrics rationale, MIB, or future security documents). In my ideal
> world in which I (and my co-suthors) had unlimited time, I would have
> had two more, one of which would have been a separation between a
> message specification in terms of addresses and attributes, and a
> mapping of the latter to 5444. (The other, just for interest, is that
> OLSRv2's processing and forwarding engine is potentially reusable
> outside OLSRv2.) Whether XML is the best intermediate form could be
> debated - and it might be important to understand whether the XML is
> being used as a presentational approach, or really intended for use.
> It has drawbacks in both cases, as well as advantages. The major
> dangers I see are people thinking you must use XML in your
> implementation - really you shouldn't even hint that - and taht the
> XML might itself obscure matters in that intermediate step. Arguably
> XML isn't that intermediate step, but another thing that the abstract
> "addresses and attributes" could be coded as.

Just to make sure you understand me correctly...

I do NOT want to use XML anywhere in the context of RFC5444.

I want to develop something similar to XML-schema based compression for 
RFC5444, because I think the same principle could be used for MANET 
protocols on top of RFC5444.

(its also similar to the IETF Robust Header Compression standard for IP 
and transport level protocols)

The goal is a transparent compressor, which takes RFC5444 binary packets 
as input and outputs a compressed packet based on a schema 
representation of the protocols in use.

On the receiver end there will be a transparent decompresser, which 
reconstructs the original RFC5444 packets based on the same schema as 
the compressor on the other end.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 17 Jan 2013 13:11:42 +0000

OK, that's something different than I read you as suggesting.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 17 January 2013 10:32
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 17 Jan 2013 21:59:13 +0100

Hi Chris

I agree that don't like XML examples and want better examples to know
best way to design. however, Why you abstract the addresses and
attribute as you mentioned, from the protocol message?
 or maybe I got it wrong :(
AB

On 1/17/13, Dearlove, Christopher (UK) <[email-masked]> wrote:
> I will say that OLSRv2 split into five documents (not counting metrics
> rationale, MIB, or future security documents). In my ideal world in which I
> (and my co-suthors) had unlimited time, I would have had two more, one of
> which would have been a separation between a message specification in terms
> of addresses and attributes, and a mapping of the latter to 5444. (The
> other, just for interest, is that OLSRv2's processing and forwarding engine
> is potentially reusable outside OLSRv2.) Whether XML is the best
> intermediate form could be debated - and it might be important to understand
> whether the XML is being used as a presentational approach, or really
> intended for use. It has drawbacks in both cases, as well as advantages. The
> major dangers I see are people thinking you must use XML in your
> implementation - really you shouldn't even hint that - and taht the XML
> might itself obscure matters in that intermediate step. Arguably XML isn't
> that intermediate step, but another thing that the abstract "addresses and
> attributes" could be coded as.
>
> --
> Christopher Dearlove

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 17 Jan 2013 21:24:06 -0500

Henning: 

(smile) 
Link-state protocols with TLVs make additions easy to consider. 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Rogge
Sent: Tuesday, January 15, 2013 2:23 PM
To: Abdussalam Baryun
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] Notifications from the IETF tools Issue Tracker

<snip> 

I have quite a few extensions planned for OLSRv2, all of them easy to do
because of the TLV format.

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Jan 2013 09:33:07 -0800

Hello Ulrich,

First, let's agree that, all other things being equal, position independence
is better than positional dependence.  Then, it's a matter of trading off
that positive feature versus other potential negatives.  In the extreme,
no one would add a kilobyte to the header just to preserve position
independence.

Next, please observe that Henning has proposed a change to RteMsg
design that offers positional independence.  I hope to write it up today
for evaluation.

Third, we have lots of experience with positional dependent designs
that are extensible -- not related to [manet].  To me this is almost a
no-brainer, but I also know that the RFC 5444 (and, perhaps more
inclusively, the XML) experts have relevant experience.  Using the same
parser is, in my view, not a factor that should determine the outcome
of this design decision.  If adding bytes to the header causes more rapid
depletion of radio transceiver batteries, then trying to inherit someone
else's parser is optimizing the wrong thing.  If we all took the time to
analyze and argue this out in gory detail, I think we could come to some
consensus position, but I also don't think that is where we should spend
our time right now.

Fourth, I think there are some noticeable problems with RFC 5444
that need fixing, but I have avoided making that into part of the
discussion about reactive protocols.  For now, the task is to make
RFC 5444 serve the purpose which it is mandated to serve.  That has
proved difficult enough.  The discussion seems to be devolving into
something of a religious war, with any criticism being *dismissed*
as irrelevant.  I have neither the time nor the inclination to fight it.

Regards,
Charlie P.

On 1/15/2013 12:36 PM, Ulrich Herberg wrote:
> Hello Charlie,
>
> I agree with Chris and Henning on this matter. You mention extensions 
> for AODV where no problems have been observed. I think part of the 
> reasons is that they (presumably) did not have to interoperate with 
> other implementations that did not support that extension (no multiple 
> vendors / multiple implementations in the same network). Henning 
> mentioned to me once that his OLSR.org (OLSRv1) implementation has 
> some extensions by having a different message type (I am sure he has 
> more details). Sure, that works fine, as long as there are no other 
> routers in the network that do not use the extension, and that 
> therefore cannot know about the new message type.
> very nice feature about OLSRv2. You can still interoperate routers 
> that only speak the "base" OLSRv2 and others that have extensions and 
> attach new addresses and TLVs in any order or position or address 
> block they want. You can use a common RFC5444 parser and generator for 
> all of them. The flexibility and extensibility of OLSRv2 was one of 
> the main reasons for developing it (compared to OLSR"v1"), and one of 
> the main reasons the MANET WG standardized RFC5444.

-- 
Regards,
Charlie P.

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 21 Jan 2013 09:44:41 -0800

Hello Charlie

On Mon, Jan 21, 2013 at 9:33 AM, Charles E. Perkins
<[email-masked]>wrote:

>  [...]

I haven't seen any "religious war". I have seen arguing 5 or 6 people
(including multiple RFC5444 authors) against positional dependence and 1
person in favor. I would call that "rough consensus", not "dismissal".
(Moreover, by having standardized RFC5444 and RFC5498, there is more
evidence of consensus in the WG on the usage of RFC5444 long before this
discussion).

Best regards
Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 21 Jan 2013 20:41:04 +0100

On 1/21/13, Ulrich Herberg <[email-masked]> wrote:
> person in favor.

It was 5 not 6, and for positional dependence was 3 (includes me, but
I prefer mix), so I think no concensus, IMHO, we still should go
through this discussion, but to relate the decision to reason and
engineering knowledge.

>I would call that "rough consensus", not "dismissal".

Any RFC may be updated in future or at any time because of new
knowledge, or even RFCs may be obsoleted by others. As someone just
mention lets focus on our documents to meet the milestones,

AB

---

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

> as irrelevant.  I have neither the time nor the inclination to fight it.

I mentioned that there may be enhancements to RFC5444 (I may be wrong,
but any RFC including 5444 may need enhacement) after reading some
inputs and thinking of designing a new manet protocol, however, I
agree/support that we postpone this issue until we submit the first
proposed standrard reactive protocol.

AB

---

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

> no one would add a kilobyte to the header just to preserve position

Reductio ad absurdum.

> of this design decision. 

That is, then, because you have not been in the business of implementing protocols and multi-protocol MANET routers. It is a HUGE benefit to be able to share parsing code, especially given that 5444 is (if used properly) both flexible, efficient to parse and efficient in encoding messages. It also gives you some nice benefits of running multiple protocols jointly (as is the case with NHDP/OLSRv2/SMF) on the same device. 

Same benefits apply if you run LOADng/OLSRv2/NHDP together.

> If adding bytes to the header causes more rapid
> discussion about reactive protocols. 

Unless you are willing to make the arguments, please don't spread such misinformation.

> For now, the task is to make
> proved difficult enough. 

This is wrong.

A multitude of MANET protocols have been designed to use RFC5444, including reactive protocols, without any problems.

It's extremely easy, even, once one understands RFC5444.

> The discussion seems to be devolving into

I am not going to respond to that directly. 

I would appreciate technical arguments, rather than strawman's and assertions. 

Thomas

>> I agree with Chris and Henning on this matter. You mention extensions for AODV where no problems have been observed. I think part of the reasons is that they (presumably) did not have to interoperate with other implementations that did not support that extension (no multiple vendors / multiple implementations in the same network). Henning mentioned to me once that his OLSR.org (OLSRv1) implementation has some extensions by having a different message type (I am sure he has more details). Sure, that works fine, as long as there are no other routers in the network that do not use the extension, and that therefore cannot know about the       new message type. 
>> The problem with fixed positions and lengths is that it's hard to extend, and to remain backwards compatible / interoperable, which is a very nice feature about OLSRv2. You can still interoperate routers that only speak the "base" OLSRv2 and others that have extensions and attach new addresses and TLVs in any order or position or address block they want. You can use a common RFC5444 parser and generator for all of them. The flexibility and extensibility of OLSRv2 was one of the main reasons for developing it (compared to OLSR"v1"), and one of the main reasons the MANET WG standardized RFC5444. 
>> I have from my implementation experience, both for LOADng and OLSRv2 for which I developed multiple extensions, always appreciated this design choice. It made it very easy to develop in a very modular style, and not care much about backward compatibility.
>> 
>> On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins <[email-masked]> wrote:
>>> 
>>> Hello Abdussalam,
>>> 
>>>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Jan 2013 13:03:30 -0800

On 1/21/2013 12:37 PM, Thomas Heide Clausen wrote:
>
>
> On 21 janv. 2013, at 18:33, "Charles E. Perkins" 

Usually, the phrase "Reductio ad absurdum." is followed by QED.

> That is, then, because you have not been in the business of 
> implementing protocols and multi-protocol MANET routers. It is a HUGE 
> benefit to be able to share parsing code, especially given that 5444 
> is (if used properly) both flexible, efficient to parse and efficient 
> in encoding messages. It also gives you some nice benefits of running 
> multiple protocols jointly (as is the case with NHDP/OLSRv2/SMF) on 
> the same device.

So you'd rather optimize for parser development time over
battery lifetime?   At the beginning of my earlier email, I
referred to "tradeoffs".  I'll stand by that.  I dispute the notion
that one has trouble using multiple other protocols if one also
uses a protocol with positional AddrBlks, and I'd be interested
to see a specific counter-example.

> Unless you are willing to make the arguments, please don't spread such 

O.K.  I'll bookmark your challenge and get back to it next month.

>> RFC 5444 serve the purpose which it is mandated to serve. That has

Well, Ian spent a lot of time on it but couldn't do it so "easily".
I don't consider myself a beginner, but I find it at minimum tedious
and at worst error-prone.  But -- I'm getting better at it.

>
> A multitude of MANET protocols have been designed to use RFC5444, 
> including reactive protocols, without any problems.
>

See the above.  If I am challenged to get testimonials to the
contrary from other people, then I'll have to wait.   I'm not at
all interested in arguing about it, especially right now!   I will
at least say that other software developers seem more willing
to accept feedback.

-- 
Regards,
Charlie P.

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 21 Jan 2013 13:16:08 -0800

Charlie,

> and at worst error-prone.  But -- I'm getting better at it.

When I changed our LOADng implementation from a fixed packet format to
RFC5444, it did not take me more than two days (that includes implementing
RFC5444). I did not think it was hard. And it was not error-prone, as shown
by an interop test that I did soon after that update, which was very
successful after only little time fixing minimal bugs. Therefore, I cannot
confirm that it is "tedious" or "error-prone".

Best regards
Ulrich

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 21 Jan 2013 22:17:58 +0100

On 21 janv. 2013, at 22:03, "Charles E. Perkins" <[email-masked]> wrote:

> battery lifetime? 

You assert that they're different?

I've not observed the negative effects you describe above in real (battery constrained) deployments.

>   At the beginning of my earlier email, I

It's not impossible.
It's just a lot easier when using 5444.

> and at worst error-prone.  But -- I'm getting better at it.

When we designed LOADng, designing it to use RFC5444 was a very easy exercise. Neither tedious nor error-prone.

And, it brought all the other benefits of RFC5444 usage also.

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Jan 2013 13:22:21 -0800

Hello Uli,

On 1/21/2013 1:16 PM, Ulrich Herberg wrote:
> RFC5444, it did not take me more than two days (that includes 
> implementing RFC5444). I did not think it was hard. And it was not 
> error-prone, as shown by an interop test that I did soon after that 
> update, which was very successful after only little time fixing 
> minimal bugs. Therefore, I cannot confirm that it is "tedious" or 
> "error-prone".

This is good news.  I think you truly qualify as an expert at RFC 5444.  
I reckon I also will be an expert before long.

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Jan 2013 14:50:44 +0100

> to see a specific counter-example.

The trouble starts when you get two protocols with positional dependent 
stuff. The solution is to stay with the T in TLV (its "type") and not 
start hacking half of it away.

Just imagine your suggestion with AODVv2 and another one that wants to 
use the first address for something else. Or just a generator that wants 
to reorder the constructed message addresses to get a better compression.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 22 Jan 2013 15:42:02 +0000

Charlie,

Inline

On Jan 21, 2013, at 4:03 PM, Charles E. Perkins wrote:

On 21 janv. 2013, at 18:33, "Charles E. Perkins" <[email-masked]<mailto:[email-masked]>> wrote:

Hello Ulrich,

Reductio ad absurdum.

For me, the issue here is that working group consensus seems to have solidified around positional independence. If fact, Charlie, you seem to be the only one holding the counter position. Based on Adrian's email on the way forward, the specification needs to reflect the consensus of the WG. As of right now, that means it (the spec) needs to change.

To the WG participants: If you are holding other views, now is the time to express them.

Well, this worries me. At a minimum, I'd like to have the opportunity of understanding the issues you allude to. Because at this point, I don't know how to classify - is this in the "minor irritant" category, the "major pain in the backside" column, or the "no way on Earth this will ever work" type? You can't just lob something like this out and then keep on going, without more information for the rest of us.

Regards,
Stan

This is wrong.

--
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 17:31:33 +0100

Dear Stan,
Co-Chair of MANET WG

Please don't ignore my input, I posted my opinion many times,  :)

I supported the reactive ideas of Mr.Perkins and agree with the
draft-25. I reviewed the draft and gave comments, but how many have
reviewed the work and gave suggestions to change with good reason for
progress.

I suggest/think that the coming process SHOULD be that the Chair of
the WG submits the new WG draft-00 (was mentioned by AD), then we will
be able to discuss more officially and reasonably. I am waiting for
the chairs to inform us with the new editors so we can get work done.
Please advise,

AB

On 1/22/13, Stan Ratliff (sratliff) <[email-masked]> wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hello Ulrich,
>
> That is, then, because you have not been in the business of implementing
> protocols and multi-protocol MANET routers. It is a HUGE benefit to be able
> to share parsing code, especially given that 5444 is (if used properly) both
> flexible, efficient to parse and efficient in encoding messages. It also
> gives you some nice benefits of running multiple protocols jointly (as is
> the case with NHDP/OLSRv2/SMF) on the same device.
>
> For me, the issue here is that working group consensus seems to have
> solidified around positional independence. If fact, Charlie, you seem to be
> the only one holding the counter position. Based on Adrian's email on the
> way forward, the specification needs to reflect the consensus of the WG. As
> of right now, that means it (the spec) needs to change.
>
> Well, this worries me. At a minimum, I'd like to have the opportunity of
> understanding the issues you allude to. Because at this point, I don't know
> how to classify - is this in the "minor irritant" category, the "major pain
> in the backside" column, or the "no way on Earth this will ever work" type?
> You can't just lob something like this out and then keep on going, without
> more information for the rest of us.
>
> Regards,
> Stan
>
>
>
>
> A multitude of MANET protocols have been designed to use RFC5444, including
> reactive protocols, without any problems.
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Jan 2013 17:41:07 +0100

> the chairs to inform us with the new editors so we can get work done.

I do not think changing the name of the draft will do ANYTHING AT ALL
to this discussion.

Looking back into the history of MANET, one protocol already "got
burned" for a "too small" attempt in allowing future extensions...
OLSR (v1).

It has a "message in packet" structure and it allowed new kind of
messages. But the structure of the Hello/TC message itself proved to
be a roadblock for the protocol because it couldn't be extended for
link metrics. Both the NRL and the Olsr.org team had to create their
own custom message type to implement an ETX metric (and making the
protocol usable in practice), which broke any compatibility. So we
have to be careful with this.

Making all information in RFC5444 based protocols depend on TLVs (and
not on position or the absence of TLVs) allows a nearly trivial merge
of new ideas into existing protocol messages. As long as the TLV
numbers do not collide, you can add whatever/wherever you want without
breaking the original protocol.

I think a lot of the current conflict is based on the decision how
much we should base the protocol DESIGN on the necessary efficiency of
some/many DEPLOYMENTS. I think we can resolve this conflict without a
compromise differently.

I will try to do a mail about this "transparent schema-based
compression" I have been talking about tomorrow, maybe this can defuse
parts of the tension in this discussion.

Henning Rogge
-- 
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: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 17:52:11 +0100

Hi Henning

it was not me to make the rules of how we discuss things, but I
understood that we need to follow in the new draft reactive protocol
as it will be starting with draft-00 and we use track tools to input
suggestions and progress. However, we can discuss any draft published
and current alive, parked or died, but is that the draft that it is
the work in progress of the WG, this is my concern,

AB

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 22 Jan 2013 18:05:44 +0000

> I do not think changing the name of the draft will do ANYTHING AT ALL

+1

Abdussalam, my apology for appearing to ignore your opinion. Poor communication on my part. However, that doesn't change my opinion at all - the rough consensus of the WG is behind the notion of position independence for TLVs in the reactive routing protocol. 

Regards,
Stan

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 19:40:36 +0100

Hi Stan,

Thanks for your reply, I respect your opinion as well,

In regards to the TLVs do you think the *protocol* performance is
better if we use non-position TLV? That is the question, the reasons
that some participants say of changing the message format are external
reasons not related to the *protocol* performance, and does not answer
the question. In my opinion they should answer so we can understand.

I understand from your reply that you stand with numbers not core
reasons. The discussions with ignoring the reactive protocol
functions/performance are useless, IMO, that direction of ignoring the
core function will not help in progress,

AB

On 1/22/13, Stan Ratliff (sratliff) <[email-masked]> wrote:
> Abdussalam, my apology for appearing to ignore your opinion. Poor
> communication on my part. However, that doesn't change my opinion at all -
> the rough consensus of the WG is behind the notion of position independence
> for TLVs in the reactive routing protocol.
>
> Regards,
> Stan
>
>
>>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 22 Jan 2013 19:15:23 +0000

AB, 

> the question. In my opinion they should answer so we can understand.

Yes, I'm concerned about overall performance with position independent TLVs. Specifically, I worry about added complexity to handle position dependence.  That being said, I do understand the notion of providing context for TLVs - that's the whole idea behind the DLEP message structure. The DLEP message provides the context (e.g. the radio neighbor, and/or the specific far-end neighbor); all TLVs are processed *within that context*. 

So I'm advocating for TLVs being as atomic in nature as is possible, since that would produce (IMO) higher-quality, better-performing implementations than something that is position-dependent. It also allows for modularity (hence, code-sharing) of the parsers involved. 

Regards,
Stan

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Jan 2013 11:32:16 -0800

Hello Stan,

RFC 5444 AddrTLVs are "positionally dependent" on the order of
the addresses in the AddrBlk.  In other words, for each address,
there can be a specific TLV <value> that refers to that address and
no others.

 From that point of view, I want to understand better your
statements:

On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote:
> Yes, I'm concerned about overall performance with position independent TLVs. Specifically, I worry about added complexity to handle position dependence.

How is "performance" in the first sentence related to "complexity" in
the second sentence?  Usually, more complexity enables higher protocol
performance, but at the cost of perhaps reduced parser development
performance (not very likely to affect the performance of the parser).

> So I'm advocating for TLVs being as atomic in nature as is possible

I guess that, in this sentence, "atomic" means that one TLV block
does not depend for the definition of its action on:
- its position in the list of TLV blocks, or
- whether or not another specific AddrTLV exists in the Address Block

But these considerations are not related to whether or not the addresses
in the AddrBlk are provided in any positionally dependent fashion.

-- 
Regards,
Charlie P.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 22 Jan 2013 12:09:07 -0800

Hello Charlie,

> there can be a specific TLV <value> that refers to that address and

I am not quite sure that I understand you correctly. But if you are saying
that only one TLV value can be associated with one particular address, this
is not true. Multiple TLVs (and their values if they have one) can be
associated with one address. There is a special case if multiple TLVs of
the same type but different value are associated with the same address,
which is mentioned in section 5.4.2. of RFC5444.
In addition, one TLV value can be associated with multiple addresses (using
the same value for each address, or in the case of a multivalue TLV with
separated values per address, but in a single TLV)

Best
Ulrich

>> Yes, I'm concerned about overall performance with position independent
>> TLVs. Specifically, I worry about added complexity to handle position
>> dependence.
>>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Jan 2013 21:13:52 +0100

On 22 janv. 2013, at 21:09, Ulrich Herberg <[email-masked]> wrote:

> Hello Charlie,
> 
> On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins <[email-masked]> wrote:
>> 
>> Hello Stan,
>> 
> I am not quite sure that I understand you correctly. But if you are saying that only one TLV value can be associated with one particular address, this is not true. Multiple TLVs (and their values if they have one) can be associated with one address. There is a special case if multiple TLVs of the same type but different value are associated with the same address, which is mentioned in section 5.4.2. of RFC5444. 
> In addition, one TLV value can be associated with multiple addresses (using the same value for each address, or in the case of a multivalue TLV with separated values per address, but in a single TLV)
> 

And, none of that is "positionally dependent".

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 21:15:42 +0100

Your examples still applies to AODVv2, it can have multiple TLVs as well,

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Jan 2013 12:47:21 -0800

Hello Ulrich,

Thanks for the clarification.  I was aware that each address could have
multiple TLV values applied, one each from different TLVs.  I was trying
to explain that, for each such TLV, there could be a distinct value applied
per address.  I think your explanation is better.

Regards,
Charlie P.

On 1/22/2013 12:09 PM, Ulrich Herberg wrote:
> I am not quite sure that I understand you correctly. But if you are 
> saying that only one TLV value can be associated with one particular 
> address, this is not true. Multiple TLVs (and their values if they 
> have one) can be associated with one address. There is a special case 
> if multiple TLVs of the same type but different value are associated 
> with the same address, which is mentioned in section 5.4.2. of RFC5444.
> In addition, one TLV value can be associated with multiple addresses 
> (using the same value for each address, or in the case of a multivalue 
> TLV with separated values per address, but in a single TLV)
>
> Best
> Ulrich
>
>
>         Yes, I'm concerned about overall performance with position
>         independent TLVs. Specifically, I worry about added complexity
>         to handle position dependence.
>
>

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 21:54:49 +0100

I think he ment to say that it was not possible in AODVv2,
maybe I misunderstood

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 22:00:17 +0100

On 1/22/13, Thomas Heide Clausen <[email-masked]> wrote:
>> that only one TLV value can be associated with one particular address,
>> this is not true. Multiple TLVs (and their values if they have one) can be
>> (using the same value for each address, or in the case of a multivalue TLV
>> with separated values per address, but in a single TLV)
>>
>

yes for TLV values associated with address we don't need position
dependent in AODVv2,

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Jan 2013 13:21:44 -0800

Hello Abdussalam,

I didn't think that Ulrich was denying the possibility of having multiple
AddrTLV blocks per AddrBlk in AODVv2.  In fact, the last version of
the AODVv2 document does specify instances of exactly that feature.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 22 Jan 2013 13:33:23 -0800

AB,

I was not saying that positional information within address blocks would
not be possible, just that I think it is a bad idea. Also, it is possible
to have multiple address blocks, but I don't think that a protocol should
mandate how to use address blocks (e.g. how many address blocks, in which
order, which addresses in which address block etc); this is the
responsibility of the RFC5444 generator (for the reasons Henning and others
mentioned).
Note that each address block is followed by exactly one "address block TLV
block", to use the correct terminology, as expressed by RFC5444:
(<addr-block><tlv-block>)*

Best
Ulrich

On Tue, Jan 22, 2013 at 1:21 PM, Charles E. Perkins
<[email-masked]>wrote:

>>>> <[email-masked] <mailto:[email-masked]>**> wrote:
>>>>
>>>>
>>>>      Hello Stan,
>>>>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jan 2013 00:04:46 +0100

Hi Ulrich,

I think you may see that it is a bad idea but that is the only choice
I see that RFC5444 serves reactive. I want to try to fix this problem
in future by an update for message format. Why cannot 5444 serves both
position and non-position info, not sure why it was designed that way?

AB

On 1/22/13, Ulrich Herberg <[email-masked]> wrote:
>>>>>      How is "performance" in the first sentence related to
>>>>> "complexity"
>>>>> in

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jan 2013 07:44:55 +0100

On 01/23/2013 12:04 AM, Abdussalam Baryun wrote:
> I see that RFC5444 serves reactive.

The specification of LOADng proves that you are wrong. It is NOT the 
only choice.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 22 Jan 2013 23:16:22 -0800

I agree with Henning.

Ulrich

Sent from my iPhone

On Jan 22, 2013, at 10:44 PM, Henning Rogge <[email-masked]> wrote:

> The specification of LOADng proves that you are wrong. It is NOT the only choice.
> 
> Henning Rogge
> 
> --

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jan 2013 09:29:21 +0100

please read
http://www.ietf.org/mail-archive/web/manet/current/msg14803.html

AB