Subject: Re: OSPF TLVs

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Apr 2004 12:33:40 +0100

Hi Venkata, 

> -> RFC3630 implies that the actual space in the message is a
> -> multiple of 32bits regardless of the value of the length field,
> -> and that the length field represents the length of the value field(s).
> ->
> -> draft-ietf-ccamp-ospf-gmpls-extensions-12 does not
> -> contradict this. That is, the field labeled "Padding" is
> -> actually a value field of the TLV. (It might have been
> -> better labeled as "Reserved"). As the text says...
> ->
> ->      The padding is 3 octets, and is used to make the
> ->      Interface Switching Capability Descriptor sub-TLV
> ->      32-bits aligned.  It SHOULD be set to zero by the
> ->      sender and SHOULD be ignored by the receiver.
> ->
> -> That is, it makes the sub-TLV length up to a 32-bit multiple. 
>
>   I agree with Acee. You confused me.

Sorry. Not my aim to spoil your day. 

>   We have two cases here: 
>
>   1. Actual (Value) length carried in a TLV is explicit by the
>      "Length" field. In this case, padding/reserved space is
>      implicitly ignored based on next boundary math (here 32-bit)
>      if any, so that parser jump to next TLV with out ambiguity.

No. This is NOT what 3630 says.
3630 says that if a TLV is not a multiple of 32-bits, padding is inserted 
between it and the next TLV.
It does not comment on the contents of the TLV.
For example, if a TLV had five reserved bytes at the end, we would not 
modify this so that it had only one reserved byte.
In other words, the contents of the TLV are opaque to the TLV packing rules. 
The length field specifies the length of the V without saying anything about 
the format of the data in the V. All packing can be performed using the 
length field. 

>   2. Actual (Value) length carried in a TLV is implicit by the
>      "Type" field. In this case, the "Length" field signifies
>      total (actual + pad/reserved). So that, parser can jump
>      to next TLV with out ambiguity. 
>
>   I thought, (1) is what followed by TE community. I think,
>   you are supporting (2).

I am?
Length may be defined by type (with respect to documentation), but it is not 
implicit.
That is, the length field ALWAYS gives the length of the V field.
If the V field contains explicit padding or reserved bits, they are included 
in the length. 

In summary, there is a distinction between how TLVs are defined and how the 
message building rules are defined.
The draft gives the former, the RFC gives the latter. 

>   I don't argue which one is the correct
>   solution, but, it would be nice to synchronize same semantics
>   across all TE TLVs.

I think there is no discrepency across these TLVs. 

>   As a side note, I don't understand why padding is in place for
>   every granular TLV (sub-sub-TLV etc). Don't you think it is
>   efficient and bandwidth saving, if padding is used only at the
>   highest level of TLV/LSA. I don't understand why we try to
>   achieve 32-bit boundary for every TLV?

I have no comments on the history of why this is what is done in OSPF, but 
it is. From an implementation perspective, 32-bit alignment may be nice. 

>   Given that machines are
>   so fast, the difference in clock cycles in fetching a 32-bit
>   vs 8-bit number is not significant in processing speed (at least
>   with modern processors).

Adrian