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) < pengshup...@huawei.com> 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:nore...@ietf.org] > > Sent: Thursday, February 11, 2021 7:03 AM > > To: gen-...@ietf.org > > Cc: draft-ietf-pce-pcep-extension-for-pce-controller....@ietf.org; > > last-c...@ietf.org; pce@ietf.org > > 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
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
