Re: Question on TLV Length Calculation

["Adrian Farrel" <adrian@olddog.co.uk>]

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

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