[ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use))

[Scott Leibrand]

Yes, TE deaggregation is worth money, and yes, transit customers will 
pay their transit providers to accept such deaggregates, just as 
Internap's customers did, and Internap in turn did.  (Remember, Internap 
bought transit from most tier 1 providers, and payed money to filterers 
like Verio to accept Internap's deaggregates.)  I'm not talking here 
about rejecting more-specifics from one's own customers: that is just 
dumb.  What I'm talking about, instead, is filtering "distant" 
more-specifics: those outside their sphere of usefulness.  (as-pathlimit 
would be a quite useful way to do this.) 

I agree with you that an "unfiltered" BGP feed will be a competitive 
advantage, and will command a price premium.  That price premium will be 
required to fund the beefier routers required to continue handling a 
full, unfiltered table.  At the same time, however, lower-cost providers 
will be free to choose to filter their BGP tables, saving money on 
routers, and passing those savings on to their customers.  They can 
also, if they wish, buy transit and point default at someone who doesn't 
filter, as a catch-all to ensure reachability to more-specific prefixes 
not covered by an announced aggregate.

This (filtering the fragmenting IPv4 routing table) won't be about "the 
good of the Internet": it'll be about business.  Some ISPs will choose 
the high-end market, and buy 2M or 10M route routers to handle the 
fragmentation.  Some ISPs will choose to filter some routes, but accept 
most and use a default to ensure full reachability.  Others may choose 
to filter aggressively and accept some collateral unreachability.

The key here is that we must choose, among our alternate realities, one 
that preserves freedom of choice.  If we choose the future of APNIC 
prop-050: IPv4 address transfers, we eliminate the choice to filter 
deaggregation, and leave ourselves with no choice but to keep up with an 
exploding route table or withdraw from the DFZ.

-Scott

Paul Vixie wrote:
>> ... yes, I do think this kind of thing will be self-correcting, for one
>> simple reason: you don't have to know who's doing it to filter effectively.
>>     
>
> i think you're being overly optimistic.
>
>   
>> All you need to know is what the minimum allocation size for each address
>> range is.  (I know you know all this already, but I'm sure there are others
>> who don't.)  A quick look at
>> http://www.iana.org/assignments/ipv4-address-space and
>> http://www.arin.net/reference/ip_blocks.html gives me a pretty good idea
>> that I could filter, more or less safely, anything larger than /8 in the 0/8
>> to 56/8 range (with a couple exceptions, like down to /20 in 24/8), down to
>> /16 in the 128/8 to 172/8 range, down to /20 in the 63/8 to 99/8 range, etc.
>>     
>
> i don't think it's anywhere near that simple.  also, even if you find a way
> to express it, if others accept these routes and you don't, then your support
> queue fills up and theirs does not, and perhaps customers leave you and go to
> them.
>
>   
>> If I were to implement such a policy, I'd first take a good hard look at my
>> BGP table (rather than the cursory look I just did), but it's by no means
>> necessary to identify the specific players doing the deaggregation in order
>> to appropriately filter it.
>>     
>
> ah, the irony.  i guess what went around came around?  internap used to be one
> of the worst TE deaggregators.  welcome to concern about other folks'
> deaggregation and global routing table size and shared fate.  <smirk>
>
>   
>> If my reading of history is correct (as it was mostly before my time), 
>> we've been through something similar before, with a number of players 
>> filtering down to minimum allocation size for many years before routers 
>> caught back up with the size of the table and the filters became more of 
>> a problem (affecting reachability of folks not advertising their 
>> aggregate route) than they were worth.  But if we see a high level of 
>> deaggregation of allocated netblocks (without a change in the underlying 
>> IANA or RIR allocation), I suspect we'll see a return of these prefix 
>> length filters.
>>     
>
> they'll return, but relaxing them for one's customers will be common, and
> relaxing them for peers in exchange for reflexive relaxation from peers will
> be common.  recurring revenue is king.  "unfiltered" will be a competitive
> advantage.  you cannot count on others doing the right thing for the internet
> (or else i'd be able to count on you to deploy V6 right now as an incentive
> to get others to do likewise since they could reach internap even on V6.)
>
> ps. i am not speaking as an arin trustee in this message.
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
>