Subject: [manet] New definition of term 'TLV' in PacketBB

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 15:08:08 +0200

I think the term TLV (type-length-value) is overloaded by the PacketBB spec:

 >    <tlv> is defined by:
 >        <tlv> = <tlv-type>
 >                <tlv-semantics>
 >                <index-start>?
 >                <index-stop>?
 >                <length>?
 >                <value>?

In many RFCs "TLV" is used to just mean Type-Length-Value, with Type and
Length represented each on one byte and the Value on Length bytes.

I think when generally people talk about TLV they really mean this
simplicity afforded by type-length-value as opposed to encoding
additional things like semantics, index, etc.

IMHO we should use TLV as simply type-length-value instead of encoding
additional semantics and index.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 19 Jun 2007 14:33:59 +0100

> I think the term TLV (type-length-value) is overloaded by the PacketBB
spec:

There are many uses of TLV in many places. Some are
simple, some are more complicated. This one does
the job it's intended to do. You actually can't do
that job with just a type, a length and a value as you
then couldn't apply information to just some of the
addresses in an address block. And that's essential.

I'm afraid I don't find this particular criticism
constructive, so I'm not going to discuss this point
further.

********************************************************************
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: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 16:11:57 +0200

Dearlove, Christopher (UK) wrote:
>> I think the term TLV (type-length-value) is overloaded by the
>> PacketBB
> spec:
> 
> There are many uses of TLV in many places. Some are simple, some are
> more complicated. This one does the job it's intended to do.

But it's different than what rfc2460 calls a 'TLV'.

> You actually can't do that job with just a type, a length and a value
> as you then couldn't apply information to just some of the addresses
> in an address block. And that's essential.
> 
> I'm afraid I don't find this particular criticism constructive, so
> I'm not going to discuss this point further.

Ok, I again went into MANET document debugging instead of contending 
just reading them :-( Generally speaking, I don't think it's 
constructive to ignore existence of already defined TLV mechanisms, 
address encoding mechanisms and code availability.

Alex

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 19 Jun 2007 16:22:58 +0200

Alex,

I appreciate your reviewing of the MANET WG specs.

Generally, I think that it might be advantageous if you try to  
understand WHY the specs are the way they are, rather than to launch  
into observing a difference with some other similar mechanism and  
then taking this as an indication that something is broken.

TLVs, for example, are TLVs, with the addendum of specifying "to  
which entities they apply". This is necessary since it allows doing  
efficient address aggregation. The alternative -- naive TLVs without  
such information -- would lead to a much less efficient address  
aggregation. (Notice that this is a simplified description, but that  
it should get the point through)

Since one of the MANET wg's design-dogmas is "efficient when  
sensible", many such trade-offs have been considered and discussed  
over the years, and packetbb reflects the result of a number of such  
discussions.

Thomas

On Jun 19, 2007, at 4:11 PM, Alexandru Petrescu wrote:

> Ok, I again went into MANET document debugging instead of  
> contending just reading them :-( Generally speaking, I don't think  
> it's constructive to ignore existence of already defined TLV  
> mechanisms, address encoding mechanisms and code availability.
>
> Alex
>
>

-- 
Thomas Clausen
[email-masked]
http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
http://www.lix.polytechnique.fr/hipercom/

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 19 Jun 2007 15:23:40 +0100

> But it's different than what rfc2460 calls a 'TLV'.

So what? It's not the only non-RFC2460 TLV in the world either.

> Generally speaking, I don't think it's 

Who says we did? In the case of TLVs, just having type, length
and value was insufficient. So we added what was needed, and
then added stuff to make it more efficient.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 17:23:01 +0200

> then taking this as an indication that something is broken.

Sorry, I didn't mean something was broken; just that it may be 
unnecessarily complex.

> it should get the point through)

The other alternative of overspecifying new ways of encoding addresses
risks obviously to create large packets for simpler cases.  Whereas I
agree head-mid-tail encodings of addresses can lead to smaller packets
when several similar addresses are sent, apparently it sends more bytes
than 'naive' TLV when only one address is sent.   And this may be less
efficient for MANEMO where often only one address/prefix is needed (the
Mobile Network Prefix).

> over the years, and packetbb reflects the result of a number of such

I agree with general consensus.  I will send a separate email trying to
identify how PacketBB can encode an IPv6 Mobile Network Prefix and then
compare that encoding with the other existing ways of encoding Mobile
Network Prefixes.

Alex

>>> spec: There are many uses of TLV in many places. Some are simple,
>>> some are more complicated. This one does the job it's intended to
>>> do.
>> 
>>> You actually can't do that job with just a type, a length and a
>>> value as you then couldn't apply information to just some of the
>>> addresses in an address block. And that's essential. I'm afraid I
>>> don't find this particular criticism constructive, so I'm not
>>> going to discuss this point further.
>> 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit
>> http://www.messagelabs.com/email 
>> _______________________________________________ manet mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/manet
>> 
>

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 19 Jun 2007 17:46:55 +0200

> Sorry, I didn't mean something was broken; just that it may be  

Sorry, Alex, you can't just say that without understanding the context.

Let me give an absurd example:

	I have 5 computers at home. In order to network those, I just need
	something simple. IPv6 addresses are too long, and all those IETF
	protocols are just unnecessarily complex.

That's the same line of argument as you're usin: I've identified one  
particular case, and going by that case, I judge the world to be  
unnecessarily complex.

packetbb is designed with a large set of conflicting constraints,  
including, but not limited to:

	- efficient packet/message size, including payloads and headers
	- simple parsing logic
	- extensibility/flexibility, such that we won't have to rewrite the  
spec
	  (and our code) every time somebody has a new idea)

