[arin-ppml] Why should we do Proposal 121
jbates at brightok.net
Mon Dec 13 10:50:27 EST 2010
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
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.
More information about the ARIN-PPML