Subject: [manet] Hares Technical Question 2: order of address in TLV

From: "Susan Hares" <[email-masked]>
Date: Mon, 14 Jan 2013 00:15:04 -0500

Technical issue 2 - order of address in TLV 

|     AddrTLV[1]     |       the first item in AddrTLV           |

|     AddrTLV[N]     |          the Nth item in AddrTLV          |

|  AddrTLV[OrigNode] |                 AddrTLV[1]                |

|  AddrTLV[TargNode] |                 AddrTLV[2]                |

Questions: 

1.  Is this sequence normal for the RFC5444?  

2.  Is it specified in RFC5444 as a requirement? 

3.  Why does Henning Rogge consider it bad? 

    He seems to imply that he wants the TLVs numbering to set the order. 

   3a. Do I understand the format? 

   3a. Why does it matter?  

The major work of the RREQ/RREP seems to have a short block of 2 ADDRTLVs.
The longer optional addresses (a DSR sort-of source routing) seems come
second and provide potential better paths. It would make processing sense to
grab the first block to process to get a basic connection (before the nodes
move on), and then fine tune).  It could be considered "make before you tune
it"  (a variant of the make before break concept). 

BGP implementation often try to pack things in the packet so the most
important processing comes first. 

Caveat:  I am trying to catch up with your excellent work. If there is
previous mail discussion, please let me know.  I'll go read it so I can ask
better questions. 

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 14 Jan 2013 01:35:45 -0500

Just one additional comment - BGP uses TLVs in its messages . This is the
ordering of the TLVs to be processed, not the TLVs.  

Sue 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Susan Hares
Sent: Monday, January 14, 2013 12:15 AM
To: [email-masked]
Subject: [manet] Hares Technical Question 2: order of address in TLV

 

 

Questions: 

   3a. Why does it matter?  

Sue Hares

---

From: Henning Rogge <[email-masked]>
Date: Mon, 14 Jan 2013 08:20:09 +0100

On 01/14/2013 06:15 AM, Susan Hares wrote:
>
>       Technical issue 2 – order of address in TLV
>
> 1.Is this sequence normal for the RFC5444?

The normal thing for RFC5444 should be that protocols do NOT specify a 
mandatory order of Addresses or TLVs.

> 2.Is it specified in RFC5444 as a requirement?
>
> 3.Why does Henning Rogge consider it bad?
>

No, I did not.

I asked for dropping ANY requirements of AODVv2 to the order of 
addresses and the split into address blocks.

There are two advantages of this:
1.) You can use a generic parser to parse AODVv2.
2.) The IMPLEMENTATION can decide on the order of addresses to allow 
better compression of the binary RFC5444 message.

>     3a. Why does it matter?

Yes, I think it does.

> The major work of the RREQ/RREP seems to have a short block of 2
> ADDRTLVs. The longer optional addresses (a DSR sort-of source routing)
> seems come second and provide potential better paths. It would make
> processing sense to grab the first block to process to get a basic
> connection (before the nodes move on), and then fine tune).  It could be
> considered “make before you tune it”  (a variant of the make before
> break concept).
>

Implementations could do this, but the protocol specification should not 
demand it. The protocol specification should just say "add address X 
with TLV Y to signal Z".

Making the protocol depend on position and split of addresses is a step 
backward from a TLV format towards a binary format where parts of the 
information is hidden in the order of non-annotated fields.

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 14 Jan 2013 13:17:06 +0100

> mandatory order of Addresses or TLVs.

IMO, the RFC5444 states that it is the protocol to define/specify its
RFC5444 messages, so this makes RFC5444 format general, but if its
updated to want the MANET routing protocol to follow a general order
way also, then I think the RFC5444 will be more limiting protocol's
activity.

AB

---

From: Henning Rogge <[email-masked]>
Date: Mon, 14 Jan 2013 13:30:08 +0100

> way also, then I think the RFC5444 will be more limiting protocol's

I think you are missing the point of a TLV format.

Henning Rogge

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 14 Jan 2013 09:23:36 -0500

Henning: 

