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

"Wanghaibo (Rainsword)" <[email protected]> Mon, 11 Nov 2019 07:21:17 +0000
Newsgroups gmane.ietf.idr
Message-ID <1E61161D6E31D849BEA887261DB609348C9BF7D5@nkgeml514-mbx.china.huawei.com>
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:[email protected]] 
Sent: Saturday, November 9, 2019 1:11 AM
To: Wanghaibo (Rainsword) <[email protected]>; [email protected]
Cc: Robert Raszuk <[email protected]>; [email protected]; Zhuangshunwan <[email protected]>; idr@ietf. org <[email protected]>
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) <[email protected]> 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:[email protected]]
> Sent: Friday, November 8, 2019 1:38 AM
> To: Wanghaibo (Rainsword) <[email protected]>
> Cc: Robert Raszuk <[email protected]>; [email protected]; 
> Zhuangshunwan <[email protected]>; idr@ietf. org <[email protected]>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/idr