Subject: Last calls for RSVP Extensions drafts

From: Vijay Srinivasan <[email-masked]>
Date: Tue, 14 Sep 1999 09:59:09 -0400

This e-mail announces the beginning of the last calls for
draft-ietf-mpls-rsvp-lsp-tunnel-03.txt and
draft-awduche-mpls-rsvp-tunnel-applicability-01.txt.

Please send your comments to the list.  The last call for these drafts
will end 5 pm US EDT, Monday, September 20.

- Vijay

---

From: Adrian Farrel <[email-masked]>
Date: Mon, 20 Sep 1999 12:33:09 +0100

Vijay,

A couple of minor thoughts, apologies if they've already been raised.

Regards,
Adrian

1.  Section 3 states that "The LABEL and RECORD_ROUTE objects, are sender
specific.  They must immediately follow either the SENDER_TEMPLATE in Path
messages, or the FILTER_SPEC in Resv messages."

but in section 3.1 we have...

"<sender descriptor> ::=  <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
                                      [ <ADSPEC> ]
                                      [ <RECORD_ROUTE> ]"

i.e. shortly after but not necessarily immediate

and in section 3.2 LABEL and RECORD_ROUTE both occur - would there be value
in specifying that there is a required order (or no required order)?

2.  Would it be more intuitive to reverse the order of sections 4.1 and 4.2
so that
* the objects that relate to Path messages come before Resv messages
* to match the order in section 3?

3.  Sections 4.3.3.2 and 4.3.3.3 Show "Flags" in the subobject diagram, but
the text describes "Padding"

4.  Could you re-state in section 4.3.3.5 that the L bit has no meaning in
an operational subobject?

5. Compare 4.3.4.1 with the text in 4.8.1 of draft-ietf-mpls-cr-ldp.  
In step 1) the main difference is consideration of the L bit in the first
subobject.  This allows the receiving node to not be part of the specified
abstract node if the L bit is set.

6.  The last sentence of 4.4.3 implies several things.
- It is not permissible to send a Resv with RRO if the corresponding Path
did not contain one
- Once a Path has been sent without RRO the function cannot be re-enabled
using RRO on a subsequent Path.
Is this the intention?  In particular, is there a restriction on an
intermediate node deciding that it wishes to enable route recording for the
path between it and the receiver even when the sender did not place RRO in
the Path message?
Further, there is no mention of whether the absence of RRO on a refresh Path
(from the sender) should be propagated to refresh Paths from the
intermediate nodes.

Typos...

4.2.2, first paragraph, second sentence.  For "send" read "sends"

4.2.2, second paragraph.  The text "capable router." appears to be missing
from before the last sentence (the one that begins "See [1] for..."    

4.3.1, second paragraph.  For "response" read "respond"

4.4.5, last sentence.  For "response" read "respond"

4.7, penultimate paragraph.  For "contents" read "content".  For "are" read
"is"
--
Adrian Farrel  mailto:[email-masked]
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

> -----Original Message-----
> From:	Vijay Srinivasan [SMTP:[email-masked]]
> Sent:	Tuesday, September 14, 1999 9:59 AM
> To:	[email-masked]
> Subject:	Last calls for RSVP Extensions drafts
> 
>