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

Reply via email to