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