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:noreply@xxxxxxxx] > Sent: Thursday, February 11, 2021 7:03 AM > To: gen-art@xxxxxxxx > Cc: draft-ietf-pce-pcep-extension-for-pce-controller.all@xxxxxxxx; > last-call@xxxxxxxx; pce@xxxxxxxx > 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
