Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-auto-bandwidth-11: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, Sep 25, 2019 at 01:56:46PM +0530, Dhruv Dhody wrote:
> Hi Ben,
> 
> Thanks for the discussion.
> 
> Snipping to open points..
> 
> > > >
> > > > As a general note, I'm not sure the phrase "calculated bandwidth to be
> > > > adjusted" is a great fit for how it's currently being used.
> > > > Specifically, the "calculation" in question seems to just be taking the
> > > > maximum of a sliding window of per-timeslice average bandwidth values,
> > > > and this seems like a sufficiently small amount of computation that I'd
> > > > be comfortable describing it as a "measurement", for "measured bandwidth
> > > > as input to path calculation".  That is, this doesn't seem like it comes
> > > > close to the amount of computation involved in actually computing paths,
> > > > so I keep misreading what information is being sent where.
> > > >
> > >
> > > In an earlier version there was a feature where the PCC could report
> > > the measured value at each sample interval (it moved to another
> > > document). IMHO for the clarity in the WG, it is still better to
> > > differentiate between the raw measured value (telemetry) and the value
> > > that is currently reported which is marked as "calculated".
> >
> > Ah, in that context it makes more sense to do it this way.  Perhaps an
> > informative reference to the other document/usage and note about the
> > terminology would help, though?
> >
> 
> I have added - "Another approach would be to send the measured values
> itself to the PCE, which is considered out of scope for this
> document.". In terminology I highlighted 'measured' and 'calculated'
> in the existing terms.

Great, that should be enough to get the reader started for the specific
meanings.

> > > > Section 1
> > > >
> > > >    Over time, based on the varying traffic pattern, an LSP established
> > > >    with a certain bandwidth may require to adjust the bandwidth reserved
> > > >    in the network dynamically.  The head-end Label Switch Router (LSR)
> > > >    monitors the actual bandwidth demand of the established LSP and
> > > >    periodically computes new bandwidth.  The head-end LSR adjusts the
> > > >    bandwidth reservation of the LSP based on the computed bandwidth
> > > >    automatically.  This feature is commonly referred to as Auto-
> > > >    Bandwidth.  The Auto-Bandwidth feature is described in detail in
> > > >    Section 4 of this document.
> > > >
> > > > >From just this text, I can't tell if this is describing the mechanisms of
> > > > this document or an existing Auto-Bandwidth feature that is related to
> > > > the mechanisms of this document.
> > > >
> > >
> > > The auto-bandwidth feature without PCE exists, where the ingress does
> > > the measurement as well as path computation. This feature has been
> > > implemented long back but was not part of any standard because it was
> > > a local implementation at the ingress node and no protocol changes was
> > > required. With the PCE things changed and here we are...
> >
> > Ah, I see.  Maybe "This feature, when available in the head-end LSR
> > implementation, is common referred to as [...]", then?
> >
> 
> Updated.
> 
> 
> > > > Section 2.3
> > > >
> > > > Are we assuming any relationship between the Up-Adjustment-Threshold and
> > > > the Overflow-Threshold?
> > > >
> > >
> > > Yes, as mentioned here while describing Overflow-Threshold -
> > >
> > >       The LSP bandwidth is adjusted to the
> > >       current bandwidth demand bypassing the Up-Adjustment-Interval if
> > >       the overflow condition is met consecutively for the Overflow-
> > >       Count.
> >
> > I was thinking more along the lines of if the Overflow-Threshold value was
> > going to be a larger number than the Up-Adjustment-Threshold.
> >
> 
> Yes, I have added this in terminology section.
> Also added a note for operator to take care while setting this in section 6.1.
> 
> I prefer to keep this generic as there are multiple combinations of
> formats to deal with.

Understood.

The updates all look good; thanks!

-Ben

> > >
> > > >       traffic demand.  If the percentage or absolute difference between
> > > >       the current MaxAvgBw and the current bandwidth reservation of the
> > > >       LSP is greater than or equal to the threshold value, the overflow
> > > >       condition is set to be met.  The LSP bandwidth is adjusted to the
> > > >
> > > > nit: I think s/set to be met/said to be met/ ?  (this appears twice)
> > > >
> > >
> > > Ack
> > >
> > > >    Minimum-Threshold:  The increase or decrease of the LSP bandwidth
> > > >       should be at least or above the minimum-threshold represented as
> > > >       an absolute bandwidth value before the bandwidth adjustment for
> > > >       the LSP is made.  This threshold can be seen as a suppression
> > > >       threshold that is used along with a percentage threshold to avoid
> > > >       unnecessary auto-bandwidth adjustments and re-signaling of the LSP
> > > >       at low bandwidth values.
> > > >
> > > > I can't tell from this text if this threshold is a (LSP) bandwidth
> > > > value/measurement or a bandwidth offset between configured and measured
> > > > values.  (The subsequent protocol element definitions are more clear
> > > > that it's the latter.)
> > > >
> > >
> > > It is latter. Do you have a suggested change, I am not sure what change to make.
> >
> > How about:
> >
> >    Minimum-Threshold:  When percentage-based thresholds are in use, they
> >       are accompanied by this minimum threshold, which is used to enforce
> >       that the magnitude of deviation of calculated LSP bandwidth from the
> >       reserved bandwidth exceeds a specific non-percentage-based criterion
> >       before any adjustments are made.  This serves to suppress unnecessary
> >       auto-bandwidth adjustments and re-signaling of the LSP at low
> >       bandwidth values.
> >
> >
> 
> Thanks for the text. Updated with minor changes.
> 
> > > > Section 4.2
> > > >
> > > >    When the Auto-Bandwidth feature is enabled, the measured traffic rate
> > > >    is periodically sampled at each Sample-Interval (which can be
> > > >    configured by an operator and the default value as 5 minutes) by the
> > > >    PCC, when the PCC is the head-end node of the LSP.  The traffic rate
> > > >
> > > > Do we cover what happens in the case when the PCC is not the head-end
> > > > node of the LSP?
> > > >
> > >
> > > No.
> >
> > Should we document that somewhere?
> >
> 
> Added.
> 
> Diff: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-stateful-pce-auto-bandwidth-11&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt
> 
> Working Copy: https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt
> 
> Thanks!
> Dhruv