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:adr...@olddog.co.uk] > Sent: 28 January 2017 22:35 > To: Dhruv Dhody <dhruv.dh...@huawei.com>; 'Jonathan Hardwick' > <jonathan.hardw...@metaswitch.com>; pce@ietf.org > Cc: pce-cha...@ietf.org; > draft-ietf-pce-stateful-pce-auto-bandwi...@ietf.org > 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 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
