Subject: [OSPF] [Fwd: Question about TLV, subTLVs and length]

From: Jeroen van der Ham <[email-masked]>
Date: Tue, 02 Oct 2007 18:54:06 +0200

Hello,

While working on implementing some features for GMPLS the question below
came up. I sent this to the ccamp list, where Adrian Farrel answered my
question, but also suggested that this issue should be taken to this
list, where someone might actually be able to do something about it. :)

The relevant part of his answer is pasted below the message.

-------- Original Message --------
Subject: Question about TLV, subTLVs and length
Date: Tue, 02 Oct 2007 17:36:40 +0200
From: Jeroen van der Ham <[email-masked]>
To: [email-masked]

Hello,

The current text defining the length of TLVs is the following (from RFC
4970):

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

Adrian Farrel wrote:
> 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. 

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

---

From: Acee Lindem <[email-masked]>
Date: Tue, 2 Oct 2007 17:05:18 -0400

Hi Jeroen,
IMHO, it doesn't make sense for anything but the padded length of the  
sub-TLVs to be included in the length of the subsuming TLV. This both  
satisfies the salient OSPF design point of maintaining 4-bytes  
alignment while still allowing the actual length of the constituent  
sub-TLV values to be determined.
Thanks,
Acee
On Oct 2, 2007, at 12:54 PM, Jeroen van der Ham wrote:

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

---

From: Jeroen van der Ham <[email-masked]>
Date: Wed, 03 Oct 2007 11:31:30 +0200

Acee Lindem wrote:
> satisfies the salient OSPF design point of maintaining 4-bytes alignment
> while still allowing the actual length of the constituent sub-TLV values
> to be determined.

I completely agree. However, the actual text in the RFCs about the
lengths of TLVs are not so clear on the matter.
Particularly the line "The TLV is padded to four-octet alignment;
padding is not included in the length field" can be misleading when
using subTLVs and their padding.

Jeroen.

---

From: Anton Smirnov <[email-masked]>
Date: Wed, 03 Oct 2007 11:48:08 +0200

Jeroen,
    if sub-TLV is in the middle of TLV's value (i.e. there exists other 
sub-TLVs after it) then sub-TLVs padding must be counted in TLVs value. 
I don't think document's wording leaves any ambiguity here.
    If sub-TLV is the last one in TLV then it is not really important if 
you will include padding into TLV length or not. If you include - it 
will be counted as sub-TLV padding and TLV itself ends on word boundary. 
If you don't - it is padding of TLV which didn't end on word boundary. 
Either way, any implementation on receiver conforming to document's 
wording should be able to correctly unpack sub-TLVs and find beginning 
of the next TLV.

    Thanks,

Anton

---

From: Acee Lindem <[email-masked]>
Date: Wed, 3 Oct 2007 10:01:25 -0400

On Oct 3, 2007, at 5:31 AM, Jeroen van der Ham wrote:

>> alignment

I'll clarify this is the OSPFv3 Traffic Engineering draft.

Thanks,
Acee