Subject: [Tsvwg] draft-ietf-tsvwg-rsvp-proxy-proto-approaches

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 1 Aug 2007 12:01:04 +0200

Hi Ken,

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

Below is the text I drafted to address your comment about un- 
reachability scenarios. It is intended to go into a new section  
(4.9). Let us know if you have any comments.
Thanks

Francois

4.9.  Reachability Considerations

    There may be situations where the RSVP Receiver Proxy is  
reachable by
    the sender, while the receiver itself is not.  In such  
situations, it
    is possible that the RSVP Receiver Proxy is not always aware that  
the
    receiver is unreachable, and consequently may accept to establish an
    RSVP reservation on behalf of that receiver.  This would result in
    unnecessary reservation establishment and unnecessary network
    resource consumption.

    This is not considered a significant practical concern for a number
    of reasons.  First, in many cases, if the receiver is not reachable
    from the sender, it will not be reachable either for application
    signaling so that application level session establishment will  
not be
    possible in the first place.  Secondly, where the receiver is
    unreachable from the sender but is reachable for application level
    signaling (say because session establishment is performed through an
    off-path SIP agent that uses a different logical topology to
    communicate with the receiver), then the sender may detect that the
    receiver is unreachable before attempting reservation establishment.
    This may be achieved through mechanisms such as ICE's connectivity
    check ( [I-D.ietf-mmusic-ice]).  Finally, even if the sender does  
not
    detect that the receiver is unreachable before triggering the RSVP
    reservation establishment, it is very likely that the application
    will quickly realise this lack of connectivity (e.g. the human
    accepting the phone call on the receiver side will not hear the
    human's voice on the sender side) and therefore tear down the  
session
    (e.g. hang up the phone) which in turn will trigger RSVP reservation
    release.

    Nonetheless, it is recommended that network administrators consider
    the above in light of their particular environment when deploying
    RSVP Proxys.

    The mirror considerations apply for situations involving an RSVP
    Sender Proxy and where the sender cannot reach the destination while
    the RSVP Sender Proxy can.

> Thanks
> FRancois
>> -ken

---

From: ken carlberg <[email-masked]>
Date: Thu, 2 Aug 2007 09:49:25 -0400

Francois,

the new section you propose below looks fine by me.

cheers,

-ken

On Aug 1, 2007, at 6:01 AM, Francois Le Faucheur IMAP wrote:

>>> 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.
>>>
>> from application server and not reachable from sender. So we may  
>> as well bring up that point (in proxy-approaches).
>
>    is possible that the RSVP Receiver Proxy is not always aware  
> that the
>    check ( [I-D.ietf-mmusic-ice]).  Finally, even if the sender  
> does not