Subject: TR: [Pce] TLV Format

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Thu, 4 Oct 2007 10:06:16 +0200

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.

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. 

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?).

Does it make sense?

Best regards

Fabien

  _____  

De : Fabien VERHAEGHE [mailto:[email-masked]] 
Envoyé : vendredi 14 septembre 2007 09:45
À : [email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 4 Oct 2007 11:25:41 +0200

Hi Fabien
 
Sorry for the late reply
 
Please see inline,

________________________________

	De : Fabien VERHAEGHE [mailto:[email-masked]] 
	Envoyé : jeudi 4 octobre 2007 10:06
	À : [email-masked]
	Objet : TR: [Pce] TLV Format

	Hello,

	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

	 The Length field would carry the actual length of the value without padding bytes due to alignment.

	Sure

	With this general rules there is no need to specify that 2 unused bytes must be added for 4 bytes length

	Note that I'm not sure why the draft proposed a 8 bytes alignment (Why not 4 bytes since in section 7.1

	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

________________________________

	Hi,

	The main problem being that the general format of the TLVs is not described (Type, length value length, 4 bytes alignment...).

	 

	"The REQ-MISSING TLV is composed of 1 byte for the type,

	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?

	"The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte

	   LENGTH: 4

	   VALUE: 32-bits flags field"

	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?

	Thanks

	Fabien

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 4 Oct 2007 13:50:16 +0100

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.

Cheers,
Adrian

----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, October 04, 2007 10:25 AM
Subject: RE: [Pce] TLV Format

Hi Fabien

Sorry for the late reply

Please see inline,

Hello,

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).

Sure

Note that I'm not sure why the draft proposed a 8 bytes alignment (Why not 4 
bytes since in section 7.1

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

Hi,

The main problem being that the general format of the TLVs is not described 
(Type, length value length, 4 bytes alignment...).

LENGTH: 4

this 4 bytes header i.e. Type (1byte) - Value field Length (1byte) - Unused 
field (2bytes) - Value field

Besides I'm not sure about the "The REQ-MISSING TLV is padded to eight-byte 
alignment." statement.

Is it really needed?

   LENGTH: 4

Thanks

Fabien

--------------------------------------------------------------------------------

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 4 Oct 2007 16:13:05 +0200

Hi Adrian,

OK, good point.
We will cover these three questions in rev 09.

Thanks,

JL

> -----Message d'origine-----
> De : Adrian Farrel [mailto:[email-masked]] 
> Envoyé : jeudi 4 octobre 2007 14:50
> À : LE ROUX Jean-Louis RD-CORE-LAN; 
> [email-masked]; [email-masked]
> Objet : Re: [Pce] TLV Format
> 
> 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.
> 
> Cheers,
> Adrian
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 10 Oct 2007 19:53:44 +0200

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-masked]>
> 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
>
>
>
> The main problem being that the general format of the TLVs is not  
> described (Type, length value length, 4 bytes alignment...).
>
>
>
> 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
>