Reopen discussion: Sub-Allcations vs. LIR-PARTITIONED

Hi,

as you might remember, there was a lengthy discussion on this list about
sub-allocations, reservations (yes, the ugly word) of IP address blocks
for LIR customers that are themselves resellers, and so on.

James Aldridge originally proposed something that ended up in being
"status: LIR-PARTITIONED PA/PI".  I just checked the RIPE DB, and there
are just 7 objects in the RIPE database that use this at all, and 6 of
them are by one maintainer.  

This matches my feelings of LIR-PARTITIONED - "nice try, but this isn't
what I imagined".

I think "official sub-allocations" are more useful, and have written up
a proposal for this (based on the discussion here and at the LIR-WG 
meeting in Prague).  Give it a good discussion and let's decide something 
in Amsterdam...

gert


--------- snip ----------
Motivation:

 - Some LIRs have internal hierarchies, like "resellers that have their
   own end customers".

 - For aggregation reasons internal to the LIR network, LIRs "allocate"
   address space to their resellers ("hierarchical sub-LIRs"), who then
   "assign" addresse from that to their customers.  Usually the LIR 
   has to approve all end-user requests, but the sub-LIR is doing the
   actual assignment from the "allocated" space.

 - The current policy doesn't explicitely permit this, but acknowledges
   to some extent that it is done.

 - When the LIR goes to the RIR to get another allocation, the 80% rule
   does not take into account the fact that some of the "not assigned"
   space may be in fact "sub-allocated" to a "sub-LIR", thus it may be
   very hard to reach 80% (and will lead to internal fragmentation).  
   (This is what Wilfried calls "reservation")

 - The sub-allocations are not documented, so an outsider cannot see
   who might be the best contact (the reseller!) if one of the end
   customers misbehaves (this part could be solved with "LIR-PARTITIONED").


Proposal:

 - permit LIRs to sub-allocate the address allocation they receive from
   a RIR to "downstream parties", from now on called sub-LIRs

 - the Sub-Allocations are documented as an inetnum: object with
   "status: SUB-ALLOCATED PA" in the RIPE database.  I do not like
   "LIR-PARTITIONED", because it isn't partitioned ("equal parts"), and
   also because it doesn't go far enough.

 - All assignments from the Sub-Allocation are done by the Sub-LIR.  
   The Sub-LIR is responsible to the LIR for following policies and
   procedures.  The LIR is responsible to the RIR for making sure that
   the Sub-LIR follows the procedures.  This is no big difference from 
   what is being *done* now, it's just "officially documented".

 - When the LIR has to apply for an additional allocation, the
   Sub-Allocation are counted for the "80% utilization rule".  So, to
   show an extreme example, a LIR that has sub-allocated 90% to its 
   resellers, and they have only assigned a total of 30% of the total 
   allocation yet, the LIR *would be* entitled to get a new allocation 
   (under the current policy, it is not).  In extreme cases, it might 
   be necessary to show lots of good documentation to the RIR as for 
   "why did you allocate so much".


Points of Concern:

 - "They will just waste address space".

   Yes, it will waste some space, due to better aggregation.    It is
   not expected that this will waste space due to "sloppyness" in 
   following the policies and procedures - each hierarchy level will be
   fully responsible for making sure that the next-lower level will 
   understand the rules and follow them.

   It is similar to what IANA and the RIRs do.  The RIRs try to hand out
   address space in a responsible way (which does not always succeeed,
   which is why changes to the procedures are made, like /19 -> /20 for
   the initial allocation), and in this proposal, the LIRs have to 
   hand out space to the sub-LIRs in a responsible way.  If the RIRs 
   mess up, they have a problem with IANA, if the LIRs mess up, they
   have a problem with their RIR.


 - "How big shall the sub-allocation be"?

   The exact numbers for the default case would have to be defined.

   Again, this is similar to the RIR->LIR case.  A LIR by default gets
   a /20, but might get a bigger space in case it produces a good 
   forecast that shows a reasonable need for a bigger space.

   I propose to give a Sub-LIR a /24 to start with, except in cases that 
   they show evidence for needing more.  Rationale: it's not too much,
   and you can delegate DNS on /24 boundaries without ugly tricks.

   When the Sub-Allocation is used up (= 80% of the space in there is
   ASSIGNED), the Sub-LIR can ask for more.  If a customer asks for more
   space than the Sub-LIR has left, the Sub-Allocation can also be 
   increased / a new Sub-Allocation be made.

 - "What's the size of networks a Sub-LIR can assign to their customers"?

   It can not go over the AW of the LIR.  This part is fixed due to the
   RIR/LIR relation.

   As for the rest, I propose that this should be a matter between the
   LIR and the Sub-LIR.  They have a contract, and it's the LIRs job to
   make sure that the Sub-LIR follows the official policies and
   procedures, maybe introducing their own Sub-AW per Sub-LIR etc.


--------- snip ----------

-- 
Total number of prefixes smaller than registry allocations:   74810  (74196)

SpaceNet AG                 Mail: netmaster at Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299