Thank you for your explanation.  I understanding your concern with the TLVs.

I just wanted to understand if there was something else regarding
implementations because implementations do work toward efficient processing.

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Rogge
Sent: Monday, January 14, 2013 2:20 AM
To: [email-masked]
Subject: Re: [manet] Hares Technical Question 2: order of address in TLV

No, I did not.

I asked for dropping ANY requirements of AODVv2 to the order of addresses
and the split into address blocks.

There are two advantages of this:
1.) You can use a generic parser to parse AODVv2.
2.) The IMPLEMENTATION can decide on the order of addresses to allow better
compression of the binary RFC5444 message.

Yes, I think it does.

> connection (before the nodes move on), and then fine tune).  It could 
> be considered “make before you tune it”  (a variant of the make before 
> break concept).
>

Implementations could do this, but the protocol specification should not
demand it. The protocol specification should just say "add address X with
TLV Y to signal Z".

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: Henning Rogge <[email-masked]>
Date: Mon, 14 Jan 2013 15:35:01 +0100

> Thank you for your explanation.  I understanding your concern with the TLVs.

Its both a matter of "whats the purpose of a TLV format if parts of the 
information is NOT in the TLVs" and a matter of efficient implementation.

> implementations because implementations do work toward efficient processing.

MANET protocols are mostly used with wireless transmission, so a lot of 
MANET implementations care more about "airtime" than "processing time".

There is quite a bit potential for more compact transmissions in 
RFC5444, but this depends highly on the order of the addresses and their 
split into different address blocks.

If the protocol mandates a certain order/split for semantic reasons, it 
blocks these optimizations.

Example:

lets assume we have a RFC5444 message with 20 addresses, 10.0.0.1 to 
10.0.0.10 and 10.1.0.1 to 10.1.0.10

If we put them into a single block in a random order, we most likely can 
only use the common prefix "10." for compression, which safes us ~20 
bytes (minus 2 bytes overhead in the header).

If we split them into two address blocks, one for 10.0.0.x and one for 
10.1.0.x, each of the address blocks have a 3 byte common header, which 
safes a total of ~60 bytes (minus 4 bytes overhead in the first header, 
minus 6 bytes for the second header).

Henning Rogge

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 14 Jan 2013 09:44:22 -0500

Henning:

Thank you for the example.   The text from RFC5444 and AODV had led me to
your example and the power of compression. 

My original question is whether the code was more efficient if certain TLVs
fell before others. 

Thank you again for the careful and well-written explanations.

Sue  

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Monday, January 14, 2013 9:35 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [manet] Hares Technical Question 2: order of address in TLV

Example:

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Mon, 14 Jan 2013 15:49:02 +0100

> Thank you again for the careful and well-written explanations.

I care for the compression part a lot because I spent quite some time to 
write a reasonable efficient compression algorithm that takes both the 
split into address blocks and the TLVs into account.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 14 Jan 2013 20:03:30 +0100

Why you think I missed any point, does the RFC5444 explain the point
of its TLV which I don't know?

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 14 Jan 2013 20:08:54 +0100

> split into address blocks and the TLVs into account.
Yes I agree that the compression algorithm makes differences, but I
think in some MANET scenarios not all,

AB

---

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

