[ppml] Principles for IPv6 PI allocations to end sites
--On February 9, 2006 3:04:13 PM -0500 Edward Lewis <Ed.Lewis at neustar.biz>
> I wish I had an answer. (I knew that when I spoke up.)
> But seriously, the drive to want provider independent space is a
> reaction to not be willing to rely on a single ISP. I'll go further
> out the limb and say "not willing to rely on a single ISP to be
WHile that's a technically accurate summary it is also misleading.
Specifically, there are many forms of that problem which have distinct
+ ISP does not reliably deliver traffic
+ ISP goes out of business
+ ISP stops performing well
+ ISP raises fees beyond what is competitive/reasonable
The bottom line is that no sane enterprise (or even small business with a
significant dependence on internet for it's business) would accept being
locked into a single provider. Sure, lots of people have grudgingly
accepted this in IPv4 to a certain extent. However, wholesale expansion
of this error into a new protocol (IPv6) is not the right answer.
> If I'm worried about reaching the largest audience, then all I want
> is a global transit provider with fat pipes. Unlike placing a mall
> at the cross roads to attract more vehicle traffic, placement of
> servers isn't so sensitive to diverse topology. (Fewer hops yes, but
> 30 T-1's are not better than a single T-3, other things being equal.)
Well... A global transit provider which will:
+ Never raise its prices
+ Reliably lower its prices as economics change
+ Never go down
+ Never misroute packets
+ Never do stupid things because of bogus billing disputes
+ Never go out of business
> I think back to the April 2001 ARIN meeting (in SF) which happened
> right after an ISP suddenly went belly up and folks went scrambling
> for a new provider.
> I mention that because that is why I think provider independent space
> is an important topic - of course I may be wrong which is why I'm
> laying my cards on the table.
I completely agree.
If this message was not signed with gpg key 0FE2AA3D, it's probably
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 186 bytes
Desc: not available