Hi JP, Thanks for your comments, I agree that adding text along the lines you suggest would be good. I will work with my co-authors and come up with text.
Could you expand a little bit more, on what kind of notification, you would like to see? Let me add how I see it since you mention section 5.3 - A PCE can use BANDWIDTH-USAGE-ATTRIBUTE TLV to set the rate of Bandwidth Usage reporting. But a mechanism to notify that the PCE is being overwhelmed and would like PCC to temporarily stop or reduce the rate of reporting, is needed. Or did you mean something else when you say ‘lower adaption rate’ ? Thanks Again! Dhruv From: Pce [mailto:[email protected]] On Behalf Of JP Vasseur (jvasseur) Sent: 04 August 2016 11:57 To: Rakesh Gandhi (rgandhi) <[email protected]>; [email protected]; Zhangxian (Xian) <[email protected]>; Leeyoung <[email protected]>; [email protected]; [email protected]; [email protected] Cc: [email protected] Subject: [Pce] Comments about draft-dhody-pce-stateful-pce-auto-bandwidth Dear co-authors, First of all, my apologies for the late comments that I had promised to send a while ago. In your first deployment model … (although the comment below somehow applies to the second model) o Deployment model 1: PCC to decide adjusted bandwidth: * In this model, the PCC (head-end of the LSP) monitors and calculates the new adjusted bandwidth. The PCC reports the calculated bandwidth to be adjusted to the PCE. * This approach would be similar to passive stateful PCE model, while the passive stateful PCE uses path request/reply mechanism, the active stateful PCE uses report/update mechanism to adjust the LSP bandwidth. * For PCE-initiated LSP, the PCC is requested during the LSP initiation to monitor and calculate the new adjusted bandwidth. … you may want to mention in the draft potential concern in terms of Scalability. You do address scalabilities issues in Section 4.3: 4.3. Scaling Considerations There are potential scaling concerns for the model where PCC (ingress LSR) reports real-time bandwidth usage information to the stateful PCE for a large number of LSPs. It is recommended to combine multiple bandwidth samples (BwSamples) using larger report-interval and report them together to the PCE, thus reducing the number of PCRpt messages. Further, Report-Threshold can be use to skip reporting the bandwidth samples for small changes in the bandwidth. The processing cost of monitoring a large number of LSPs at the PCC and handling bandwidth change requests at PCE should be taken into consideration. Note that, this will be implementation dependent. But referring to the control plane overhead, which IMO is less of an issue compared to resignaling operation. As you know, resizing may imply rerouting along a different path, which itself may trigger preemption of lower priority TE LSPs, … all of this combined with make-before-break. And there are situations where we need to signal with BW=0 first in order to find room for both TE LSPs. You may argue that this also applies to the case of a non-PCE deployment where each head-end acts as a PCE for its own TE LSPs. That being said, in the PCE case the scalability is exemplified since rerouting/resignalling of many TE LSPs at high frequency may simply push the model to its limit. I would at least suggest to expand your section 5.3, or even preferably also add a notification type in the NOTIFICATION object for the PCE to report a suggested lower adaption rate. Thoughts ? Thanks. JP.
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
