[ppml] Proposed Policy: Adding an HD ratio choice for new IPv4 allocations

[Owen DeLong]

> To begin with, it's not hierarchy alone that creates the
> problem. Hierarchy interacts with the bit-mask operations
> used to divide network addresses and host addresses. These
> bit-mask operations impose a power-of-2 structure on network
> sizes and aggregate sizes. The hierarchy exacerbates the
> problem because the power-of-2 rule applies at each level.
>
> Suppose that I have a special product that requires 5
> IP addresses per customer. I have 5 PoPs with 25 customers
> at each PoP. Therefore, at each PoP I need 125 addresses for
> a sum total of 625 addresses to cover the needs of all
> 5 cities.
>
A rather pathological example, but, OK... Let's run with that...

> But IPv4 doesn't work that way. In fact, I have to give each
> customer 8 addresses for a total of 200 addresses at a PoP.
> That makes 1000 addresses in total, right? Wrong. I have to
> give each PoP 256 addresses, not 200. That makes for a total
> of 1280 addresses. This is how hierarchy increases inefficiency
> by compounding the "overhead" associated with the power-of-2
> rule.
>
Why?  Why does each POP have to aggregate to a /24?  Why can't
each POP simply advertise the individual /29s into your backbone?
You only need to aggregate at your borders to other ASs, and, if
you're getting allocation/assignment direct from ARIN (where this
would matter), you've got at least a /22, so, having the /29s
inside your AS and the /22 or more outside should not be an
issue.  Sure, aggregating at the POP level may be desirable in
cases where it makes sense, but, this seems to identify a
situation where it does not.

Further, if you have, in fact, issued /29s to the customers,
then you have "utilized" for the ARIN term, 200 addresses
per POP, not the 125 you claim.  200/256 is 0.78125, so,
if you've done your entire network in this manner and you
don't have any other small assignments in your POPs to take
up the remaining (1 /29, 1 /28, 1 /27) prefixes aggregated
to that POP (and for some reason, you can't put them elsewhere
in your network as more specifics (?), then, I suppose that
you might have some difficulty with the 80% rule.
However, if you had 26 customers per POP, or, managed to
find a need for that /27 (say the POP infrastructure), then,
you'd have no problem with the current 80% rule.

My general position on the HD thing has been "It's optional,
some may find it useful, who cares... It's not a big deal."
However, your example has now convinced me that it is actually
a way to reward inefficient network topology with more address
space.  As such, I withdraw my neutrality and oppose the
current proposal.

> In a real network, each of the subnets will also have extra
> addresses to accomodate growth because no network operator
> can function by only growing their subnets by one customer
> requirement at a time. The larger the network, the more this
> overhead eats up addresses especially when you are trying
> to make sure that routes can be aggregated to keep the number
> of individual routes low. In a small network you can ignore
> aggregation, give every customer a random block of addresses
> and let dynamic routing sort out the mess. This will not
> scale.
>
That's true, but, I'm not at this point convinced that HD ratio
is a meaningful solution to that problem.  I have long advocated
that there are cases in which an LIR should be able to treat
nodes as if they were individual sub-LIRs and justify space to
ARIN on that basis.  When I was at Exodus, this was bad enough
that we finally succumbed and paid multiple fees to ARIN to make
each of our regions a separate LIR instead of being a single
organization with a single allocation criteria.  However, I
don't believe HD really addresses this issue.  I do believe
that it rewards pathological inefficiencies as the one you describe
above.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050222/ed3e31de/attachment.sig>