Note that addresses are not in TLVs. Addresses are in address blocks. Each address block has an associated TLV block
The way in which 5444 is used by OLSRv2 and NHDP, and which various people think should be at least advised for its use, is that an address in an address block has no meaning in and of itself. It''s only when a TV (or TLVs) is/are associated with it that it gains meaning. That's even a broader consideration than not gaining any information due to position.
In OLSRv2, in particular, most addresses in a TC message are advertised neighbours. It would have been possible (and in fact was the case in earlier drafts) that any unlabelled (by a TLV) address was so associated. But instead a specific TLV was added. Technically a small overhead, but it freed up the possibility of later adding additional addresses that meant something totally new (with their own TLV for that meaning). Otherwise all added addresses would have to be advertised neighbours. (Or we go down an even more complicated route of assigning a meaning to "no TLV", and then start asking about distinctions between addresses and address objects.) What might such an address mean? An obvious possibility is something local (which actually also once was present, but removed).
I don't think any such advice would cause replacement of 5444. If published in an RFC it could be informational (this is what the authors intended) or BCDP (this is how you should use 5444 - or possibly this is how you should use 5444 in the 5498 context).
--
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]<mailto:[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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: 14 January 2013 05:15
To: [email-masked]
Subject: [manet] Hares Technical Question 2: order of address in TLV

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.
Technical issue 2 - order of address in TLV

Questions:

   3a. Why does it matter?

The major work of the RREQ/RREP seems to have a short block of 2 ADDRTLVs. The longer optional addresses (a DSR sort-of source routing) seems come second and provide potential better paths. It would make processing sense to grab the first block to process to get a basic connection (before the nodes move on), and then fine tune).  It could be considered "make before you tune it"  (a variant of the make before break concept).

BGP implementation often try to pack things in the packet so the most important processing comes first.

Caveat:  I am trying to catch up with your excellent work. If there is previous mail discussion, please let me know.  I'll go read it so I can ask better questions.

Sue Hares

********************************************************************
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 15:01:11 +0100

On 1/15/13, Dearlove, Christopher (UK) <[email-masked]> wrote:
> I don't think any such advice would cause replacement of 5444. If published
> in an RFC it could be informational (this is what the authors intended) or
> BCDP (this is how you should use 5444 - or possibly this is how you should
> use 5444 in the 5498 context).

not replacing RFC5444, but I like the suggestion as informational or
maybe a best practice doc for using 5444,

AB

> Please see this
> process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>
> on how to deal with suspicious emails.

---

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

Hello Henning,

Early last year, I sent out a long email detailing design choices
for encoding the two required addresses for RREQ and RREP
into an AddrBlk with various possibilities for TLVs. Because of
the "usual case" compression with IPv6 addresses, I picked
the design that is now in AODVv2, after waiting for comments
from the mailing list.

LOADng picked another of the design points that I had laid
out. Since there is only one address in the LOADng AddrBlk,
it's pretty easy for it to be position-independent. However,
the LOADng design also eliminates the possibility for address
compression which is the raison d'etre for RFC 5444. Please
note that as far as I know LOADng had made their design
decisions before my email. It wasn't discussed on the issue
tracker.

There are several other reasons for putting both addresses
into the AddrBlk, which if you're interested I can recapture
from the earlier email.

Since there's no RREQ/RREP in OLSR, these issues (I guess)
were never completely explored before. My understanding
of RFC 5444 (pretty good at this point) and OLSR is that they
were made for each other, and the reactive design requirements
were not at the time as clear as they are now.

Regards,
Charlie P.

> 1.) You can use a generic parser to parse AODVv2.

Well, it can't be "too" generic!

> better compression of the binary RFC5444 message.

What if no possible compression of position-independent specification
can be better than the position-dependent version?

Aren't all RFC5444 messages binary?

> Implementations could do this, but the protocol specification should 
> not demand it. The protocol specification should just say "add address 
> X with TLV Y to signal Z".

This means more TLVs to supply the positional information, instead of
just having the positional information inherently understood based on
the message type.

There's no free lunch. The state resides somewhere. I'd say our job is
to make efficient yet natural encodings for the required information.

>
> Making the protocol depend on position and split of addresses is a 
> step backward from a TLV format towards a binary format where parts of 
> the information is hidden in the order of non-annotated fields.

Hidden is a loaded term. The information is "hidden" in the message type,
and in the protocol specification. More annotations ---> larger message
sizes, and we're already dealing with various enlargements due to other
RFC 5444 features.

-- 
Regards,
Charlie P.

---

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

> were not at the time as clear as they are now.

The good thing that OLSRv2 was made for the RFC5444 and verse versa,
because usually proactive protocols have higher overload of manet
messages, so we needed that RFC5444 had good features for the manet
proactive, and now we do the reactive part, but if we designing the
reactive messaging and we think that RFC5444 needs few updates I think
the right time for it is while doing that design,

