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. :)