[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OSPF TLVs

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