Subject: [Tsvwg] WG last call RSVP proxies documents draft-ietf-tsvwg-rsvp-proxy-approaches-04 and draft-ietf-tsvwg-rsvp-proxy-proto-05

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 May 2008 17:30:27 +0200

This messages initiates a 2 week working group last call for "RSVP 
Extensions for Path-Triggered RSVP Receiver Proxy" to proposed standard 
and "RSVP Proxy Approaches" for informational status.

http://tools.ietf.org/id/draft-ietf-tsvwg-rsvp-proxy-approaches-04.txt
http://tools.ietf.org/id/draft-ietf-tsvwg-rsvp-proxy-proto-05.txt

Please provide your comments no later than the 28th of May.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 May 2008 15:26:50 -0500

At 10:30 AM 5/14/2008, Magnus Westerlund wrote:
>Extensions for Path-Triggered RSVP Receiver Proxy" to proposed 
>standard and "RSVP Proxy Approaches" for informational status.
>

with my individual hat on -- I strongly support these two documents 
as they are now

James

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 16 May 2008 08:17:05 -0700

Francois,

I have been reviewing the proxy I-D and I have a couple of questions about Notify.  You have defined the behavior of a proxy destination to be to reflect the Notify request from the Path message into the Resv message so that the sender will receive downstream Resv error information.

Since proxy nodes are invisible, are you not also implicitly defining the behavior of a non-proxy destination?  And are you not also implictly defining that all senders must be capable of receiving downstream Resv information?

I.e., it seems that you are implicitly defining the operation of source and destination nodes wrt Notify in a non-GMPLS context, and not just the operation of source and destination proxies.

Thanks,

John  

>-----Original Message-----
>From: Magnus Westerlund [mailto:[email-masked]] 
>Sent: Wednesday, May 14, 2008 8:30 AM
>To: tsvwg
>Subject: [Tsvwg] WG last call RSVP proxies 
>documentsdraft-ietf-tsvwg-rsvp-proxy-approaches-04 
>anddraft-ietf-tsvwg-rsvp-proxy-proto-05
>
>This messages initiates a 2 week working group last call for 
>"RSVP Extensions for Path-Triggered RSVP Receiver Proxy" to 
>proposed standard and "RSVP Proxy Approaches" for informational status.
>

---

From: Ashok Narayanan <[email-masked]>
Date: Fri, 16 May 2008 14:02:19 -0400

John,

 > I have been reviewing the proxy I-D and I have a couple of questions about
 > Notify.  You have defined the behavior of a proxy destination to be to reflect
 > the Notify request from the Path message into the Resv message so that the
 > sender will receive downstream Resv error information.

Reflecting the NOTIFY from the Path message is an optional behaviour of the 
receiver proxy; not mandatory or default.

 > Since proxy nodes are invisible, are you not also implicitly defining the
 > behavior of a non-proxy destination?

No, I don't think so. The receiver proxy reflects the NOTIFY_REQUEST from the 
Path message into the Resv, *because* it generally doesn't know what to do with 
any ResvError short of sending it back to the sender. This qualification does 
not apply to a non-proxy destination, therefore I don't believe that non-proxy 
destinations will (or should) reflect the NOTIFY_REQUEST from the Path, back 
into the Resv. However, if a particular end-to-end RSVP application in fact 
wanted to take advantage of this functionality (perhaps because their RSVP 
endpoint on the receiver was really nothing more than a dumb proxy), then 
there's no reason they couldn't. The idea behind reflecting the NOTIFY_REQUEST 
is to get the ResvError quickly to the person who really needs to see it - the 
sender - because the person to whom it is addressed - the receiver - cannot do 
anything with it except send it up.

 > And are you not also implicitly defining
 > that all senders must be capable of receiving downstream Resv information?

It is true that doing this requires the sender be able to process all ResvError 
messages as well, which is functionality over and above that required by 
RFC2205. However, this is not _mandatory_, because the generation of a Notify 
message containing the ResvError does not suppress the generation of the 
ResvError itself, towards the receiver. The receiver proxy should then turn 
around and generate a PathError towards the sender, which the sender can then 
interpret. So, if the sender was able to interpret the ResvError in the Notify 
message, he received notification of the error condition sooner; but if he just 
threw it away, he would still receive notification of the error condition, just 
a little later. Of course, it is better to deploy this extension with senders 
who can understand the ResvError message, in order to speed up failure detection.