just my thoughts,

AB

---

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

> the design that is now in AODVv2, after waiting for comments

I did some tests with IPv4 addresses in OLSRv1 TC sampled from the
Vienna Funkfeuer network and they were compressable too. So its not
only an IPv6 thing.

But I agree, with IPv6 you (most times) get more advantage from the compression.

> Well, it can't be "too" generic!

Generic parsers/generators will easily work for NHDP, OLSRv2, SMF and
LOADng... but AODVv2 will need some strange special cases and
extensions.

> can be better than the position-dependent version?

Even if you have only a single address in your only address block, the
overhead for putting in a TLV on it would be two byte. A small cost
for having a clean protocol design.

> to make efficient yet natural encodings for the required information.

Yes, sometimes its "2 byte overhead" vs. "special hack".

This "positional information" is just a step backward to the packet
formats we had with AODV and OLSRv1.

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: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Jan 2013 20:47:19 +0100

> formats we had with AODV and OLSRv1.

I think that the some position information in AODVv2 is flexible and
different than the old versions. Not sure what you mean backward,

AB

---

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

> different than the old versions. Not sure what you mean backward,

Both AODV and OLSR encoded the meaning of the bytes without their
messages in their position relative to the start of the message.

I think RFC5444 was meant as a replacement to use TLVs for this.

Henning Rogge

---

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

> I think RFC5444 was meant as a replacement to use TLVs for this.

 I think RFC5444 was meant as a replacement to use manet routing TLVs
for any specified by the protocol best. For the proactive I agree the
best is that replacement. The question is what is the best for
reactive routing, for example; what will be the best practice for
reactive protocol when using RFC5444? I am thinking now in this
direction (without mixing thoughts of reactive and proactive as you
are doing).

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 15 Jan 2013 21:17:42 +0100

> direction (without mixing thoughts of reactive and proactive as you

I don't think reactive or proactive makes a difference here.

Henning Rogge

---

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

Reactive routing message traffic is different than Proactive routing
message traffic, the MANET routing traffic model of each routing is
different even if they serve the same users. The RFC5444 is all about
packing that traffic, do you still think they are same?

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 15 Jan 2013 21:27:09 +0100

On Tue, Jan 15, 2013 at 9:21 PM, Abdussalam Baryun
<[email-masked]> wrote:
> different even if they serve the same users.

I know.

> The RFC5444 is all about packing that traffic, do you still think they are same?

I think that the same TLV format can serve the needs of both without
the need of "position encoded information".

Henning Rogge

---

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

> the need of "position encoded information".

Ok, I need an answer from any WG participant, to the question which I
never claim  that I know so far, but want to know; How/what is the
best way to format RREQ and RREP as TLV in our reactive protocol in
faivor of all scenarios served (please note that Proactive serve
better different scenarios than Reactive do and verse versa)?

AB

---

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

Hello Henning,

It's clear that you prefer more TLVs instead of more contextual
information.  You express that explicitly, and also implicitly by
some of chosen terminology.  But there's often two sides to
the story.  Follow-up below...

> But I agree, with IPv6 you (most times) get more advantage from the compression.

I didn't mean to exclude IPv4, but we agree the case for IPv6 is stronger.

> LOADng... but AODVv2 will need some strange special cases and

Do you mean that the AddrBlk in AODVv2 is strange?  Which extensions did
you mean?   The term "special cases", I could (try to) understand to mean
cases not encountered by protocols retrieving sets of somehow "equivalent"
addresses.  Notably, "generic" is not the same as "our code".

> for having a clean protocol design.

But what if a "clean protocol design" is measured by requiring
fewer "special case" TLVs?

> Yes, sometimes its "2 byte overhead" vs. "special hack".

I really don't think that using the same design philosophy as has been
used in hundreds of successful protocols should be called a "hack",
and it certainly isn't "special" in that context.  What about people
who think RFC 5444 is a "hack", because there are ever more cases
that require two-byte overhead here, two-byte overhead there,
defining a new "hack" TLV when simple positional description would
do?  If they disappear from [manet] because their design ideas are
labeled as "hacks", did RFC 5444 "win"?

Moreover, as I understand it, it's not even just about RFC 5444,
but about on the one hand conforming to someone's existing
parser, and denigrating the word "positional".

> formats we had with AODV and OLSRv1.

I'm not so sure which direction is forward.  Anyway I hope it is
clear that the overhead in the typical IPv6 RREQ/RREP case is
much more than "2 bytes".

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 16 Jan 2013 09:14:03 +0100

> addresses.  Notably, "generic" is not the same as "our code".

just compare RFC5444 to a piece of XML.

your way to encode the information is

<addr seq="123">10.0.0.1</addr>
<addr seq="555">10.0.0.2</addr>

with the hidden request that the first addr has a different meaning than 
the second one.

my idea about encoding would be something like this:

<originator seq="123">10.0.0.1</originator>
<target seq="555">10.0.0.2</target>

> fewer "special case" TLVs?

If this is the case, why did we ever moved to a TLV format? Binary 
format with most things defined by their order (and not a type) are 
clearly "less overhead".

But they can be a pain to extend later.

> and it certainly isn't "special" in that context.

How many of them are TLV based formats?

> What about people

I am not aware of protocols leaving [manet] after RFC5444 got finalized.

> much more than "2 bytes".

After looking into the RREP specification in the current draft of 
AODVv2, it might be even less than 2 bytes to skip the "position 
information"... it could be zero bytes.

The following is just an example for the RREP what we could do to get 
rid of it.

The RREP contains two addresses, both already "tagged" with an address 
block TLV.

We could easily take two message specific Address Block TLVs, one called 
"Route Generation Sequence number" and one called "Route Request 
Sequence Number" (the first one is similar to the Answer Set Number of 
OLSRv2).

