[Tsvwg] Suggestions about draft-polk-tsvwg-rsvp-bw-reduction

James, Subha,

Just had another look at draft-polk-tsvwg-rsvp-bw-reduction and have a
couple of suggestions.

1) Non-dependency on Preemption Policy_Data
============================================
While use of preemption makes the need for bandwidth reduction
mechanisms more obvious, those mechanisms may also be useful in
environments where preemption is NOT used at all.

So I am assuming that the objective is to specify mechanisms which can
be used whether flows whose bandwidth is to be reduced happen to use
Preemption Policy_Data or not. Agreed?

I believe the mechanisms you have specified could be made to work when
preemption is not used but I am not clear as to whether this is
currently the case or not. For example, current text says:
"   When a reservation is partially failed, a ResvErr  (Reservation
   Error) message is generated just as it is done currently with
   preemptions.  The error spec object and the preemption pri policy
   object are included as well.  Very few additions/changes are needed
"
Do you agree that the "Preemption Policy Data" object does not need to
always be there?
In particular, if the flow whose bandwidth is reduced does not have a
Preemption associated with it, then the ResvErr would Not contain a
Preemption Policy Object?

In the same vein, current text says:
"
  This document is intended to be classified as an 'update' to RFC
   3181 [3] if published as an RFC.
"
Perhaps, we may be better off to think of this work as extensions to
2205 rather than to 3181. It should be possible to achieve bandwidth
reduction whether 3181 Policy_Data objects are used or not used. 3181
preemption is just one of the multiple elements that may be taken into
account in the policy which determines which flow to reduce bandwidth
from.

2) Backwards Compatibility
===========================
It would probably be useful to discuss backwards compatibility in
environments where some endsystems or routers do support these
extensions while some don't.
In particular, it may be worth clarifying how the system always
reconverges considering :
        -1) that ResvTear is NOT sent
        -2) some devices may understand new ResvErr and do partial
preemption, while others won't understand and will do full reservation
tear-down.

Cheers

Francois

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg