[arin-ppml] Why should we do Proposal 121

[Jack Bates]

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 
recommended originally).



Jack (wordy as always, but think I covered it all)