Skip to main content

Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)
draft-ietf-pce-lsp-control-request-11

Yes

(Deborah Brungard)

No Objection

Éric Vyncke
(Adam Roach)
(Alexey Melnikov)
(Alissa Cooper)
(Magnus Westerlund)

Note: This ballot was opened for revision 09 and is now closed.

Roman Danyliw
No Objection
Comment (2019-10-01 for -09) Sent
** I support Ben Kaduk’s DISCUSS point on the need to clarify the authorization policy of a PCE asking for control, and have the same question as Alvaro Retana posed about how the PCC determines when to honor a PCE’s request to take control an LSP.  More discussion of this policy mechanism is needed.

** As this draft is defining a bit from the previously reserved allocation of the flag field and redefining the semantics of 0 in the PLSP-ID of the SRP object per Section 7.2 of RFC8281, is there a reason that this draft does not formally update RFC8281.
Éric Vyncke
No Objection
Deborah Brungard Former IESG member
Yes
Yes (for -09) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2019-09-27 for -09) Sent
I have a substantive comment and then some nits/editorial notes.

(1) It seems to me that any PCE can request control of an LSP.  Even if the sessions are authenticated and encrypted, how does the PCC determine if it's ok for the requesting PCE to ask for control?  §8.1 says that an "implementation SHOULD allow the operator to configure the policy based on which it honors the request to control the LSPs".  If the implementation doesn't allow the configuration of policy, then it is possible for a rogue PCE to ask for control of an LSP, and for the PCC to grant it.  Why is the ability to configure this policy not REQUIRED?  I believe this case should be explicitly called out as a vulnerability.

(2) Abstract: s/A Path Computation Client (PCC) has set up LSPs/A Path Computation Client (PCC) that has set up LSPs 

(3) §1: s/which PCE to delegate the orphaned LSP/which PCE to delegate the orphaned LSP to

(4) §1: s/a simple extension, by using this a PCE can/a simple extension, by using it a PCE can

(5) In §3 the new C Flag is called the "LSP-Control Request Flag", but §7.1 only uses "LSP-Control".  Please be consistent; the more descriptive name is probably better.
Barry Leiba Former IESG member
No Objection
No Objection (2019-09-25 for -09) Sent
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.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2019-10-18) Sent
Thank you for addressing my Discuss points!
Magnus Westerlund Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (2019-09-30 for -09) Sent
Hi,

thank you for this document.
This document indicates:
"...MUST NOT trigger the error condition for unknown PLSP-ID in an LSP update request as per [RFC8231] ...".
"...MUST NOT trigger the error handling as specified in [RFC8231] ...".

Yet, it also says:
The procedures for granting and relinquishing control of the LSPs are specified in accordance with the specification [RFC8231].

So
1/ it seems to me that the latter sentence, considering the first two, is not strictly correct.
2/ the rationale is well described, so I'm fine with not respecting the original rules of 8231, but then I wonder if this document shouldn't update 8231.