[ppml] Proposed Policy: PI assignments for V6

[marcelo bagnulo braun]

Hi Owen,

El 06/12/2004, a las 21:23, Owen DeLong escribió:
[...]

>> 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.

Ok. First of all, imho we should separate providers from end-sites.
Providers imho should be able to get their own PA address block, since 
they will aggregate their customers blocks.
As you may know in some regions any ISP can get their own PA block 
(IPv4) just paying the fee. imho that's good
OTOH, imho end-sites should not, by default, be able to get their own 
IPv6 PI block, yet, until we explore other options.
(just a terminology nit, if we are assigning address block to a 
provider, and this provider will assign it to their customers, it is by 
definition PA, right. OTOH, if we assign it directly to end-sites, this 
is really PI. So i am not sure that the terminology applied in the 
proposed policy really applies to isps, but in any case this is not the 
main issue here)

>   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.

OK, this is a very good point
So we are not talking about using PI addressing to achieve multihoming 
here, but PI as a goal in itself, to obtain provider independence. OK, 
conceptually i very much subscribe to your p.o.v. that provider 
independence is a very important thing.
However, i have have some concerns/questions:
First, if provider independence is a value in itself, then why do you 
associate it it with multihoming? i mean, as i read the policy, the way 
for an end site to obtain a PI block is basically to be multihomed, why 
do you want to provide such privilege to multihomed users? i mean 
provider independence is a value for any user, multihomed or not. 
Moreover, if a multihomed user is using PA addressing from his 
upstreams, then i would argue that he is more independent from his isps 
than a single homed user. This is because he has two (or more) address 
blocks, so if he decides to change one of his providers, he still has 
the addresses from the other providers stable. In the case of a single 
homed user, when he decides to change his only provider, he has no 
stable addresses. So i would conclude that it would be better to 
provide a PI assignment policy that doesn't really depends on whether 
the user is multihomed or not.
Second, are there any other options that would provide the benefits of 
pi without actually assigning pi blocks? i mean renumbering procedures  
  in ipv6 are suppose to address some part of this problem, are there 
any operational experience that they are not good enough? ULAs are 
supposed to provide stable internal addressing without the problems 
caused by ambiguity, are there any operational experience that there 
are problems with this? are you aware of other features provided by PI 
addressing that should be addressed? (besides multihoming, i mean :-)
Third, do we know that we can make PI addressing work/scale? or, to be 
fair, do we know that it doesn't work? from what i heard, some experts 
consider that this is a huge problem, but you may have heard 
different...

>  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.

Ok, i don't really buy this stuff
I don't think we can easily correct mistakes, see v4 swamp now, see the 
% of the IPv4 address space that was assigned before CIDR.

>
>> 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.
>

YES, this is whole point since this is the only way we know to prevent 
the tragedy of the commons or public goods problem.
Trust and enforcement.
 From the perception of each individual, the solution that preserves the 
public goods is an inferior solution, and it is probably more 
expensive/difficult for him. (in our case, a PA compatible multihoming 
solution will impose managing multiple prefixes, gaining new experience 
and so on)
However, from the community p.o.v. this is the only solution in the log 
run. So how do solve this problem?
You cannot expect that those who would get the benefit refrain 
themselves because they know that is the best thing to do for the 
community.
So, the community as a whole has to preclude the behaviours that 
hinder/abuse from the public goods in benefiting a few ones (in our 
case public good=global routing table, the few ones that are benefited= 
multihomed users)

So we should build policies that protect the community. Please note 
that trust is another fundamental factor, since the preservation of the 
public good only makes sense if everybody preserves it. So if trust is 
broken i.e. a behaviour that allows individual to benefit from the 
public good is permitted, then the trust is broken and you cannot 
expect anyone else to preserve the resource. (in other words, imho this 
is global problem, not local to a region, that is why i am here, so far 
from home :-)

So i would indeed expect the community to prevent solutions that are 
perceived as superior by the individuals but are perceived as inferior 
by the community as a whole

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

as i said before i very much agree with this point, but i would like to 
explore alternatives to achieve the same goal. In particular, i would 
like that people could give a chance to the PA compatible multihoming 
solution, and to IPv6 renumbering mechanisms, and ULAs and so on...

>
>> 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

i guess that by now, it is clear that the key question is: beneficial 
for who?
for the community, of course. For the user, probably less beneficial 
that the PI based one (just because its experience with the existing 
solution)

>  when it comes, we can look at repealing this policy
> or providing incentives for it.

this means that we would be accepting a solution that we have serious 
hypothesis that doesn't scale without giving a chance to exploring 
other solutions that may work. i am not sure is like this approach


>  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.

i guess this is a key issue here. are current running networks have a 
desperate need for this PI assignment that we cannot wait to explore 
alternative solutions?

Regards, marcelo

>
> Owen
>
> -- 
> If it wasn't crypto-signed, it probably didn't come from me.