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.

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 <dd@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.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*