This would allow AODVv2 to differentiate between your originator and 
target address by looking at the TLV.

(it might also allow nodes with multiple local addresses to reply to a 
route request with more than one address, just by tagging multiple 
addresses with the corresponding TLV)

Henning Rogge

---

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

Hello Henning,

> just compare RFC5444 to a piece of XML.

I agree this is a very good comparison.
> format with most things defined by their order (and not a type) are 

People, including me, use TLVs because they are great for
many purposes.  Please note that there is no problem to
have positional information in TLVs.

> But they can be a pain to extend later.

Binary format is harder to read, that is sure.

But TLVs can obviously be also in "binary format".

> How many of them are TLV based formats?

Given that TLVs can be (i) binary and (ii) positional, I'm not sure
exactly what you are asking, and I do not know just what the
percentages are.  But, Mobile IP and Diameter use TLVs.

> I am not aware of protocols leaving [manet] after RFC5444 got finalized.

Well, there have been various complaints about [manet] headers
being "too big".  And, anyway, I was asking theoretical questions, about
which I'd still like to know your opinion.

> We could easily take two message specific Address Block TLVs, one 
> called "Route Generation Sequence number" and one called "Route 
> Request Sequence Number" (the first one is similar to the Answer Set 
> Number of OLSRv2).
>

This would be fine with me.  It's encoding the positional information 
into the AddrTLV
instead of the AddrBlk.  One still has to know which address is which, 
so the new
AddrTLV definitions would have to cover the case when both addresses 
have SeqNum.
We could have four AddrTLV definitions:
- Single SeqNum for Originator Address
- Single SeqNum for Target Address
- Two SeqNums, Originator Address first
- Two SeqNums, Target Address first

I'm fine with this, because I see no urgency in preserving AddrTLV numbering
space.  However, I'm not very clear about which design is "cleaner".

> addresses with the corresponding TLV)

Well, if we're really dealing with an exponential increase in AddrTLV 
type definitions,
I'm not sure about what's better.  Or maybe I am missing some other way of
doing the positional encoding.

-- 
Regards,
Charlie P.

---

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

> percentages are.  But, Mobile IP and Diameter use TLVs.

I agree with the above, but we may add (iii) random order TLVs in 5444
message, which I think prefered by Henning,

AB

---

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

