[ppml] Proposed Policy: PI assignments for V6

[marcelo bagnulo braun]

El 07/12/2004, a las 18:58, Owen DeLong escribió:

>>> 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.
>
> That's already done.  However, _BOTH_ are part of the community.
>

agree with that

>> Providers imho should be able to get their own PA address block, since
>> they will aggregate their customers blocks.
>
> That's already policy, but, it's a PI block from which they assign PA
> space.  However, in v6 policy, it's limited to providers that have a
> plan to assign addresses to 200+ organizations within some time period.
>

imho this is problem with current policy and need to be changed. This 
is not only a problem with small ISPs as you mention, but it is also a 
problem for transit providers who only sell transit to other isp and 
that may be less than 200, it is also a problem for mobile providers 
who may have millions of customers, but they only assign a /128 or a 
/64.
i agree that there is a problem with the v6 policy

>> 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.
>
> This is what you've already said.  We can agree to disagree about it.
>

ok

>> (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)
>>
> OK... Again, to clarify the terminology:
>
> If an RIR ALLOCATES or ASSIGNS a block, it is a PI block.  The block 
> can
> be used by the receiving entity regardless of what upstream(s) said 
> entity
> does or does not remain connected to.  The BLOCK, therefore is PROVIDER
> INDEPENDENT (PI).
>
> Once an RIR ALLOCATES a block to an LIR, the LIR (also the provider) 
> can
> make ASSIGNMENTS from that block to END SITES.  Those ASSIGNMENTS are
> considered PA (Provider Allocated) blocks.
>
> Hopefully this clarifies the terms PI, PA, ALLOCATE/ALLOCATION and 
> ASSIGN/
> ASSIGNMENT.
>

ok, i guess this is somehow different from the RIPE terminology, but i 
see what you mean

> The terminology in the policy is intended to apply to ISPS that have a 
> small
> number of NETWORK customers and some number of SINGLE-ADDRESS customers
> as well as END SITES that have a need for PI space in order to obtain 
> the
> same operational quality as what is currently present in IPv4.

ok, my point is that i would treat these two separately. I don't have a 
problem with small isps getting their PI allocation, my objection are  
related to PI assignments to end sites

>
>>>   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.
>
> Good... At least we agree on part of this.  Multihoming is an important
> part of provider independence in my opinion.  Afterall, the only way to
> make a painless transition from one ISP to another is to be connected 
> to
> both of them for some period of time.
>

>> 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.
>
> Because there is value to the community in having some level of
> provider-based aggregation.  The average small network which can live
> without multihoming can usually accept a renumber-based solution to
> provider migration.  Larger sites that care more about this are
> usually multihomed.  It provides a way to prevent a land-rush from
> overflowing the routing tables. It has worked quite well so far in
> the v4 arena with current assignment/allocation policies.  Since we
> have a track record in v4 with a  similar policy and it has worked
> well, it seemed like a good idea for initial v6 policy.
>

I am not sure about this.
I mean with current widespread of DSL and CATV and so one, a SOHO can 
be easily multihomed. I mean, i am not sure that being multihomed is an 
exclusive feature of really big and complex networks, i would expect 
that more and more homes will be multihomed.

>> 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.
>
> The problem with that is that his TCP sessions (or any other 
> established
> flow) can't survive provider-death during the flow.

i think we have a misunderstanding here... i was not considering this 
as a mutlihoming but a isp transition mechanism. My point was that if a 
multihomed site that has two PA blocks changes one of its providers, it 
still has the address space of the other provider stable. while if a 
single homed site changes provider, it has no stable address space 
(this was a sort of reason to show that single homed sites may be 
needing PI addressing more than multihomed sites)

> As such, this form
> of multihoming does not meet the needs of a significant portion of the
> community.  I agree that in an ideal world, it would be desirable to be
> able to give EVERYONE PI space and be done with it.

fully agree with this point (i guess that our differences are about the 
view of what is technically possible and what is not)

>  Unfortunately, what
> is really needed is a separation between end-point identifier and 
> route-
> descriptor.

Yes

>   This didn't happen in IPv6, so, we are where we are...

I didn't happen in the past but it is somehow happening now (at least 
an attempt to do something in this direction). Are you familiar with 
the work being done in multi6?

i guess that at this point we diverge.
multi6 is working to do this id/locator split that you consider 
necessary to solve this problem. The problem is that is not ready yet. 
If we give up waiting now, the PI approach will take over and the 
multi6 approach will never get a chance.
So, if i were to give up, i probably agree with you that the steps that 
you mention below are a reasonable approach. The point is that imho we 
need more time before going there. I don't know how familiar you are 
with the work being done in multi6, but i would ask you to check it out 
and decide if it deserves to have a chance.

