[lir-wg] Action from RIPE 42: Sub-Allocations revisited

Hi,


I think this is a very useful proposal. Several of our customers are ISPs
themselves and intends to become LIR when they have utilization of a /22.
Until then the procedure for registering their assignments is a bit
complicated, the main problems are that we cannot let our customer take care
of the administrative part - we have to be in contact with their customer
and when allocating/reserving an IP net for the customer, we get a problem
when requesting a new allocation from Ripe (80% rule).



> 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.
>

I also believe "SUB-ALLOCATED PA" is more appropriate.


> Points of Concern:
>
>  - "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.
>
>    As a starting point for the discussion, I propose:
>
>     - minimum size of a Sub-Allocation: /24
>       (because that's what's needed to be able to properly delegate
>       the reverse DNS zone)
>     - maximum size of a Sub-Allocation: 4x AW per year and sub-LIR
>       (the number "4" here is of course open for discussion)
>     - if a bigger size is required, go through NCC hostmasters
>
>    alternatively one could introduce a new "Sub-Allocation-AW", but
>    that's even more bureaucracy.

In my oppinion it should be closer to a /22. If its only a /24 it has to be
split into quite many subnets before its worth the effort of "setting up" a
sub-LIR.. But I don't see much point in allocating a larger net than /22, if
larger is needed and growth expected then it would be better to set up a
normal LIR.

Yes, a "Sub-Allocation-AW" might be an idea, but I think it should be a
matter between the LIR and the sub-LIR, no reason to bother Ripe with this.


>
>
>  - "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.
>

The LIR acts as a RIR, so the sub-LIR sends ripe-219 applications to the LIR
and the LIR approves according to AW, if the request is larger than AW it is
forwarded to Ripe NCC hostmasters (just as normal IP requests).

>
> Thoughts and Considerations from the RIPE NCC (Leo Vegoda):
>
> 1. How should the RIPE NCC act when a further allocation is
>    requested if the existing allocation is not at "about 80%" usage
>    (when used means valid assignments) - but "about 80%" is used in
>    assignments and sub-allocations?
>
>    Answer: see above in the "Motivation" block.  The idea is that
>            Sub-Allocations are considered "usage", so if (for example)
>            40% is ASSIGNED and another 40% is SUB-ALLOCATED, 80% usage
>            is achieved.  What percentage of the SUB-ALLOCATED space is
>            actually ASSIGNED is not considered.
>
>            So the answer is "if all other things are fine, a new
> allocation
>            should be made".
>
>            It is envisioned that the NCC hostmasters are going to ask
>            nasty questions if the percentage of SUB-ALLOCATED is
>            "overly" high and the percentage of end-user
> assignments overall
>            is "overly" low (exact values to be defined).
>

It would be a problem if specific percentages dictates if another allocation
is possible or not, since their could be valid reasons for even extreme
situations. But in general it might be prudent to go through the documented
need for the sub-allocations when requesting a new allocation.

>
> 2. If the RIPE NCC should count a "sub-allocation" as used then
>    should it take account of the degree of assignment in the
>    sub-allocations? If so, what degree should be assigned from them?
>
>    Answer: I think that the number of end-user assignments made inside
>            sub-allocations should not be a hard criterium (like the
>            80% rule).  I do think that very low ratios should lead to
>            nasty questions.
>
>            I do also think that this should be compared to the IANA/RIR
>            level - if a RIR comes back to IANA because all /8s have been
>            "used up" (by allocating to LIRs), IANA doesn't consider the
>            actual usage ratio *inside* the allocations, as long as the RIR
>            has been following its rules for "under which circumstances is
>            it permitted to make an allocation, and which size is OK".
>

No, I don't think it would make sense if Ripe NCC had to go into the degree
of assignments of a LIRs sub-LIRs when deciding to do another allocation.
But again, its important that the sub-allocations are properly documented
(and valid), that should instead be the criterium.

>
> 3. Should there be a maximum size an LIR can sub-allocate? If so,
>    what size? (I know you've previously proposed a /24 as a default
>    or minimum size).
>
>    Answer: see above (yes, but the exact number has to be decided upon).
>

I would think it would be better if the sub-LIR instead setup a normal LIR
in case the need was larger than a /22, or would people prefer sub-LIRs with
/20 allocations or larger? In my oppinion the sub-LIR status should only be
temporary until the customers address utilization had passed /22.


>
> 4. Should holders of a sub-allocation be allowed to sub-allocate,
>    too? This is allowed in IPv6. Should IPv4 be different?
>
>    Answer: I can see arguments for both sides - sub-sub-allocations might
>            not really make sense in IPv4 (not enough bits to do so much
>            hierarchy), but then, it might make sense in some networks.
>
>            I'd leave this one to the community for a decision.

No, in that case the sub-LIR would probably have a need of quite many
addresses, and therefore it would be better to set up a  LIR.

>
>
> 5. LIRs are contractually obliged to follow the RIPE community's
>    policies. Is it possible to enforce any requirement for a holder
>    of a sub-allocation to follow those policies, too?
>
>    Answer: The LIR has signed that it will obey all policies.  So it would
>            be part of those to enforce the RIPE rules onto the Sub-LIR
>            as well (by an appropriate contract).  This would have to be
>            made very explicit in the "sub-allocation policy document".
>

It is the responsibility of the LIR that ALL assignments (also those from
sub-allocations) are valid according to policies. A contract like the one
between LIRs and RIRs might be a good idea between the LIR and the sub-LIR
too.

>
> 6. If an LIR makes a sub-allocation this is presumably becasue it
>    trusts the re-seller to administer the space responsibly and
>    wants to delegate responsibility for the assignments. This implies
>    that the LIR would place the re-seller's mnt-lower on the sub-
>    allocation allowing the re-seller to assign without returning to
>    the LIR. However, this would remove control over that portion of
>    address space from the LIR. Would this policy require the reclaim
>    attribute to be implemented in the Database?
>
>    Answer: this is something to be worked out with the database WG,
>            but to avoid trouble with the RIPE DB entries when a Sub-LIR
>            "goes away" without cleaning up their entries, this is
>            considered useful.
>

Yes, I believe its necessary that the LIR can somehow overrule everything
done in the Ripe DB by the sub-LIR.


A few things I would like to add to this proposal:

It might also be a good idea if the Ripe NCC keeps a record of all the
sub-LIRs, especially if/when the sub-LIR decides to become a LIR.

The sub-LIR should also be allowed to assign its own infrastructure within
the sub-allocation.

The Ripe-219 should as default describe whether its a LIR or a sub-LIR
assignment.

Some sort of fee for registering as a sub-LIR might be appropriated, at
least to make sure not everybody suddenly wants to be sub-LIR! But maybe the
decision should be made by the individual LIRs. I would assume that the LIR
have to take care of all questions the sub-LIR might have regarding
policies, RIPE DB entries and so on. If all future LIRs have first been
sub-LIRs it should make it easier for the Ripe NCC hostmasters when setting
up the LIRs and doing the first assignments.


Med venlig hilsen/Best regards
Christian Rasmussen
Hosting manager
jay.net a/s