Hello Abdussalam and all,

Yes, I certainly agree that TLVs can have the non-positional feature
favored by Henning and Ulrich.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

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

Hi Charlie, and All

For me I don't much care about the way the message is formatted as
long the protocol targets its functions at best for all its scenarios.
The RFC5444 specifies that it is for the protocol to chose the way of
its messages. The OLSRv2 was done its 5444-messages in such method for
its purposes. Now we need to find the best way for our new reactive
protocol 5444-messages, but to faivor its functions best not the best
of hybrid routing with OLSRv2. I prefer we find a different way which
is best of format the reactive TLVs in its rfc5444-message, and the
message in the rfc5444-packet.

Abdussalam Baryun,
University of Glamorgan, UK

---

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

> have positional information in TLVs.

To come back to XML, you would not do positional informations in XML... 
and I think you shouldn't do this in RFC5444 either.

> AddrTLV definitions would have to cover the case when both addresses

No, it does not...i propose to use a DIFFERENT TLV for the "route 
generation sequence number" and for the "route request sequence number".

By this it encodes the same information without the need of any special 
position.

The implementation can easily decide for each address if its an 
originator, a target or something else (to ignore the address) just by 
looking WHICH TLV is attached to the address.

Henning Rogge

---

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

You can think that 5444-message information details is a language of
routers as you refer to XML in comparing them. This will mean that
that language is a general language because the 5444 is general
language not specific,

AB

---

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

I'm not sure what "positional information in TLVs" means.

The discussion has been one of whether information about what an address in a message means is carried either by where the address is (possibly which address block, and/or in what position in an address block) or by TLVs that attach information to the address. Neither is positional information in TLVs.

[email-masked] | http://www.baesystems.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: 16 January 2013 23:17
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] Hares Technical Question 2: order of address in TLV

----------------------! 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.
--------------------------------------------------------

Hello Henning,

-- 
Regards,
Charlie P.

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

---

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

Not random, but unspecified, and permitted to be ordered for efficiency as the message constructor chooses. Not the same.

