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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 25 Sep 2019 23:26:15 -0700

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:
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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:

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

— 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
Flag”.

   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.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 30 Sep 2019 16:59:19 +0530

Hi Barry,

Thanks for your review. Snipping to just one point -

> PCUpd message”, “a control request”, “an LSP”, and “the C Flag”.

I think the reason for SHOULD NOT was because when a PCC receives this
- it would simply ignore it!
This did not rise to the level of error usual for MUST NOT!

If you feel that the above isn't a good enough reason, changing would
not cause any harm either.

Thanks!
Dhruv

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Sep 2019 10:09:39 -0400

> not cause any harm either.

If the working group thinks that SHOULD NOT is right, it should stay
that way -- I just questioned the combination of "mutually exclusive"
and "SHOULD NOT".  So here are my thoughts:

1. If there is no reason they should ever be set together, then it
should be MUST NOT.

2. If there might be a reason to set them together -- it's difficult
to meet the conditions in some way, or whatever -- then SHOULD NOT is
OK.

3. If you keep it as SHOULD NOT, I think you should change the
"mutually exclusive" sentence to be less strong.

It sounds to me like MUST NOT is the right thing here -- that there's
never a reason to set them both together, and that it doesn't make
sense in the protocol to have them both set.  So even though the
receiver can ignore the situation, MUST NOT still applies.

Barry