>  The
> only end-point identifier we have also has to serve as the 
> route-descriptor.
> Given the limitations of current and likely future hardware, the global
> routing table simply can't support PI for absolutely everyone, so, we 
> need
> to figure out some way to identify the greatest needs for PI space that
> we can support and go in that direction.
>
> 	First, obviously, is providers.  That's already mostly taken care
> of, but, smaller providers are still out in the cold.  This policy 
> would
> rectify that.
>
> 	Second, in my opinion, is sites that require a unique routing policy.
> In general, that means multihoming.  There are a few other cases.  In 
> any
> case, this policy also addresses those needs.
>
> 	Third, in my opinion, is the general case of every site should be
> able to tell their provider to take a hike and switch to a new provider
> relatively painlessly and without having to renumber.  Unfortunately, 
> it
> is not currently realistic to solve this problem.
>
>> 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 :-)
>
> The renumbering procedures that were supposed to be so easy in IPv6 
> were
> deprecated early in the process.  Things like A6/DNAME that would have
> been a big help here were dropped because of some perceived complexity
> or risk.  As such, v6 did not address the renumbering issue adequately 
> to
> provide a meaningful alternative to PI.  Yes, there is operational
> experience to support this.
>
> ULAs are a bad idea.  ULAs are simply PI pretending not to be PI.  In 
> fact,
> the only reason I oppose ULAs is because they are an illusion.  While 
> there
> is no operational experience with ULAs (we haven't created them yet, 
> how
> can we have operational experience with them), we do have operational
> experience with human nature.  Paul Vixie posted a response on this 
> thread
> about ULAs that summed it up pretty well.  In short, human nature will
> migrate ULAs from Local to PI over time.  How hard it is and how much 
> time
> it takes is an unknown variable, but, over time, ULAs will become PI.
>
> Multihoming and Provider Independence from a service viability 
> perspective
> are the biggies.  Saying are there any other features provided besides
> these is sort of like saying "Are there any benefits to breathing, 
> besides
> continuing to live?"
>
>> 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...
>>
> I'm not sure who considers it a huge problem.  I do think I have a 
> certain
> amount of expertise in this area.  I certainly have a fair amount of
> experience in this area.  Based on operational experience over most of 
> the
> last year with policies 2002-3 and 2003-15, it does not appear that an
> IPv4 land-rush was created by those policies.  Worst case, if every ASN
> went for a prefix under this policy (remember, all those current 
> transit
> ASNs won't go for one) and tried to expand the following day, you'd 
> have
> approximately 60,000 new v6 routes.  I think the current v6 table could
> handle that without difficulty, so, yes, it scales for now.  The 
> reality
> is that most probably won't go for it, and, I'll be surprised if this
> policy contributed 10,000 routes to the v6 table over the next 5 years.
>

i agree that for the next few years there won't be problems with the 
size of the ipv6 routing table, but i don't agree with the next point, 
that the routing system will be able to deal with the load imposed by 
multihomed users in the future
there are at least some doubts about this, see for instance RFC 3221

> As to the long-term implications, such as what happens when we have
> more than 64k ASNs (Pekka's big concern), I still suspect you won't
> see more than 40 or 50,000 routes contributed by this policy.

why do you assume this?
do you expect that there won't be more than 50,000 multihomed users?
you don't buy the dsl catv soho multihoming? see rfc 3221 for the 
rationale about this (section 5.1 describes why a small site would want 
to multihome)

i mean if there is no other multihoming solution, then all multihomed 
site will want a pi block is guess and those will be more than 50,000 i 
guess.

> Even
> if we assume there are as many as 10,000 major ISPs world-wide that
> have to announce as many as 8 routes (remember, 8 /32s is 2 million
> customers, and, ISPs that burn through a couple of /32s probably get
> a /30 next time), that's still only 130,000 routes total.  What's the
> current routing table size for v4?  160,000 or so?
>
> Yep... I think it scales.
>



>>>  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.
>>
> Right... The v4 swamp was assigned before CIDR.  The v4 swamp also has
> absolutely no right of reclamation or annual renewal.  Addresses issued
> prior to the RIR system CAN NOT be taken away from the people that have
> them.  Those people do not pay annual fees for them.  That is a very
> different case from what would happen under this policy with v6.
>
> With this policy, the RIR can inform an organization that their
> allocation/assignment will not be renewed and that they must obtain
> replacement space under new policies.


Have you ever saw this really happening? do you really believe this is 
an option?
i mean i don't think this is reasonable to do, actually. I mean, 
imagine you are an huge end site. Now you get a PI block, and you 
hardcode it into your apps. Now, the next year the riri decides to take 
it back and that you need to get a PA block, do you see this happening?

> There's absolutely no way to
> do this with the v4 swamp because it is not subject to renewal.
>
> That's the key difference.
>
> Is it easy, no.  However, it's possible, and, with patience, it's even
> easy.  Just requires a substantial amount of time.  However, I think 
> that's
> OK.  The big issue with the mistakes we made in v4 was to stop making 
> them.
> The need to reverse the ones already made is not really a big deal to 
> most
> of the community at this point.  If we discover this was a bad idea, I
> think it would be much the same.  Once we stopped the policy, the 
> majority
> of the issue would be resolved.  Recovering the existing 
> allocations/assignments
> made under the policy would be much easier than in v4, but, similarly
> unnecessary.

The point is that since we have been using this multihoming solution, 
we have not tried alternatives solution, so what will happen is that 
some folks will still have their PI address, and the others will have 
to wait for the new multihoming solution to be tried and deployed, all 
this with real IPv6 production widespread

>
>>> 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.
>
> Well... I don't subscribe to your theory of punish the masses to make
> my solution that favors the few more viable.

I really think that we have a misunderstanding here.
I am not proposing to punish the masses.
multihomed users =! masses
actually multihomed users are really a minority that are heavily 
contributing with the pollution of the bgp global routing table
So, waiting for a PA compatible multihoming solution is NOT punishing 
the masses
Giving PI address blocks to multihomed users is benefiting a few ones 
(the multihomed users) at expenses of the whole community (all the 
other users that are not multihomed)

So my theory is exactly the opposite of what you stated above

>
>>  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)
>
> And it won't provide flow survivability.

No, check multi6 work please

>
>> However, from the community p.o.v. this is the only solution in the 
>> log
>> run. So how do solve this problem?
>
> Again, you attempt to define the community only in terms of providers.
> WRONG!!! The community includes the end sites too.
>
> I don't think your proposed solution is better for the community or for
> any of the individuals it claims to serve.  I think it is an inferior
> solution that does not provide important elements that are available
> with PI space.  It's only better for the ISPs.
>

I fail to see why you consider that i am trying to benefits the ISPs, 
but you for the record, this is not my intention.
The growth of the bgp problem is a problem that affect all the internet 
users, not only isps.
I mean, bgp table size limits for instance the reconvegence time of the 
routing system. This implies that if there is a failure, the routing 
system will take longer to recover, breaking for instance established 
communication. If we abuse of the routing system it won't provide the 
basic features needed.
So i am definetly not concerned about the problems of the isps, i am 
concerned about the functioning of the internet.

OTOH, i think you have some sort of misunderstanding of what a multi6 
would provide (or at least attempts to provide. For instance session 
survivability is a preferred feature)

>> 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 :-)
>>
> Yes, and, I am attempting to do just that with this policy.  I think 
> this
> policy is a better solution for the community.  The only people who 
> don't
> benefit from this policy are large providers and certain transit 
> networks.
>

