Thank you Luyuan for providing review comments on the draft-dhody-pce-stateful-pce-auto-bandwidth.
Adding PCE WG. Thanks again, Rakesh (for authors) From: Luyuan Fang <[email protected]<mailto:[email protected]>> Date: Wednesday, 29 July, 2015 8:14 PM To: Rakesh Gandhi <[email protected]<mailto:[email protected]>>, Dhruv Dhody <[email protected]<mailto:[email protected]>> Cc: Ravi Singh <[email protected]<mailto:[email protected]>> Subject: RE: PCE Auto-bandwidth Draft Hi Rakesh and all, Thanks for asking! Here is my feedback. In general, it is a very well written and very useful draft. I appreciate a lot of the thoughtful operation considerations and detailed procedural/protocol specifications throughout the document, very good work. Here are some comments: 1. On pg 8: "...With Auto-Bandwidth feature, the LSP bandwidth can be set to some arbitrary value (including zero) during initial setup time, and it will be periodically adjusted over time based on the actual bandwidth requirement...." I don't quite like to have initial BW set as arbitrary value "including zero". In theory, nothing wrong here. But in practice, operators planned the network, they should have rough ideas what to expect. Reducing the churns when using auto-bandwidth is very important. I saw operator removed auto-bandwidth because seeing too many churns per day. Of course, when that happens, it also means the network capacity planning need to be revisited… I’d suggest change "the LSP bandwidth can be set to some arbitrary value (including zero) during initial setup time, " to "the LSP bandwidth can be set to arbitrary value, in practice, it can be operator expected value from the initial planning/design if known". Or something along the similar line. 2. On pg 9: "overflow count" is mentioned in Overflow-Threshold, should it be defined. Same for "underflow count"… 3. Nice to see the flexibility and operation considerations, such as "Multiple bandwidth samples are collected every report-interval, and reported together to the PCE. To avoid reporting minor changes in real-time traffic, report-threshold is used, to suppress the sending of the collected samples during the report-interval. The collected samples are reported if at least one sample crosses the Report-Threshold (percentage or absolute value). " I like this. And I like the following as well, so to deal with traffic surge... "In order to accommodate sudden changes in the real-time traffic, report flow threshold is employed by pre-maturely expiry of the report-interval to report the unreported bandwidth samples collected so far." As well as the report reduction consideration is very nice. 4. One thought – PCE should also have ability to adjust the intervals depending on the traffic pattern. Some LSPs are rather less eventful, some encounter a lot of changes, so the reporting and adjusting interval should also be able to change accordingly by the PCE. The draft can be very helpful to operators when implemented correctly, and used correctly. Thanks, Luyuan
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
