[ppml] Revising Centrally Assigned ULA draft

[John Paul Morrison]

I would question why a small ISP would need to buy bigger hardware. I've 
setup small ISPs and multi-homed businesses and know that most don't 
really need full routes.
A small ISP can always default. Chances are one of their upstreams is 
either better or cheaper than the other one, and their backup link is 
more costly or slower. It's always been costly to run full BGP, and if 
small business or ISP doesn't want to keep pace, then that's their 
choice. They won't be out of business if they start filtering or 
defaulting.

Anyway, I think when we're talking about the fundamental scalability and 
future of the Internet, and basing policy that affects everyone - the 
argument has always been that the core would collapse if we did or 
didn't do X.  ("the sky is falling" argument). These vendors and 
presentations seem to show the complete opposite. 



David Williamson wrote:
> On Tue, Jun 19, 2007 at 09:54:07AM -0700, John Paul Morrison wrote:
>   
>> - 5 to 10 years of growth, scalability not yet limited by FIB/RIB size - 
>> (speed and forwarding path more the issue)
>> - No Need for Panic
>>     
>
> So the existing small ISP at the edge of the DFZ behind a couple of
> DS-3s is going to be fine?  Even if this poor sap buys bigger hardware
> to accomodate a larger FIB/RIB, how's he going to get a full table
> update (after maintenance or a crash) in a timely fashion?
>
> I agree there's no need for panic, but there's need for some serious
> work.  The biggest players are going to be pushing the edge of the
> RIB/FIB envelope.  The next set down in scale (but still near the
> "core", whatever that is) will be pretty much okay.  The little guys
> near the edge are going to be pretty screwed unless they put out some
> serious dollars.
>
> I don't think the scaling issues are solved for everyone.  Not even
> close.  There may be solutions for some, but it's not general.  The
> vendors can stand up and pat themselves on the back, but that doesn't
> mean this will all really work.
>
> Put me down in the class of cynics.  It's not entirely obvious to me
> that the network as we know it today will continue to operate nearly as
> smoothly as it does now (and I'm surprised that it does).  Without a
> forcing cuntion of some kind, there's no real possibility for change.
> We can all hope that the transition to IPv6 does that.  I suspect it
> won't.
>
> For ppml purposes, I'm very tempted to write a followup to 2007-6
> that's even less restrictive.  Let's remove all minimum allocation
> sizes from ARIN policies.  You get what you can justify.  That would be
> good stewardship of the number resources, even if it would be horribly
> bad for the routing system.  ARIN doesn't guarantee routability,
> though, so I don't see a problem there.
>
> If I do propose such a thing, I fully expect to get shouted down, even
> though I think it might be in the best interests of the network as a
> whole.  If it forces a change in the routing system (a loc/id split
> solution, or a way to monetize routing slots, or...something more
> creative) - that's good!
>
> Stoking the fires,
>
> -David
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070619/4e898d47/attachment.htm>