No, single homed users don't benefit from this policy but they will 
definitely suffer from it, if the routing sysem is not able to deal 
with the size of the routing table.

(Just for the record, i still like the idea of sites not having to pay 
the cost of renumbering when changing isps, but i like more the idea of 
the routing system working properly, if you see what i mean)

>> 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...
>>
> Please explain to me how established flows (excluding SCTP) survive
> provider failure in your scenario.  If you can't, please accept that 
> this
> policy is necessary.

Please see multi6 work and accept that this policy should wait until 
the multi6 solution has a fair chance :-)


>
>>> 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)
>>
> The USERs are the MAJORITY of the community.  You need to learn this.
> You need to learn that LARGE PROVIDERS are the MINORITY in the 
> community.
> They are the people that the USERs PAY in order to meet the needs of 
> the
> USERs.

Please, i very much agree with you on this
but using your style on this...
SINGLE-HOMED users are the MAJORITY of the community.
MULTIHOMED users are the MINORITY of the community

see my point?

>
>>>  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
>>
> I don't have any such serious hypothesis.   I think this solution 
> scales
> to the defined set of users just fine.  I don't, on the other hand, 
> believe
> anyone has proposed any other solutions that may actually work.
>

well we have already covered these points,
DSL+CATV user case, RFC 3221 for some doubts if this would scale, 
multi6 work for a proposal of how this could work

>>
>>>  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?
>>
> There are current running networks that will not migrate to v6 until 
> they
> can get PI assignments or allocations.

agree, but the cases that i know of are really big end sites. For those 
i suspect that we probably will need a policy of PI. But i would like 
that it is more restrictive that the one you have proposed and probably 
i would wait some time until we determine which users can be served by 
a multi6 solution

>   Further, we have explored alternative
> solutions, and, the solutions that have been explored so far are very 
> flawed
> from an end-user perspective.  They do not provide the same fundamental
> capabilities as PI space and they require much greater administrative
> overhead on the part of the end-site to deal with their implementation.
>

please see the multi6 work, and point out what do you consider to be 
the problems flaws in it

> As such, as far as I am concerned, we have explored your proposed 
> solution
> and deemed it inferior to PI space.

i don't know what you have explored, but the multi6 proposal have been 
available since washington IETF, and is still not complete i.e. you can 
contribute and state what is the features that you need

>   This sentiment has been echoed on this
> list and others by multiple members of the community. (although 
> possibly not
> by any large ISPs, so, possibly not by what you consider the 
> community).
>

again, i don't see where do get this idea from :-(
regards, marcelo



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