Re: OSPF TLVs

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

Venkata, 

I don't see why there is any change required.
You appear to be precluding TLVs from having any length that is not a 
multiple of four bytes. This seems unnecessary. 

What we currently have is a rule that tells you how to encode a TLV into an 
OSPF LSA if it is not a multiple of four bytes.
You have a separate rule that says that a specific TLV has some reserved 
bytes. 

Why do we need to make any changes?
Further, if the length of the TLV is "implicit" we don't need to use a 
length field at all. There is a place for TVs, but this is not it. 

The only change that might be of use would be to change the name of any 
field that is included in a TLV from "padding" to "reserved" to avoid 
confusion. 

Perhaps the draft's authors would like to contribute to this thread. 

Thanks,
Adrian
----- Original Message -----
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: <adrian@olddog.co.uk>; <ospf@peach.ease.lsoft.com>; 
<ccamp@ops.ietf.org>; "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
Sent: Friday, April 23, 2004 7:41 PM
Subject: RE: OSPF TLVs 


> Adrain, 
>
> -> >   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.  
>
>   If V field contains explicit padding/reserve bits, the current
>   value length must be known some how (mostly implicit by the type
>   field). That is what I am saying. 
>
>   Let us come to a consensus. Let me know we are on same page or not
>   based on below diagram: 
>
>   RFC 3630 section 2.3.2.  TLV Header 
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |              Type             |             Length            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                            Value...                           |
>       .                                                               .
>       .                                                               .
>       .                                                               .
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>
>    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).   
>
>
> [Start Modification] 
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |              Type             |             Length            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                      Value Current...                         |
>       .                                                               .
>       .                                                               .
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                      Value Reserved...                        .
>       .                                                               .
>       .               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .               |                   Pad ... (0-3 octet)         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     
>
>    The Length field defines the length of the value portion (current +
>    reserved) in octets. Length of current value portion is implicit by 
>    the type field. 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).  
>    
> [End Modification] 
>
>
> Venkata.