[Pce] Barry Leiba's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Thu, 26 September 2019 06:26 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17920120045; Wed, 25 Sep 2019 23:26:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-pce-lsp-control-request@ietf.org, Hariharan Ananthakrishnan <hari@netflix.com>, pce-chairs@ietf.org, hari@netflix.com, pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.102.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <156947917508.29034.2649004397929023444.idtracker@ietfa.amsl.com>
Date: Wed, 25 Sep 2019 23:26:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/_WqHzBshQst_15dBlVNCIcBtFmE>
Subject: [Pce] Barry Leiba's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 06:26:15 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-pce-lsp-control-request-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I have only some editorial comments.  There’s no need to respond, but please
consider these comments, as I think they’ll help make the document clearer. 
Particularly note the first comment for Section 3.

— Abstract —

   This document describes an extension to the Path Computation Element
   communication Protocol (PCEP) to enable a PCE to make such requests.

It’s a small thing, but no requests have been mentioned that could match “such
requests”.  But “control” has been discussed, so  I think you need to say it
this way:

   This document describes an extension to the Path Computation Element
   communication Protocol (PCEP) to enable a PCE to make requests for
   such control.

— Section 1 —

   In case of virtualized PCEs (vPCE) running as virtual network
   function (VNF), as the computation load in the network increases

“Running as virtual network function” sounds like it’s missing something. 
Maybe “running in VNF mode,” or some such?

   The PCEs could use proprietary algorithm to decide which LSPs
   to be assigned to the new vPCE.

Either “a proprietary algorithm” or “proprietary algorithms”.

   Thus having a mechanism for the PCE
   to request control of some LSPs is needed.

You need a comma after “Thus”.

   This specification provides a simple extension, by using this a PCE
   can request control

Comma splice.  The easiest fix is to change the “,” to a “:”.  Or else split it
into two sentences at the comma.

— Section 3 —
This section refers to the new flag as the “LSP-Control Request Flag”.  The
IANA Considerations section (7.1) just calls it “LSP-Control”.  Probably
Section 7.1 should call it “LSP-Control Request”, and this section should refer
to “TBD” so that th RFC Editor will insert the bit number that IANA assigns.

   The Stateful PCE Request Parameters (SRP) object is defined in
   Section 7.2 of [RFC8231], it includes a Flags field.

Comma splice.  Change “it” to “and” to fix it.

   The C Flag has no meaning in other PCEP messages that
   carry SRP object

Either “an SRP object” or “SRP objects”.

— Section 4 —

   The D Flag and C
   Flag are mutually exclusive in PCUpd message.  The PCE SHOULD NOT
   send control request for LSP which is already delegated to the PCE,
   i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD
   NOT be set.

I’m confused: “mutually exclusive” means that they can’t both be set.  So why
SHOULD NOT and not MUST NOT?  (You’re also missing a few articles here: ”a
PCUpd message”, “a control request”, “an LSP”, and “the C Flag”.

   It should be noted that a legacy implementation of PCC, that does not
   support this extension would trigger the error condition as specified
   in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and
   error-value 1 (Attempted LSP Update Request for a non-delegated LSP))
   as the D Flag would be unset in this update request.

Please move the comma that’s after “PCC” and place it instead before “as the D

   It also specifies how a
   PCE MAY obtain control over an orphaned LSP that was PCE-initiated.

This should be “may”, not a BCP 14 key word.