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. 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. 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. 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. 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. Thanks Gyan On Mon, Mar 28, 2022 at 12:10 PM Dhruv Dhody <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 > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce