Subject: Comments on draft-ietf-rsvp-proxy-00.txt

From: "Brian Williams (EPA)" <[email-masked]>
Date: Fri, 31 Mar 2000 21:10:38 +1000

The RSVP receiver proxy draft appears to cover the null service case quite
reasonably. 

However, I would also like to see the receiver proxy cover another case
also. On page 4 of the draft, there are two diagrams shown: case A for
normal RSVP processing, and case B for RSVP receiver proxy.

My question is what happens for the situation where the host H1 initiates an
RSVP session but the host H2 does not support RSVP. If the RSVP was proxied
at R1, the RSVP session could be mapped to DS which would provide some QoS
for the data stream to the host H2. However, you do not know at that stage
whether host H2 supports RSVP or not.

Here, the decision to proxy at R1 cannot be a simple policy decision that
can be made when the PATH is received at R1 as it depends on whether host H2
is RSVP capable or not. If H2 is RSVP capable, then you may not
install/retain the RSVP proxy at R1. However, if host H2 is not RSVP capable
(does not respond to PATH message), then it would be beneficial to install
the proxy at R1 as shown in this draft.

I believe it would be beneficial to consider this case also in the draft,
since it is another situation that would lead to case B.
/brian