Subject: Fwd: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-01.txt

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 6 Jul 2007 16:03:59 +0200

Hello,

This updated version of rsvp-proxy-proto addresses all the comments  
received to date including:
	* outcome of the list discussion with John Drake: added new section  
"3.1.4 Use of PathErr by Regular Receivers
	* outcome of discussion with Lou Berger: added new section "3.1.3  
Use of Path_State_Removed Flag"
	* as announced/discussed on the list: description of a an new  
optional method for sender notification based on NOTIFY: added new  
section "3.2 Sender Notification via Notify Message"

This version also includes the following additional changes:
	* wrote full-blown Security Considerations
	* Completed the IANA considerations section.
	* added specification for Error Value (for "Unrecoverable Receiver  
Proxy Error" Error Code)
	* added text on handling of InPlace" flag

So, from the authors viewpoint, the document is now pretty much ready.

We welcome feedback before we propose to move this document further  
in teh process.

Cheers

Francois

Begin forwarded message:

> From: [email-masked]
> Date: 28 June 2007 21:50:02 GMT+02:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Area Working Group  
> Working Group of the IETF.
>
> 	Title		: RSVP Extensions for Path-Triggered RSVP Receiver Proxy
> 	Author(s)	: F. Le Faucheur, et al.
> 	Filename	: draft-ietf-tsvwg-rsvp-proxy-proto-01.txt
> 	Pages		: 25
> 	Date		: 2007-6-28
> 	
> RSVP signaling can be used to make end-to-end resource reservations
>    in an IP network in order to guarantee the QoS required by certain
>    flows.  With conventional RSVP, both the data sender and  
> receiver of
>    a given flow take part in RSVP signaling.  Yet, there are many use
>    cases where resource reservation is required, but the receiver, the
>    sender, or both, is not RSVP-capable.  Where the receiver is not
>    RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
>    thereby performing RSVP signaling on behalf of the receiver.  This
>    allows resource reservations to be established on the segment of  
> the
>    end-to-end path from the sender to the RSVP Receiver Proxy.   
> However,
>    as discussed in the companion document presenting RSVP Proxy
>    approaches, RSVP extensions are needed to facilitate operations  
> with
>    an RSVP Receiver Proxy whose signaling is triggered by receipt of
>    RSVP Path messages from the sender.  This document specifies these
>    extensions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy- 
> proto-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-tsvwg-rsvp-proxy-proto-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>

---

From: ken carlberg <[email-masked]>
Date: Mon, 9 Jul 2007 10:26:46 -0400

Francois,

the draft is quite nice.  Most of the comments below are suggestions  
for added clarity.  A number of these are nits, so feel free to  
discard or modify those as you see fit.

1) It may be helpful to move the Terminology section up so that it is  
directly under the first paragraph of section 1.  In section 2, you  
start off with terminology specific to this draft (eg, "RSVP receiver  
Proxy"), and then later describe what it is in the Terminology  
section below.

You should also add a description of what is a "regular receiver" in  
the Terminology section, and to state that it refers to an RSVP  
capable end-host in the classic end-to-end model.

It may also be helpful to state as early as possible, either in the  
Introduction or in the Terminology section, that for this document  
the Sender always refers to the RSVP capable node that originates  
Path messages.  And that the receiver always refers to the RSVP  
capable node that originates RESV messages and is a proxy.  My  
confusion on this matter came up in the first sentence of page 5,  
when you state "...some notifications about reservation state (...)  
are only sent to the receiver".  I presume you mean the RSVP proxy  
receiver, as opposed to the destination end host that may also be an  
RSVP capable receiver.

2) just a nit, but I would feel more comfortable using the term  
"intermediary" instead of "slave" in the third paragraph of page 4.

3) nit.  Section 3, first paragraph, change "of the sender" to "to  
the sender"

4) Page 9, 1'st paragraph.  Could you add a sentence or two stating  
what are the benefits of ensuring that the sender gets a prompt  
failure notification?