-Ashok

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 16 May 2008 20:52:37 +0200

Hello John,

I pretty much concur with Ashok. In short:
	- nothing new is required on a destination
	- a sender may implement an optional behavior that would help in  
case a receiver proxy is used and the proxy uses the optional Notify  
mechanism. The sender does not have to implement this.
	- a similar concern has actually come up in the CCAMP review and we  
tried clarify that point with text like :
"   Note, however, that such benefits come at the cost of :
...
    o  a requirement for senders to process Notify messages traveling
       upstream but conveying a downstream notification.
"

Does this sound reasonable?

Francois

On 16 May 2008, at 20:02, Ashok Narayanan wrote:

> Reflecting the NOTIFY from the Path message is an optional  
> behaviour of the receiver proxy; not mandatory or default.
>
> No, I don't think so. The receiver proxy reflects the  
> NOTIFY_REQUEST from the Path message into the Resv, *because* it  
> generally doesn't know what to do with any ResvError short of  
> sending it back to the sender. This qualification does not apply to  
> a non-proxy destination, therefore I don't believe that non-proxy  
> destinations will (or should) reflect the NOTIFY_REQUEST from the  
> Path, back into the Resv. However, if a particular end-to-end RSVP  
> application in fact wanted to take advantage of this functionality  
> (perhaps because their RSVP endpoint on the receiver was really  
> nothing more than a dumb proxy), then there's no reason they  
> couldn't. The idea behind reflecting the NOTIFY_REQUEST is to get  
> the ResvError quickly to the person who really needs to see it -  
> the sender - because the person to whom it is addressed - the  
> receiver - cannot do anything with it except send it up.
>
> It is true that doing this requires the sender be able to process  
> all ResvError messages as well, which is functionality over and  
> above that required by RFC2205. However, this is not _mandatory_,  
> because the generation of a Notify message containing the ResvError  
> does not suppress the generation of the ResvError itself, towards  
> the receiver. The receiver proxy should then turn around and  
> generate a PathError towards the sender, which the sender can then  
> interpret. So, if the sender was able to interpret the ResvError in  
> the Notify message, he received notification of the error condition  
> sooner; but if he just threw it away, he would still receive  
> notification of the error condition, just a little later. Of  
> course, it is better to deploy this extension with senders who can  
> understand the ResvError message, in order to speed up failure  
> detection.
>
> -Ashok
>
>
> Drake, John E wrote:
>> Francois,
>> I have been reviewing the proxy I-D and I have a couple of  
>> questions about Notify.  You have defined the behavior of a proxy  
>> destination to be to reflect the Notify request from the Path  
>> message into the Resv message so that the sender will receive  
>> downstream Resv error information.
>> Since proxy nodes are invisible, are you not also implicitly  
>> defining the behavior of a non-proxy destination?  And are you not  
>> also implictly defining that all senders must be capable of  
>> receiving downstream Resv information?
>> I.e., it seems that you are implicitly defining the operation of  
>> source and destination nodes wrt Notify in a non-GMPLS context,  
>> and not just the operation of source and destination proxies.
>> Thanks,
>> John
>>> Subject: [Tsvwg] WG last call RSVP proxies documentsdraft-ietf- 
>>> tsvwg-rsvp-proxy-approaches-04 anddraft-ietf-tsvwg-rsvp-proxy- 
>>> proto-05
>>>

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 16 May 2008 13:18:38 -0700

>From: Ashok Narayanan [mailto:[email-masked]] 
>Sent: Friday, May 16, 2008 11:02 AM
>To: Drake, John E
>Cc: tsvwg
>Subject: Re: [Tsvwg] WG last call RSVP proxies 
>documentsdraft-ietf-tsvwg-rsvp-proxy-approaches-04anddraft-ietf
>-tsvwg-rsvp-proxy-proto-05
>
>John,
>
>questions about  > Notify.  You have defined the behavior of a 
>proxy destination to be to reflect  > the Notify request from 
>the Path message into the Resv message so that the  > sender 
>will receive downstream Resv error information.
>

JD:  The section is described as optional but it is full of 'MUST's.  Viz:

"Upon receiving a Path message with a Notify Request object, the RSVP Receiver Proxy MUST include a Notify Request object in the Resv messages it generates.  This Notify Request object MUST contain the address that was included in the Notify Request of the received Path message- a.k.a. the sender's address- and not an address of the Receiver Proxy."
 
