Subject: Question on TLV Length Calculation

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 25 Jan 2008 13:26:58 -0500

Hi Folks,
 
Simple question on length calculation for RSVP-TE TLVs:  I've noticed
that 
draft-ietf-ccamp-ethernet-traffic-parameters-03.txt has adopted a method
of
calculating TLV length from RFC 4420, where the length includes only the
value portion of the TLV, and does not include the header (type and
length
bytes) or any padding bytes.
 
This is a bit different from how length is computed for objects and
sub-objects,
where length includes header as well.  Having not followed the
discussion 
on RFC 4420 closely, can someone clarify:
 
-- is this method of length calculation to be followed on all new TLVs
defined
for RSVP-TE?
 
-- if not, is there some basis for deciding what calculation to follow
when 
defining a new TLV?
 
Thanks,
 
Lyndon

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 31 Jan 2008 10:52:43 -0000

Hi Lyndon,

I didn't see an answer to this on the list. Dimitri, do you have a view?

> Simple question on length calculation for RSVP-TE TLVs:  I've
> noticed that draft-ietf-ccamp-ethernet-traffic-parameters-03.txt
> has adopted a method of calculating TLV length from RFC 4420,
> where the length includes only the value portion of the TLV, and
> does not include the header (type and length bytes) or any padding
> bytes.
>
> sub-objects, where length includes header as well.  Having not
> followed the discussion on RFC 4420 closely, can someone clarify:
>
> -- is this method of length calculation to be followed on all new
> TLVs defined for RSVP-TE?
>
> when defining a new TLV?

More important than the object and subobject length calculations, are the 
TLV length calculations defined in RFC 3471 where we have...
      Length: 16 bits
         Indicates the total length of the TLV, i.e., 4 + the length of
         the value field in octets.  A value field whose length is not a
         multiple of four MUST be zero-padded so that the TLV is four-
         octet aligned.

I would say that we should aim for consistency and that RFC 4420 was a 
mistake (mea culpa) caused by mirroring the capabilities advertisement 
features from a similar draft in the OSPF working group (OSPF TLVs use L = 
value length).

Consistency means following 3471 where possible (note that we can't go back 
and fix 4420 because it is deployed).

So the questions for Dimitri with 
draft-ietf-ccamp-ethernet-traffic-parameters-03.txt are:
- is there a reason to diverge from 3471?
- is it too late to fix this?

Thanks,
Adrian