[arin-ppml] Why should we do Proposal 121
jbates at brightok.net
Mon Dec 13 16:33:06 EST 2010
On 12/13/2010 2:42 PM, William Herrin wrote:
> I hate to tell you, but I frankly don't think it would be appropriate
> for you to try to reserve space for sparse /32 allocations at the LIR
> level any more than it would have been appropriate for such a dramatic
> reservation scheme with IPv4 back at CrossLink. I've been through the
> bit math in this forum before. There are barely enough bits for three
> layers of sparse allocation: RIR, ISP and customer. There really
> aren't enough for another layer of sparse.
Except we are referring to the same thing. I'm not asking for sparse
allocations as an ISP providing for another ISP. I'm asking for the
appropriate space and right to give the ISP a /32. Keep in mind, some of
these are multihomed. I'm just a consultant in many ways.
Even if the pricing model changed, there's nothing wrong with me
receiving a /24 to handle a large number of ISPs; though honestly I'm
happy with a /27 which meets my requirements.
The community benefit, is that by current network topology, I'll be
advertising a /27, /30, and 2x /32 networks (my aggregate plus a medium
and 2 small ISP customers deaggregated due to multihoming).
Compare this to the fact that each can go to ARIN and request a separate
/32 for each ISP and even their subtending ISP customers. This could be
done by the same technical person (me), but then we end up with over 12
/32 routes added to the table.
> Perhaps policy should be adjusted so that a registrant (you) can
> request discontiguous addresses when justified under the MDN policy.
> That way if you know your discrete networks will grow independently
> rather than growing together you can get appropriate allocations that
> can grow by enlarging the netmask while the unallocated space for
> sparse-allocation continues to be held by ARIN instead of by you and
> you continue to pay for space in aggregate instead of separately.
> How far would that go towards solving your problem?
It doesn't really solve my problem, as currently ARIN is not supporting
/32 assignments to my subtended ISP customers. This means they aren't
allowed any growth room under the space which is being allocated to me
(currently debating a /30 total). In most of these cases, a /32 supports
plenty of room for growth and so discontiguous space is not a current
fear (unless I accept the /30 and assign the bare minimums to each
subtending ISP, which guarantees discontiguous space and given that my
smallest networks which are most likely to need additional space are
multihomed, it means that will show in the BGP routing tables). You
stipulate using different sparse allocations, but that still jumps me
from 4 prefixes up to over 12; which is worse than my current IPv4
routes. Even if I treat them by ASN, I just had 2 of my smallest ISP
customers jump from singlehomed to multihomed and advertised multiple
/23 IPv4 routes(2 today, and an additional 3 /23 in a few weeks when the
other transitions). :(
I have 4 ASNs, and with a /27, I could easily handle 4 prefixes
advertised. This is much less than if I go to ARIN direct for each ISP.
I know someone is doing math and curious about the /27 vs the /28, and
this is due to there being subtending ISPs off my subtending ISPs which
are multihomed (we only care about contiguous within the ASN itself).
Owen has done the math and informs me that it's not a problem to have
ISPs grown this way, 1) looking at the rarity of the tree, 2) the price
associated if it grows too large and 3) there is a crap load of IPv6 space.
Here's where it gets funny. Under current policy, if initial allocation
supported HD-Ratio adjusted allocation (like the new policy), I'd still
qualify for a /27 (current policy doesn't support this, but only the
bare minimum to renumber). By the new policy, I qualify for a /24. In
all cases, I can still assign the /32 or shorter prefixes for each of
the subtending ISPs. Yet by current policy, I was offered a /30. No room
to grow, and guaranteed to advertise multiple routes (/32 ISP minimum
allows for ISP growth in smaller ISPs and was probably why it was
Jack (wordy as always, but think I covered it all)
More information about the ARIN-PPML