>
> > Since proxy nodes are invisible, are you not also 
>implicitly defining the  > behavior of a non-proxy destination?
>
>NOTIFY_REQUEST from the Path message into the Resv, *because* 
>it generally doesn't know what to do with any ResvError short 
>of sending it back to the sender. This qualification does not 
>apply to a non-proxy destination, therefore I don't believe 
>that non-proxy destinations will (or should) reflect the 
>NOTIFY_REQUEST from the Path, back into the Resv.

JD:  What I was concerned about was unless it was stipulated that the receiver also reflected the Notify request, a sender will have to deal with different behavior depending upon whether it is dealing with a receiver or a proxy receiver and it doesn't which it is dealing with.

>  However, if 
>a particular end-to-end RSVP application in fact wanted to 
>take advantage of this functionality (perhaps because their 
>RSVP endpoint on the receiver was really nothing more than a 
>dumb proxy), then there's no reason they couldn't. The idea 
>behind reflecting the NOTIFY_REQUEST is to get the ResvError 
>quickly to the person who really needs to see it - the sender 
>- because the person to whom it is addressed - the receiver - 
>cannot do anything with it except send it up.

JD:  But unless it is stipulated that if the sender places a Notify request in a Path message that it must be able to process a Notify that contains reservation failure information, then there is no guarantee that the sender will know what to do with it either.  

>
> > And are you not also implicitly defining  > that all 
>senders must be capable of receiving downstream Resv information?
>
>It is true that doing this requires the sender be able to 
>process all ResvError messages as well, which is functionality 
>over and above that required by RFC2205. However, this is not 
>_mandatory_, because the generation of a Notify message 
>containing the ResvError does not suppress the generation of 
>the ResvError itself, towards the receiver. The receiver proxy 
>should then turn around and generate a PathError towards the 
>sender, which the sender can then interpret. So, if the sender 
>was able to interpret the ResvError in the Notify message, he 
>received notification of the error condition sooner; but if he 
>just threw it away, he would still receive notification of the 
>error condition, just a little later. Of course, it is better 
>to deploy this extension with senders who can understand the 
>ResvError message, in order to speed up failure detection.

JD:  Since neither the sender nor the proxy receiver know the capabilities of each other, the utility of this optional procedure seems a little marginal.

>questions about Notify.  You have defined the behavior of a 
>proxy destination to be to reflect the Notify request from the 
>Path message into the Resv message so that the sender will 
>receive downstream Resv error information.
>> 
>defining the behavior of a non-proxy destination?  And are you 
>not also implictly defining that all senders must be capable 
>of receiving downstream Resv information?
>> 
>> I.e., it seems that you are implicitly defining the 
>operation of source and destination nodes wrt Notify in a 
>non-GMPLS context, and not just the operation of source and 
>destination proxies.
>> 
>> Thanks,
>> 
>> John
>> 
>http://tools.ietf.org/id/draft-ietf-tsvwg-rsvp-proxy-approaches-04.tx
>>> t http://tools.ietf.org/id/draft-ietf-tsvwg-rsvp-proxy-proto-05.txt
>>>
>---------------------------------------------------------------------
>>> - Multimedia Technologies, Ericsson Research EAB/TVM
>>>

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 16 May 2008 13:27:54 -0700

Francois,

I just sent an e-mail response to Ashok.  I think the optional procedure could be improved if the sender and the proxy receiver understood each other's capabilities.  If you don't want to consider that, my other suggestion would be to add a section, based upon Ashok's e-mail to me, on 'operational considerations'.

Thanks,

John  

>From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
>Sent: Friday, May 16, 2008 11:53 AM
>To: Ashok Narayanan; Drake, John E
>Cc: Francois Le Faucheur IMAP; tsvwg IETF list
>	- a sender may implement an optional behavior that 
>would help in case a receiver proxy is used and the proxy uses 
>the optional Notify mechanism. The sender does not have to 
>implement this.
>	- a similar concern has actually come up in the CCAMP 
>review and we tried clarify that point with text like :
>> questions about
>> Reflecting the NOTIFY from the Path message is an optional behaviour 
>> of the receiver proxy; not mandatory or default.
>>
>> defining the
>> No, I don't think so. The receiver proxy reflects the NOTIFY_REQUEST 
>> from the Path message into the Resv, *because* it generally doesn't 
>> know what to do with any ResvError short of sending it back to the 
>> sender. This qualification does not apply to a non-proxy 
>destination, 
>> therefore I don't believe that non-proxy destinations will 
>(or should) 
>> reflect the NOTIFY_REQUEST from the Path, back into the 
>Resv. However, 
>> if a particular end-to-end RSVP application in fact wanted to take 
>> advantage of this functionality (perhaps because their RSVP endpoint 
>> on the receiver was really nothing more than a dumb proxy), then 
>> there's no reason they couldn't. The idea behind reflecting the 
>> NOTIFY_REQUEST is to get the ResvError quickly to the person who 
>> really needs to see it - the sender - because the person to 
>whom it is 
>> addressed - the receiver - cannot do anything with it except send it 
>> up.
>>
>> > And are you not also implicitly defining that all senders must be 
>> > capable of receiving downstream Resv
>> information?
>>
>process all 
>> ResvError messages as well, which is functionality over and 
>above that 
>> required by RFC2205. However, this is not _mandatory_, because the 
>> generation of a Notify message containing the ResvError does not 
>> suppress the generation of the ResvError itself, towards the 
>receiver. 
>> The receiver proxy should then turn around and generate a PathError 
>> towards the sender, which the sender can then interpret. So, if the 
>> sender was able to interpret the ResvError in the Notify message, he 
>> received notification of the error condition sooner; but if he just 
>> threw it away, he would still receive notification of the error 
>> condition, just a little later. Of course, it is better to 
>deploy this 
>> extension with senders who can understand the ResvError message, in 
>> order to speed up failure detection.
>>
>> -Ashok
>>
>>
>> Drake, John E wrote:
>>> Francois,
>questions 
>>> about Notify.  You have defined the behavior of a proxy destination 
>>> to be to reflect the Notify request from the Path message into the 
>>> Resv message so that the sender will receive downstream Resv error 
>>> information.
>implicitly defining 
>>> the behavior of a non-proxy destination?  And are you not also 
>>> implictly defining that all senders must be capable of receiving 
>>> downstream Resv information?
>>> source and destination nodes wrt Notify in a non-GMPLS context, and 
>>> not just the operation of source and destination proxies.
>>> Thanks,
>>> John

---

From: "Loffredo Tullio" <[email-masked]>
Date: Tue, 20 May 2008 14:38:23 +0200

________________________________________
Dear all,
Telecom Italia believes that these documents are ready for publication.

Best regards,
Tullio Loffredo and Massimo Sassi

Telecom Italia,
Control Layer Innovation

________________________________________
From: Magnus Westerlund <[email-masked]>
Date: 14 May 2008 17:30:27 GMT+02:00
To: tsvwg <[email-masked]>
Subject: [Tsvwg] WG last call RSVP proxies documents draft-ietf-tsvwg-rsvp-proxy-approaches-04 and draft-ietf-tsvwg-rsvp-proxy-proto-05

This messages initiates a 2 week working group last call for "RSVP Extensions for Path-Triggered RSVP Receiver Proxy" to proposed standard and "RSVP Proxy Approaches" for informational status.

Cheers

Magnus Westerlund

--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 21 May 2008 15:29:26 +0200

John, Ashok, all

On 16 May 2008, at 22:27, Drake, John E wrote:

> Francois,
>
> I just sent an e-mail response to Ashok.  I think the optional  
> procedure could be improved if the sender and the proxy receiver  
> understood each other's capabilities.  If you don't want to  
> consider that, my other suggestion would be to add a section, based  
> upon Ashok's e-mail to me, on 'operational considerations'.

Below is the text I've drafted to this effect (to go into next rev  
that will be posted at the end of WG Last Call period). Let me know  
if you have further comments:

"
In environments where there are both RSVP-capable receivers and RSVP  
Receiver Proxies acting on behalf of non RSVP-capable receivers, a  
sender does not know whether a given reservation is established with  
an RSVP-capable receiver or with an RSVP Receiver Proxy. Thus, a  
sender that supports the procedures defined in this section may very  
well include a Notify Request object in Path messages for a  
reservation that happens to be controlled by an RSVP-capable  
receiver. This document does not define, nor expect, any change in  
existing receiver behavior. As a result, in this case, the sender  
will actually not receive Notify messages conveying downstream  
notifications. However, this is perfectly fine because the  
synchronisation between the RSVP reservation state and the  
application requirement can be performed by the actual receiver in  
this case as per the regular end-to-end RSVP model, so that in this  
case, the sender need not care about downstream notifications.

