Hi Michael, Using identical terms to describe the same concepts is indeed a desirable goal imho. However what follows is a short description of the terms used in the APNIC region - which are again (unfortunately!) different to those used by the other RIRs. APNIC inherited the terms PA and PI and used these terms in the past. However the feedback received through the delivery of the training courses always pointed to a lot of confusion over the actual meaning. Most commonly the feedback was along the lines of "Isnt a PA block a PI block to the ISP using it?" As it seemed that the essential issue was one of portability, the terms 'portable' and 'non-portable' address space were subsequently introduced to replace 'PI' and 'PA' respectively. RIRs make portable allocations and assignments (small multihoming assignment policy, IXP policies, critical infrastructure etc) whilst LIRs make non-portable assignments and sub-allocations. regards, Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison <anne@apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 ---------------------------------------------------------------------- See you at APNIC 16 Seoul, Korea, 19-22 August 2003 http://www.apnic.net/meetings ---------------------------------------------------------------------- On Mon, 11 Aug 2003 Michael.Dillon@radianz.com wrote:
People are requesting *multiple* PI blocks because they can't get a PA allocation, and that seems to be just wrong to me.
Something strange is happening to the English language here. Whenever I read PI and PA, I have a mental concept of independent blocks that I can announce, and borrowed blocks that I get from my provider's aggregate. In this set of mental concepts, a provider gets a PI block from an RIR and then allocates PA blocks to their customers.
But after stumbling through this thread, I checked the RIPE website and discovered that the IPv4 policies state:
LIRs are allocated Provider Aggregatable address space that they assign to their End Users and announced as one prefix.
The problem is that the word "aggretable" means something that is capable of being aggregated. The block that a customer receives from the LIR is a part of a larger aggregate and is therefore "aggregatable". But the block that the LIR receives from the RIR is not necessarily aggregatable because there is no guarantee that the RIR will reserve adjacent blocks for the LIR. I know that the practice is to reserve the adjacent blocks for some period of time, but there are a lot of LIRs which have multiple non-aggregatable blocks from the RIRs.
This is important because if we are not clear and consistent in our use of the language, then we create confusion and misunderstandings.
For instance, in the ARIN world, PA stands for Provider Assigned in order to make it clear that the RIR gives providers PI space and the providers cut it up into PA blocks for their customers. It's like lending and borrowing. If I lend you a bicycle then you are borrowing it from me. Then you can lend the borrowed bicycle to your friend so that you are both a borrower and a lender of the bicycle.
It seems to me that the distinction needs to be made between network-independent address blocks and network-dependent or network-attached ones.
NI Network-Independent address blocks are allocated to an organization by the RIR and can be announced in whole or in part by any network with which the organization has a relationship.
NA Network-Attached address blocks are assigned to an organization by an LIR and can only be used with the network(s) operated by that LIR.
Then we could drop the acronyms and start talking about independent address blocks and attached network blocks.
Personally, I don't believe that all 5 RIRs should have the same policies but I do believe that all 5 RIRs should use the same terminology and language to talk about addressing as long as the talking is done in English. --Michael Dillon _______________________________________________ Hostmaster-staff mailing list Hostmaster-staff@apnic.net http://mailman.apnic.net/mailman/listinfo/hostmaster-staff