Hi,
and once again, the suballocation topic. On RIPE42 in Amsterdam, the
feedback was pretty much non-existant, so nothing has been decided on
this proposal.
I still think it's useful. Not for all LIRs, but for the larger ones
that have a multi-level reseller hierarchy, or maybe a multi-national
internal hierarchy (Stephen and the MIR thing).
In the last months, I've heard a few comments from different sides that
"hmm, yes, this could be exactly what we need". Also, APNIC is working
on a similar proposal for their community.
Please read the following thoughts, and form an opinition. (It's a bit
repetitive, as a couple of questions have come up again that are already
answered in the draft).
If you're in favour of it, please voice it. If you don't think it's
useful, but don't see any harm coming from it, please voice that as well
(please don't just write "this is crap!" unless you're convinced that
nobody else can benefit from it either, and it will do more harm than
good).
If you *do* think it's complete crap and will destroy the whole RIPE
structure, please by all means voice that as well :-)
Gert Doering
-- NetMaster
------------- 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.
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.
- "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.
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).
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".
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).
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.
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".
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.
7. Database rules would have to be made as for what kind of "nesting"
is permitted (SUB-ALLOCATED PA is only permitted inside another
SUB-ALLOCATED or ALLOCATED PA, not inside "* PI", and so on).
Answer: yes, of course.
Other Comments (various sources)
* this will generate a radical new structure (two-level RIR/LIR to
multi-level)
Answer: yes, this is the intention.
* Considering the address wastage - it might not actually waste that
much space, if it means some "Sub-LIRs" will not become full-sized LIRs
(with a /20 each) but are happy with a /22 Sub-Allocation.
So maybe it will even reduce the new-LIR rush in the progress.
* Would this mean that the existing AWs would have to be reviewed
(to make sure that these LIRs do not mis-use their AW to create
lots of useless Sub-Allocations)?
Answer: I don't think so. Maybe one need to do some kind of
"small audit" on sub-allocated ranges after a few month,
to get experience with this.
--
Total number of prefixes smaller than registry allocations: 46611 (45583)
SpaceNet AG Mail: netmaster(a)Space.Net
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
80807 Muenchen Fax : +49-89-32356-299
