Re: RTBH Support Across the Industry

[Saku Ytti via NANOG <nanog () lists nanog org>]

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
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/JVCTZQPIE6UQU45EOOH642ZT3OCTWZWL/