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

Hi,

Per my understanding of the existing types defined in that section, it does not preclude the extensions of new types with new behaviors.

Thanks,
Shunwan

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Zhuangshunwan
Sent: Monday, November 11, 2019 8:41 PM
To: Robert Raszuk <robert@raszuk.net>; Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
Cc: idr-chairs@ietf.org; wangaj3@chinatelecom.cn; idr@ietf. org <idr@ietf.org>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Hi Robert,

The sentence you quoted simply says that the existing type can perform such behavior, and not “Must” or “Should”.

Thanks,
Shunwan

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, November 11, 2019 7:50 PM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>; idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>; wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Wanghaibo,

Flow spec 5575 and 5575bis limits to what can be used as match criteria to IPv4/IPv6 IP layer and transport layer headers:

"The following sections define component types and parameter encodings for the IPv4 IP layer and transport layer headers."

Your proposal can not proceed under FlowSpec umbrella as packet's target ASN is not carried in any of the packet headers so it can not be applied as a packet ACL.

If you want to continue with this extension let's use a different SAFI and preferable a different name.

Thx,
R.

On Mon, Nov 11, 2019 at 8:21 AM Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>> wrote:
Hi Jeffrey,

        Thanks for your suggestion.

        Flowspec is intended to match only the message fields.
        Our solution here is an enhancement to Flowspec, which can effectively reduce the space of the flowspec.

        The rules here are also used in conjunction with the existing Flowspec rules, so using the new SAFI to describe it is not appropriate.
        We can increase OPEN capability negotiation to enable when this feature is supported.

Regards,
Haibo

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

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<mailto: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<mailto:jhaas@pfrc.org>]
> Sent: Friday, November 8, 2019 1:38 AM
> To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>
> Cc: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>;
> Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>>; idr@ietf. org <idr@ietf.org<mailto: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

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr