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

From: Lou Berger <[email-masked]>
Date: Fri, 30 Mar 2007 15:47:02 -0400

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