Subject: [Pce] Opsdir last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10

From: Joe Clarke via Datatracker <[email-masked]>
Date: Mon, 26 Aug 2019 12:36:14 -0700

Reviewer: Joe Clarke
Review result: Ready

I have been requested to review this draft on behalf of the OPS Directorate. 
This draft describes PCEP extensions for MPLS-TE LSP automatic bandwidth
adjustment with stateful PCE.  In general, I think the draft is well-written,
and I appreciate the addition of the operational considerations section.  It is
in that section I have a couple of comments.

In section 6.2 you say:

A Management Information Base (MIB) module for modeling PCEP is
described in [RFC7420].  However, one may prefer the mechanism for
configuration using YANG data model [I-D.ietf-pce-pcep-yang].

However, when you look at that MIB module, there is only one read-write object.
 On top of that, the IESG has mandated that new MIB modules should not have
read-write objects.  I think your language pointing one to the YANG module
should be stronger.  Perhaps:

A MIB module for gathering operational information about PCEP is defined in
[RFC7420].  Additionally, the YANG module defined in [I-D.ietf-pce-pcep-yang] 
provides for both configuration of PCEP as well as operational management.

===

In section 6.6, do you have any more concrete recommendations on a reasonable
limit of LSPs with auto-bandwidth that you have discovered from testing or
operational experience?  Providing some data here may prove useful, even if it
is somewhat anecdotal.

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 28 Aug 2019 12:25:14 +0530

Hi Joe,

Thank you for your careful review.

> provides for both configuration of PCEP as well as operational management.

This is a good suggestion, we will update.

> operational experience?  Providing some data here may prove useful, even if it

We discussed this and felt reluctance in putting a number down in the
RFC, esp when we don't do it for our base published RFCs (ex. such as
how many LSPs can be delegated to a PCE). I also checked with at least
one vendor and was told that it is quite dependent on the deployment
scenario and would let the operator decide.

Thanks!
Dhruv

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 28 Aug 2019 15:23:39 +0000

> This is a good suggestion, we will update.

Thanks.

> scenario and would let the operator decide.

Maybe not a hard number, but is there any kind of example you could provide for a given scenario that provides clearer guidance on what kind of impact  each one of these LSPs would present?

Joe

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 29 Aug 2019 10:44:39 +0530

Hi Joe,

> Maybe not a hard number, but is there any kind of example you could provide for a given scenario that provides clearer guidance on what kind of impact  each one of these LSPs would present?

How is this -

6.6.  Impact On Network Operations

   In order to avoid any unacceptable impact on network operations, an
   implementation SHOULD allow a limit to be placed on the number of
   LSPs that can be enabled with auto-bandwidth feature.  For each LSP
   enabled with auto-bandwidth feature there is an extra load on PCC, as
   it needs to monitor the traffic and report the calculated bandwidth
   to be adjusted to the PCE. The PCE further re-compute paths based on
   the requested bandwidth and update the path to the PCC, which in
   turns triggers the re-signalling of the path. All these steps adds
   extra load and churn in the network and thus operator needs to take
   due care while enabling this features on a number of LSPs.

Thanks!
Dhruv

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 29 Aug 2019 14:41:14 +0000

This is more informative as to the risks/impact.  Works for me.  Thanks.

Joe

PGP Key : https://www.marcuscom.com/pgp.asc

> On Aug 28, 2019, at 22:15, Dhruv Dhody <[email-masked]> wrote:
> 
> Hi Joe,
>