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

Dhruv Dhody <> Wed, 28 August 2019 06:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDAC81208E5; Tue, 27 Aug 2019 23:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hoDWsm29xpdT; Tue, 27 Aug 2019 23:55:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFD4C1208BA; Tue, 27 Aug 2019 23:55:51 -0700 (PDT)
Received: by with SMTP id s21so3876183ioa.1; Tue, 27 Aug 2019 23:55:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/dzgidEylLiwfzUObsW5C9nan+mpZ1sPl8OzDrVRdQs=; b=XX+TI2RXPg1mw/vunOpda+4Kendn9ic5ZCJZyNGYNnOnh2n+BYrVr89VtAFIjgEnjP HEzy0agFABgOwFDMy+k2J1jMmlNNp/DzQypYUGHDFQtGtgBJLKPJY7otR1znNMee+I9x sHYdoAhm3L9XMJI/iuvDSK9sSI387cNOJoFz6nqjnW1siYxg7idFNAfz7DfX9CxBokhz EbupcyUNGLU2G4T/3zalVuAyKjdcZpns738mwJ1w2KESoPGMKGKVCAuuEz5w109F9Vbz cO7ICLQJ53nwDCdyXRON5UtgT3zuEFHtS+7wvwMwf4i+n0oWwL6oY6vZb3rBJpo52idZ DXOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/dzgidEylLiwfzUObsW5C9nan+mpZ1sPl8OzDrVRdQs=; b=fTCfdENc5mxTcNIkYsmTnyuNlZawnZzfjsYiCvmTGb+LaJaoV49tsaX4XBjxXCszV5 G5FNMi5xaMQk/JtdCh7u+ng92CLDaJ3h4TIOj7p4edSQzGOeVnL2Ro06PBHdkkPjSU/B mzKM8yyBmjhiwtMjwE4Q8QtqYbTw5OUCUT4/GkcCgrIGEYvKu9cRbGU7secVB2socGXT X+mSC64h0OMZMhkElUVOkGkpRY4h8VrvtdxN04rrUmDAxdOrIinSSG7pSuKE7sOKxioz 5jkou857u/oVwZqKO31lfC5Tj6w30ByzqG7zpCN1Mokdq8DpDOedLs5fhzPqisdZiN/R bA6Q==
X-Gm-Message-State: APjAAAXH8xjGzgDCKAmyQO+lfFjIzknzOlwPNyohC/F62DSv3UQmv7oU OUkqXLHhcCbxMOLyVxIRwCuDUj55jlltVywQSo4=
X-Google-Smtp-Source: APXvYqyOV3x3ito5Mp4zODi/7ZfK8ILQPgLwekeJUmsZ8oTcSI3F1wIUPBxgmSsZEA7XuVJpsBRqhgorlaM9K4IrTPg=
X-Received: by 2002:a5e:c301:: with SMTP id a1mr2757519iok.1.1566975350877; Tue, 27 Aug 2019 23:55:50 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Wed, 28 Aug 2019 12:25:14 +0530
Message-ID: <>
To: Joe Clarke <>
Cc:,, " Discussion" <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Pce] Opsdir last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Aug 2019 06:55:58 -0000

Hi Joe,

Thank you for your careful review.

On Tue, Aug 27, 2019 at 1:06 AM Joe Clarke via Datatracker
<> wrote:
> 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.

This is a good suggestion, we will update.

> ===
> 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.

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.