[arin-ppml] Why should we do Proposal 121

[William Herrin]

On Mon, Dec 13, 2010 at 10:50 AM, Jack Bates <jbates at brightok.net> wrote:
> On 12/10/2010 9:46 PM, William Herrin wrote:
>> When you say "manage resources for them," do you mean number
>> resources, as in you stay on top of the registry and IP address issues
>> so that they don't have to? Or do you provide a smorgasbord of
>> ISP-related resources in bulk, branded email services and so forth,
>> basically a deal where they managed the sales operation and whatever
>> technical components they find advantageous and buy the rest from you?
>
> While there is some amount of branding, unfortunately, way back in the day,
> many of them ended up branding to us, instead of themselves. It makes it
> really fun when you decide to split things up and brand them individually
> when there is already a bunch of users thinking of it the other way.
>
> We manage 99% of the servers for them (a few have inhouse stuff), account
> maintenance app, and share configuration duties for their routers and
> equipment they buy. So the ILEC owns all their hardware, customers, etc, and
> we own the central servers and routers which bring them together (core) to
> interlink to various NSP.

Hi Jack,

You have basically the same situation I had back in the day at
CrossLink. We had some resellers who were just sales folk and some who
bought in bulk and manged the customer. We also had two special
resellers: one who owned hardware, customers and POP sites but we
bought and managed the pipes and one who managed the entire last mile
process. The latter reseller/partner expected us to provide upstream
connectivity, servers (except web) and management/configuration of the
equipment.

We managed the IP addresses at the top level and in the large it was
one ISP, not three. Like my situation, it doesn't sound to me like you
have 12 subordinate ISPs, it sounds to me like you have 12
reseller/partners.

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.


On the other hand, I think your story points out one flaw in the IPv6
process that I'd like to see get further attention:  Multiple Discrete
Networks. Where your networks are geographically diverse, you can
request a /32 for each under the MDN policy. However, you still get a
contiguous larger allocation. As those discrete networks grow, this
inherently results in undesirable discontiguous announcements.

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?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004