Last Call Review of draft-ietf-pce-pcep-extension-for-pce-controller-11
review-ietf-pce-pcep-extension-for-pce-controller-11-genart-lc-mishra-2021-02-10-00

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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

Summary:
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:
None

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.