[mpls] RE: Comments on draft-lefaucheur-rsvp-dste-02.txt

Hello Arthi,

(broadening the audience to include the mpls and tsvwg Working Groups)

Thanks for your comments. Please see below embedded responses.  

>> -----Original Message-----
>> From: Arthi Ayyangar [mailto:arthi@juniper.net] 
>> Sent: vendredi 4 mars 2005 22:40
>> To: Francois Le Faucheur (flefauch)
>> Cc: Michael DiBiasio (dibiasio); Bruce Davie (bdavie); 
>> christou_chris@bah.com; davenport_michael@bah.com; 
>> gash@att.com; bgoode@att.com
>> Subject: Comments on draft-lefaucheur-rsvp-dste-02.txt
>> 
>> 
>> Hi Francois,
>> 
>> The ID looks good. I am glad to see that you have added the 
>> TTL discussion
>> as well as the hierarchy related text that we talked about 
>> last time. I
>> have a few additional comments listed below.
>> 
>> 1)
>> In section 3.5, you may want to clarify that the Resv itself is sent
>> directly (IP routed) to the PHOP (aggregator). So again, none of the
>> transit nodes need to handle this message.

Will do.

>> 2)
>> Secondly, in section 3.2, the selection of TE tunnel for the 
>> e2e aggregate
>> Path msg is also in a way admission control, but in the 
>> forward direction.
>> Do you agree ? At this time no bandwidth is reserved, but 
>> this definitely
>> involves some form of admission control. E.g. if you have 
>> two TE tunnels
>> to the same de-aggregator, the fact that one has sufficient 
>> bw whereas the
>> other one does not, will play a role in which one you pick.

I agree that (i) bandwidth is not reserved at that time and (ii)
remaining unreserved bandwidth on a given TE tunnel may be taken into
account by the Headend as one of the parameters affecting its tentative
Tunnel selection.
I don't think I would quite call that "admission control" but the above
is true. I think the current text does not contradicts that, right. But,
let me know if you feel it does.

>> 
>> 3) In section 3.6, where you describe the following in the context of
>> re-sizing the TE tunnel..
>> 
>>    "If sufficient bandwidth is not available on the final TE 
>> Tunnel, the
>>    Aggregator must follow the normal RSVP procedure for a reservation
>>    being placed with insufficient bandwidth to support this 
>> reservation.
>>    That is, the reservation is not installed and a ResvError is sent
>>    back towards the receiver"
>> 
>> Do you think it would be useful to say the following ? - "in order to
>> reduce disruptions, the aggregator should/may use "make-before-break"
>> procedures as described in RFC 3209 to alter the TE tunnel bandwidth"

Yes, it would be useful to add something like that. I would suggest
right at the end of the preceding paragraph ie:
"   As noted in [RSVP-AGGR], a range of policies may be applied to the 
   re-sizing of the aggregate reservation (in this case, the TE tunnel.)

   For example, the policy may be that the reserved bandwidth of the 
   tunnel can only be changed by configuration. More dynamic policies 
   are also possible, whereby the aggregator may attempt to increase the

   reserved bandwidth of the tunnel in response to the amount of 
   allocated bandwidth that has been used by E2E reservations. 
   Furthermore, to avoid the delay associated with the increase of the 
   Tunnel size, the Aggregator may attempt to anticipate the increases 
   in demand and adjust the TE tunnel size ahead of actual needs by E2E 
   reservations.
"

>> 4) Section 3.7
>> 
>> In addition to what you have, "if a TE tunnel was 
>> established dynamically
>> in account of an E2E reservation request, then once there 
>> are no longer
>> any E2E reservations admitted into the TE tunnel, the TE 
>> tunnel MAY be
>> torn down. This is dictated by local policy on the aggregator."

The current draft only covers the case where TE tunnels are
pre-established and leaves dynamic establishment of TE tunnels for
further studies. There didn't see a clear requirement for the dynamic
case which involves additional complexities (eg. dynamic discovery of
Head-ends/Tail-ends as defined in RFC3175).
If we were to cover dynamically established tunnels, then I would be
fine with your text above. But it is currently out of the current scope.
Do you feel we should extend the current scope and cover the case of
dynamically established tunnels?

>> 5) Section 3.6
>> 
>> On a reservation failure at the aggregator, is a PathErr 
>> also sent out
>> upstream (towards sender) ?

I don't believe so.
In regular RSVP, Path Err report errors in the processing of Path
messages. In case of CAC rejection on the Resv, we should just send a
ResvhErr. The destination may decide to try make a smaller reservation
or try a different Intserv service. Everything is normal as far Path is
concerned.

>> Finally, you may want to mention somewhere (just to prevent 
>> confusion)
>> that these reservations are assumed to be unidirectional.

We can state that. But RSVP reservations are unidirectional of course,
so sas there something specific that you feel would create confusion?

Thank you for your review an comments.

Francois

>> thanks,
>> -arthi
>> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls