[arin-ppml] Why should we do Proposal 121

[Jack Bates]

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.

For them, cost savings come in time and personnel, with perhaps some 
savings in bandwidth (we pass costs on at no profit, though it's a curve 
of losing money to making money to balance out the losses, as we go from 
one upgrade to the next). Most of our profit is in the servers and 
helpdesk they use, which also provides them with an on-call engineer 
24/7 to handle any issues (including their corp firewalls or advice on 
in-house networking needs).

> You kind of focused your comments on the price benefit to pooling
> requests to ARIN. The fee for a /28 split 12 ways is a good bit less
> than the 12 times the fee for a /32. I assume there's also a financial
> benefit to needing only one ARIN policy specialist who can manage the
> ARIN interactions versus each of the 12 needing to have one of their
> guys fully up to speed and presumably ARIN gains efficiencies from
> dealing with one expert instead of 12 amateurs.
>

This is my viewpoint. Most of the ILECs haven't a clue who ARIN is or 
how IP allocations work. In IPv4, I monitor when they are close to 
exhaustion and allocate more addresses to them. If they have a new 
project (such as upgrading the cell systems to 3g), we discuss what the 
needs of the project are, and I make the necessary allocation.

In fact, it is such a way, that even if I did go to ARIN for each /32, 
I'd have to make the request myself 12 times! :(

> Do you experience any purely technical benefits from pooling the ISPs'
> requests, or are they all these sort of process benefits? By technical
> benefit, I mean something like aggregated prefixes in the routing
> table. If so, can you tell us a little more about it?
>

Obviously, when a customer multihomes, I have to deaggregate the space 
they are using. This is one reason I've pushed for the ability to give 
them /32, else I'll end up having to assign multiple prefixes to them 
(in v4, it's not unusual for even the small one's to have 3x /23 due to 
growth over time). While 2-3 prefixes isn't excessive, I'm small scale 
so my contribution to table growth is also small, but equally unacceptable.

At all times, I advertise our aggregates as received from ARIN. I may 
advertise an overlaying smaller route in the case of a multihomed ILEC 
or for load balancing purposes if necessary (generally I can get away 
with not needing the load balancing due to other BGP customers who 
request direct from ARIN and are actually customers of my ILEC customers).

tldr; We use much less routes due to aggregation as suspected and when 
multihoming hope to issue the /32 minimum to keep from doubling or 
tripling the routes sent for that ILEC.



Jack