Internet core scale and market-based address allocation

Mon May 5 18:30:23 UTC 2003

> At 05:18 PM 5/5/2003 +0100, Sean M.Doran wrote:
> 
> >More importantly than keeping the "routing brain" underpowered
> >compared to run-of-the-mill PeeCees, constraining the amount
> >of state in the network gives us some system slack in making
> >time-space tradeoffs within a routing system (and parts thereof).
> >As an industry, we can cope with memory speed increases
> >levelling off, OR with specialized chip production slowing down.
> >Increasing the amount of state in the network destroys
> >a very important belts-and-braces approach to growth.
> 
> Very good point--the issue is one of the amount of core state, whether that 
> state is created through unicast BGP prefix advertisements or multicast 
> MSDP Source Active advertisements.
> 
> In each of these cases, I believe service providers should charge the 
> customer for state that is (or could be) created in the core.

What about those who are affected by state generated by someone else's
customers? Providers are already compensated by their customers.
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.

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.

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.

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.

This would, at least, provide consistency to filtering such that everyone
knows what to expect, rather than finding out that what they are doing
means they lack reachability to some parts of the network.

The place for determining that line, however, is not here, as we are
notoriously bitterly divided on the issue. However, a locked door BOF
wherein no one can leave until consensus is arrived at, might work. :)