and a whole host of other criteria that I shall not list here. A lot  
of effort has been made to try to balance those. Occasionally, some  
simplicity in the parsing logic has been sacrificed for improved  
compactness in the format. Occasionally it's the other way around.

packetbb was designed as a building block for MANET wg protocols, and  
so has been discussed exhaustively in that context.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 17:57:07 +0200

>     protocols are just unnecessarily complex.

Haha, I think I understand what you mean.

> particular case, and going by that case, I judge the world to be 

Right... I may have been wrong.  The PacketBB is just complex, not 
necessarily "unnecessarily" complex.

> and a whole host of other criteria that I shall not list here. A lot of 
> effort has been made to try to balance those. Occasionally, some 
> packetbb was designed as a building block for MANET wg protocols, and so 
> has been discussed exhaustively in that context.

Ok Thomas, please don't take my remarks as discarding.  PacketBB is 
designed for MANET protocols, identifies its commonalities, and respects 
many MANET requirements.  I agree with what's designed by consensus and 
for a Working Group.

Just please help me picture a PacketBB message (header or body) that 
contains an IPv6 Mobile Network Prefix (an IPv6 address and its prefix 
length).  I want to do that correctly and according to existing 
consensus.  I'm not looking for immediate feedback, just when you think 
it's possible.

Or maybe I shouldn't ask for this encoding at all?  Am I pushing in the 
wrong direction?

Alex

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Jun 2007 10:42:39 -0700

I partly agree. TLV is a generic term describing any encoding that  
includes the concept of a type, a length, and a value. There is no  
specific requirement about octet boundaries either; to name one  
example RSVP's generic TLV looks like this (from RFC 2205):

       3.1.2 Object Formats

          Every object consists of one or more 32-bit words with a one-
          word header, with the following format:

                 0             1              2             3
          +-------------+-------------+-------------+-------------+
          |       Length (bytes)      |  Class-Num  |   C-Type    |
          +-------------+-------------+-------------+-------------+
          |                                                       |
          //                  (Object contents)                   //
          |                                                       |
          +-------------+-------------+-------------+-------------+

That said, this particular TLV could be called a PacketBB TLV, or a  
PacketBB Information Element. It would be entirely appropriate to go  
on to describe in detail the format and intended structure of the TLV.

Dumb question: what makes this specific to manet? Why is this not  
"how to design an internet message"?

On Jun 19, 2007, at 6:08 AM, Alexandru Petrescu wrote:

> PacketBB spec:

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 20:58:20 +0200

Fred Baker wrote:
> specific requirement about octet boundaries either; to name one example 
> RSVP's generic TLV looks like this (from RFC 2205):
> 
>       3.1.2 Object Formats
> 
> PacketBB Information Element. It would be entirely appropriate to go on 
> to describe in detail the format and intended structure of the TLV.

I think yes, it would be appropriate to call it a PacketBB TLV or a 
PacketBB Information Element.

> Dumb question: what makes this specific to manet? Why is this not "how 
> to design an internet message"?

I would also like to learn more about this.

I currently think having heard two reasons:

(1) PacketBB is one way people used to try to converge between OLSR and 
DYMO.  I think this is a good approach - try to encode things in the 
same way, by both protocols, eventually leading to one MANET protocol. 
But this does not motivate it being so complex, IMHO.

(2) MANETs are very much risking to run on bandwidth-constrained links, 
thus try to optimize (read compress) as much as possible what's being 
transmitted.  Which is generally a good principle (be conservative in 
what you send etc).  But seems to ignore that many other IETF 
communities looked exactly at same bandwidth-constrained links and 
already came up with similar mechanisms, one notable being ROHC.  Also, 
designers seem to overlook the fact that it is possible to achieve short 
messages by other means than compressing, as it is possible to have 
secure mechanisms without using crypto.

