Re: Destination-IP-Origin-AS Filter for BGP Flow Specification
Jeffrey Haas <[email protected]> Fri, 8 Nov 2019 12:11:06 -0500
| Newsgroups | gmane.ietf.idr |
|---|---|
| Message-ID | <[email protected]> |
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