IETF Logo Mail Archive

Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Fri, 08 November 2019 01:48 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 C0FE81200CC for <idr@ietfa.amsl.com>; Thu, 7 Nov 2019 17:48:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9NY52nKmPfI for <idr@ietfa.amsl.com>; Thu, 7 Nov 2019 17:48:38 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D320B12004A for <idr@ietf.org>; Thu, 7 Nov 2019 17:48:37 -0800 (PST)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7D837DCDC23BD2BA2C0B for <idr@ietf.org>; Fri, 8 Nov 2019 01:48:36 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Nov 2019 01:48:35 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Fri, 8 Nov 2019 09:48:24 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: Robert Raszuk <robert@raszuk.net>, "wangaj3@chinatelecom.cn" <wangaj3@chinatelecom.cn>, Zhuangshunwan <zhuangshunwan@huawei.com>, "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification
Thread-Index: AQHVkzhgbTLi2TlKoUev/Znja6jzI6d8OJtQgAM+6oCAAQ4XsA==
Date: Fri, 08 Nov 2019 01:48:24 +0000
Message-ID: <1E61161D6E31D849BEA887261DB609348C9AA9E5@nkgeml514-mbx.china.huawei.com>
References: <CAOj+MMHLFxe94chd1woN74KeJy3UQa2mfSjXjrE7uudPBDw6KQ@mail.gmail.com> <1E61161D6E31D849BEA887261DB609348C9A97E0@nkgeml514-mbx.china.huawei.com> <20191107173733.GR3277@pfrc.org>
In-Reply-To: <20191107173733.GR3277@pfrc.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.142]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dPkGC-ojh-OGoiAz8UW0eXr_oG0>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification
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, 08 Nov 2019 01:48:40 -0000

Hi Jeffrey,

	Flowspec is designed for security protection, but current usage is not limited to security protection, 
    but also to optimize traffic. Using Flowspec to optimize traffic is safer and more reliable than send routes to router.

    Our scenario here is for optimize traffic. The actions here are all performed on the routers. You need to perform a FIB lookup to get dest-as.

    This does violate some of the current rules and introduces a certain performance penalty,
    but it can reduce the demand for Flowspec entry space, so you can use this rule in the appropriate scenario.

Regards, 
Haibo

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfrc.org] 
Sent: Friday, November 8, 2019 1:38 AM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
Cc: Robert Raszuk <robert@raszuk.net>; wangaj3@chinatelecom.cn; Zhuangshunwan <zhuangshunwan@huawei.com>; idr@ietf. org <idr@ietf.org>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Haibo,

On Tue, Nov 05, 2019 at 08:11:12AM +0000, Wanghaibo (Rainsword) wrote:
> PS: Netflow is already supporting statistical traffic based on Dest-IP-Origin-AS, it already download Dest-IP-Origin-AS to FIB entry, this prosess can be reused.

>From a forwarding perspective, this is the detail that bothers me.

Flowspec right now is currently independent of FIB state.  It functions on the firewall layer, which is typically implemented prior to FIB.

What this feature implies is something roughly like:
Packet comes in, hits rule to check dst-as.
dst-as lookup needs to happen as one of:
- communicate to BGP routing process. (not likely to scale)
- trigger a FIB lookup, check returned dst-as.  Violates pipelining in many
  architectures.
- Have the entire FIB's dst-as-map pushed into memory for firewall,
  implement as a longest-match lookup on that collection.

-- Jeff

v2.23.0 | Report a Bug | By Email