Subject: [Tsvwg] Re: some comments on draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 5 Apr 2007 10:56:40 +0200

Hello Lou,

I agree with all your points.

To reflect those in the next rev, I would propose that:
	* we use your diagram below instead of the current diagrams in 4.5  
(ie show "App Signaling entity" instead of "SIP/SBE" + formalize the  
Proxy control interface)
	* we describe the case where the "App entity" is colocated with the  
"RSVP Proxy" (what was illustrated  in Figure 9) only as a  
"particular case" of the more general case. Today we first talk about  
the particular case and then describe the more general case.
	* we add some words about the App Sig<-->RSVP-Proxy interface and  
what example protocols could be used (as you do below) and state  
definition of that interface is outside the scope of this document.  
(we could progress this separately though).
	* we move back into 4.5 the case currently described in 4.6 and  
describe it as another particular case of the more general case where  
the "App-Sig<-->RSVP-Proxy" interface happens to be "RSVP over GRE"

Does that work?
If yes, i'll try draft some text for review.

Thanks

Francois

On 30 Mar 2007, at 21:47, Lou Berger wrote:

> Francois, Jukka, Dan, Allan,
>
> I think there is an additional scenario that you probably intend to  
> allow, but isn't explicitly covered in the document.  The scenario  
> is similar to what is presented in section  4.4, 4.5, and 4.6 but  
> differs in a few of the specifics. I think the scenario could be  
> integrated into the existing sections or added as it's own.
>
> The scenario can be represented by the following:
>
>
>                     |-------------|      |-------------|
>                     | Application |      | Application |
>                 ____| Signaling   |______| Signaling   |__
>                /    | Entity      |      | Entity      |  \
>               /     |-------------|      |-------------|   \
>              /        //                       \\           \
>             /        //                         \\           \
>            /        //                           \\           \
>           /        //                             \\           \
>          /        //                               \\           \
>         /        //                                 \\           \
>        /    |--------|                         |--------|         \
>   |----|    | RSVP   |   ***    ***     ***    | RSVP   |         
> |----|
>   | S  |----| Sender |---*r*----*r*-----*r*----|Receiver|--------|  
> R  |
>   |----|    | Proxy  |   ***    ***     ***    | Proxy  |         
> |----|
>             |--------|                         |--------|
>
>
>      ****************************************************************>
>
>                       =========RSVP============>
>
>
>   |----|                  |----|               ***
>   | S  | Sender           | R  | Receiver      *r* regular RSVP
>   |----|                  |----|               *** router
>
>   <***> media flow
>
>   ==>  segment of flow path protected by RSVP reservation
>        in forward direction
>
>   /    Application level signaling
>
>   //   RSVP proxy control signaling
>
>
> The differences are small from the existing scenarios, but they are:
>
> 1) The scenario isn't SIP specific (diff from Section 4.4)
> 2) Formalizes the separation of application layer entities and RSVP  
> signaling entities (diff from section 4.5 and 4.6)
> 3) Highlights separation of sender proxy control and receiver proxy  
> control (as is already shown in figure 9, but not in the same  
> combination)
>
> I think point 2 is really the most interesting.  The separation is  
> represented in the above figure as "RSVP proxy control signaling".   
> I really consider this type of control signalling as a type of  
> policy control (or management) interface.  That said, I'm agnostic  
> on the protocol to use to support this interface.  It could be  
> Fred's old RSVP MIB, COPS-PR, QPIM (rfc3644), XML+??? or anything  
> else for that matter.
>
> I look forward to your response.
>
> Lou
>
> PS In the second draft, draft-ietf-tsvwg-rsvp-proxy-proto, you might
> consider allowing use of the Path_State_Removed flag [RFC3473].

---

From: "Lou Berger" <[email-masked]>
Date: Thu, 5 Apr 2007 11:34:03 +0000

Francois,

Sounds like a reasonable plan. I look forward to see the next rev. 

Btw While the App Sig<-->RSVP-Proxy interface is out of scope for this document, I think it's still worth pursuing.

Much thanks,
Lou

-----Original Message-----
From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 5 Apr 2007 10:56:40 
To:Lou Berger <[email-masked]>
Cc:Francois Le Faucheur IMAP <[email-masked]>, [email-masked],       [email-masked], [email-masked], [email-masked]
Subject: Re: some comments on draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt

Hello Lou,

Does that work?

Thanks

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 10 Apr 2007 16:43:18 +0200

Hi Lou,

> consider allowing use of the Path_State_Removed flag [RFC3473].

Yes, good idea, the Path_State_Removed flag (PSR) could be used to  
expedite the release of resources/states (at least in some cases).

The one potential concern we have is in environments involving "old"  
RSVP routers which do not understand the PSR flag.
For example assume we have :
Sender--->R1--->R2--->Receiver_Proxy--->Receiver
where:
	- R1 is PSR-capable
	- R2 is not PSR-capable. R2 passes the PathErr upstream without  
resetting the PSR flag to zero and yet does not remove its Path state.
In that case, the Path state will be removed on Receiver-Proxy and on  
R1 , but will remain on R2. Furthermore, even if the Sender was to  
send a PathTear, this would not make it to R2 because R1 has already  
cleared the Path state.
The bottom line, is that in that heterogeneous case, the state  
removal is slower than without using PSR (we have to wait until Path  
times out on R2).

So, to be on the safe side, our proposal would be that :
	* by default, the PSR flag is not used (eg by default PSR flag not  
set by Receiver Proxy)
	* optionally, via a config knob, the RSVP Receiver Proxy behavior  
can be changed to set the PSR flag. This would be used in controlled  
environments (eg within a single Triple Play operator domain) where  
operator is sure that all routers are PSR-capable. In this case, the  
state removal is accelerated because the PathErr message directly  
tear downs Path state (and consequently Resv state) and Sender need  
not even send a PathTear.

Does that sound reasonable.

Francois

---

From: Lou Berger <[email-masked]>
Date: Tue, 10 Apr 2007 23:26:39 -0400

Francois,
         Yes, this sounds reasonable.

Lou