I may also be reading the following two paragraphs of that page  
incorrectly, but if an implementation MUST support the method of 3.1,  
why would I add support for 3.2?  Is it rather a case of MUST support  
3.1  *or*  3.2, with the latter being more efficient but requiring  
support of rfc-3473?  Or am I using poor terminology and should the  
text say something like, "must support the method of 3.1, and  
optionally 3.2, but may deploy/use either method"?

5) Finally, this may be a nit, but it might be helpful to add a  
Considerations section at the end of the document that mentions the  
possible scenario of proxy reservations being established and yet the  
end-host destination being unreachable/non-existent?  Proxy RSVP  
routers will know if the downstream leaf router is reachable, but  
they won't necessarily know if the last hop to the end host is  
reachable.  And since the proxy segment may be part of an asymmetric  
path, one can't rely on upstream data to give a hint to the proxy  
receiver that the destination is up.

I don't think this is major liability, but just something that needs  
to be mentioned to those that choose to deploy this work.

-ken

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 16 Jul 2007 17:45:21 +0200

Hello Ken,

Thanks for your thorough review of the rsvp-proxy-proto. Please see  
below:

On 9 Jul 2007, at 16:26, ken carlberg wrote:

> the draft is quite nice.

great.

> Most of the comments below are suggestions for added clarity.  A  
> number of these are nits, so feel free to discard or modify those  
> as you see fit.
>
> 1) It may be helpful to move the Terminology section up so that it  
> is directly under the first paragraph of section 1.  In section 2,  
> you start off with terminology specific to this draft (eg, "RSVP  
> receiver Proxy"), and then later describe what it is in the  
> Terminology section below.

The Introduction section defines the terms that it uses already  
("Sender Proxy" and "Receiver Proxy"). The idea of the terminology  
section was to have a handy place to go back for the reader to check  
all the terms. So a standalone section seems reasonable to me.
We should probably state that this terminology is borrowed from proxy- 
approaches.

> You should also add a description of what is a "regular receiver"  
> in the Terminology section, and to state that it refers to an RSVP  

Agreed.

> receiver, as opposed to the destination end host that may also be  
> an RSVP capable receiver.

The idea is that:
	* the sender = the sender of data flow
	* the receiver = the receiver of data flow.
If you see places where sender/receiver is not used with this  
meaning, let us know and we want to address this.

In the case of interest for this draft, the assumed model was that  
the sender was RSVP-capable (so it can do the synchronisation betwen  
RSVP and application). So the draft was written with this model in  
mind. However, it is applicable to scenarios where the sender is not  
RSVP capable and instead there is a RSVP Sender Proxy (that is  
synchrnised with application). So I think we should go through the  
doc and make sure the text covers both cases.

For example, we may want to replace:
" Since the synchronisation between RSVP reservation and application  
requirement is now effectively performed by the sender, it is  
important that the sender is aware of the reservation state.
"
by
"
Since the synchronisation between RSVP reservation and application  
requirement is now effectively performed by the sender (or through an  
RSVP Sender Proxy), it is important that the sender (or RSVP Sender  
Proxy) is aware of the reservation state.
"

To avoid the confusion you mention above, we could also replace "are  
only sent to the receiver" by "are only sent towards the receiver".

How does that sound?

> "intermediary" instead of "slave" in the third paragraph of page 4.

fine.

> 3) nit.  Section 3, first paragraph, change "of the sender" to "to  

or perhaps "notification of the sender (or RSVP Sender Proxy) about  
reservation failure".

> what are the benefits of ensuring that the sender gets a prompt  

yes. This includes ability to provide faster corresponding enduser  
notification at application layer (eg busy signal, application-level- 
rerouting) as well as faster release of application-level resources.

> incorrectly, but if an implementation MUST support the method of  
> 3.1, why would I add support for 3.2?  Is it rather a case of MUST  
> support 3.1  *or*  3.2, with the latter being more efficient but  
> requiring support of rfc-3473?  Or am I using poor terminology and  
> should the text say something like, "must support the method of  
> 3.1, and optionally 3.2, but may deploy/use either method"?

