Subject: [Tsvwg] CCAMP Vancouver comments on draft-ietf-tsvwg-rsvp-proxy-proto

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 10 Dec 2007 15:08:39 +0100

Hi,

Just following up on the good suggestions we received during the rsvp- 
proxy-proto preso in CCAMP WG.
Below is a recap of the comments and proposed changes to rsvp-proxy- 
proto in order to reflect those.
Comments welcome.

Thanks again to CCAMP WG.

Francois

1) Processing of "Downstream Errors" by Sender
====================================

With Notify approach, the sender not only has to support Notify, but  
it also has to process  "downstream errors". It is worth making this  
explicit.

To that effect, I propose that:
Under  section "3.2.  Sender Notification via Notify Message".
We replace:
"
    Note, however, that such benefits come at the cost of more
    sophistication and of a requirement for RSVP routers and senders to
    support the Notify messages and procedures defined in [RFC3473].
"
by
"
    Note, however, that such benefits come with some costs including :
	o more sophistication
	o a requirement for RSVP routers and senders to
            support the Notify messages and procedures defined in  
[RFC3473]
	o a requirement for senders to process downstream error messages.
"

2) Sending Notify in-addition/instead of PathErr
====================================

Current text does not discuss whether the two methods (PathErr and  
Notify) are exclusive or additive (ie use Notify in addition to  
PathErr). There was also concern expressed about Notify messages  
being less reliable than PathErr and thus it may be safer to get  
Notify issued in-addition to PathErr (and not instead). On the other  
hands there are environments where not sending the PathErr (ie send  
Notify only) could help scalability.

Hence we propose a recommended approach on the safe side (ie send  
both Notify and PathErr) with an optional approach allowing better  
scalability (ie send Notify only). To that effect, I propose that:
At the end of section "3.2.  Sender Notification via Notify Message",
We add:
"
When the method of sender notification via Notify message is used, it  
is RECOMMENDED that the RSVP Receiver Proxy also issues sender  
notification via a PathErr message. This maximizes the chances that  
the notification reaches the sender in all situations (e.g. even if  
some RSVP routers do not support the Notify procedure, or if a Notify  
message gets dropped). However, for controlled environments (e.g.  
where all RSVP routers are known to support Notify procedures) and  
where it is desirable to minimize the volume of signaling, the RSVP  
Receiver Proxy MAY rely exclusively on sender notification via Notify  
message and thus not issue sender notification via PathErr message.
"

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 10 Dec 2007 15:12:10 +0100

Hi,

Francois

---

From: Lou Berger <[email-masked]>
Date: Mon, 10 Dec 2007 09:26:58 -0500

Francois,
         This captures and addresses the primary comments I made to 
you at the end of CCAMP.  Please don't forget to add a 
(compatibility) note about how this approach results in an upstream 
node receiving a downstream notify.

Much thanks,
Lou

At 09:08 AM 12/10/2007, Francois Le Faucheur wrote:
>Hi,
>
>Just following up on the good suggestions we received during the 
>rsvp- proxy-proto preso in CCAMP WG.

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 10 Dec 2007 20:57:33 +0200 (EET)

Hi Francois, all,

The proposed modifications look good to me.

Cheers,
Jukka

On Mon, 10 Dec 2007, Francois Le Faucheur wrote:

> rsvp-proxy-proto preso in CCAMP WG.
> Below is a recap of the comments and proposed changes to rsvp-proxy-proto in
> order to reflect those.
> Comments welcome.
> 
> With Notify approach, the sender not only has to support Notify, but it also
> has to process  "downstream errors". It is worth making this explicit.
> 
> Current text does not discuss whether the two methods (PathErr and Notify) are
> exclusive or additive (ie use Notify in addition to PathErr). There was also
> concern expressed about Notify messages being less reliable than PathErr and
> thus it may be safer to get Notify issued in-addition to PathErr (and not
> instead). On the other hands there are environments where not sending the
> PathErr (ie send Notify only) could help scalability.
> 
> Hence we propose a recommended approach on the safe side (ie send both Notify
> and PathErr) with an optional approach allowing better scalability (ie send
> Notify only). To that effect, I propose that:
> When the method of sender notification via Notify message is used, it is
> RECOMMENDED that the RSVP Receiver Proxy also issues sender notification via a
> PathErr message. This maximizes the chances that the notification reaches the
> sender in all situations (e.g. even if some RSVP routers do not support the
> Notify procedure, or if a Notify message gets dropped). However, for
> controlled environments (e.g. where all RSVP routers are known to support
> Notify procedures) and where it is desirable to minimize the volume of
> signaling, the RSVP Receiver Proxy MAY rely exclusively on sender notification
> via Notify message and thus not issue sender notification via PathErr message.
> "
>