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

Jeffrey Haas <jhaas@pfrc.org> Fri, 08 November 2019 17:11 UTC

Return-Path: <jhaas@pfrc.org>
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 EAF491208AB; Fri, 8 Nov 2019 09:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no 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 rGJeHrQCZB8t; Fri, 8 Nov 2019 09:11:08 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 604E012083C; Fri, 8 Nov 2019 09:11:08 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A05711E2F2; Fri, 8 Nov 2019 12:14:53 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <1E61161D6E31D849BEA887261DB609348C9AA9E5@nkgeml514-mbx.china.huawei.com>
Date: Fri, 08 Nov 2019 12:11:06 -0500
Cc: Robert Raszuk <robert@raszuk.net>, "wangaj3@chinatelecom.cn" <wangaj3@chinatelecom.cn>, Zhuangshunwan <zhuangshunwan@huawei.com>, "idr@ietf. org" <idr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <092F40A2-3FD5-4712-8147-D71DAAA86A6D@pfrc.org>
References: <CAOj+MMHLFxe94chd1woN74KeJy3UQa2mfSjXjrE7uudPBDw6KQ@mail.gmail.com> <1E61161D6E31D849BEA887261DB609348C9A97E0@nkgeml514-mbx.china.huawei.com> <20191107173733.GR3277@pfrc.org> <1E61161D6E31D849BEA887261DB609348C9AA9E5@nkgeml514-mbx.china.huawei.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>, idr-chairs@ietf.org
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fW95sUkPnNRUGM9J-mJ1Uq7zriw>
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 17:11:10 -0000

Haibo,

Thanks for the expected clarification.

To the chairs, as noted below the feature violates some fundamentals of flowspec architecture.  I'd strongly object to the feature being adopted without a new SAFI to get it out of the existing flowspec use cases.

-- Jeff


> On Nov 7, 2019, at 8:48 PM, Wanghaibo (Rainsword) <rainsword.wang@huawei.com> wrote:
> 
> 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