(Why can order affect efficiency? Because the most efficient way of attaching TLVs is with the addresses the TLV applies to grouped together. Whether the gain is significant depends on various details. Note that, despite using multiple TLVs, this is possible in NHDP/OLSRv2. However in the simplest cases there is no significant gain due to order - except not having multiple address blocks is usually a gain, unless e.g. you have two or more quite different types of address. Even then it may not be a gain.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 16 January 2013 23:41
To: Charles E. Perkins
Cc: [email-masked]
Subject: Re: [manet] Hares Technical Question 2: order of address in TLV

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 Jan 2013 06:46:54 -0800

Hello Henning,

On 1/16/2013 11:07 PM, Henning Rogge wrote:
> To come back to XML, you would not do positional informations in 
> XML... and I think you shouldn't do this in RFC5444 either.

The logical conclusion of this argument, is to simply do XML.

It's a matter of how much overhead, for what gain.

>> which I'd still like to know your opinion.

...

>>> information"... it could be zero bytes.

Your solution below is definitely not zero bytes overhead.

> By this it encodes the same information without the need of any 
> special position.
>

I'll map this out in detail and make the comparison.  I'm fine
with a solution that can be encoded without too much overhead,
and as mentioned before I  am not too concerned about chewing
up TLV type space.

-- 
Regards,
Charlie P.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 17 Jan 2013 15:03:02 +0000

On Jan 17, 2013, at 2:07 AM, Henning Rogge wrote:

> To come back to XML, you would not do positional informations in XML... and I think you shouldn't do this in RFC5444 either.

+1

I have no specific scenario in mind, but creating positional requirements could be "kiss of death" for routers, especially if the processing leads to data moves inside a packet. By that, I mean if you have a scenario where you have a sound, good packet partially built, *then* come up on a situation where you have to reorganize the packet to add an additional, position-dependent TLV, you've just taken a huge performance hit in order to shuffle the data around. It's much better to just slap another TLV onto the end of the packet, and keep on moving. 

Regards,
Stan

>> percentages are.  But, Mobile IP and Diameter use TLVs.
[snip]

---

From: Teco Boot <[email-masked]>
Date: Thu, 17 Jan 2013 17:17:46 +0100

+/- 1

This positional vs. TLV discussion is getting somewhat black and white. Looking out of my window, I see a grey world. Ahh, Dutch foggy weather...

Encode each and every bit in a TLV, where such bits are in a group, isn't that smart. An array of bits makes lots of sense. Positional encoded info is in OLSRv2 already (LINK_METRIC TLV, 2 octets which are 4 bits and the exponent & mantissa fields).

So I can't see why it is bad to use a TLV "payload" value with multiple fields. Could be multiple addresses. Yes, address block TLV is another tool that could be used. It is up to the protocol designers to make smart decisions.

Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 17 Jan 2013 08:58:48 -0800

Teco,

On Thu, Jan 17, 2013 at 8:17 AM, Teco Boot <[email-masked]> wrote:

> +/- 1
>
> This positional vs. TLV discussion is getting somewhat black and white.
> Looking out of my window, I see a grey world. Ahh, Dutch foggy weather...
>

I can't say the same about the weather here in California ;-)

>
> Encode each and every bit in a TLV, where such bits are in a group, isn't
> that smart. An array of bits makes lots of sense. Positional encoded info
> is in OLSRv2 already (LINK_METRIC TLV, 2 octets which are 4 bits and the
> exponent & mantissa fields).
>

I think the discussion was about a fixed position of addresses that are
associated with some meaning (e.g., 1st position in the 1st address block
means destination address); not about representation of a TLV value (e.g.,
how to interpret the value of the LINK_METRIC TLV).

>
> So I can't see why it is bad to use a TLV "payload" value with multiple
> fields. Could be multiple addresses.

That is already supported with TLVs, both by using start- and stop-index as
well as multi-value TLVs, and does not require positional assumptions of
addresses in RFC5444 messages.

Best regards
Ulrich

> Yes, address block TLV is another tool that could be used. It is up to the
> protocol designers to make smart decisions.
>
> Teco
>
>
> > I have no specific scenario in mind, but creating positional
> requirements could be "kiss of death" for routers, especially if the
> processing leads to data moves inside a packet. By that, I mean if you have
> a scenario where you have a sound, good packet partially built, *then* come
> up on a situation where you have to reorganize the packet to add an
> additional, position-dependent TLV, you've just taken a huge performance
> hit in order to shuffle the data around. It's much better to just slap
> another TLV onto the end of the packet, and keep on moving.
> >
> > Regards,
> > Stan
> >
> >>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 Jan 2013 10:21:30 -0800

Hello Stan,

> I have no specific scenario in mind, but creating positional requirements could be "kiss of death" for routers, especially if the processing leads to data moves inside a packet. By that, I mean if…

This comment does not apply to the current design of originator/target
ordering in the AODVv2 AddrBlk.  It's not the *position* of any TLV that
was under discussion, nor the ordering of the TLVs.  In the current design,
it's expected that new TLVs or AddrBlks will be added just as you suggest.

-- 
Regards,
Charlie P.

---

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

I agree with all your comments, hope we start going through reactive
protocol design in relation with these format methods,

AB

On 1/17/13, Teco Boot <[email-masked]> wrote:
> that smart. An array of bits makes lots of sense. Positional encoded info is
> in OLSRv2 already (LINK_METRIC TLV, 2 octets which are 4 bits and the
> fields. Could be multiple addresses. Yes, address block TLV is another tool
> that could be used. It is up to the protocol designers to make smart
> decisions.
>
> Teco
>
>
>> I have no specific scenario in mind, but creating positional requirements
>> could be "kiss of death" for routers, especially if the processing leads
>> to data moves inside a packet. By that, I mean if you have a scenario
>> where you have a sound, good packet partially built, *then* come up on a
>> situation where you have to reorganize the packet to add an additional,
>> position-dependent TLV, you've just taken a huge performance hit in order
>> to shuffle the data around. It's much better to just slap another TLV onto
>> the end of the packet, and keep on moving.
>>
>> Regards,
>> Stan
>>
>>>

---

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

Hi Chris,

comments in line;

On 1/17/13, Dearlove, Christopher (UK) <[email-masked]> wrote:
> Not random, but unspecified, and permitted to be ordered for efficiency as
> the message constructor chooses. Not the same.

I now understand the better way to call it, thanks,

>
> (Why can order affect efficiency? Because the most efficient way of
> attaching TLVs is with the addresses the TLV applies to grouped together.

It is good explaination but I would like to know the attached function
to such TLV so I can know how to measure gain (who defines the game).

> Whether the gain is significant depends on various details. Note that,
> despite using multiple TLVs, this is possible in NHDP/OLSRv2. However in the
> simplest cases there is no significant gain due to order - except not having
> multiple address blocks is usually a gain, unless e.g. you have two or more
> quite different types of address. Even then it may not be a gain.)
>

Thanks for that it added to my knowledge of NHDP which is important in
routing. However, the above is right only if we are ignoring the
importance of the protocol processing and states. The RFC5444 ignores
the issues because it was designed for all routings, and we should
think in the above way when designing general messaging, but I think
if we design in one protocol we should go through another direction.

AB

---

From: Henning Rogge <[email-masked]>
Date: Fri, 18 Jan 2013 07:52:07 +0100

On 01/17/2013 05:17 PM, Teco Boot wrote:
> +/- 1
>
> This positional vs. TLV discussion is getting somewhat black and
> white. Looking out of my window, I see a grey world. Ahh, Dutch foggy
> weather...
>
> Encode each and every bit in a TLV, where such bits are in a group,
> isn't that smart. An array of bits makes lots of sense. Positional
> encoded info is in OLSRv2 already (LINK_METRIC TLV, 2 octets which
> are 4 bits and the exponent & mantissa fields).
>
> So I can't see why it is bad to use a TLV "payload" value with
> multiple fields. Could be multiple addresses. Yes, address block TLV
> is another tool that could be used. It is up to the protocol
> designers to make smart decisions.

I think the discussion what to put into the value of a TLV is quite 
different from the one we had before.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 18 Jan 2013 10:01:53 +0000

If you want to work out sizes, then step one is read and fully understand 5444. If you achieve that, you can do the rest.

Your second paragraph is not clear, but if it means what I think it means, I completely disagree.

-----Original Message-----
From: Abdussalam Baryun [mailto:[email-masked]] 
Sent: 17 January 2013 20:40
To: Dearlove, Christopher (UK)
Cc: Charles E. Perkins; [email-masked]
Subject: Re: [manet] Hares Technical Question 2: order of address in TLV

Hi Chris,

comments in line;

AB

---

From: Teco Boot <[email-masked]>
Date: Fri, 18 Jan 2013 18:37:47 +0100

I just intended to say: in real world, nothing is black nor white.

In address block TLVs, addresses are "an ordered set", "all sharing the same Head and the same Tail". I have no idea what "ordered" means. Intended to be ascending order, I presume. DYMO-25 violates this.

Option for a DYMO-26: OrigNode can be <msg-orig-addr>. Other mandatory singular fields can be put in a RteMsgTLV with positional info. I do not say I prefer this, it is just a valid usage of RFC 5444. If it reduces message size, it makes sense, doesn't it?

Teco

Op 18 jan. 2013, om 07:52 heeft Henning Rogge het volgende geschreven:

> I think the discussion what to put into the value of a TLV is quite different from the one we had before.
> 
> Henning Rogge
> 
> --

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 18 Jan 2013 10:13:16 -0800

Hello Teco,

I wrote up that design in email early in 2012.

The current design allows for IPv6 address abbreviation, which in
my understanding was one of the prime motivations for RFC 5444.

Henning has made an alternate proposal which may also preserve
this feature and I will write it up early next week.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 18 Jan 2013 19:39:13 +0100

> this feature and I will write it up early next week.

We still have to look at the rest of the protocol messages, but I
think most of them can be converted without wasting lots of bytes.

Henning Rogge