Hi Gyan, Thank you for your support and suggestions.
Since this draft is going to be refined considering the new draft being built in SPRING, the current uploaded draft is not changed accordingly. Please find more responses in line below. From: Gyan Mishra [mailto:hayabusa...@gmail.com] Sent: Tuesday, March 29, 2022 12:24 PM To: Dhruv Dhody <d...@dhruvdhody.com> Cc: draft-li-pce-pcep-p...@ietf.org; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05 Hi Dhruv I reviewed the draft and support WG adoption. Should this draft be adopted by the PCE WG? Yes Please state your reasons - Why / Why not? This documents PCEP PMTU extension is valuable for any operator deployments of SR-MPLS or SRv6 and/or uses SR-TE and want to ensure that fragmentation does not occur along the stateful path instantiated. What needs to be fixed before or after adoption? The document well written and to the point and is ready for adoption Are you willing to work on this draft? Yes I would be happy to collaborate on the draft Review comments should be posted to the list. Few comments for the authors below: It maybe worthwhile to mention PMTUD path MTU discovery which allows a TCP session to dynamically adjust the MSS for incoming and outgoing MSS. As this document utilizes PMTU which is based on the PMTUD concept which is being carried in a new metric field in the PCEP report message I think for clarity it would. BGP uses TCP and by default most all vendor implementations have PMTUD enabled by default on all BGP sessions. Maybe worthwhile mentioning. Shuping> This document just defines a new metric type for PCEP, I am not sure if we need to repeat the benefit of why MTU discovery is useful. And if something must be said than just a reference to existing RFC should suffice. In the abstract I don’t understand this sentence. Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available. Shuping> For RSVP-TE signaled paths we have mechanism in RSVP-TE signaling to get path-MTU. In SR we do not have this mechanism. The above text is highlighting this point. I understand SR eliminates the control plane signaling for label distribution LDP which is now via IGP extension, but how does that make it so the SR MTU information is not available. Directed LDP is for adjacency nodes or targeted LDP for session protection for non directly connected nodes. RFC 5036 LDP does not support signaling for MTU. RFC 7552 LDP updates for IPv6 also does not support signaling for MTU. RFC 3988 is an experimental extension to support signaling for MTU. I see RFC 3988 as a informational reference. I think it would be good to mention what I stated above related to LDP not providing any signaling for MTU and RFC 3988 as its experimental and not standard track also not implemented by all vendors. Shuping> PCE plays no role in LDP, you will not find any such information in any PCE document. Section 3.5 mentions that path MTU adjustment can be made for primary or TI-LFA local protection path. I would think this can be used for SR-TE protected path instantiated by stateful PCE but not for local protection. Shuping> The text says that the overhead because of TI-LFA can still be calculated and adjusted. Also would this draft be applicable to Non SR MPLS and GMPLS LDP signaling RFC 3988 is experimental only so MPLS and GMPLS as well have a gap for MTU signaling. I do see you stated in the introduction. You may want to state the gap that exists as RFC 3988 is experimental and now this solution fills that gap as well. Shuping> This can be used for other path setup types. But PCE plays no role in LDP and thus your comment does not apply. Thank you! Best Regards, Shuping Thanks Gyan On Mon, Mar 28, 2022 at 12:10 PM Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> wrote: Hi WG, This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05. https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/ Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list. Please respond by Monday 11th April 2022. Thanks! Dhruv & Julien _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce -- [图像已被发件人删除。]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
