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

From: Andrew Smith <[email-masked]>
Date: Wed, 29 Mar 2000 22:58:42 -0800

Some comments re the WG last call on the above draft - apologies for being
so close to the deadline but it's been a busy week.

1. This work is not yet ready for RFC publication as WG output.

2. Scope: there is no reason to tie RSVP proxy to NULL service; no reason to
tie it to DiffServ/DSCPs: instead, should use generic examples of wanting to
replace or add RSVP objects. No reason to include discussion of SBM here. No
reason to tie the mechanism to outsourced policy management: this should be
described as a general mechanism for RSVP.

3. Subflows? what is this all about?

4. The draft talks about "generation of the Resv message": are we talking
about individual messages or installation of state here? I always thought
that RSVP messages were just a mechanism to install/refresh/delete state in
intermediate and terminal nodes. I think this draft uses the wrong model for
what is being done here.

5. Section 3: the discussion of where along the path to locate the proxy
function does not give much help. I think this discussion is outside the
scope (yes, it is a policy or configuration issue).

6. Section 3.1: There is no need to specify all those details of RSVP
message syntax and rules: the behaviour of what goes in a RESV message is
already defined by RFC2205.

7. Section 3.2: what is special about SBMs? yes, you have to have the proxy
at the right point along the path: same issue exists with pure RSVP.

8. Section 5: should not be making any changes to RSVP recommendations here.

9. Section 6: IPR - still waiting to see these claims: I do not think it is
appropriate to forward this as an RFC with this still pending.

Andrew Smith

---

From: "Nitsan Elfassy" <[email-masked]>
Date: Thu, 30 Mar 2000 13:49:24 +0200

Andrew,

See inline: (I have answered those parts which I know all co-authors are in
full consensus.)
> described as a general mechanism for RSVP.

We all agree with you, I guess. Usage of Proxy action to NULL service was
(or meant to) brought as an example.

> 3. Subflows? what is this all about?

I would remove that issue, unless my co-authors disagree (??).

> intermediate and terminal nodes. I think this draft uses the

The wording may not be clear enough about it but we certainly refer to Resv
State installation, which requires that the router should behave accordingly
(i.e. send refresh messages, keep the state information).

Let me add some history.
When Silvano presented draft-ietf-rsvp-proxy-00.txt to the RSVP WG in
Washington, three questions were asked:
1. Does Proxy breaks or adds a new behavior to RSVP ?
2. If Proxy then why only Resv ? What about Proxying Path messages ?
3. Does anyone fines RSVP Proxy useful ?

The answers that were given:
1. Bob B. and Lixia X. both concluded that Proxy RSVP does not require any
addition to the RSVP protocol RFC. However, they did agree that there is a
need for an informational document that will shed a light on RSVP Proxy
possible usage.

2. On that same meeting we all agreed that the Proxy model should apply not
only to Resv but also to Path message.
Maybe it should have been better reflected.
Anyway, it is not only about answering a Path message.

3. Benny R. from Lucent and Diana from MCI backed up the Cisco co-authors
proposed usage and pointed out Resv Proxy as very useful. Both emphasized it
should be used for ALL RSVP services.

> scope (yes, it is a policy or configuration issue).

Yes it is a policy/configuration issue, but since this document meant to
shed a light on the possible usage, a clarification would remove any doubt.

> message syntax and rules: the behavior of what goes in a
> RESV message is
Agreed.

> appropriate to forward this as an RFC with this still pending.

thanks,

Nitsan