>What about those who are affected by state generated by someone else's
>customers? Providers are already compensated by their customers.To a first approximation, peers have business relationships. How money
flows (if any), how much bandwidth is available between the peers, how far
the peers will pass traffic for each other---those are all parts of the
business relationship between the parties.
Assuming peers are equal, their number of announcements are likely to
approximate each other with a zero-sum. However, the customers of these
peers are still contributing to my resource usage, as well as my
customer's usage. Should I pay my customer for someone else's deaggregation?
Certainly my customer is being affected by someone else's customer's
wanton deaggregation.
The only way this could possibly work is direct billing to those consuming
the resources by everyone who's resources are being consumed across the
entire network.
I believe that a fourth factor--the amount of state that each are willing
to accept and carry for the other--should be added to the equation.>The issue is when Joe Bob ISP's customer deaggregates their /16 into
>/24s for their own traffic engineering purposes which the rest of the
>internet has to bear without cost recovery.Cost recovery would be nice. The ability to make a profit would be even
better. The goal should be to financially reward the parties that can
handle complex state in their networks.
I'ld rather stay away from discussions of profit, and focus on simple
cost recovery from those who presently pollute for their own needs.
We also want to financially reward parties that do route
aggregation. Providers should have a financial incentive to hand out
provider-managed space to their customers. The obvious incentive is for
the provider to advertise a small number (one?) of short prefixes, with the
customers getting longer sub-allocations. That's how providers might
recover the costs of managing their provider-managed spaces.
I don't see financial rewards being possible or useful. At worst, in a
rewards based system, we have what we presently have. In a disincentive
based system, at worst, I'm compensated for my resources (and so are you,
our customers, our peers, etc.)
>The problem is how these 3rd parties bill Joe Bob's customer for
>their deaggregates, and how to identify approved (paid for) deags
>vs. unapproved deags.As you say--organizations de-aggregate to engineer where traffic
flows. Why are they motivated to do this? Because the costs of circuits
are a known quantity, and the cost of de-aggregation roughly zero. So a
fiscally rational organization will de-aggregate whenever and whereever
possible.If, on the other hand, each prefix advertisement had a cost associated with
it, then an organization would be able to make a de-aggregation decision
based on its local requirements. The organization might even decide not to
de-aggregate at all, if the prefix advertisement costs were high enough to
justify additional circuit costs.Consider the possibility of charging a peer one rate for transit state, and
a lesser rate for no-advertise state. That's what we do today already to
control bandwidth costs.
Following the peer/transit model, as I've explained above, is
insufficient, since the state is shared on all providers, and
their customers equally.
>The high-level model is fairly easy:
>1) largest aggregates are free
>2) more-specifics from within the same originating ASN are charged
>at rate X which is adjusted proportionally to prefix length
>(as length gets longer, the rate goes up).
>3) more-specifics from within different originating ASN are charged
>at rate Y (Y<X since meaningful content is more likely to exist), and
>again, adjusted proportionately to prefix length.Why should advertisements of varying lengths cost more (or less) than any
other? It's the routing table entry that costs, not the length.
a prefix of a shorter length (all other factors aside) has greater
value in a reachability framework. Someone would need to pay a lot
of money to get their /32s to be accepted by everyone, when said /32s
are already covered by someone else's /19.
>It is only when you get to the specifics that things start to break
>down.
>1) The prior identification of permitted/rogue routes
>2) The means through which these rates get set
>3) The means through which an ASN can contact 3rd parties in order
>to provide payment.
>4) The means through which an ASN can verify that the 3rd party has
>accepted their route, or is even eligible for payment (someone not
>running BGP isn't having any resources consumed).>Since this sort of settlement basis is (in my opinion) doomed to fail,
>the only other approach is what we have now, filtering everyone everywhere.
>What can and should be done is that the line in the sand is determined,
>agreed to, and adopted by everyone.Let me be clear--I don't believe that settlement should happen anywhere
other than within existing peering relationships.
and on this we disagree.
Recall that I'm also proposing that netblocks be treated as property, able
to be bought and sold. Part of the transaction cost would involve paying a
registry to register ownership, just as real estate or trademarks are
registered today.
Also here as well. I'll know the internet has signed its own death warrant
if this should ever occur.