BGP Flowspec is usually described as the surgical replacement for RTBH: instead of dropping everything bound for an address, you drop only the flow that matches the attack. That holds only when the rule is precise, reaches the routers that matter in time, and is accepted by the networks upstream of you, and a DDoS test exists to find out which of those is true. Defined in RFC 8955 (2020, replacing RFC 5575 from 2009, with IPv6 in RFC 8956), it uses BGP itself to carry packet-filter rules to every router that peers with the one that announces them.
What a rule can say
A Flowspec announcement is a match plus an action. The match is built from up to twelve component types: destination and source prefix, IP protocol, port, destination and source port, ICMP type and code, TCP flags, packet length, DSCP and fragment state. Components combine, so one rule can say "UDP, source port 123, to this /24, packets longer than 400 bytes", which describes an NTP reflection flood and almost nothing else.
The action rides as a BGP extended community. A traffic-rate of zero means discard; a non-zero rate polices the flow to a ceiling. Redirect sends matching packets into a separate routing table, usually one that leads to a scrubbing center, and traffic-marking rewrites DSCP so the flow can be queued down rather than dropped.
That vocabulary is what makes it finer than a blackhole. The address under attack stays reachable for everything the rule does not describe.
Where it breaks
The first limit is acceptance. RFC 8955 has a receiving router validate a Flowspec route against the unicast best path for the same destination, so a network cannot announce filters for space it does not route. Many carriers go further and accept no customer Flowspec at all, or only scoped to the customer's own prefixes. If yours does not, your rules only take effect on your own edge, after the flood has already filled the circuit to you.
The second is hardware. Rules are installed in the router's filter memory, which is finite and shared with everything else that lives there. A platform that holds a few thousand entries will refuse or silently skip the rest, and some line cards support only a subset of the match types or actions. A rule that is valid on the wire can still be unenforced on the box.
The third is the rule itself. In March 2013 an automatically generated Flowspec rule at Cloudflare matched packets around 99,971 bytes long, far larger than any packet the network could carry. Routers that received it consumed their memory and crashed across the network, and the outage was far larger than the attack it was written for. A Flowspec mistake propagates exactly as fast as a correct rule does.
What a DDoS test measures
Propagation time comes first: from the moment a rule is announced to the moment matching packets stop arriving, measured at the target rather than read from a router's console. A rule that installs in four seconds on your edge and never reaches the upstream has done nothing for a saturated link.
Then precision. The test runs the attack alongside a legitimate traffic mix and counts what the rule catches on each side, because a match on protocol and port alone will often drop real users of that port too. The packet-length and TCP-flag components are where precision comes from, and also where platform support is thinnest.
Finally, withdrawal and capacity. The rule has to come off cleanly once the attack stops, and the test confirms how many rules the edge actually enforces before it begins to refuse more, which matters most under a multi-vector attack that needs several at once.
Choosing between a narrow rule you control and an upstream filter you have to request is a decision the on-premise DDoS testing guide works through.