Hi, Julien, Dhruv, all, Thank you very much for the detailed review and comments, the update is now integrated in -20. Besides the comments raised in this email, the comments from rtgdir early review (reference to https://datatracker.ietf.org/doc/review-ietf-pce-pcep-stateful-pce-gmpls-19-rtgdir-early-hares-2022-06-22/ ) are also addressed.
Thank you. Best wishes, Haomian (on behalf of authors & contributors) 发件人: Dhruv Dhody [mailto:[email protected]] 发送时间: 2022年6月23日 23:28 收件人: Julien Meuric <[email protected]> 抄送: [email protected]; [email protected] 主题: Re: [Pce] Chair Review of draft-ietf-pce-pcep-stateful-pce-gmpls-19 Thanks Julien! As a shepherd, I want to thank you for your review and for providing another pair of eyes! Authors, once these and the early RTGDIR review comments are handled, we are ready to ship this I-D to our AD. Thanks for your work! Regards, Dhruv On Thu, Jun 23, 2022 at 8:50 PM <[email protected]<mailto:[email protected]>> wrote: Dear authors of draft-ietf-pce-pcep-stateful-pce-gmpls, Considering the level of change after the shepherd's review of the aforementioned I-D, I've performed a 2nd review. Only some minor issues/nits remain. Please find them below. - Page 1: s/provides extensions required/provides the extensions required/ - P.4: * s/do not cover the GMPLS networks/do not cover GMPLS-controlled networks/ * OLD: The various requirements for stateful GMPLS including PCE-initiation for GMPLS LSPs is provided in Section 4. An overview of the PCEP extensions are specified... NEW: The various requirements for stateful GMPLS, including PCE-initiation for GMPLS LSPs, are provided in Section 4. An overview of the PCEP extensions is specified... - P.5: * s/the LSP delegated to the PCE/the LSPs delegated to the PCE/ * s/the change of the LSP./the change of the LSPs./ * s/sent by PCC to PCEs./sent by PCCs to PCEs./ * s/An LSP Initiate Request (PCInitiate) messages are/An LSP Initiate Request (PCInitiate) message is/ * s/The PCE-Initiated LSP would follow/PCE-initiated LSPs follow/ - P.6: * Knowing that the END-POINT line formatting used to be broken, considering a different character for the 2nd level of bullets may limit the ambiguity in further editions. * s/MUST be use to specify/MUST be used to specify/ * s/and not in this document as well./nor in this document./ - P.10: * A title should be added after the figure. * s/X bit is defined in [RFC5521]./X bit: Same as the X bit defined in XRO sub-objects by [RFC5521] (i.e. mandatory vs. desired)./ - P.11: * OLD: If the PCC supports the extensions as per this document (understands the U flag that indicates the stateful LSP-UPDATE-CAPABILITY) but did not... NEW: If the PCC understands the U flag that indicates the stateful LSP-UPDATE-CAPABILITY but did not... * OLD: If the PCE supports the extensions as per this document (understands the R flag that indicates the stateful LSP-REPORT-CAPABILITY) but did not... NEW: If the PCE understands the R flag that indicates the stateful LSP-REPORT-CAPABILITY but did not... - P.12: * OLD: If the PCC supports the extensions as per this document (understands the I flag that indicates LSP-INSTANTIATION-CAPABILITY) but did not... NEW: If the PCC understands the I flag that indicates LSP-INSTANTIATION-CAPABILITY but did not... * OLD: A stateful PCE performs the re-optimization when the R bit is set in RP object. NEW: A stateful PCE is expected to perform an LSP re-optimization when receiving a message with the R bit set in the RP object. - P.13: * s/the receiving PCE or PCC would send/the receiving PCE or PCC MUST send/ Regards, Julien _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
