Subject: [Tsvwg] draft-polk-tsvwg-intserv-multiple-tspec

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 26 Mar 2009 14:13:10 -0700

James, Subha,

Regarding:
"	   [Editor's Note:  the authors are currently unsure if there needs
                     to be a separate RSPEC for each TSPEC in the
                     Guarantee service.  Feedback is necessary before
                     completing the Multi_TSPEC  version of the above
                     format.
"
I believe you do need multiple RSPEC. This is the component that  
affects admission control and resource allocation. You would use a  
different RSpec if you use a different TSpec.

Regarding the options, the backwards compatibility properties of  
Option #3 make it very attractive.
Do you see drawbacks for Option 3?

Francois

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Mar 2009 11:35:12 -0500

Francois

Thank you for the review. comments in-line below

>different RSpec if you use a different TSpec.

thank you for that. I wasn't sure if we need separate admission 
control for different TSPECs, given the assumption that at least 1 
TSPEC was going to be chosen. In other words, I wasn't sure what 
would be different in, for example, a 3 TSPEC <sender descriptor> in 
the RSPECs (or if each RSPEC would have the same values in each field).

I have no concerns one way or the other, and just didn't know if an 
RSPEC would be the same for 1 or each TSPEC in the same <sender descriptor>.

>Regarding the options, the backwards compatibility properties 
>of  Option #3 make it very attractive.

thanks

that makes 4 votes for Option 3, and 1 for Option 2

>Do you see drawbacks for Option 3?

Because RFC 2205 says (in section 3.10) that all optional parts of a 
SENDER or RECEIVER_TSPEC are to be ignored, I see no issues with Option 3.

BTW - this is the only reason Option 2 would be a limiting choice - 
because if a router doesn't understand the parameter number (say 125 
for MULTI_TSPEC), then there wouldn't be a TSPEC that's readable 
within the <sender descriptor>, which is not good for establishing a 
reservation. Having 'a' TSPEC is kinda critical to RSVP.