Hi Adrian, We have posted a new update handling the comments from you and Haomian.
I-D: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/ Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-control-request-05 Snipping to --- Section 4 If the LSP(s) is/are already delegated to the PCE making the request, the PCC ignores the C Flag. Doesn't this over-complicate things? Why not have the PCE always respond with D set or clear depending on whether it wants to have delegated? That way, a PCE that drops context (i.e., does it have control or not?) is able to regain context. Or are you trying to prevent a thrash where... PCE ---> C flag D flag <--- PCC PCE ---> D flag and C flag D flag <--- PCC PCE ---> D flag and C flag etc. I see you don't give the PCE advice about not setting the C flag for LSP, it already has delegate control over. That would lead to... PCE ---> C flag D flag <--- PCC PCE ---> D flag -- First, we rephrased this for clarity - 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. If a PCC receives a PCUpd message with D flag set in the LSP object (i.e. LSP is already delegated) and the C flag is also set (i.e. PCE is making a control request), the PCC MUST ignore the C Flag. Second, for a delegated LSP, PCE always sends PCUpd with the D flag set unless it wants revocation of the delegation. Both D and C flag in PCUpd message should not be set together. We wanted to have a new flag to independently indicate 'LSP control request' and not overload the existing flag. --- Section 4 It should be noted that a legacy implementation of PCC, that does not understand the C flag in PCUpd message, would simply ignore the flag (and the request to grant control over the LSP). At the same time it 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 looked through 8231 and 8281 and I don't find a discussion of handling unknown flags. What is missing in 7.2 of 8231 is "Unassigned flags MUST be set to zero on transmission, and unknown flags MUST be ignored on receipt." I think that without that addition to 8231, your text doesn't work. --- We rephrased this to say - 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. Further, in case of PLSP-ID of 0, the error condition as specified in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and error-value 3 (Attempted LSP Update Request for an LSP identified by an unknown PSP-ID)) would be triggered. So this I-D can be progressed independently, while the WG decides how to handle the missing statement in RFC 8231. Thanks for your review, Mahendra -------------------------------------------------- Mahendra Singh Negi Mahendra Mobile: +91-7204000290<tel:+91-7204000290> Email: mahendrasi...@huawei.com<mailto:mahendrasi...@huawei.com> From:Adrian Farrel <adr...@olddog.co.uk> To:'Dhruv Dhody' <dhruv.i...@gmail.com>;pce@ietf.org <pce@ietf.org> Cc:draft-ietf-pce-lsp-control-requ...@ietf.org <draft-ietf-pce-lsp-control-requ...@ietf.org> Date:2019-06-17 21:17:02 Subject:RE: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04 Hi, Picking up on Dhruv's request, I did a quick review as co-chair. It's after the end of WG last call, but life is full of little disappointments. Enjoy! Adrian === Please reduce to five or fewer authors on the front page or provide the shepherd with a good reason why not. --- Please expand "LSP" in the document title. --- I found the Abstract a bit hard to work through. How about... A stateful Path Computation Element (PCE) retains information about the placement of MPLS-TE Label Switched Paths (LSPs). When a PCE has stateful control over LSPs it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A Path Computation Client (PCC) has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE. There are use-cases in which a stateful PCE may wish to obtain control of locally configured LSPs of which it is aware but that have not been delegated to the PCE. This document describes an extension to the Path Computation Element communication Protocol (PCEP) to enable a PCE to make such requests. --- Please expand abbreviations on first use in the body of the document (even if they have already been used in the Abstract). I found: - PCEP - TE LSP - PCC - PCE --- You need to move the block of text "Requirements Language" down to after the Introduction. Probably create a Section 2.1 for it. That is also consistent with it not being appropriate to use Requirements Language in the Introduction. (You have just one "MAY" which can safely be made lower case.) --- Section 3 s/a R/an R/ s/LSP(s)/LSPs/ OLD The LSP is identified by the LSP object. NEW The LSPs are identified by the LSP object. END --- Section 3 has... [RFC8281] defines a R (LSP-REMOVE) flag. This is true, but not very relevant. You don't mention the R flag anywhere else. Maybe just delete this? --- Section 4 OLD LSP(s) is/are NEW LSPs are END s/[RFC8231] ./[RFC8231]./ --- Section 4 If the LSP(s) is/are already delegated to the PCE making the request, the PCC ignores the C Flag. Doesn't this over-complicate things? Why not have the PCE always respond with D set or clear depending on whether it wants to have delegated? That way, a PCE that drops context (i.e., does it have control or not?) is able to regain context. Or are you trying to prevent a thrash where... PCE ---> C flag D flag <--- PCC PCE ---> D flag and C flag D flag <--- PCC PCE ---> D flag and C flag etc. I see you don't give the PCE advice about not setting the C flag for LSPs it already has delegate control over. That would lead to... PCE ---> C flag D flag <--- PCC PCE ---> D flag --- Section 4 In case multiple PCEs request control over an LSP, and if the PCC is willing to grant the control, the LSP MUST be delegated to only one PCE chosen by the PCC based on its local policy. This might be clearer as... A PCC MUST NOT delegate an LSP to more than one PCE at any time. If a PCE requests control of an LSP that has already been delegated by the PCC to another PCE, the PCE MAY ignore the request, or MAY revoke the delegation to the first PCE before delegating it to the second. This choice is a matter of local policy. --- Section 4 It should be noted that a legacy implementation of PCC, that does not understand the C flag in PCUpd message, would simply ignore the flag (and the request to grant control over the LSP). At the same time it 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 looked through 8231 and 8281 and I don't find a discussion of handling unknown flags. What is missing in 7.2 of 8231 is "Unassigned flags MUST be set to zero on transmission, and unknown flags MUST be ignored on receipt." I think that without that addition to 8231, your text doesn't work. --- Section 6 s/vectors/vector/ --- Section 7.1 It would be good if you could help IANA correctly identify the registry you want actioned. I think this is... IANA maintains a registry called the "Path Computation Element Protocol (PCEP) Numbers" registry. It contains a subregistry called the "SRP Object Flag Field" registry. I note that the current registry reads... Value Description Reference 0-30 Unassigned [RFC8281] 31 LSP-Remove [RFC8281] ....so your proposed description for the c-bit is a bit lengthy. --- Section 8.1 There is a further policy described in the document: that of deciding which of a pair of delegation requests to honour. --- Not sure whether it belongs in 8.1 or 8.3... The PCE that sends a delegation request and doesn't get a response "may choose to retry requesting the control preferably using exponentially increasing timer." That implies a timer that should be configurable. --- Not sure whether it belongs in 8.1 or 8.3 or 7... The Security considerations section suggests dropping delegation requests if the PCC is swamped. I think you need to configure the threshold for swamping, and to recommend that the issue be logged. -----Original Message----- From: Pce <pce-boun...@ietf.org> On Behalf Of Dhruv Dhody Sent: 17 June 2019 11:02 To: pce@ietf.org Cc: draft-ietf-pce-lsp-control-requ...@ietf.org Subject: Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04 Hi WG, The WG LC ends in 2 days. We would like to see some more responses before we make the consensuses call. Please confirm if the document is ready to be sent to the IESG. Detailed comments are always welcome! Thanks! Dhruv On Tue, Jun 4, 2019 at 9:56 PM Dhruv Dhody <dhruv.i...@gmail.com> wrote: > > Hi WG, > > This email starts a working group last call for > draft-ietf-pce-lsp-control-request-04. The WG LC will run for 2 weeks, till > 19th June 2019. > > https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/ > > Please indicate your support or concern for this draft. > > If you are opposed to the progression of the draft, please articulate your > concern. > > If you support, please indicate that you have read the latest version and > it is ready for publication. Further, explaining the importance of the work in > your opinion is appreciated. > > As always, review comments and nits are most welcome. Silence on the list, not > so much :) > > Thanks, > Dhruv, Julien, & Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
