I wouldn't hold my breath, only very few will buy or use any value add services. I suspect it would be difficult to even recover the investment and support costs. If in addition to blackholing communities we'd offer communities to downgrade traffic, I expect almost no one would use it. In this service you'd set QoS-downgrade BGP community on DADDR and get as much dirty traffic in as you can without congesting any non-dirty traffic. And dirty traffic would remain marked with DSCP so you could identify which has been downgraded and further keep it downgraded inside your network, drop or redirect to analyzer. QoS downgrade requires no new investments, just configuration. But based on how little use advanced blackholing communities get, I expect it's not a good business case. Whole tier1 transit business case is in trouble, because we have two very different competing requirements, most of the volume is from CDNs who use IP transit as a cheaper wave service to load their caches. And CDNs are barely making ends meet, so you can't get more fat from them. CDN doesn't care about quality at all, they connect to everyone and use internal tooling to push traffic to the best performing path. Even if you have a partial view, they won't care. Then there are people who don't peer and only rely on ip transit for connectivity, who care a great deal about quality, but don't have any meaningful volume. It's hard to satisfy both in a single business case, one wants cheap that sometimes has useful paths somewhere. Another is less cost sensitive but always wants to have good reachability everywhere. On Wed, 11 Jun 2025 at 13:03, Douglas Fischer via NANOG <nanog@lists.nanog.org> wrote:
Today, from the point of view of coordinating DDoS attack mitigation, the biggest challenge is having a reference on whether the propagated external actions are having results or not. FlowSpec rules (or another method) are sent and we are left blind here, not knowing what is happening there and in what volume.
It is no longer news that there are IP Transit Providers that support Flowspec. Some limit it to 100 rules, some reach 500... And I am not talking about mitigation, just Flowspec. Today this is a differential, but I believe it will soon be commonplace.
I also remember hearing here at NANOG about some ITPs in which sending traffic flow is part of the transit product's feature set. My memory is not helping me remember whether the exported flow was of all traffic or if it was only of what was dropped.
On the other hand, there are mitigation companies that claim to "do some magic", but provide zero visibility of what was actually received and mitigated. A complete black box.
Looking at these positions in the market, I wonder if it is possible to expect any movement from the market, either from the demanders or from the suppliers of the product "IP Transit" that naturally involves Flowspec and also the export of NetSlow/sFlow that may have been dropped by the Flowspec rules sent. Does it make any sense to expect this? It is obvious that on the supplier side this involves CAPEX and OPEX and no one should expect this "for free". Costs related to this should be added to the price of the IP Transit product.
P.S.: These statements certainly refer to the FlowSpecv2 draft. But it expired in October 2024, and I have not followed the discussions about it anymore. And even if FlowSpecv2 magically became an RFC overnight, it would still take 3-4 years for it to enter the boxes in production on the Internet. So although I think the idea of FlowSpecv2 is excellent, I don't have high expectations for the short term.
-- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DQYSGXPZ...
-- ++ytti