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.