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

Lizhenbin <lizhenbin@huawei.com> Tue, 31 March 2020 07:30 UTC

Return-Path: <lizhenbin@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 73C3F3A1D1E for <idr@ietfa.amsl.com>; Tue, 31 Mar 2020 00:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 AqwJJ3XWKGCX for <idr@ietfa.amsl.com>; Tue, 31 Mar 2020 00:30:11 -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 C8B133A1D1D for <idr@ietf.org>; Tue, 31 Mar 2020 00:30:10 -0700 (PDT)
Received: from lhreml703-chm.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 7DCBFC4FF2D5D59B677 for <idr@ietf.org>; Tue, 31 Mar 2020 08:30:06 +0100 (IST)
Received: from lhreml703-chm.china.huawei.com ( by lhreml703-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; Tue, 31 Mar 2020 08:30:06 +0100
Received: from DGGEMM403-HUB.china.huawei.com ( by lhreml703-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; Tue, 31 Mar 2020 08:30:05 +0100
Received: from DGGEMM512-MBX.china.huawei.com ([]) by DGGEMM403-HUB.china.huawei.com ([]) with mapi id 14.03.0487.000; Tue, 31 Mar 2020 15:29:58 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <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: AdYGjhUttAt3lPHsTfmnpSciWcUkAAAhjKSCAAZrsTA=
Date: Tue, 31 Mar 2020 07:29:57 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D936D25E4@dggemm512-mbx.china.huawei.com>
References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> <2020033112223451917676@chinatelecom.cn>
In-Reply-To: <2020033112223451917676@chinatelecom.cn>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D936D25E4dggemm512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6dI-5gBh5W7Kx9QF0dM4y24lz8g>
Subject: [Idr] =?utf-8?b?562U5aSNOiAgV0cgQWRvcHRpb24gLSBkcmFmdC1saS1pZHIt?= =?utf-8?q?sr-policy-path-mtu-03=2Etxt_-_2_Week_WG_adoption_call_=283/30_-?= =?utf-8?q?_4/13=29?=
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: Tue, 31 Mar 2020 07:30:12 -0000

Hi WG,
I support the adoption. It is a useful case and after several rounds of refining the draft is ready for WG adoption.

Best Regards,
Zhenbin (Robin)

From: Susan Hares<mailto:shares@ndzh.com>
Date: 2020-03-30 20:35
To: 'IDR List'<mailto:idr@ietf.org>
Subject: [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