[ppml] Proposed Policy: PI assignments for V6

[Owen DeLong]

> i think it is not a good idea to accept this policy _now_
>
OK... We can agree to disagree on this.

> i think that probably a PI assignment policy will be needed in the
> future, but i wouldn't promote it now.
>
I think it is more needed now than it may be in the future, and, if that
is the case, we can always repeal it in the future if that is desirable to
the community.

[snip -- stuff about theory that IETF will produce a good multihoming 
solution
for PA space eventually and we should all just wait]

> In any case, as you may well notice, any multihoming solution compatible
> with PA addressing will require that:
> - multiple PA prefixes configured in the multihomed sites (instead of one)
> - it won't provide PI addressing (so a multihomed site will still have to
> renumber if it changes providers)
> This two reasons make it a priori an inferior solution to obtaining PI
> addressing on the eyes of the multihomed site, even though it is a much
> superior solution in the eyes of the community since it preserves global
> routing system scalability.

I think you have a different perception of the community than many on this
list.  The community includes the multihomed organizations as well as the
providers.  The reality is that PI as implemented in V6 currently provides
yet another path for provider-lockin through the difficulty of renumbering
and many organizations do not consider that a palatable situation.  If v6
ever delivers a solution that solves the various issues (multihoming in
various forms is but one of the issues) related to PA space, then, we can
revisit and possibly repeal the policy.  Unlike the v4 swamp, there's no
address space in v6 that isn't subject to renewal by the registry.  As such,
policy changes can, in the v6 world, correct past allocation policies in
the long run.

> In any case, if a PI assignment policy is adopted, the PA compatible
> multihoming solution won't get any chance to get deployed i guess, since
> i guess that multihomed sites will have the following choices:
> - A PA compatible solution which: doesn't provides provider independence,
> requires multiple prefixes and it is new i.e. no experience, no products,
> no previous knowledge
> - a PI multihoming solution: everything works as you already know
> What do you think multihomed sites will choose?
>
Or translated:

You want to see PA multihoming get adopted even though you know it will
be perceived as an inferior solution by a significant portion of the
community.  Therefore, you think ARIN should block the solution which is
perceived as superior in order to support the other one.

Provider independence is a BIG IMPORTANT factor to a lot of organizations
in the community.

> My proposal is to wait until a PA compatible solution for multihoming is
> developed and some experience is gained with it. Then we can see if it is
> useful and especially who is useful for. Probably it won't be good enough
> for some sites, and probably then we will need a PI asignment policy to
> satisfy the need of those sites.
> But we shouldn't do it now, that the multihoming solution is not yet
> here, and we would be killing it before it comes.
>
If it's truly beneficial when it comes, we can look at repealing this policy
or providing incentives for it.  However, many organizations have real 
networks
to run in the meantime.  We shouldn't abandon this policy just because it
might interfere with the adoption rate of some future proposal that may or
may not meet the desires of the community.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20041206/66b7d2f4/attachment.sig>