Re: 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
[email protected]
http://mailman.apnic.net/mailman/listinfo/global-v6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iHUEARECADUFAkWvbsguFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy
b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I0wKAJ4oTLw9PbklBpAwudlDI8O7sQ3U
4gCeNKUU/D+D8djRrREiXc/q6I++Omk=
=nn0a
-----END PGP SIGNATURE-----