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. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
