A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
draft-ietf-tsvwg-rsvp-bw-reduction-02

[Ballot discuss]
I've put a Discuss on because the answer I gave to IANA turned out
to be wrong, and sorting it out turns out to require understanding
COPS at the turn of the century.  The question is whether the RFC 2750
error values, which are added to by this document, were registered
(seems not).  It seems we should register them now.  Will resolve this
quickly.

[Ballot discuss]
I've put a Discuss on because the answer I gave to IANA turned out
to be wrong, and sorting it out turns out to require understanding
COPS at the turn of the century.

[Ballot comment]
At the end of section 1, it states:
  This document is intended to be classified as an 'update' to RFC
  2205 [1], as this mechanism affects the behaviors of the ResvErr and
  ResvTear indications defined in that document.
And I think it would be good to state that in the abstract as well.

IANA Comments:
Upon approval of this document the IANA will assign an error code for the following:
      ErrSubCode = X (ERR_PARTIAL_PREEMPT)
In which registry should this error code be placed?

AD Review comments for the rev as well:

Security Considerations
  This document does not lessen the overall security of RSVP or of
  reservation flows through an aggregate.

It does allow the possibility of an attacker reducing the bandwidth
of an aggregate one or more times, which can cause preemptions
or other denials of service.  You should describe this risk.
Is there any remedy?


Also, editorial, but important:

  in this rev you should remove section 1.2.

  Throughout:  s/IPsec/IPSec

  This sentence needs fixing in several regards:
  The nodes initiating the IPsec flow can be an end-
  system like a computer, or it can router between two end-systems, or
  it can be an in-line bulk encryption device immediately adjacent to
  a router interface, [11] directly addresses this later scenario.

James is doing a rev in time for going on the IESG agenda as we
aren't seeing other LC discussion, and these comments will improve
the review.

Response to GEN-ART LC comment by Joel Halpern (comment is published
at:

http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06014.html


>If the document does need to be revised
>a) The suggested added paragraph would very nicely address my concern.
>b) I appreciate the willingness to repair the nits.
>
>Thank you,
>Joel M. Halpern
>
>At 01:57 PM 1/23/2006, James M. Polk wrote:
> >If you want, I can add a comment something like this:
> >
> >"Bandwidth SHOULD NOT be reduced across multiple reservations at the same
> >time, in reaction to the same reduction event.  A router not knowing the
> >impact of reservation bandwidth reduction on more than one flow may cause
> >more wide spread ill effects than is necessary."
> >
> >I think this leaves room for a future RSVP extension to "update" this
> >document with how this can be done successfully.
> >
> >Thus, instead of disrupting one flow, two flows will be hurt for a
> >time.
> >I am not sure that is actually what this does.
> >Even if I am correct, that is not a reason to refrain from publishing
> >this.  However, it would suggest a note of caution.
> >
> >Nit:  In the example in section 3, it is confusing to use Flow A, Flow B
> >and Aggregate A (Of Flows 1-5) and Aggregate B (Of flows A-E).  Couldn't
> >the aggregates be X and Y (or I and J, or...)
> >
> >I could make this change as well, probably to Aggregates X and Y.
> >
> >Nit: In the example description in section 3.1, it would be helpful if the
> >description of the 880k "offered" said "offered load".  I was confused and
> >thought it might mean offered capacity which would be completely backwards.
> >
> >fair change request