A sender that does not support the procedures defined in this section  
could happen to include a Notify Request object in Path messages for  
a reservation simply because it is interested in getting upstream  
notifications faster. If the reservation happens to be controlled by  
an RSVP Receiver Proxy supporting the procedures defined in this  
section, the sender will then also receive unexpected Notify messages  
containing downstream notifications. It is expected that such a  
sender will simply naturally drop such downstream notifications as  
invalid. Because it is RECOMMENDED above that the RSVP Receiver Proxy  
also issues sender notification via a PathErr message even when  
sender notification via Notify message is used, the sender will still  
be notified of reservation failure in accordance with the "sender  
notification via PathErr" method. In summary, activating the OPTIONAL  
"sender notification via Notify" method on a Receiver Proxy, does not  
prevent a sender that does not support this method, to rely on the  
MANDATORY "sender notification via PathErr" method. It would,  
however, allow a sender supporting the "sender notification via  
Notify" method to take advantage of this OPTIONAL method.
"

Thanks

Francois

>>>>> --
>>>>> --
>>>>> --

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 21 May 2008 09:53:53 -0700

Looks good 

>Sent: Wednesday, May 21, 2008 6:29 AM
>To: Drake, John E; Ashok Narayanan
>> understood each other's capabilities.  If you don't want to consider 
>> that, my other suggestion would be to add a section, based upon 
>> Ashok's e-mail to me, on 'operational considerations'.
>
>Below is the text I've drafted to this effect (to go into next 
>rev that will be posted at the end of WG Last Call period). 
>Let me know if you have further comments:
>
>"
>In environments where there are both RSVP-capable receivers 
>and RSVP Receiver Proxies acting on behalf of non RSVP-capable 
>receivers, a sender does not know whether a given reservation 
>is established with an RSVP-capable receiver or with an RSVP 
>Receiver Proxy. Thus, a sender that supports the procedures 
>defined in this section may very well include a Notify Request 
>object in Path messages for a reservation that happens to be 
>controlled by an RSVP-capable receiver. This document does not 
>define, nor expect, any change in existing receiver behavior. 
>As a result, in this case, the sender will actually not 
>receive Notify messages conveying downstream notifications. 
>However, this is perfectly fine because the synchronisation 
>between the RSVP reservation state and the application 
>requirement can be performed by the actual receiver in this 
>case as per the regular end-to-end RSVP model, so that in this 
>A sender that does not support the procedures defined in this 
>section could happen to include a Notify Request object in 
>Path messages for a reservation simply because it is 
>interested in getting upstream notifications faster. If the 
>reservation happens to be controlled by an RSVP Receiver Proxy 
>supporting the procedures defined in this section, the sender 
>will then also receive unexpected Notify messages containing 
>downstream notifications. It is expected that such a sender 
>will simply naturally drop such downstream notifications as 
>invalid. Because it is RECOMMENDED above that the RSVP 
>Receiver Proxy also issues sender notification via a PathErr 
>message even when sender notification via Notify message is 
>used, the sender will still be notified of reservation failure 
>in accordance with the "sender notification via PathErr" 
>method. In summary, activating the OPTIONAL "sender 
>notification via Notify" method on a Receiver Proxy, does not 
>prevent a sender that does not support this method, to rely on 
>the MANDATORY "sender notification via PathErr" method. It 
>would, however, allow a sender supporting the "sender 
>notification via Notify" method to take advantage of this 
>OPTIONAL method.
>"
>
>Thanks
>
>Francois
>
>
>
>>
>> Thanks,
>>
>> John
>>
>would help in 
>review and we 
>behaviour 
>NOTIFY_REQUEST

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 30 May 2008 12:42:57 -0300

Magnus and all,

I have just posted a new version of proxy-proto  (draft-ietf-tsvwg- 
rsvp-proxy-proto-06.txt) that addresses the change requested during  
the WG Last Call (as agreed on the list).

I the two companion rsvp-proxy documents are now good to go.

Thanks

Francois

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 May 2008 19:41:04 +0200

Francois Le Faucheur IMAP skrev:
> Magnus and all,
> 
> I have just posted a new version of proxy-proto  
> (draft-ietf-tsvwg-rsvp-proxy-proto-06.txt) that addresses the change 
> requested during the WG Last Call (as agreed on the list).
> 

Okay, I will do publication request to my self. It will unfortunately 
take a few weeks before the AD review will have finished for this document.

Cheers

Magnus Westerlund