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

[Dhruv Dhody <[e-mail]>]

Hi Adrian, 

Thanks for your further response. I have uploaded a new version with two issues open. 
Please see inline. 


> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 28 January 2017 22:35
> To: Dhruv Dhody <[e-mail]>; 'Jonathan Hardwick'
> <[e-mail]>; [e-mail]
> Cc: [e-mail];
> [e-mail]
> Subject: RE: [Pce] Poll for adoption:
> draft-dhody-pce-stateful-pce-auto-bandwidth-09
> 
> 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.
> 

[Dhruv] Done! 

> >> ---
> >> 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.
> 

[Dhruv] :) I meant, for the existing implementation of auto-bandwidth feature with local CSPF. Anyways...  

> > 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.
> 

[Dhruv] Understood. I will keep this point open in the current version and gather feedback from my co-authors as well as operators, before updating.  

> >>---
> >> 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.
> 
> 

[Dhruv] Personally I am fine either way. I will update once I get a confirmation from my co-authors. 

Thanks again for your reviews. 

Regards,
Dhruv