This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

-- Document --

  PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with
                              Stateful PCE
              draft-ietf-pce-stateful-pce-auto-bandwidth-10

Reviewer: David Black (david.black@dell.com)

This draft describes a stateful bandwidth auto-adjustment protocol for PCE
(Path Computation Element) bandwidth adjustment of LSPs (Label Switched Paths).

From a Transport perspective, an important concern is how this bandwidth
auto-adjustment interacts with transport protocol reaction to network
conditions. These two phenomena should occur on vastly different timescales,
so that any transport protocol reactions to a bandwidth adjustment have
settled out before bandwidth samples are taken for the next bandwidth
adjustment.  If the transport protocol reactions and bandwidth adjustments
occur on similar timescales, undesirable interactions (e.g., oscillation)
become possible.  Such undesirable interactions need to be avoided.

The design center of this draft avoids these undesirable interactions, as
the default sample interval of 5 minutes is much longer than the RTT-based
(RTT = Round Trip Time) reaction times of transport protocols.  However,
RTT is not the relevant metric here, e.g., as the initial BBR congestion
control algorithm specified a probe of network conditions every 10 seconds.
5 minutes (more than an order of magnitude larger than 10 seconds) is still
a reasonable sample interval, but in the extreme, the bandwidth auto-
adjustment protocol in this draft is capable of sampling network bandwidth
and reacting to it every second, which could cause undesirable interactions
with transport protocols (e.g., that employ BBR with a 10 second probe
interval).  The sample interval is of primary concern here, as the protocol
adjusts bandwidth based on a single sample, namely the largest bandwidth
observed in the adjustment interval.

This reviewer expects that network operators would not configure such
extreme parameters, and hence believes that the draft contains some unstated
assumptions and/or recommendations about reasonable vs. unreasonable parameter
settings. Those assumptions ought to be stated, e.g., sample interval
SHOULD NOT be less than 1 minute.  There's nothing special about 1 minute -
it's an easy-to-express amount of time that appears to suffice to avoid
potential interactions with transport protocols - the draft authors are
strongly encouraged to propose alternative values and/or text to address
this concern.