Hi Victoria, Many thanks for your review. Please find the diff which reflects the changes we have made following your suggestions.
https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-pcep-extension-for-pce-controller-09&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-10.txt Please find our responses in line below. Best regards, Shuping From: Pritchard, Victoria [mailto:victoria.pritch...@airbus.com] Sent: Tuesday, December 22, 2020 9:16 PM To: rtg-...@ietf.org Cc: rtg-...@ietf.org; draft-ietf-pce-pcep-extension-for-pce-controller....@ietf.org; pce@ietf.org Subject: RtgDir review: draft-ietf-pce-pcep-extension-for-pce-controller-09 Hello, I have been selected as the Routing Directorate reviewer for this draft: PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pce-pcep-extension-for-pce-controller-09 Reviewer: Victoria Pritchard Review Date: 22/12/2020 IETF LC End Date: Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The draft is generally very good and the diagrams are also very helpful. [Shuping] Thank you! A few sections may initially cause a reader to be confused. I have suggested some reorganisation of the text in case this is helpful. I also found a few things which were unclear, which could be clarified in the document, and have included questions in the Minor issues section. [Shuping] Thanks for providing such detailed comments with suggested text. Much appreciated! Major Issues: No major issues found. Minor Issues: Section 5.4: I got confused reading this - the first part isn't clear but then extra information is given, but it would be better to be clear from the start... Here is some suggested text: --- During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise their support of and willingness to use PCEP extensions for PCECC using these elements in the OPEN message: o A new Path Setup Type (PST) in the PATH-SETUP-TYPE-CAPABILITY TLV to indicate support for PCEP extensions for PCECC - TBD1 (Path is set up via PCECC mode) o A new PCECC-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV to indicate willingness to use PCEP extensions for PCECC o The STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with the I flag set [RFC8281]) The new Path Setup Type is to be listed in the PATH-SETUP-TYPE-CAPABILITY TLV by all PCEP speakers which support the PCEP extensions for PCECC in this document. The new PCECC-CAPABILITY sub-TLV is included in PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object to indicate willingness to use the PCEP extensions for PCECC during the established PCEP session. Using flags in this TLV, the PCE shows the intention to function as a PCECC server, and the PCC shows willingness to act as a PCECC client (see Section 7.1.1). If the PCECC-CAPABILITY sub-TLV is advertised and the STATEFUL-PCE-CAPABILITY TLV is not advertised, or is advertised without the I flag set, in the OPEN Object, the receiver MUST: o Send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=TBD4 (stateful PCE capability was not advertised) o Terminate the session The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the corresponding Path Setup Type being listed in the PATH-SETUP-TYPE-CAPABILITY TLV. If it is present without the corresponding Path Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be ignored. If support and willingness are indicated by the PCE, but not by the PCC, the PCE MUST: o Send a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-Value TBD2 (Missing PCECC-CAPABILITY sub-TLV) o Terminate the PCEP session If support and willingness is indicated by the PCC but not the PCE, the PCE will ignore the capability. Unknown sub-TLVs are ignored in accordance with [RFC8408] and [RFC5440]. If one or both speakers (PCE and PCC) have not indicated support and willingness to use the PCEP extensions for PCECC, the PCEP extensions for PCECC MUST NOT be used. If a PCECC operation is attempted when both speakers have not agreed in the OPEN messages, the receiver of the message MUST: o Send a PCErr message with Error-Type=19 (Invalid Operation) and Error-Value=TBD3 (Attempted PCECC operations when PCECC capability was not advertised) o Terminate the PCEP session [Shuping] Thanks for a detailed suggested text, much appreciated. Note that the error handling is the same at both PCC and PCE. The description of the error case of the missing PCECC-CAPABILITY sub-TLV was incorrect which may have added to the confusion. Please see the updated version. --- Question: If the PCE shows support and willingness, but the PCC doesn't, and the session is closed, would the PCE attempt a new session without the use of these extensions for PCECC? [Shuping] The session is terminated only if the PCECC operation is attempted. Otherwise session is live and non-PCECC operations can go on! Question: If the PCC supports the extension but the PCE doesn't, is there already text elsewhere that says unknown Path Setup Types can be ignored by the PCE? The suggested text above may be wrong if not. [Shuping] The suggested text is updated now - "A legacy PCEP speaker (that does not recognize the PCECC Capability sub-TLV) will ignore the sub-TLV in accordance with [RFC8408] and [RFC5440]." Question: If the PCC does not support the PCECC extensions but the PCE attempted to start a PCECC operation, will the PCC be able to send an error (the error mentioned implies support but not willingness)? [Shuping] The error for unknown PST in RFC 8408 will kick in. I have added text for it. Section 5.5.1 PCE-Initiated PCECC LSP: Again this section seems a bit jumbled, confusing at the start, but with re-reading becomes clearer. Halfway down this section it says: "Note that the label forwarding instructions (see Section 5.5.3) from PCECC are sent after the initial PCInitiate and PCRpt message exchange with the ingress PCC." So the description above this, detailing the LSP-IDENTIFIER TLV and LSP object within the CCI, is not part of the first message exchange? If there needs to be an initial exchange without CCI first, to get the PLSP-ID etc, to put in the next set of PCInitiate messages, then this statement should go at the beginning of this section, maybe with a reference Figure 1, and state any differences to the usual exchange. I think from re-reading, it means the initial exchange as per RFC 8281 is modified with Path Setup Type set to TBD1, but still includes an LSP object (reserved PLSP-ID = 0, Delegate flag, SYMBOLIC-PATH-NAME TLV?) as in section 5.3 RFC 8281? [Shuping] Yes. Updated as per your suggestion. The diagram Figure 1 is really helpful. A few references to it in the description may help, particularly to indicate the initial exchange, then the CCI exchanges with all nodes, and describing in chronological order as shown in the diagram would help. [Shuping] Done. Section 5.5.3.1: What does it mean to "download the label" - does this just mean to parse the message or does it imply some further processing? [Shuping] It also includes updating the corresponding forwarding tables. Section 5.5.4: This section also seems to be a little out of order. I would remove the first sentence, start with the "make-before-break" procedure, make it clear these instructions are sent to the transit and egress PCCs first, then to the ingress PCC last. The diagram is again very good. [Shuping] Updated. Section 5.5.9: This is the first mention of the P flag - is this the same P shown in the earlier diagrams? Should the flag have been mentioned earlier? [Shuping] Removed the P flag from figure. Thinking a bit about it is better if this section is made part of draft-ietf-pce-binding-label-sid. I propose to remove the section, we can handle the below comment as part of the other I-D. Again the ordering could be improved. e.g. - PCE could allocate binding label on its own accord for a PCE-initiated or delegated LSP, and inform the PCC in the PCInitiate message or PCUpd message by including P=1 and TE-PATH-BINDING TLV - PCE could request that the PCC allocates the binding label by setting P=0 in the PCInitiate - If binding label is not supplied in PCInitiate, a PCC could request that the PCE allocate it by including P=1 D=1 and TE-PATH-BINDING TLV (with no Binding Value) in a PCRpt. The PCE would allocate the binding label ... In the capability exchange sections you mentioned error messages if someone attempts an operation without declaring support and willingness to use that capability - is there anything similar in case the binding label allocation is requested/allocated when the PCECC capability has not been agreed for the session? [Shuping] See above. Section 7.1.1 PCECC Capability sub-TLV: "Advertisement of the PCECC capability implies support of LSPs that are set up through PCECC" However, earlier this draft stated that advertisement of the capability is done using the path setup type, and that this PCECC capability TLV should not be included without the PCECC type also being listed in the Path-Setup-Type list (and should be ignored if the path setup type is not listed). So in this section we should avoid potential conflict with the earlier statement. Perhaps: "The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN Object in the PATH-SETUP-TYPE-CAPABILITY TLV, when the Path Setup Type list includes the PCECC Path Setup Type TBD1. A PCECC-CAPABILITY sub-TLV MUST be ignored if the PST list does not contain PST=TBD1." [Shuping] Updated. Should the new PATH-SETUP-TYPE be mentioned in the OPEN Object section too? [Shuping] Added. To match earlier sections, this section could use the word "willingness" when describing the L bit. [Shuping] Done. Section 7.3: The C bit - does it mean the PCC sets the C bit to indicate it has allocated the instruction rather than allocated the CC-ID - as far as I understood it, the CC-ID comes from the PCE? [Shuping] The identifier CC-ID is always allocated by PCE. The C bit indicates the label allocation to be done by PCC as prompted by the PCE. I have corrected the text. Nits: Section 5.3: Brackets around the reference to section 7.3 seem like they should be around the rest of the sentence "(see Section 7.3 for the encoding of the central controller instructions)." [Shuping] Updated to "This document defines a new PCEP object called CCI (Section 7.3) to specify the central controller instructions." Section 5.5: Should the Path Setup Type TBD1 be mentioned, to clearly identify that PCECC LSP is intended? [Shuping] Updated! The PCEP messages pertaining to a PCECC MUST include PATH-SETUP-TYPE TLV [RFC8408] in the SRP (Stateful PCE Request Parameters) object [RFC8231] with PST set to TBD1 to clearly identify that PCECC LSP is intended. Is the requirement of the PATH-SETUP-TYPE TLV in these messages new? This could be highlighted more clearly if so. [Shuping] Updated! This is the updated statement - "On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in the PATH-SETUP-TYPE TLV in the SRP object MUST be included for a LSP set up via the PCECC-based mechanism." This is the first time "SRP" has been used - should this be expanded? [Shuping] Done! Kind regards, Victoria Pritchard. This email and its attachments may contain confidential and/or privileged information. If you have received them in error you must not use, copy or disclose their content to any person. Please notify the sender immediately and then delete this email from your system. This e-mail has been scanned for viruses, but it is the responsibility of the recipient to conduct their own security measures. Airbus Operations Limited is not liable for any loss or damage arising from the receipt or use of this e-mail. Airbus Operations Limited, a company registered in England and Wales, registration number, 3468788. Registered office: Pegasus House, Aerospace Avenue, Filton, Bristol, BS34 7PA, UK. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
