[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLOBAL-V6] PI space under IPv6
In fact, APNIC also approved a PI ("portable" in their terminology) policy.
I think is being implemented really soon.
In the other regions, there are several proposals, which didn't reached
consensus at the time being, and I'm already working in submitting new
versions for all them also.
Regards,
Jordi
> De: Jeroen Massar <jeroen@unfix.org>
> Organización: Unfix
> Responder a: <global-v6-bounces@lists.apnic.net>
> Fecha: Thu, 18 Jan 2007 12:57:44 +0000
> Para: Ray Plzak <plzak@arin.net>
> CC: <global-v6@lists.apnic.net>
> Asunto: Re: [GLOBAL-V6] PI space under IPv6
>
> Ray Plzak wrote:
>> While this discussion on this thread is very interesting, I am wondering if
>> anyone is going to propose a policy in any of the regional policy fora? The
>> policies that are in place weren't made up by a few people but have been
>> arrived at after many people have discussed them on mail lists and at public
>> policy meetings. For those who are critical of the current policies in the
>> various regions, I suggest that they propose an alternative policy in these
>> fora.
>
> My point is that the current policies are mostly fine, although maybe a
> bit strange. RIR's are there to provide address space to organizations
> that need it. In ARIN land there is a "PI" policy, which in effect
> simply allows "small" organizations to receive their own address space.
> A similar policy should be available in all other regions.
>
> Calling it "PI" is fine, but "PA" is also "PI", the only difference is
> that one should not cut up "PA" address space into little chunks. The
> main reason for calling it "PA" though is so that organizations that
> receive from their LIR address space out of PA space that they can't
> later claim that "we own it and we think it is PI so we take it along".
> That problem though should simply be solved in the contract between the
> LIR and their client. Naming PA and PI differently is IMHO useless.
>
> As I've shown in the message you replied to, there are numerous ways to
> represent a company as different legal entities, as such that company
> can then simply request multiple separate blocks already. This thus does
> not solve anything with "Routing Slots" etc. If a holder of "PA space"
> wants they will de-aggregate anyway, which is already happening as can
> be seen by GRH and also RIS.
>
> Also when you have a large company with say a /18, when that company
> splits off certain branches, do those parts then have to renumber or can
> they keep using their part of the /18? Indeed it will cost an extra
> routing slot.
>
> Another point with those routing slots is the following one: if you are
> a global company, you get a /32. Now you have very fat pipes in the US,
> but you also have a branch in, say, Tokio, which has only limited
> capacity. There are then three ways of letting Tokio use that /32: a)
> let it announce the /32 and then forward over their small pipe all the
> traffic that /32 attracts to the US, as that is where it needs to go. b)
> Splitting the /32 into 2 separate BGP announcements, thus traffic to the
> US doesn't go the Tokio. c) [preferred but almost never used]: tag the
> routes with BPG communities so that the prefix is only announced in a
> limited way. The latter will cause traffic toward Tokio to be first
> received by the US part of the network, then you'll have to forward it
> to Tokio yourself. Same issue as a) in effect, but somewhat better.
> B) is thus the solution that people will use.
>
> This has indeed nothing to do with address space allocations, as done by
> the RIR's but with current common (not best) practices. The current
> routing systems simply don't allow the usage in the ways that a lot of
> ISP's (ab)use BGP at the moment.
>
> As such there will be de-aggregation, even when there is this thing
> called "PA" and a big ISP gets a /18 or something similar. They will
> announce it in chunks. And how is that different from allocating them
> separate blocks?
>
>
> The whole "Routing Slots" issue should be solved with a different means.
> And it has *NOTHING* to do with how RIR's give out address space.
>
> Greets,
> Jeroen
>
> _______________________________________________
> global-v6 mailing list
> global-v6@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/global-v6
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
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.
