Subject: Re: [Pce] PCE Auto-bandwidth Draft

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 5 Aug 2015 22:31:08 +0000

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-masked]<mailto:[email-masked]>>
Date: Wednesday, 29 July, 2015 8:14 PM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Cc: Ravi Singh <[email-masked]<mailto:[email-masked]>>
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