Subject: [Tsvwg] Rr:Comments on draft-lefaucheur-rsvp-dste-02.txt

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Tue, 8 Mar 2005 16:43:56 +0100

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:[email-masked]] 
>> Sent: vendredi 4 mars 2005 22:40
>> To: Francois Le Faucheur (flefauch)
>> Cc: Michael DiBiasio (dibiasio); Bruce Davie (bdavie); 
>> [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]
>> 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

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Rurick Kellermann" <[email-masked]>
Date: Wed, 9 Mar 2005 14:52:31 -0500

Francois, 

Each of the hosts issuing a RESV is waiting for an approval of its
request. When aggregation is performed, one might have the case where
the aggregate of the reservation could fail due to b/w, etc.  

In that case, a) shouldn't the aggregator inform the individual hosts
with a PathErr message? b) if the condition which caused the PathErr
message persists, say due to insufficient b/w for the aggregate, some
individual requests could have obtained a PATH if they had been
responded individually (i.e. through a PATH message instead of an
E2EPATH).

Regards,

Rurick

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Wed, 9 Mar 2005 22:05:32 +0100

Hi Rurick,

________________________________

	From: Rurick Kellermann [mailto:[email-masked]] 
	Sent: mercredi 9 mars 2005 20:53
	To: Francois Le Faucheur (flefauch)
	Cc: [email-masked]
	Subject: Re: [Tsvwg] Rr:Comments on
draft-lefaucheur-rsvp-dste-02.txt

	Francois, 

	Each of the hosts issuing a RESV is waiting for an approval of
its 
	request. When aggregation is performed, one might have the case
where 
	the aggregate of the reservation could fail due to b/w, etc.  

	In that case, a) shouldn't the aggregator inform the individual
hosts 
	with a PathErr message? 
	[FLF:] Remember that with RSVP the reservation is controlled by
the destination (which issues the Resv). In case of CAC failure, you
want to notify the destination and the way to do that is to send a
ResvErr. The source need not be informed about the CAC failure.

	In the context of achieving CAC for VoIP, the destination , upon
receipt of a ResvErr, would then notify its Call Manager (eg SIP
Proxy/Server) that the reservation (aka "SIP precondition") is not met.
The CAll Manager woul take appropriate action (eg abort call setup and
return some tone indicating network busy).

	 b) if the condition which caused the PathErr 
	message persists, say due to insufficient b/w for the aggregate,

	 some 
	individual requests could have obtained a PATH if they had been 
	responded individually (i.e. through a PATH message instead of
an 
	E2EPATH). 
	[FLF:] I am not quite with you. Say we have a TE tunnel with
bandwidth B which can currently fit 10 calls. Say, we have 10 calls that
try to get established. Each source will send a Path, ecah destination
will send a Resv which will all be accepted by CAC over teh tunnel. Say
another 5 calls come and the Tunnel head-end can increase the Tunnel
size to fit total of 15 calls. Then the 5 additional calls will get
accepted. Say another 5 calls come in, and say teh TE tunnel Head-end
can no longer increase teh TE Tunnel size. Then each source for these 5
last call will send a Path and each destination will send a Resv. Each
Resv will be rejected by CAC on teh tunnel headend and a ResvErr (with
error cause "no bandwidth") will be generated by teh tunnel head-end
towards each destination.

	Does that clarify?

	Francois

	Regards, 

	Rurick

---

From: "Rurick Kellermann" <[email-masked]>
Date: Wed, 9 Mar 2005 17:24:51 -0500

Hi Francois,

See my comments in-line.

Rurick

On Wed, 2005-03-09 at 16:05, Francois Le Faucheur (flefauch) wrote:
> Hi Rurick,
>         
>         ______________________________________________________________
>         [FLF:] Remember that with RSVP the reservation is controlled
>         by the destination (which issues the Resv). In case of CAC
>         failure, you want to notify the destination and the way to do
>         that is to send a ResvErr.

RK: Agreed. My typo - meant to type ResvErr,

>          The source need not be informed about the CAC failure.

RK: Agreed. 
>         
>         In the context of achieving CAC for VoIP, the destination ,
>         upon receipt of a ResvErr, would then notify its Call Manager
>         (eg SIP Proxy/Server) that the reservation (aka "SIP
>         precondition") is not met. The CAll Manager woul take
>         appropriate action (eg abort call setup and return some tone
>         indicating network busy).

RK: Agreed. However, IMO, Section 3.5 could benefit with the explanation
that the source issues an E2E RESVErr which is issued instead of all the
individual RESV Err. messages? In other words, this is the advantage of
aggregation capabilities.
 
>         bandwidth B which can currently fit 10 calls. Say, we have 10
>         calls that try to get established. Each source will send a
>         Path, ecah destination will send a Resv which will all be
>         accepted by CAC over teh tunnel. Say another 5 calls come and
>         the Tunnel head-end can increase the Tunnel size to fit total
>         of 15 calls. Then the 5 additional calls will get accepted.
>         Say another 5 calls come in, and say teh TE tunnel Head-end
>         can no longer increase teh TE Tunnel size. Then each source
>         for these 5 last call will send a Path and each destination
>         will send a Resv. Each Resv will be rejected by CAC on teh
>         tunnel headend and a ResvErr (with error cause "no bandwidth")
>         will be generated by teh tunnel head-end towards each
>         destination.

RK: What I meant in b) was: there are already 15 calls and the TE Tunnel
Head-end can increase the tunnel to accept 2 more calls instead of 5.
With the E2E ResvErr. 5 calls would be rejected, instead of 3 if
individual ResvErrs. had been received. At this point it is up to the
application to throttle the reservation requests, which is
implementation specific. Can your explanation above be included? Also,
any intention of adding capability to accept the  'not 5 but 3' reply?

Thanks for your replies...

Cheers, Rurick