Anyways, this is one big IMHO and I'm interested to learn more about 
MANET members' oppinions on this topic.

Alex

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 20 Jun 2007 09:50:20 +0100

> "how to design an internet message"?

packetbb started as a more efficient format for OLSRv2.
(And had no one else been interested that's where it
would have stayed - and we'd go back to that if necessary.)
The basic design (for which I can't claim credit) noted
that OLSR is basically about a node expressing relationships
with its neighbours - I can hear him, I have a symmetric
link to him, he's my MPR. The format evolved from that.
There's also some non-address specific stuff, and it
kept the OLSR message header, with minor changes, as that
allowed efficient "do I process and/or forward this"
decisions.

This did produce something with wider application than
OLSR, and the SMF and DYMO authors thought they could
use it. Various things were done to accommodate some
extra requirements (such as not having to have all of
the header) and some additional efficiency options in
TLVs. These are all in the Manet group of course, but
maybe people in the Autoconf group may use it. But as
you note, it's not MANET specific - but we've branded
it that way as the Manet WG is tasked to produce MANET
protocols, of which this is an essential component (and
why we need to get this done). We felt that branding it
as a general purpose format would lead to delays as
people outside the MANET community would feel they
needed to be consulted etc. (I'm not arguing they would
be wrong - after all, we haven't considered all of their
requirements.)

But if anyone outside the MANET community wants to use
it "as is" - or use it as the basis for something else,
we'd be very happy. The underlying assumptions that
produced it are after all, as you note, more widely
applicable than MANETs, or even than routing protocols.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Jun 2007 11:33:20 +0200

> use it.

Sometimes it is mentioned PacketBB is used in SMF. There was a discussion on
this in Prague also. I posted before Joe was right and PacketBB is not used
in SMF. SMF can make use of NHDP and NHDP makes use of PacketBB. But SMF
will work without NHDP and performs CF-based forwarding or can use other
sources for relay set information.

By the way, I think the origin of the name PacketBB should be described
somewhere.

Teco.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 20 Jun 2007 10:37:04 +0100

> By the way, I think the origin of the name PacketBB should
> be described somewhere.

If it were permanent, yes. But the only place it
occurs is in the ID name, and that will go when it
becomes an RFC. (This is typical, zeroconf is an
obvious example.)

bb = building block, however. Or so I'm told.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Jun 2007 11:45:47 +0200

Besides a lot of references in ML and refs to the ID, I found a ref to
"PacketBB" in the DYMO ID, section 4.2:
            +----------------------------+-------------------+
            |    Information Location    | Notational Prefix |
            +----------------------------+-------------------+
            |          IP header         |        IP.        |
            |         UDP header         |        UDP.       |
            |   packetbb message header  |      MsgHdr.      |
            |    packetbb message TLV    |      MsgTLV.      |
            |   packetbb address blocks  |      AddBlk.      |
            | packetbb address block TLV |      AddTLV.      |
            +----------------------------+-------------------+
Anyway, we need a name for the packet building block.
Teco.

> -----Original Message-----
> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: woensdag 20 juni 2007 11:37
> To: Teco Boot
> Cc: manet
> Subject: RE: [manet] New definition of term 'TLV' in PacketBB
> 
>

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 20 Jun 2007 10:48:14 +0100

>>> I suggest that means that (in due course) DYMO should be
>>> modified. That will naturally be when packetbb stops
>>> being just an ID.

>>> RFC xxxx

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Jun 2007 12:35:16 +0200

Do you really mean whe should replace short names with RFC IDs?
The table would look like:
            +----------------------------+-------------------+
            |    Information Location    | Notational Prefix |
            +----------------------------+-------------------+
            |       RFC791 header        |      PktHdr.      |
            |       RFC768 header        |      DgrmHdr.     |
            |    RFCxxxx message header  |      MsgHdr.      |
            |     RFCxxxx message TLV    |      MsgTLV.      |
            |    RFCxxxx address blocks  |      AddBlk.      |
            |  RFCxxxx address block TLV |      AddTLV.      |
            +----------------------------+-------------------+
I know I overdo it. General used objects would be assigned a name and
abbreviation. I don't care if it would be PacketBB or GMPMF (Generalized
MANET Packet/Message Format) or something else. I won't opt for RFCxxxx. But
that is just me.
Teco

> Sent: woensdag 20 juni 2007 11:48
> To: Teco Boot
> Cc: manet