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

Re: Interface Switching Capability Descriptor sub-tlv length


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" <Oliver.Carter@DATACONNECTION.COM>
To: <OSPF@PEACH.EASE.LSOFT.COM>
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.