Subject: [Pce] Comments about draft-dhody-pce-stateful-pce-auto-bandwidth

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Thu, 4 Aug 2016 06:27:16 +0000

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 4 Aug 2016 07:41:39 +0000

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-masked]] On Behalf Of JP Vasseur (jvasseur)
Sent: 04 August 2016 11:57
To: Rakesh Gandhi (rgandhi) <[email-masked]>; [email-masked]; Zhangxian (Xian) <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Pce] Comments about draft-dhody-pce-stateful-pce-auto-bandwidth

Dear co-authors,

Thoughts ?

Thanks.

JP.

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Thu, 4 Aug 2016 17:14:18 +0000

Hi Dhurv,

On Aug 3, 2016, at 11:41 PM, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:

Hi JP,

JP> Thanks a lot.

JP> This is indeed what I meant. In the description you may want to indicate the exact source for “congestion”: it may be the PCE itself, or the overwhelming extra signaling that too frequent auto-BW timers would trigger (determined by the PCE).

Thanks.

JP.

Thanks Again!
Dhruv

From: Pce [mailto:[email-masked]] On Behalf Of JP Vasseur (jvasseur)
Sent: 04 August 2016 11:57
To: Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zhangxian (Xian) <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Pce] Comments about draft-dhody-pce-stateful-pce-auto-bandwidth

Dear co-authors,

Thoughts ?

Thanks.

JP.

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 16 Aug 2016 12:51:54 +0000

Hi JP,

We have updated the section 4.3 scaling with this text –

   It should be noted that with both deployment models, any bandwidth
   change would require re-signaling of an LSP in a make-before-break
   fashion, which can further trigger preemption of lower priority LSPs
   in the network.  When deployed under scale, this can lead to a
   signaling churn in the network.  The Auto-bandwidth application
   algorithm is thus advised to take this into consideration before
   adjusting the LSP bandwidth.  Operators are advised to set the values
   of various auto-bandwidth adjustment and reporting parameters
   appropriate for the deployed LSP scale.

   ...

   If a PCE gets overwhelmed, it can notify the PCC to temporarily
   suspend its auto-bandwidth reporting (see Section 5.7).  Similarly if
   a PCC gets overwhelmed due to signaling churn, it can notify the PCE
   to temporarily suspend the LSP bandwidth adjustment.

Also a new section added –

5.7.  The PCNtf Message

   As per [RFC5440], the PCEP Notification message (PCNtf) can be sent
   by a PCEP speaker to notify its peer of a specific event.  As
   described in Section 4.3 of this document, a PCEP speaker SHOULD
   notify its PCEP peer that it is overwhelmed, and on receipt of such
   notification the peer SHOULD NOT send any PCEP messages related to
   auto-bandwidth adjustment or bandwidth usage reporting.  If a PCEP
   message related to auto-bandwidth adjustment or bandwidth usage
   reporting is received, it MUST be silently ignored.

   When a PCEP speaker is overwhelmed, it SHOULD notify its peer by
   sending a PCNtf message with Notification Type = TBD6 (Auto-bandwidth
   Overwhelm State) and Notification Value = 1 (Entering auto-bandwidth
   overwhelm state).  Optionally, OVERLOADED-DURATION TLV [RFC5440] MAY
   be included that specifies the time period during which no further
   PCEP messages related to auto-bandwidth adjustment or bandwidth usage
   reporting should be sent.  When the PCEP speaker is no longer in the
   overwhelm state and is available to process the auto-bandwidth
   adjustment or bandwidth usage reporting, it SHOULD notify its peer by
   sending a PCNtf message with Notification Type = TBD6 (Auto-bandwidth
   Overwhelm State) and Notification Value = 2 (Clearing auto-bandwidth
   overwhelm state).

   When Auto-Bandwidth feature is deployed using Deployment Model 1, a
   PCE can send this notification to PCC when a PCC is reporting
   frequent auto-bandwidth adjustments.  If a PCC is overwhelmed with
   re-signaling/re-routing, it can also notify the PCE to not adjust the
   LSP bandwidth while in overwhelm state.

   When Auto-Bandwidth feature is deployed using Deployment Model 2, a
   PCE can send this notification when a PCC is reporting bandwidth-
   usage too frequently for the PCE to process.  In this model as well,
   if a PCC is overwhelmed with re-signaling/re-routing, it can notify
   the PCE to not update bandwidth while in overwhelm state.

The working copy with diff is attached.

Regards,
Dhruv (on behalf of co-authors)

From: JP Vasseur (jvasseur) [mailto:[email-masked]]
Sent: 04 August 2016 22:44
To: Dhruv Dhody <[email-masked]>
Cc: Rakesh Gandhi (rgandhi) <[email-masked]>; [email-masked]; Zhangxian (Xian) <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Comments about draft-dhody-pce-stateful-pce-auto-bandwidth

Hi Dhurv,

Hi JP,

JP> Thanks a lot.

Thanks.

JP.

Thanks Again!
Dhruv

Dear co-authors,

Thoughts ?

Thanks.

JP.