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

[Alissa Cooper <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 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) <[e-mail] <mailto:[e-mail]>> wrote:
> 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://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>
> 
> Please let us know if there is any further comments. 
> 
> Thank you!
> 
> > -----Original Message-----
> > From: Gyan Mishra via Datatracker [mailto:[e-mail] <mailto:[e-mail]>]
> > Sent: Thursday, February 11, 2021 7:03 AM
> > To: [e-mail] <mailto:[e-mail]>
> > Cc: [e-mail] <mailto:[e-mail]>;
> > [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> > Subject: Genart last call review of
> > draft-ietf-pce-pcep-extension-for-pce-controller-11
> > 
> > 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 <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.
> > 
> 
> 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.
> 
> 
> > 
> > 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.
> > 
> 
> 
> 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
> -- 
>  <http://www.verizon.com/>
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>