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

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 General Area Review Team (Gen-ART) (genart)
Deadline 2021-02-08
Requested 2021-01-25
Authors Zhenbin Li, Shuping Peng, Mahendra Negi, Quintin Zhao, Chao Zhou
Draft last updated 2021-02-10
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)
Assignment Reviewer Gyan Mishra 
State Completed
Review review-ietf-pce-pcep-extension-for-pce-controller-11-genart-lc-mishra-2021-02-10
Posted at
Reviewed rev. 11 (document currently at 14)
Review result Almost Ready
Review completed: 2021-02-10


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-pce-pcep-extension-for-pce-controller-??
Reviewer: Gyan Mishra
Review Date: 2021-02-10
IETF LC End Date: 2021-02-08
IESG Telechat date: 2021-02-25

This document is very well written and describes a new PCEP protocol extension for using PCE as a centralized controller PCECC for provisioning using its own discrete label space for all or discrete parts static LSP ERO path.  

Major issues:

Minor issues:

For stateful PCE how do you prevent label collisions when both the PCE is provisioning using its own label space and the routers also are using their own label space as well and have a mix of both.  After the label download and sync at each router hop PCE PCC session their maybe some nodes that use the router label space  and other nodes using PCE label space.

It would seem more complicated to have a mix of having both PCE managed label space and non PCE managed label space and for this draft since it’s about provisioning static LSP using PCE discrete label space I think it would make more sense to have entire LSP to be provisioned using PCE label space to prevent label collisions.  This caveat I think should be added to the considerations section as well.   I did not see it mentioned but I think it’s also worthwhile mentioning what is the advantage of using this extension where the PCE uses its own label space.  Also list the disadvantages as well so the operator had a clear picture of reasons to use this extension and maybe reasons to not use.  It maybe also worthwhile to mention use cases where it makes sense to use this extension and others where it is not.

In section 9 I agree it’s a good idea to have mutually authentication and encrypted sessions for all PCE PCC sessions to prevent malicious PCE using this extension.

Nits/editorial comments:
The abstract states the following in the last sentence which I think should better describe the goal and purpose of the draft.

“ This document specifies the procedures and PCEP extensions for using the PCE as the central controller.”

I would say use of PCE as a centralized controller for provisioning RSVP-TE or SR-TE static LSP explicit ERO path for all or parts of an LSP using its own discrete label space.