Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Sat, 07 May 2022 09:57 UTC

Return-Path: <pengshuping@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A667CC15E6EB; Sat, 7 May 2022 02:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXxmEnkLw3Rz; Sat, 7 May 2022 02:57:07 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFBEC15E6C5; Sat, 7 May 2022 02:57:07 -0700 (PDT)
Received: from fraeml744-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KwN7W6lz2z67Xgw; Sat, 7 May 2022 17:54:15 +0800 (CST)
Received: from canpemm500005.china.huawei.com (7.192.104.229) by fraeml744-chm.china.huawei.com (10.206.15.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 7 May 2022 11:57:02 +0200
Received: from canpemm500008.china.huawei.com (7.192.105.151) by canpemm500005.china.huawei.com (7.192.104.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 7 May 2022 17:57:00 +0800
Received: from canpemm500008.china.huawei.com ([7.192.105.151]) by canpemm500008.china.huawei.com ([7.192.105.151]) with mapi id 15.01.2375.024; Sat, 7 May 2022 17:57:00 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, Dhruv Dhody <dd@dhruvdhody.com>
CC: "draft-li-pce-pcep-pmtu@ietf.org" <draft-li-pce-pcep-pmtu@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
Thread-Index: AQHYQr5b73XaKm7qXEeeIVm25IxGuazVPhMAgD2gT6A=
Date: Sat, 07 May 2022 09:57:00 +0000
Message-ID: <1454307f7d104369899fcddbf4c178cd@huawei.com>
References: <CAP7zK5bC95SwqbPC-Fm1-bTyAmaVOb-O5Bg4CKqe3tSe=LUzZQ@mail.gmail.com> <CABNhwV2CC9vOnkyczt08OWZ1VAF2M0VwCTpN-gdHMPrgRCGMwg@mail.gmail.com>
In-Reply-To: <CABNhwV2CC9vOnkyczt08OWZ1VAF2M0VwCTpN-gdHMPrgRCGMwg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.41.150]
Content-Type: multipart/related; boundary="_004_1454307f7d104369899fcddbf4c178cdhuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/oakpbSl2IahtGBus-4aUNopRuyI>
Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 May 2022 09:57:11 -0000

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:hayabusagsm@gmail.com]
Sent: Tuesday, March 29, 2022 12:24 PM
To: Dhruv Dhody <dd@dhruvdhody.com>
Cc: draft-li-pce-pcep-pmtu@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 <dd@dhruvdhody.com<mailto: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<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347