[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GLOBAL-V6] Re: [ppml] PI addressing in IPv6 advances in ARIN
Hi Owen,
See below, in-line.
Regards,
Jordi
> De: Owen DeLong <owen@delong.com>
> Responder a: <owen@delong.com>
> Fecha: Fri, 14 Apr 2006 11:54:20 -0700
> Para: <jordi.palet@consulintel.es>, "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>,
> "ppml@arin.net" <ppml@arin.net>, "shim6@psg.com" <shim6@psg.com>
> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN
>
>
>
> --On April 14, 2006 1:39:07 PM +0200 JORDI PALET MARTINEZ
> <jordi.palet@consulintel.es> wrote:
>
>> Hi Owen,
>>
>> You said it: If somebody find the good solution, it will be attractive to
>> the people to go for it. Otherwise, you always have the chance to become
>> an LIR. My proposal actually is already considering this point and a way
>> to avoid a need for renumbering if that happens.
>>
> The problem with the LIR qualification idea is that there is a requirement
> for a plan to assign to 200 external organizations. There are two problems
> with this requirement. First, there is no clear definition of the term
> external in this context. Second, the number 200 is rather arbitrary.
> A /32 is 65,536 possible customer assignments. The number 200 is not
> related to this fact in any meaningful way. It could just as easily
> be justified at 100, 10, 2000, 20000, 30000 or whatever. I am not
> a big fan of arbitrary policy and that seems pretty arbitrary to
> me.
I totally agree with you on this, but this is a different problem. The 200
external organizations requirement should go away, and has gone already in
most of the regions.
Also some regions aren't so strict in apply the policy, which I think is
good.
>
> I'm also not a big fan of putting the RIRs in the role of creating more
> than one class of internet citizenship and providing advantages to
> organizations that meet certain criteria. I don't know if you were
> involved back when CIDR first came into being or not. At the time,
> nobody viewed it as a solution. We all viewed it as a temporary hack
> until a better solution was devised in v6. It was supposed to all
> get fixed in v6. That was one of the primary reasons for abandoning
> TUBA early on.
>
>> I just want to make sure that we have a way-out if it becomes necessary,
>> but avoid a showstopper now. I think is it possible.
>>
> My point is that if it becomes necessary, it will be because we have not
> found a true solution.
And I agree on that. We must work (and some of us already are doing) in
finding out the true solution, but in any case, we need a way to recover
from possible mistakes, if possible.
>
>> I don't have a technical solution yet (and agree with your views on this
>> in the email below in general), but I'm confident we will have. If it
>> will take 4 years from now, or just 2, who knows, so my proposal is
>> ensuring that we have those 4 years+3 for allowing the people either to
>> return the block, or become an LIR and avoid renumbering an any changes
>> in their network.
>>
> I understand your proposal. Frankly, if I didn't think an expiry clause
> would be a showstopper, I wouldn't hesitate to agree with it. However,
> since I believe:
> 1. It would be a showstopper for a lot of enterprises.
Yes, but this is why we have a community bases consensus, which can take a
position regardless of what few or lot (I doubt it) enterprises looking at
it as a problem. I think if they see it as a problem is because they aren't
correctly informed, or may be the policy is not clear enough to help them to
read it correctly.
> 2. The necessity of reclaiming the addresses is symptomatic
> of an inadequate "solution"
I see it as the escape to avoid doing a mistake. I don't believe it will be
required, but we don't know yet, and I prefer to keep the door with a lock
in such way that the community can close it if needed.
>
>> By the way, it may happen, and I'm hoping so, that the technical solution
>> don't make necessary to return the PI block anymore, and in that case, we
>> will be even able to remove at that time the "temporarily" point in the
>> policy (if it becomes accepted).
>>
> Right. I am hard pressed to envision any solution that does not have that
> property. This is why I said I think we need to clearly define what
> constitutes
> a solution. In my opinion, to be a solution, rather than a hack, it must
> have the following properties:
>
> 1. Routing table growth is either unconstrained or unrelated
> to prefix deaggregation.
>
> 2. The existence of a reachable connected prefix in one part
> of the network does not automatically create resource
> cost in all other default-free parts of the network.
>
> 3. Topological convenience from the ISP perspective is not
> an overriding concern in address policy.
>
> 4. Interdomain Routing topology should not need to be a
> concern in the eligibility to obtain a direct assignment
> or allocation.
>
> 5. The size of the organization should affect only the amount
> of address space they can receive. It should not control
> their ability to receive portable address space.
>
> If you define a solution along the lines of those 5 points, then, when we
> have a solution, there is no need to eliminate these assignments. If,
> on the other hand, we declare victory short of these goals, then, I believe
> we have again missed the mark and need to keep working.
We are in sync ;-)
>
> Owen
>
>
>> Regards,
>> Jordi
>>
>>
>>
>>
>>> De: Owen DeLong <owen@delong.com>
>>> Responder a: <owen@delong.com>
>>> Fecha: Fri, 14 Apr 2006 03:48:34 -0700
>>> Para: <jordi.palet@consulintel.es>, "v6ops@ops.ietf.org"
>>> <v6ops@ops.ietf.org>, "ppml@arin.net" <ppml@arin.net>, "shim6@psg.com"
>>> <shim6@psg.com> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN
>>>
>>>
>>>
>>> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ
>>> <jordi.palet@consulintel.es> wrote:
>>>
>>> [snip]
>>>> However, I want to balance this with the medium-long term implications
>>>> created in the routing table and with the time needed to build and
>>>> deploy a better technical solution (or several) which is accepted by the
>>>> community.
>>>>
>>> I think we first need to define what we consider a solution... See below.
>>>
>>>> So my proposal basically is about having PI now everywhere (once ARIN
>>>> adopt it, is unfair not having it in other regions), but those PI
>>>> allocations for multihoming should be temporary and those address blocks
>>>> returned to the RIRs some time (lets say 3 years) after the new
>>>> technical solution is declared as a valid one.
>>>>
>>> I would not actually support this idea. The whole point of having PI
>>> space is to have the addresses for a long-term. Having a timeframe for
>>> return would simply restore the same barrier to entry that existed
>>> prior to passing the policy.
>>>
>>> Other RIRs are free to implement whatever v6 PI policy they feel is
>>> appropriate for their region. I would support a globally standardized
>>> v6 PI policy along the lines of ARIN 2005-1.
>>>
>>> However, I would like to argue that if the new technical solution will
>>> benefit from the return of this address space, it is most likely not
>>> truly a solution, but, instead, another clever hack piled on top of
>>> the existing set of hacks.
>>>
>>> I suppose if someone found the magic bullet to make geotopological
>>> addressing really work, that might qualify. However, I have very low
>>> expectations in that area.
>>>
>>> Absent that, any true solution will involve making the size of the
>>> routing table independent of the number of PI (or even PA) blocks issued
>>> by the RIRs or will make the size of the routing table practically
>>> irrelevant.
>>>
>>> I know this isn't the easy solution, but, we need to look long and
>>> hard at the way we do things. I think that solving these problems
>>> is going to require a significant paradigm shift. Assuming that we
>>> can use IP addresses for both end system identification and for
>>> routing topology indicators is how we created this problem. I don't
>>> see solving it without breaking that assumption, at least at the
>>> interdomain level.
>>>
>>>
>>>> At this way, on the long-run, we will not have routing table
>>>> implications, but we allow now the people that want to move ahead only
>>>> if they have a multihoming solution doing so.
>>>>
>>> If you think there is a possible solution (a real solution, not just
>>> a hack that postpones the inevitable at the expense of usability
>>> like CIDR did), then I'd like to hear what you are thinking.
>>>
>>>> This 3-years time for getting a multihoming network back to the new
>>>> technical solution (once adopted) is enough time, I think (it could be
>>>> changed to 5 years if needed, or whatever), so nobody today see the
>>>> temporarily of the proposal as a showstopper to go for it now.
>>>>
>>> I think you underestimate the momentum and requirements of the modern
>>> enterprise if you believe that to be true. Any capability available
>>> in v4 that is not available on at least equal or better terms in v6
>>> is a deterrent to v6 deployment.
>>>
>>> The ability to get permanent addresses which do not have to be returned
>>> when you switch providers or renumbered on a schedule determined by
>>> some external organization is a major example of such a capability.
>>>
>>> Owen
>>>
>>>
>>> --
>>> If it wasn't crypto-signed, it probably didn't come from me.
>>
>>
>>
>>
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>>
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>>
>>
>>
>> _______________________________________________
>> PPML mailing list
>> PPML@arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
>
>
>
> --
> If it wasn't crypto-signed, it probably didn't come from me.
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
