Re: IP Transit provider with Flowspec and NetFlow(sFlow) of dropped - Utopian?

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

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/DQYSGXPZ7ATXZDNWVLTYCHO5LV2TFG3R/



-- 
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/2KCUHVOQSW6EAEOTTGDNFXVTLITJRTCK/