Hi,
On Oct 4, 2007, at 2:50 PM, Adrian Farrel wrote:
Hi,
Did you see the question about padding and lengths on the CCAMP and
OSPF lists?
It might be worth getting this explained in the PCEP I-D, as well.
The questions are:
When an object contains a TLV with padding (so the TLV length field
does not include the length of the padding) what is the value of
the length field in the object?
When a TLV contains multiple TLVs with padding, what is the value
of the length field in the object?
When a TLV contains sub-TLVs with padding, what is the value of the
length field in the TLV?
These three questions seem to have well-known and "obvious" answers
for other protocols, but are not written down. Let's write them
down for PCEP.
This is planned for rev-09 for sure.
Thanks.
Cheers.
JP.
Cheers,
Adrian
----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN"
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2007 10:25 AM
Subject: RE: [Pce] TLV Format
Hi Fabien
Sorry for the late reply
Please see inline,
________________________________
De : Fabien VERHAEGHE [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 4 octobre 2007 10:06
À : [EMAIL PROTECTED]
Objet : TR: [Pce] TLV Format
Hello,
I did not see any reply for this comment.
I seize the opportunity to clarify my opinion:
I think TLV alignment statement must be a general rules for all
TLVs of a given object.
Definitely right. We are going to add a section on generic TLV
encoding. All TLVs specificed in PCEP objects will have to follow
this encoding.
Here it is:
7.1.1. PCEP Object TLVs
A PCEP object may include a set of one or more optional TLV(s).
A PCEP object TLV is comprised of 2 octets for the type, 2 octets
specifying the TLV length,
and a value field. The Length field defines the length of the value
portion in octets.
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).
PCEP Object TLV types MUST be managed by IANA.
Unrecognized TLVs MUST be ignored.
Note that this is the encoding already used in RFC 3630 & 4420.
The draft then needs also to specify that the alignment padding
bytes must be included before
or after the value field.
The Length field would carry the actual length of the value without
padding bytes due to alignment.
Those statements seem important to me for the processing of unknown
TLVs.
Sure
With this general rules there is no need to specify that 2 unused
bytes must be added for 4 bytes length
value TLV such as The REQ-MISSING.
Note that I'm not sure why the draft proposed a 8 bytes alignment
(Why not 4 bytes since in section 7.1
it is said that object length must always be a multiple of 4?).
Yes this was a mistake. We are going to align TLV definitions to
new section 7.1.1.
Thanks for your comment.
Regards,
JL
Does it make sense?
Best regards
Fabien
________________________________
De : Fabien VERHAEGHE [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 14 septembre 2007 09:45
À : [EMAIL PROTECTED]
Objet : [Pce] TLV Format
Hi,
I think there is a little problem with PCEP object TLV format.
The main problem being that the general format of the TLVs is not
described (Type, length value length, 4 bytes alignment...).
Besides for existing TLVs we have:
"The REQ-MISSING TLV is composed of 1 byte for the type,
1 byte specifying the number of bytes in the value field, 2 bytes
for an "Unused" field (the value of which MUST be set to 0),
followed by
a fix length value field of 4 bytes specifying the request-id-number
that correspond to the missing request.
The REQ-MISSING TLV is padded to eight-byte alignment.
TYPE: To be assigned by IANA
LENGTH: 4
VALUE: request-id-number that corresponds to the missing request"
I think the LENGTH field should be set to 6, the unused field 2
bytes being part of the Value field. Otherwise
it means those 2 bytes are part of the TLV header and it should be
said that all TLVs will be formatted with
this 4 bytes header i.e. Type (1byte) - Value field Length (1byte)
- Unused field (2bytes) - Value field
Otherwise, there may be some problem when decoding a message with
unknown TLV.
Besides I'm not sure about the "The REQ-MISSING TLV is padded to
eight-byte alignment." statement.
Is it really needed?
For the NO-PATH-VECTOR TLV we have
"The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte
specifying the number of bytes in the value field, followed by a fix
length value field of 32-bits flags field used to report the
reason(s) that led to unsuccessful path computation.
The NO-PATH-VECTOR TLV is padded to eight-byte alignment.
TYPE: To be assigned by IANA
LENGTH: 4
VALUE: 32-bits flags field"
In this case there is no Unused field 2 bytes.
I think it would be better to have the same format for all TLVs of
all object.
And again I'm wondering if the LENGTH field should be set to 4 or 6?
Can you please clarify this to me? Am I missing something?
Thanks
Fabien
----------------------------------------------------------------------
----------
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
