[Idr] 答复: WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

Huzhibo <huzhibo@huawei.com> Fri, 03 April 2020 07:53 UTC

Return-Path: <huzhibo@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B1C1D3A1396 for <idr@ietfa.amsl.com>; Fri, 3 Apr 2020 00:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hzDhKqzwdZDf for <idr@ietfa.amsl.com>; Fri, 3 Apr 2020 00:53:15 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18453A1395 for <idr@ietf.org>; Fri, 3 Apr 2020 00:53:14 -0700 (PDT)
Received: from lhreml705-chm.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 9344D3498047EB769786 for <idr@ietf.org>; Fri, 3 Apr 2020 08:53:13 +0100 (IST)
Received: from lhreml705-chm.china.huawei.com ( by lhreml705-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 3 Apr 2020 08:53:12 +0100
Received: from DGGEMM423-HUB.china.huawei.com ( by lhreml705-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Fri, 3 Apr 2020 08:53:12 +0100
Received: from DGGEMM529-MBS.china.huawei.com ([]) by dggemm423-hub.china.huawei.com ([]) with mapi id 14.03.0487.000; Fri, 3 Apr 2020 15:53:08 +0800
From: Huzhibo <huzhibo@huawei.com>
To: Susan Hares <shares@ndzh.com>, 'IDR List' <idr@ietf.org>
Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)
Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/aB4Q
Date: Fri, 3 Apr 2020 07:53:08 +0000
Message-ID: <06CF729DA0D6854E8C1E5121AC3330DFAF5D9355@dggemm529-mbs.china.huawei.com>
References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com>
In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_06CF729DA0D6854E8C1E5121AC3330DFAF5D9355dggemm529mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TCZT3SdtT92fr5riMQSMpMSM5b4>
Subject: [Idr] =?gb2312?b?tPC4tDogIFdHIEFkb3B0aW9uIC0gZHJhZnQtbGktaWRy?= =?gb2312?b?LXNyLXBvbGljeS1wYXRoLW10dS0wMy50eHQgLSAyIFdlZWsgV0cgYWRvcHRp?= =?gb2312?b?b24gY2FsbCAoMy8zMCAtIDQvMTMp?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2020 07:53:17 -0000

Traditional MPLS uses the LDP / RSVP protocol to obtain the Path MTU. Segment Routing removes the LDP / RSVP protocol and requires a new mechanism to calculate the Path MTU.
Support Adaption.


Zhibo Hu

发件人: Idr [mailto:idr-bounces@ietf.org] 代表 Susan Hares
发送时间: 2020年3月30日 20:36
收件人: 'IDR List' <idr@ietf.org>
主题: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-03.txt

You can view this draft at:

This draft distributes path maximum transmission unit for the
SR policy via BGP.

Any discussion regarding on whether one desires
SR Policy should be clearly distinguished from the
Technical discussions on the mechanisms to pass SR policy MTU.

The questions for the people to discuss on this draft are:

1) Is there a need for this mechanism in networks using
        MPLS-SR or SR-V6 and SR policy?

2) Are there any error handling issues besides what is being
     Taken care of in RFC7752bis-03.txt

3) Do you think this draft is ready to be adopted?
     In this category, please list any concerns you have
     regarding adoption.  This category can include
     general concerns about BGP-LS, MPLS-SR,
    SR-V6, and SR-Policy.

Cheers, Sue Hares