Subject: Fwd: Re: draft-ietf-mpls-rsvpte-attributes-04.txt

From: mike shand <[email-masked]>
Date: Wed, 08 Sep 2004 15:01:07 +0100

>X-BrightmailFiltered: true
>Reply-To: "Adrian Farrel" <[email-masked]>
>From: "Adrian Farrel" <[email-masked]>
>To: "mike shand" <[email-masked]>
>Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>,
>         <[email-masked]>
>Subject: Re: draft-ietf-mpls-rsvpte-attributes-04.txt
>Date: Wed, 8 Sep 2004 14:40:48 +0100
>X-Mailer: Microsoft Outlook Express 6.00.2800.1158
>X-PMX-Version: 4.7.0.111621
>X-from-outside-Cisco: 128.107.250.142
>
>Hi Mike,
>
>Thanks for the review.
>
> > I'm conducting a "routing directorate" review of the above draft and I
> > have a couple of questions regarding the format of the TLVs.
> >
> > 1) In section 3, under length, it says that the padding to take the value
> > field up to a 4 byte boundary is NOT included in the length.
> > However in section 3.1 para 3 it says that the length field is always a
> > multiple of 4 bytes regardless of the number of bits set.
> >
> > I'm having difficulty reconciling those two statements.
>
>You are not the first to ask this question and I wonder what to do to stop 
>it being asked
>again.
>
>The value field in section 3.1 para 3 is always a multiple of four bytes. 
>It is NEVER
>padded. (It never needs to be padded.)
>Bits are either defined or undefined, but never pads.
>Thus the length field is always a multiple of 4 and always reflects 
>exactly the length of
>the value field.
>
>Other TLVs may have value fields that are not a multiple of four bytes. In 
>these cases (as
>described in section 3):
>- the length field reflects exactly the length of the value field
>- padding is added to round the value field up to a four byte boundary.
>
>We would certainly welcome your input on how to make this more clear.
>
> > 2) The TLV defined above in section 3 is of the normal design in that the
> > length is the length of the value field only and does not include the type
> > and length fields. However, the TLV defined 7.2 has a different form where
> > the length includes the type and length fields.
> >
> > Is there some rationale why the same protocol uses both types of encoding?
>
>As you say, the TLV definition in section 3 is "normal". Thus it is the 
>prefered way to
>define TLVs for the new object.
>
>The "TLV" in section 7.2 is not actually a TLV but is a sub-object 
>according to the
>definitions and format in RFC3209. We have no scope to play with this 
>definition (not
>withstanding the fact that it is abnormal).
>
> > And one final question. In section 9 it says in paras 5 and 7 that LSRs
> > SHOULD be prepared to receive this object in any order....
> >
> > should that be a MUST, or is SHOULD acceptable? It would appear to be
> > non-optional.
>
>Good catch.
>
> > A couple of typos I spotted.
> >
> > section 6 Inheritance rules. End of first para.
> >
> > "belongs to the same switching capability class THAN the triggering LSP".
>
>yup
>
> > section 7.3.1 Subobject presence rules, last para
> >
> > nearest to the STOP of the stack)
>
>yup
>
>Thanks, Mike.
>
>I'll hold the last three changes ready for the next rev.
>Any advice about clarifying the first two points would be welcomed.
>
>Cheers,
>Adrian

---

From: Alex Zinin <[email-masked]>
Date: Tue, 30 Nov 2004 17:09:18 -0800

Mike, Adrian-

 Have these comments been addressed? I still see -04 in the tracker.

-- 
Alex
http://www.psg.com/~zinin