Subject: Question about TLV, subTLVs and length

From: Jeroen van der Ham <[email-masked]>
Date: Tue, 02 Oct 2007 17:36:40 +0200

Hello,

The current text defining the length of TLVs is the following:

>    The Length field defines the length of the value portion in octets
>    (thus a TLV with no value portion would have a length of zero).  The
>    TLV is padded to four-octet alignment; padding is not included in the
>    length field (so a three octet value would have a length of three,
>    but the total size of the TLV would be eight octets).  Nested TLVs
>    are also 32-bit aligned.  For example, a one-byte value would have
>    the length field set to 1, and three octets of padding would be added
>    to the end of the value portion of the TLV.  Unrecognized types are
>    ignored.

To me this seems very unclear about the handling of lengths of subTLVs,
and their impact on the length of the upper TLV.
The padding after a subTLV should of course not be included in the
length of that subTLV. But should that padding be included in the length
of the (enclosing) TLV?

I would think that the padding for the subTLV should be included in the
length of the enclosing TLV. Most of the time it is possible to deduce
the length, but if more than 4 bytes of padding are added, you run into
problems.

I really couldn't find a definitive answer on this anywhere, it may be
worth defining this somewhere, as the current wording is not clear on
this issue.

Jeroen.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Oct 2007 17:14:22 +0100

Hi Jeroen,

>>    to the end of the value portion of the TLV.  Unrecognized types are

I guess you are quoting from RFC4970 that repeats and adds to the tex in 
RFC3630?

> and their impact on the length of the upper TLV.

Sub-TLVs form part of the V of the parent TLV.

> length of that subTLV. But should that padding be included in the length

Hah! Nice question.

Consider that the L field has two purposes.
1. To define the actual length of the V field
2. To allow a parser to step over the whole TLV without decoding it

In order to perform the second, the operation on a TLV with multiple 
sub-TLVs it is essential that the L of the parent TLV includes all of the 
padding implicit in the sub-TLVs.

> the length, but if more than 4 bytes of padding are added, you run into

Exactly.

> worth defining this somewhere, as the current wording is not clear on

If you were quoting text from the OSPF RFCs, you might want to take this to 
the OSPF list for confirmation.

Cheers,
Adrian

---

From: George Swallow <[email-masked]>
Date: Tue, 02 Oct 2007 16:21:52 -0400

> > the length, but if more than 4 bytes of padding are added, you run into

Actually 4 bytes or more (more than 3 bytes).

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719