Hi Adrian, OK, good point. We will cover these three questions in rev 09.
Thanks, JL > -----Message d'origine----- > De : Adrian Farrel [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 4 octobre 2007 14:50 > À : LE ROUX Jean-Louis RD-CORE-LAN; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > 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 > > ----- 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
