Subject: RE: [Tsvwg] WGLC for draft-ietf-tsvwg-rsvp-ipsec-00.txt NOW

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Thu, 18 May 2006 14:05:30 +0200

Hi,

Just forwarding to the list the comments from Alexander Sayenko on
draft-ietf-tsvwg-rsvp-ipsec-00.txt.
I will respond to those in a separate message.

Francois

>> -----Original Message-----
>> From: Alexander Sayenko [mailto:[email-masked]] 
>> Sent: samedi 29 avril 2006 15:48
>> To: Francois Le Faucheur (flefauch)
>> Cc: Bruce Davie (bdavie); [email-masked]; 
>> [email-masked]; [email-masked]
>> Subject: Comments on generic aggregate reservations
>> 
>> Dear Authors
>> 
>> I have a few comments concerning the 
>> draft-ietf-tsvwg-rsvp-ipsec-00.txt
>> document.
>> 
>> RFC 3175, section 1.4.12, describes a way of preestablishing 
>> the aggregate
>> reservations. It might be useful if there are no E2E 
>> signaling messages or
>> if we just want to preestablish an aggregate. According to 
>> RFC 3175, it is
>> the responsibility of the aggregator to send the appropriate 
>> PATH message,
>> the deaggregator will just respond with the RESV message.
>> 
>> This procedure should be revised for the generic RSVP 
>> aggregations. Since
>> the aggregator sends the PATH message with the SESSION 
>> object that the
>> deaggregator constructs, there no "simple" way to 
>> preestablish a session. To
>> my opinion, two solutions are available. The first one is to tell the
>> deaggregator to send the PATH_ERROR message with the 
>> necessary SESSION
>> object. It will trigger the PATH message at the aggregator, 
>> which in turn
>> will trigger the RESV message at the deaggregator. The 
>> second solution is
>> similar to the one described in RFC 3175. However, since the 
>> aggregator is
>> not aware of all the vDstPort values that the deaggregator 
>> has assigned or
>> may potentially assign in the future, there is no safe way 
>> to ensure the
>> consistency across all the vDstPort values that may be used. 
>> At the same
>> time, if the administrator knows what s/he is doing, there 
>> is no technical
>> obstacle for preestablishing the reservation in such a way. 
>> I think the new
>> document should elaborate on these possibilities and present 
>> the RECOMMENDED
>> way.
>> 
>> Another proposition concerns the extended vDstPort. It is 
>> mentioned that it
>> is "normally set to all zeroes". Is it logical to send zeros 
>> (16 bytes in
>> the case of IPv6)? Furthermore, while sending the refresh 
>> PATH messages we
>> can reduce the overhead. I realize that one can use the RSVP refresh
>> reduction, but it is just recommendation, not obligation. 
>> So, the solution
>> is to introduce another C-Type that will correspond to the
>> GENERIC-AGGREGATE-IPv6/v4 SESSION without the extended 
>> vDstPort field.
>> 
>> Also, I have implemented the aggregated RSVP reservations 
>> for the NS-2
>> simulator. Since the generic aggregation is quite similar to 
>> RFC 3175, it is
>> possible to introduce those modifications quite easily. So, 
>> if you are
>> interested in numeric results, we can agree on some 
>> simulation scenario. In
>> fact, at the moment I have one that simulates the DiffServ 
>> domain (EF, AF1,
>> AF2, BE) that is managed by the aggregated RSVP. In any 
>> case, I will not be
>> suprised if you already have some prototype implementation 
>> for Cisco IOS
>> :-))
>> 
>> Sincerely,
>> Alexander Sayenko (PhD)
>> Assistant
>> Telecommunication laboratory, MIT department
>> University of Jyvaskyla, Finland
>>  

>> -----Original Message-----
>> From: James Polk (jmpolk) 
>> Sent: jeudi 6 avril 2006 03:19
>> To: tsvwg
>> Cc: Lars Eggert; [email-masked]; James Polk (jmpolk)
>> Subject: [Tsvwg] WGLC for draft-ietf-tsvwg-rsvp-ipsec-00.txt NOW
>> 
>> TSVWG Group
>> 
>> As agreed to in Dallas during the TSVWG meeting, the WGLC for
>> 
>> 	draft-ietf-tsvwg-rsvp-ipsec-00.txt
>> 
>> starts NOW.
>> 
>> All comments (nits, errors, suggestions, comments, approval) 
>> regarding this 
>> ID should be directed to the TSVWG list.
>> 
>> WGLC will end on or about April 20th, 2006, depending on the 
>> level of 
>> discussion at that time.
>> 
>> James
>> Lars
>> Magnus
>> 	IETF TSVWG co-chairs
>>