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