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

[Gyan Mishra <[e-mail]>]

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]> 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://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]]
> > Sent: Thursday, February 11, 2021 7:03 AM
> > To: [e-mail]
> > Cc: [e-mail];
> > [e-mail]; [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>.
> >
> > 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 A**rchitect *



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