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

[Dhruv Dhody <[e-mail]>]

Hi Ben,

Thanks for your review. A few thoughts on your DISCUSS...

On Mon, Sep 30, 2019 at 11:19 PM Benjamin Kaduk via Datatracker
<[e-mail]> wrote:
>
> 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.
>

There are various cases when PLSP-ID can be zero already. RFC 8231 has
end-of-synchronisation marker. RFC 8281 uses it to indicate removal of
all LSPs. So IMHO this extension defines a new use of PLSP-ID=0 to be
used, that too, only when the C flag is set!

As Deborah puts it - this does not require an update to existing RFC
8231 implementation. Only those implementing this 'optional' feature
needs to consider this.


> 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.
>

In this case Capability negotiation might be an overkill. We are just
adding a new flag; there is a clear error case to work with legacy
implementation.

Anyways, We can update the security considerations to include this
fact. Something like -

   Note that, a PCE may not be sure if a PCC supports this feature.  A
   PCE would try sending a control request to a 'legacy' PCC, which
   would in turn respond with an error as described in Section 4.  So a
   PCE would learn this fact only when it wants to take control over an
   LSP.

Do you see anything else worth highlighting?

> 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.
>
>

Delegation is just about giving temporary control to PCE, the real
impact on LSP would happen when a PCE updates the LSP parameters. This
impact fall under RFC 8231 where PCC decides to either accept the
update or not. Moreover RFC 8281 grants PCE the capability to initiate
LSPs as well.

So IMHO this request control falls within the existing perimeter of
the protocols.

I wrote this to Alvaro -

> Thanks for pointing this out. Since RFC 8231 uses SHOULD wrt policy, I
> would consider not changing that. We can highlight that the PCC is the
> ultimate arbiter on if the delegation should be made and to which PCE.
> Even after delegation, the PCC can take back control anytime. But at
> the same time blindly accepting control request could be a problem!

> I propose this text in Security section -

>   A PCC is the ultimate arbiter of delegation.  As per [RFC8231], a
>   local policy at PCC is used to influence the delegation.  A PCC can
>   also revoke the delegation at any time.  A PCC MUST NOT blindly trust
>   the control requests and SHOULD take local policy and other factors
>   into consideration before honoring the request.

So the key question is that does this 'control request' raises to the
level that we make policy a MUST, when RFC 8231/8281 did not...

> ----------------------------------------------------------------------
> 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?
>

Suggestion to make this clearer with -

   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 any control request would have the D Flag (delegate) unset
   and it would be considered as attempt to update a non-delegated LSP.

> Section 6
>
> Please cite RFC 7525 as BCP 195.
>
>

Thanks!
Dhruv