Subject: Re: Interface Switching Capability Descriptor sub-tlv length

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Apr 2004 19:34:14 +0100

This didn't seem to make it through to the CCAMp list. 

Acee wrote... 

> I'm copying the ccamp list since this is a CCAMP WG document. My
> opinion is that the padding should not be included in the sub-TLV
> length since this is stated explicitly in RFC 3630.

I think you are wrong as follows Acee... 

I agree that the text could be a little confusing. 

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. 

Hope this clarifies.
Adrian 

 ----- Original Message -----
From: "Oliver Carter" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, April 21, 2004 2:35 PM
Subject: Interface Switching Capability Descriptor sub-tlv length 

> Hi all, 
>
> We have seen a minor interop problem with the Interface Switching 
> Capability Descriptor sub-tlv length value (defined in the
> draft-ietf-ccamp-ospf-gmpls-extensions draft).  In short, we are setting 
> the length so as to not include the pad bytes in the structure, and 
> another vendor is expecting the pad bytes to be included.  As explained 
> below, the specifications are slightly ambiguous - can it be clarified 
> what should be filled out in the length value please? 
>
> RFC 3630 Section 2.3.2 states that "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)."  this would support the argument that the length should be
> unpadded. 
>
> However, draft-ietf-ccamp-ospf-gmpls-extensions-12, section 1.4 describes
> the Interface Switching Capability Descriptor which states " The length is
> the length of value field" and then shows the padding of the Switching
> Capability field as part of the value field.  This would support the
> argument that the padding for this TLV should be included in the length
> field. 
>
> So which argument is correct, and can this be made explicit in the next
> version of draft-ietf-ccamp-ospf-gmpls-extensions? 
>
> Thanks 
>
> Oli 
>
> P.S. Apologies if this has already been resolved by the list - my 
> searching didn't turn up anything.