Subject: [manet] PacketBB Recent Discussion #2 - Ordering TLVs

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 14 Aug 2007 17:56:38 +0530

I'd like to focus the discussion around ordering of TLV types within TLV blocks.

If you have a good reason why we should not consistently order TLVs
within a TLV block, please email it to the list. Please provide a
clear use case that shows why ordering the TLVs is bad.

Thanks.
Ian Chakeres

Note: I would like to quickly finish any remaining PacketBB discussion
and move this document forward.

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 14 Aug 2007 14:08:05 -0700

Hello Ian,

Some people claim that there is no need for the
restriction, and the authors claim that they have
gotten input to support the restriction.  I myself do
not see that it is needed for OLSR, or DYMO, or for
NHDP or SMURF.  The arguments from implementability
stem from claimed code explosion in the body of the
parser, but I don't automatically see why and we do
not have the details to study.  I would have thought it
was as complicated as having a flag.

Given that no existing use cases support the need for
ordering, I think that it should not be mandated.
Plus, if we imagine that new protocol revisions might
insert new TLV blocks into the message body, then
there is a renumbering problem which would suggest
leaving wide spaces within the existing tlv-type numbering
spaces.  That really is a known bad and messy problem.
Or else we are saying that no such future revisions will
be encouraged, or that we'll have a lot of redundant
tlv-type allocation.

Regards,
Charlie P.

---

From: "Justin Dean" <[email-masked]>
Date: Tue, 14 Aug 2007 17:58:56 -0400

A couple of comments before I head out.

The packet sizes of olsrv2/nhdp are generally smaller than those in olsrv1.
At least that was the case during the olsrv2 interop in Japan.  Furthermore
the most gains happen with the larger packet sizes as more aggregation will
occur.  An IPv6 olsr v1 packet is going grow much faster with than an OLSRv2
packet when using packetbb.  I would very much like to stress this point of
growth in size as even with the example discussed earlier the growth at the
higher end is the same (1 byte per address) for both examples.

Having a bit for ordering would allow for both behaviors but at this point I
don't see where it would be cleanly added.  I do however think the
suggestion has some merit if there is a bit someplace which makes sense. 

Two examples of a need for the restriction or at the very least clarity in
packetbb are:  A fragmentation type tlv which would need to be first to
allow the parser to correctly read/store the message in one pass.
Piggybacking protocols in one packetbb packet if any protocols mandated
ordering and the others did not it would break the one mandating ordering.  

Justin

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 5:08 PM
To: ext Ian Chakeres
Cc: manet
Subject: Re: [manet] PacketBB Recent Discussion #2 - Ordering TLVs

Hello Ian,

Some people claim that there is no need for the restriction, and the authors
claim that they have gotten input to support the restriction.  I myself do
not see that it is needed for OLSR, or DYMO, or for NHDP or SMURF.  The
arguments from implementability stem from claimed code explosion in the body
of the parser, but I don't automatically see why and we do not have the
details to study.  I would have thought it was as complicated as having a
flag.

Given that no existing use cases support the need for ordering, I think that
it should not be mandated.
Plus, if we imagine that new protocol revisions might insert new TLV blocks
into the message body, then there is a renumbering problem which would
suggest leaving wide spaces within the existing tlv-type numbering spaces.
That really is a known bad and messy problem.
Or else we are saying that no such future revisions will be encouraged, or
that we'll have a lot of redundant tlv-type allocation.

Regards,
Charlie P.

---

From: Bo Berry <[email-masked]>
Date: Tue, 14 Aug 2007 23:04:18 -0400

Ian:

As the protocol evolves, TLVs will be added and need to be
inserted or worst the list reordered.  TLV values can also
be obsoleted, leaving holes in the ordered list of values
or forcing another reorder.  Over time the number of TLVs
will change.  In this same time products will be running
different versions of the protocol with supporting
parsers. I think the requirement for an ordered list
of TLVs in this context will be problematic.

Thanks for moderating.

-Bo

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 09:34:48 +0100

> ordering, I think that it should not be mandated.

It has been repeatedly pointed out that ordering allows
trivial confirmation of non-duplication, and non-duplication
allows cleaner protocol specification and message processing.

********************************************************************
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: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 09:38:10 +0100

There's no problem in ordering no matter how TLVs are
defined. They are ordered according to their numbers
in this actual TLV block being transmitted. Easy as
that. If numbering changes so that meanings change
you've broken compatibility anyway. This is no sort
of argument at all.

-----Original Message-----
From: Bo Berry [mailto:[email-masked]] 
Sent: 15 August 2007 04:04
To: Ian Chakeres
Cc: manet
Subject: Re: [manet] PacketBB Recent Discussion #2 - Ordering TLVs

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Ian:

Thanks for moderating.

-Bo

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 21 Aug 2007 20:58:47 +0530

I would like to open up the question regarding ordering, as I don't
feel there is a clear agreement on this item.

What is the main advantage of ordering of TLVs?

Please respond if you have an opinion.

Also, I would like to keep the discussion limited to ordering, and not
the benefits related to finding/detecting duplicates (addressed in
another email).

Ian Chakeres

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 21 Aug 2007 16:44:25 +0100

Ordering has two advantages. For me the first I list is
more important, but actually the second was the major
motivation for the suggestion.

- It makes finding/detecting duplicates trivial. Yes, I
  know Ian just said don't list this, but I think that's
  to miss the critical point. Verifying non-duplication
  without sorting is nasty, with it it's trivial. (It
  also keeps duplicate packet/message TLVs, where
  permitted, together, which is also a simplifying matter.)

- It allows a basic implementation that knows which TLVs
  it handles to stop and skip TLVs when it has got to one
  past its range.

Note that I regard the first of these as a necessary part
of non-duplication. The second of these I personally don't
think critical, but I believe others (who proposed it)
disagree. If you don't consider verifying non-duplication,
then I agree the argument is not strong, which is why I
find it necessary to include that aspect here.

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 21 August 2007 16:29
To: manet
Subject: [manet] Re: PacketBB Recent Discussion #2 - Ordering TLVs

               *** WARNING ***

Ian Chakeres