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. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
