On Tue, 28 Jul 2026 at 16:40, Phil Bedard <bedard.phil@gmail.com> wrote:
Flowspec can be used to simply remark traffic into scavenger and on their own network many do that today. But like you mention the ability to put more granular guardrails on what gets accepted from others else isn’t really baked into the standards. FS can have more complex resource implications. You create a FS policy that has 6 match conditions and it will take up a lot more TCAM space. There were also some highly publicized outages caused by it early on when people did try using it downstream->provider.
We are just now looking into FS for an internal use-case, and the person testing the solution immediately got bitten by a customer affecting bug, they weren't trying to break it, they were just trying to make it work. So it still is fragile in 2026. I personally think it was implemented wrong, it should have had a route-target (or filter-target, filter-name, etc community) and by default it does absolutely nothing, until you attach said filter name somewhere in some direction in some way. The basic principle that it sits as a forwarding-plane filter is pretty insane to me, I guess some features community wants depend on ingres lookup happening, so it cannot always appear as ingress filter, but we should have given option do we associate it to given interface or as forwarding-filter with post-lookup keys. Like in Junos parleance filter could be term blaablaa { then { next filter flow-spec-filter microsoft; } } Part of your own filter, which you attach along with other terms in some interface in some direction. -- ++ytti