[ppml] Just say *NO* to PI space -- or how to make it lessdestructive

[Davis, Terry L]

Scott

Good points.

I might also ask folks to think back to the mid-nineties when the v6
designs were initiated.

In 95 few businesses considered their network links to be "business
critical", we couldn't have known that the corporate world would expect
network reliability of 5 9's as a baseline today.

Nor could we have guessed even in 2000 that our network reliability and
outage recovery plans would be part our Sarbanes-Oxley audits.

What I can tell you now is that because of these fundamental changes in
business globally, the deployment model we envisioned in the
mid-nineties won't work for business today.

-There is simply no way that large corporations would sign up with a
"single provider" for their IP addresses.  The network is now the life
blood of business and I don't know of any business executive that would
permit themselves to be tied to a single supplier for something so
critical to their bottom line.

-Likewise, multi-homing to business is now a de-facto network
expectation of most large corporations.  As I said, they expect to
deploy regional/national/global networks that have seamless connectivity
with their sites and 5 9's or better of reliability.

-I'm not even sure if a single service provider for this level of
business criticality would pass the Sarbanes-Oxley audits.  Business, in
the post Enron environment, has a level of responsibility to their
shareholders that they never could have envisioned a decade ago.

In the decade it has taken us to be ready to deploy IP-v6, the world we
based many of the deployment concepts of IP-v6 on has changed radically.

We need to find a way to accommodate these changes in the relationship
of the network to business; PI space is the only concept that I have
seen so far that will provide business with the service model they now
need.

I'm virtually certain that most large and/or international corporations
won't deploy IP-v6 unless they can make the service model fit their
business needs.

Take care
Terry

> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com]
> Sent: Thursday, April 20, 2006 7:10 AM
> To: Pekka Savola
> Cc: ppml at arin.net; address-policy-wg at ripe.net;
global-v6 at lists.apnic.net
> Subject: Re: [ppml] Just say *NO* to PI space -- or how to make it
> lessdestructive
> 
> On 04/20/06 at 4:48pm +0300, Pekka Savola <pekkas at netcore.fi> wrote:
> 
> > Now, from practical point of view, it seems there is strong "need"
for
> > PI, and it might be a PI policy of some kind might actually get
> > through.
> 
> Very true.  I'd even s/might/will/.
> 
> > If so, the policy should be such that it minimizes the bad effects
of
> > PI and encourages people to use other solutions if those are viable
> > for them (unfortunately, the only way to achieve that appears to be
> > $$$$), in particular (in the rough order of importance):
> >
> >   1. Each assignment must be accompanied by a recurring fee (at
least
> > 1000-2000 USD/EUR a year, preferably 5000+).  This is peanuts
> > (compared to other costs) to anyone who actually needs this
> > multihoming solution.  However, this ensures at least some minimum
> > usage barrier ("those who don't really need this can use different
> > multihoming solutions"), and recovery of the resources back to RIR
> > after the company has gone bankrupt or no longer needs the
addresses.
> > If you don't know where to put the extra money, donate it to ISOC or
> > something.
> 
> As has been discussed at ARIN, this is a good way to get the
government to
> declare the RIR a monopoly engaging in anticompetitive behavior.  I
for
> one don't want that.
> 
> Now if you think ISPs should start charging end sites for the
privilege
> of running BGP, that might fly.  ISPs in the DFZ are bearing the costs
of
> maintaining the extra routes*, so they can justify a per-route charge,
and
> they actually have contracts with their customers, so they can
collect.
> (* Yes, other end sites in the DFZ also bear those costs, but since
they
> contribute routes to the table as well, and can sometimes switch to
> default-only BGP, I'd argue that DFZ ISPs are the ones stuck "holding
the
> bag" of routing table growth.)
> 
> >   2. one-size-fits-all assignments, period.  You get a /48 or /32 (I
> > don't have much preference here), but you must not be able to
justify
> > for larger space.  This is to avoid the organization from getting a
> > larger block and chopping it into smaller pieces and polluting the
> > global routing table with more specifics which would get past prefix
> > length filters.
> 
> With the current ARIN policy proposal, you'd get a /48, with a /44
> reserved for growth.  Would you advocate giving everyone a /44 up
front
> instead?  Or something else?  I don't have too much preference here,
FWIW.
> 
> >   3. assignments from a separate address block, set aside for PI.
To
> > ease strict "assignment-size only" filtering of these blocks.
> 
> This is already a part of 2005-1, and has been a part (expressed or
> implied) of every other PI proposal I've seen.
> 
> -Scott
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml