Subject: [Gen-art] Genart last call review of draft-ietf-pce-pcep-extension-for-pce-controller-11

From: Gyan Mishra via Datatracker <[email-masked]>
Date: Wed, 10 Feb 2021 15:02:45 -0800

Reviewer: Gyan Mishra
Review result: Almost Ready

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.

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 11 Feb 2021 08:50:06 +0000

Hi Gyan, 

Many thanks for your review. Please find my responses inline below. 

I have also uploaded the new version of this draft according to your reviews and suggestions. . 

https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-12 
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-12

Please let us know if there is any further comments. 

Thank you!

> -----Original Message-----
> From: Gyan Mishra via Datatracker [mailto:[email-masked]]
> Sent: Thursday, February 11, 2021 7:03 AM
> To: [email-masked]
> Cc: [email-masked];
> [email-masked]; [email-masked]
> Subject: Genart last call review of
> draft-ietf-pce-pcep-extension-for-pce-controller-11
> 
> Reviewer: Gyan Mishra
> 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.
> 
> 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:
> 
> 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.
> 

This is covered in Section 3, I have added text to clarify further -

   As per Section 3.1.2. of [RFC8283], the PCE-based controller will
   take responsibility for managing some part of the MPLS label space
   for each of the routers that it controls, and may take wider
   responsibility for partitioning the label space for each router and
   allocating different parts for different uses.  The PCC MUST NOT make
   allocations from the label space set aside for the PCE to avoid
   overlap and collisions of label allocations.

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

OK, I have added -

   It is RECOMMENDED that
   PCE makes allocations (from the label space set aside for the PCE)
   for all nodes along the path.

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

I have added the following text, which includes the correct references -

   [RFC8283] examines the motivations and applicability for PCECC and
   use of PCEP as an SBI.  Section 3.1.2. of [RFC8283] highlights the
   use of PCECC for label allocation along the static LSPs and it
   simplifies the processing of a distributed control plane by blending
   it with elements of SDN and without necessarily completely replacing
   it.  This allows the operator to introduce the advantages of SDN
   (such as programmability) into the network.  Further Section 3.3. of
   [I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where
   the PCECC technique could be useful.  Section 4 of [RFC8283] also
   describe the implications on the protocol when used as an SDN SBI.
   The operator needs to evaluate the advantages offered by PCECC
   against the operational and scalability needs of the PCECC.

> encrypted sessions for all PCE PCC sessions to prevent malicious PCE using
> this extension.
> 
> Nits/editorial comments:
> “ This document specifies the procedures and PCEP extensions for using
> the PCE as the central controller.”
> 

Updated to -

   This document specifies the procedures and PCEP extensions for using
   the PCE as the central controller for provisioning labels along the
   path of the static LSP.

Best regards, 
Shuping

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 12 Feb 2021 03:35:13 -0500

Hi Shuping

I reviewed the updated version and it looks good ready for publication.

Kind Regards

Gyan

On Thu, Feb 11, 2021 at 3:50 AM Pengshuping (Peng Shuping) <
[email-masked]> wrote:

> Review
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 24 Feb 2021 16:18:06 -0500

Gyan, thanks for your review. Shuping, thanks for responding. I entered a No Objection ballot.

Alissa

> On Feb 12, 2021, at 3:35 AM, Gyan Mishra <[email-masked]> wrote:
> 
> 
> Hi Shuping 
> 
> On Thu, Feb 11, 2021 at 3:50 AM Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Gyan, 
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-12 <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-12> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-12 <https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-12>
> 
> > From: Gyan Mishra via Datatracker [mailto:[email-masked] <mailto:[email-masked]>]
> > To: [email-masked] <mailto:[email-masked]>
> > Cc: [email-masked] <mailto:[email-masked]>;
> > [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
> > 
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>