IETF Logo Mail Archive

Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Sat, 08 October 2022 02:28 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 21194C1524DC for <idr@ietfa.amsl.com>; Fri, 7 Oct 2022 19:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 WpMKsI3e68b3 for <idr@ietfa.amsl.com>; Fri, 7 Oct 2022 19:28:38 -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 90C20C1524D2 for <idr@ietf.org>; Fri, 7 Oct 2022 19:28:38 -0700 (PDT)
Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MkpwX6pqqz67Ncp; Sat, 8 Oct 2022 10:27:08 +0800 (CST)
Received: from kwepemi500001.china.huawei.com (7.221.188.114) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 8 Oct 2022 04:28:36 +0200
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi500001.china.huawei.com (7.221.188.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 8 Oct 2022 10:28:34 +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.031; Sat, 8 Oct 2022 10:28:34 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
CC: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, Zhuangshunwan <zhuangshunwan@huawei.com>
Thread-Topic: draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)
Thread-Index: AQHY2r2qvDvI4bVh3EGSyzZ8zldceg==
Date: Sat, 08 Oct 2022 02:28:34 +0000
Message-ID: <c76e223fd52942e7b8b2924f1de340c6@huawei.com>
References: <BYAPR08MB4872EEE329BDDDCC0F387B17B3559@BYAPR08MB4872.namprd08.prod.outlook.com>
In-Reply-To: <BYAPR08MB4872EEE329BDDDCC0F387B17B3559@BYAPR08MB4872.namprd08.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.204]
Content-Type: multipart/alternative; boundary="_000_c76e223fd52942e7b8b2924f1de340c6huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_xL8tHKryJ0lp4XOY73d7zE1OMg>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)
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: Sat, 08 Oct 2022 02:28:43 -0000

Hi Sue and WG,

I support the adoption of this draft.

Currently, more and more information is delivered by using the extended BGP address family through the controller.
Different from traditional BGP flooding, this mode requires filtering at the receive end. For example, the SR-Policy defines the method of directly filtering the receiver based on the RT.
However, this method is not applicable to some old address families, such as Flowspec. Therefore, it is necessary to introduce a common filtering mechanism at the receive end.

Best Regards,
Haibo

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, September 28, 2022 1:30 AM
To: idr@ietf.org
Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>; Zhuangshunwan <zhuangshunwan@huawei.com>
Subject: draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

This begins a 2 week WG adoption and IPR call for draft-dong-idr-node-target-ext-comm-05.txt.
https://datatracker.ietf.org/doc/draft-dong-idr-node-target-ext-comm/

The authors should respond to this email with an IPR statement.

The WG should consider in their discussion:
1) Will this new  transitive extended community help
in operational networks?

2) What conflicts does this new Extended Community have
with other functions in general BGP route distribution or
VPNs (EVPN, IPVPN)?

3) do you have any concern about the text in the draft?

Cheerily, Sue

v2.23.0 | Report a Bug | By Email