Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

["Adrian Farrel" <[e-mail]>]

Hey Dhruv,

Thanks for the careful response.

I've snipped down to  couple of points.

Best,
Adrian

>> I note that this revision seems to have dropped the ability for a PCC
>> to report samples to the PCE and have the PCE do all of the work of
>> determining whether auth-bandwidth adjustments are needed/desirable
>> before performing the various path computations.

[snip]

> [Dhruv] You are right, we have not dropped the model, only decided to pursue
> the second model in a different draft “draft-gandhi-pce-pm-04” which deals
> with reporting parameters to the PCE including bandwidth Utilizations, as well
> as delay, jitter etc. This would be in-line with other RFCs in OSPF, IS-IS and
PCE
> which deals with these parameters together.  

OK. Understood. Maybe a simple note and pointer to the other I-D (Informative
reference) would be helpful and stop future reviewers asking similar questions.

>> ---
>> Did you consider allowing a different Adjustment-Interval for adjustment
>> up and adjustment down (with them defaulting to the same value)?
>
> [Dhruv] No, it is not supported by most of the vendors.

ROFL
It's not even a WG draft yet.

> They keep the same interval but allow setting of different values for the
> overflow and underflow threshold/count. Do you feel that this should
> be added? 

Not sure. If I was writing the code, I would certainly have used two different
timers because that is cheap and easy and flexible. Whether I would have exposed
both as configurable in the first release is debatable.

If I was deploying I think I would want to experiment with making changes more
sticky in one direction than in the other direction. How important that is might
depend on how expensive it is to increase b/w once it has been reduced, and how
likely it is that an increase might fail.

>>---
>> 4.2 has
>>
>> All thresholds in this document could be represented in both absolute
>> value and percentage, and could be used together.
>>
>> I looked but couldn't find. If absolute and percentage are both supplied
>> and imply different thresholds, which one is used? Could be as simple as
>> "the first threshold hit", but this could lead to some flaps that are 
>> not obvious to someone staring at either the up/down percentage 
>> thresholds or at the up/down absolute values.
>
> [Dhruv] In section 5.2.3 (and similarly 5.2.5) states – 
>
> An implementation MAY include both
> sub-TLVs for the absolute value and the percentage, in which case the
> bandwidth is adjusted when either of the adjustment threshold
>  conditions are met.
>
> Which is similar to what you state. 
> Do you suggest we add some guidelines to provide information on which
> threshold is met by logging? 
> Or do you feel strongly about this and we should use only one format? 

I think that this may be flexibility too far. I can't see a way that this would
break anything, but might lead to "unexpected" results. For example...

Up % = 1%
Down % = 10%
Up absolute = 1 GB
Down absolute = 1 MB

This would cause wibbles, but maybe that is what the operator has asked for.

But maybe nothing more to say.