What is intended is a "router" must implement 3.1 and may also  
optionally implement 3.2. This is because we propose to have at least  
a common denominator on all routers claiming support of this document  
(ie 3.1). This is needed to guarantee interoperability.
Within a given deployment environment, the operator can choose what  
he/she wants (ie use 3.1 or 3.2 or both if they so desire).

So how about we :
	* replace "an implementation MUST" by "a router implementation MUST"
	* adding a sentence to the effect that the network operator is free  
to deploy 3.1 or 3.2 or both in a given environment.

> possible scenario of proxy reservations being established and yet  
> the end-host destination being unreachable/non-existent?  Proxy  
> RSVP routers will know if the downstream leaf router is reachable,  
> but they won't necessarily know if the last hop to the end host is  
> reachable.  And since the proxy segment may be part of an  
> asymmetric path, one can't rely on upstream data to give a hint to  
> the proxy receiver that the destination is up.
>
> I don't think this is major liability, but just something that  
> needs to be mentioned to those that choose to deploy this work.

I would say this consideration is not specific to the particular type  
of RSVP Proxy discussed in this document, but actually applicable to  
most RSVP Proxy scenario/approaches. So I would suggest we bring this  
point in the rsvp-proxy-approaches document.

As you say, generally in practice I don't expect this is to be a  
major concern since application level-signaling would take place with  
the sender/receiver before RSVP reservations are established, so that  
if either is unreachable, application signaling will be affected  
first. But it is conceivable that receiver is reachable from  
application server and not reachable from sender. So we may as well  
bring up that point (in proxy-approaches).

Thanks

FRancois

---

From: ken carlberg <[email-masked]>
Date: Tue, 17 Jul 2007 14:41:45 -0400

Francois,

>> It may also be helpful to state as early as possible, either in  
>> the Introduction or in the Terminology section, that for this  
>> document the Sender always refers to the RSVP capable node that  
>> originates Path messages.  And that the receiver always refers to  
>> the RSVP capable node that originates RESV messages and is a  
>> proxy.  My confusion on this matter came up in the first sentence  
>> of page 5, when you state "...some notifications about reservation  
>> state (...) are only sent to the receiver".  I presume you mean  
>> the RSVP proxy receiver, as opposed to the destination end host  
>> that may also be an RSVP capable receiver.
>
> The idea is that:
> the sender was RSVP-capable (so it can do the synchronisation  
> betwen RSVP and application). So the draft was written with this  
> model in mind. However, it is applicable to scenarios where the  
> sender is not RSVP capable and instead there is a RSVP Sender Proxy  
> (that is synchrnised with application). So I think we should go  
> through the doc and make sure the text covers both cases.

That would be helpful.  And just to close the point I made above, you  
could clear up any ambiguity by saying something like: "...some  
notifications about reservation state (...) are only sent towards the  
receiver and terminated by the on-path proxy receiver".  Its that  
last part that I felt needed clarity.

> " Since the synchronisation between RSVP reservation and  
> application requirement is now effectively performed by the sender,  
> it is important that the sender is aware of the reservation state.
> "
> by
> "
> requirement is now effectively performed by the sender (or through  
> an RSVP Sender Proxy), it is important that the sender (or RSVP  
> Sender Proxy) is aware of the reservation state.
> "
>
> To avoid the confusion you mention above, we could also replace  
> "are only sent to the receiver" by "are only sent towards the  
> receiver".
>
> How does that sound?

fine

fine.

> optionally implement 3.2. This is because we propose to have at  
> least a common denominator on all routers claiming support of this  
> document (ie 3.1). This is needed to guarantee interoperability.
> 	* adding a sentence to the effect that the network operator is  
> free to deploy 3.1 or 3.2 or both in a given environment.

fine.  I probably should have been more clear in my original comment  
and advocated the use and distinction of implementation and deployment.

cheers,

-ken