Thanks. Wfm. A > -----Original Message----- > From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com] > Sent: 23 February 2017 06:58 > To: 'adr...@olddog.co.uk'; 'Jonathan Hardwick'; '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 > > Hi Adrian, WG, > > This is an update for the two open issues - > > [snip] > > > > >> --- > > > >> 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. > > > > [[Dhruv Dhody]] Authors discussed this point and concluded that this flexibility > could be quite useful. And thus have added separate interval and threshold for > up and down - > > - Up-Adjustment-Interval > - Down-Adjustment-Interval > - Up-Adjustment-Threshold > - Down-Adjustment-Threshold > > > > > >>--- > > > >> 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. > > > > [[Dhruv Dhody]] We would like to keep this flexibility as it useful when the LSP > bandwidth becomes large or small, and optionally providing threshold in both > absolute and %age is useful. > Consider we set overflow threshold as either 20% or 500M. > When tunnel gets large (say 10G), the 20% is 2G, which is too large a threshold > and thus 500M as an absolute value helps, but when the same tunnel is small I > would like 20% threshold to be applied, even when it is less than 500M. > > We have clarified this in the latest version. > > The diff is attached, it also includes some editorial changes. > > Thanks again for your detailed review comments. > > Regards, > Dhruv (on behalf of co-authors)
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
