[Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-lsp-control-request-09: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-lsp-control-request-09: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This may just be a philosophical discussion, but if RFC 8231 marks the
PLSP-ID value of 0 as "reserved" and we are making use of the extension
point, do we need to have an Updates: relationship with 8231?  This
seems particularly poigniant given that we have to explicitly override
the RFC 8231 error handling, with some text in the second paragraph of
Section 4.

What kind of feature negotiation is available to check support prior to
using this flag?  After all, if the peer does not implement this
document it will not implement the override of 8231 error handling and
will respond with errors when the D flag is set (or the PLSP-ID of 0
used).  If we have to just "try it and fall back to not using it if we
get errors", that has some associated security considerations as well.

What can we say about authorization policy on the PCC?  Alvaro touched
on this in his Comment, but I think it's important enough to be
Discuss-level.  Since this policy is the key factor to the security
posture of this extension, not only does it seem like there MUST be the
ability to configure the policy, but it also seems like we should be
able to give some guidance on typical use cases (where the authors
believe the security properties to be reasonable).  Other use cases
might require an additional level of analysis by those proposing to
deploy the solution.


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

Section 1

               It includes mechanisms to effect LSP state
   synchronization between Path Computation Clients (PCCs) and PCEs,
   delegation of control of LSPs to PCE, and PCE control of timing and
   sequence of path computations within and across PCEP sessions.  [...]

nit: assuming this is grouped as "it includes mechanisms to: (1) effect
LSP state synchronization [...], (2) delegation of control [...], and
(3) PCE control of timing and sequence [...]", the verb tenses need to
be changed so that they match up.

   For Redundant Stateful PCEs (section 5.7.4. of [RFC8231]), during a
   PCE failure, one of the redundant PCE could request to take control
   over an LSP.  The redundant PCEs may use a local policy or a

Just to check: this request is only possible with the mechanism defined
in this document, and is not possible with just the previous
technologies?  I might suggest to s/could/might want to/ to make it more
clear that this is motivating the rest of the document.

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

nit: singular/plural mismatch "PCEs"/VNF

   can be used in conjunction to [RFC8231].  Ultimately, it is the PCC
   that decides which PCE to delegate the orphaned LSP.

nit: either "to which to delegate the orphaned LSP" or "to delegate the
orphaned LSP to".

Section 3

   A new flag, the "LSP-Control Request Flag" (C), is introduced in the
   SRP object.  On a PCUpd message, a PCE sets the C Flag to 1 to
   indicate that it wishes to gain control of LSPs.  The LSPs are
   identified by the LSP object.  A PLSP-ID of value other than 0 and
   0xFFFFF is used to identify the LSP for which the PCE requests
   control.  The PLSP-ID value of 0 indicates that the PCE is requesting
   control of all LSPs originating from the PCC that it wishes to
   delegate.  [...]

nit: I suggest s/identified by the LSP object/identified by the PLSP-ID
in the LSP object following the SRP object/.

   delegate.  The C Flag has no meaning in other PCEP messages that
   carry SRP object and the flag MUST be set to 0 on transmission and
   MUST be ignored on receipt.

nit: I suggest s/object/objects/ and s/and the/and for which the/

Section 4

   If a PCE wishes to gain control over an LSP, it sends a PCUpd message
   with C Flag set to 1 in SRP object.  The LSP for which the PCE
   requests control is identified by the PLSP-ID.  The PLSP-ID of 0

nit: as above, I suggest s/identified by the PLSP-ID/identified by the
PLSP-ID in the associated LSP object/

   timer.  A PCE ignores the C Flag on the PCRpt message.  Note that, if

nit: I think this is now redundant with the text added in respone to
the genart review ("The C Flag has no meaning in other PCEP messages
that carry SRP object and the flag MUST be set to 0 on transmission and
MUST be ignored on receipt").

   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))
I don't understand this sentence -- what does "as the D Flag would be
unset" mean?  Does it just mean that the PCC treats it as unset because
it has no code to handle the D flag at all?

Section 6

Please cite RFC 7525 as BCP 195.