IETF Logo Mail Archive

Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Wed, 24 August 2022 16:25 UTC

Return-Path: <rainsword.wang@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF12C1522D6 for <idr@ietfa.amsl.com>; Wed, 24 Aug 2022 09:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 1HiQAQvc-SqM for <idr@ietfa.amsl.com>; Wed, 24 Aug 2022 09:25:45 -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 8CBB6C14CF0A for <idr@ietf.org>; Wed, 24 Aug 2022 09:25:11 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MCWdl56Thz67h3l for <idr@ietf.org>; Thu, 25 Aug 2022 00:24:43 +0800 (CST)
Received: from kwepemi100001.china.huawei.com (7.221.188.215) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 24 Aug 2022 18:25:07 +0200
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi100001.china.huawei.com (7.221.188.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 25 Aug 2022 00:25:05 +0800
Received: from kwepemi500002.china.huawei.com ([7.221.188.171]) by kwepemi500002.china.huawei.com ([7.221.188.171]) with mapi id 15.01.2375.024; Thu, 25 Aug 2022 00:25:05 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
Thread-Index: AdixiH0y3ISbqR2CToODhF/zjyghUwCq0jlwAOhyD8A=
Date: Wed, 24 Aug 2022 16:25:05 +0000
Message-ID: <6f9c478a2ef745818e3ef3d713218dae@huawei.com>
References: <BYAPR08MB487262F752C8777A1B9698EFB36B9@BYAPR08MB4872.namprd08.prod.outlook.com> <d9e07ea96dd64ea081ba763941a22b17@huawei.com>
In-Reply-To: <d9e07ea96dd64ea081ba763941a22b17@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.90.198]
Content-Type: multipart/alternative; boundary="_000_6f9c478a2ef745818e3ef3d713218daehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/G57xbxQfxTIX3Io5t0r5FeZpbkU>
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 24 Aug 2022 16:25:46 -0000

Hi Sue and WG,

I support this adoption.
This draft proposes the mechanism to control the overflow of VPN routes within one VRF from influencing other VPNs on the same device automatically.

The updated contents have accommodated the suggestions and addressed the comments raised within the WG discussions. Some additional concerns can be addressed after the adoption.

I am not aware of any undisclosed IPR to this draft.

To make the actual progress of this draft, we should avoid to discuss the solved points back and forth. For example, RTC mechanism is not suitable for the scenarios that described in this adoption draft, because:
1) RTC has no any automatic detection mechanism to determine which RT should be withdrawn now.
2) It is unpractical to set the quota value for <RT>, or <RT, PE> under VRF, because RT can't uniquely distinguish one VRF on one PE.
3) It is dangerous to propagate the RT based filter rule unconditionally in the intra-domain or inter-domain wide, as that done in current RTC mechanism.

The conclusion, RTC is not the right direction to accomplish the goal.

Regards,
Haibo

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, August 16, 2022 11:56 PM
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

This begins a 2 week WG Adoption call for draft-wang-idr-vpn-prefix-orf-03.txt
https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf/

The authors believe that they have addressed the concerns raised in
the previous 2 WG adoption calls.

The WG should consider if:

1) The revised text answers the previous concerns regarding
the scope of this draft?

2) Does the revised text provide a useful function for
networks?

3) Are there any additional concerns regarding the new text?

Each of the authors should send an IPR statement for
this version of the draft.

The adoption call was moved to 8/29 to 8/30 to allow questions
to be asked at the IDR interim meeting on 8/29/2022 (10am - 12pm EDT).

Cheers, Sue Hares

v2.23.0 | Report a Bug | By Email