Last Call Review of draft-ietf-pce-pcep-extension-for-pce-controller-09

Request Review of draft-ietf-pce-pcep-extension-for-pce-controller
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2020-12-23
Requested 2020-12-09
Requested by Deborah Brungard
Authors Zhenbin Li, Shuping Peng, Mahendra Negi, Quintin Zhao, Chao Zhou
Draft last updated 2020-12-22
Completed reviews Rtgdir Last Call review of -09 by Victoria Pritchard (diff)
Genart Last Call review of -11 by Gyan Mishra (diff)
Secdir Last Call review of -10 by Yaron Sheffer (diff)
Secdir Telechat review of -12 by Yaron Sheffer (diff)
Prep for IETF Last Call
Assignment Reviewer Victoria Pritchard 
State Completed
Review review-ietf-pce-pcep-extension-for-pce-controller-09-rtgdir-lc-pritchard-2020-12-22
Posted at
Reviewed rev. 09 (document currently at 14)
Review result Has Issues
Review completed: 2020-12-22



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

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


I have some minor concerns about this document that I think should be resolved before publication.


    The draft is generally very good and the diagrams are also very helpful.

    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.

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

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

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?

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.

Section What does it mean to "download the label" - does this just mean to parse the message or does it imply some further processing?

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.

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

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

Should the new PATH-SETUP-TYPE be mentioned in the OPEN Object section too?

To match earlier sections, this section could use the word "willingness" when describing the L bit.

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?


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

Section 5.5:
Should the Path Setup Type TBD1 be mentioned, 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.
This is the first time "SRP" has been used - should this be expanded?

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.