Re: CCAMP Vancouver comments on draft-ietf-tsvwg-rsvp-proxy-proto

[Francois Le Faucheur IMAP <flefauch@cisco.com>]

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.
"