ARIN allocating /20 netblocks?

Jeremiah Kristal wrote:

ARIN has made a slight change to make it easier for small ISPs to get
provider independant netblocks. They will assign a /20 and reserve the
adjacent /20, the customer is allowed to announce the entire /19.
For further information, please view http://www.arin.net/initial-isp.html

Now, let's `cat post | bullshitfilter.pl` and see what we get:

ARIN has made a slight change to make it easier for them to make more
money by allowing anyone to register for IPs. They will assign a /20 and
reserve the adjacent /20...

$

Ahh, that makes more sense now.

-jamie the cynic :slight_smile:

That must have been your bullshitify.pl filter.

The change made it possible for many "small" ISPs to truely multihome.
FDT is one of them. When I found out about "the change", I was about to
renumber FDT into Digex address space, since we did not qualify under the
old rules for an ARIN CIDR block (immediately fill 80% of a /19). The
/20 Digex was going to give us was in filtered space, meaning anyone
filtering BGP like Sprint would not see our advertisements and would only
have reached us through Digex...making our additional T1's to the net
somewhat pointless.

You should not have had the original problem (IMHO of course).

Consider, Jon, what happens if you fail to meet the criteria to keep that
whole /19 - some time down the road.

You should not have had the original problem (IMHO of course).

How do you mean?

Consider, Jon, what happens if you fail to meet the criteria to keep that
whole /19 - some time down the road.

I can see that being a serious concern for really small ISPs getting a /20
from a reserved /19 if they only currently utilize a /21 and have to fill
the /19 in 18 months. We had 2 UUNet /20's to renumber out of. Filling
the reserved /19 won't be a problem...I just need to file the paperwork to
get the top half of the /19 officially allocated.

Why do you need to renumber out of previous space if MCI doesn't have to
when they get a bigger block handed to them?

Why should your *customers* bear the burden of this policy?

My point: you shouldn't, and your customer's shouldn't. You should, as a
multi-homed ISP, be able to get a /19 immediately and without obstruction -
period.

Why do you need to renumber out of previous space if MCI doesn't have to
when they get a bigger block handed to them?

Well...because I knew from day 1 that our UUNet space was non-portable,
and that we were effectively borrowing it.

Why should your *customers* bear the burden of this policy?

This was the part that sucked. Renumbering was a bitch, but with proper
planning, it really wasn't too big a deal...just lots of work.
Renumbering is one of those tasks during which you really find out which
of your customers have clues and which are a few clues short of a full
deck.

My point: you shouldn't, and your customer's shouldn't. You should, as a
multi-homed ISP, be able to get a /19 immediately and without obstruction -
period.

We didn't start out multihomed. We were singlehomed for 3 years. Are you
saying we should have been able to keep our UUNet IP space (even though we
left UUNet)?

> Why do you need to renumber out of previous space if MCI doesn't have to
> when they get a bigger block handed to them?

Well...because I knew from day 1 that our UUNet space was non-portable,
and that we were effectively borrowing it.

> Why should your *customers* bear the burden of this policy?

This was the part that sucked. Renumbering was a bitch, but with proper
planning, it really wasn't too big a deal...just lots of work.
Renumbering is one of those tasks during which you really find out which
of your customers have clues and which are a few clues short of a full
deck.

> My point: you shouldn't, and your customer's shouldn't. You should, as a
> multi-homed ISP, be able to get a /19 immediately and without obstruction -
> period.

We didn't start out multihomed. We were singlehomed for 3 years. Are you
saying we should have been able to keep our UUNet IP space (even though we
left UUNet)?

No.

You should have been able to, at the point you purchased the second DS1 and
multihomed, been able to obtain a free and clear /19 - end of discussion.

To get the SECOND /19 you'd have to show that the first one was consumed.
The algorythm is simple - you construct a rate-of-use table for the
subsequent allocations which look something like this:

  Used previous allocation in < 3 months = Add 2 bits to the size
    (ie: Used a /19 in > 3 months, get a /17 next time)

  Used previous allocation in < 6 months = Add 1 bit to the size
    (ie: Used a /19 in < 6 months, get a /18 next time)

  Used previous allocation >= 6 months, <= 1 years = Same size

  Used previous allocation >= 1 year = Decrease one bit size UNLESS
    you were at a /19, in which case we give you another /19

Simple, objective, conservative, automatically rate-adjusts to actual
conditions without any gamesmanship possible, "subjective" evaluation,
requirement to submit materials under NDA, or anything else.

We can tune the "time values" to obtain optimum results, but frankly, I bet
these are a pretty good guess.

Now tell me why we shouldn't be doing it this way.....

Even the largest firms could do this and it would work. EVERYONE starts
with a /19 - including Joe's Big Provider.

Joe gets a /19. He uses it in a week (since he's Mr. Big)
He comes back, and gets a /17. He uses THAT in a week.
He comes back, and gets a /16 (2 contig /16s). Things start to slow down
(he's getting MAJOR space; 16x more in a chunk now than he started with!)

He uses the /15 (that's 512 class "C"s!) in six months, and gets a /14.

The /14 lasts him two years, unless he's REALLY Mr. Big, in which case he
does this again once or twice more ends up somewhere between a /13 and
a /11 (32 class "B"s!)

So we just got Mr. Big on the net - completely - with less than a half-dozen
announcements. If he SAYS he'll be back in a week up front we do smart
things and hold the contig portions for a month or so (to see if he's full
of horse-hockey) so we can just expand the original allocation - thereby
conserving one or two route entries.

Note that even if you don't "hold", it makes no significant difference
anyway; a half-dozen route entries is insignificant for someone of this
size!

Contrast that to what MCI or any other "major" carrier announces today, and
then tell me why this isn't a superior, easier to implement, and WORKABLE
policy.

In article <19980516152145.42206@mcs.net>,

Ok, so I only lose 16 T1 customers instead of 1024.

Of course, those 16 represent half of my annual revenue at that point.

Ok, so I only lose 16 T1 customers instead of 1024.

If you lose 16 T1 customers during a renumbering of a /20, either you
don't know how to renumber, or they were already unhappy for some
other reason.

If you tell your customers "You need to renumber because evil forces
are colluding against us," they won't be very amenable... try
explaining that they'll get better connectivity.

The social and technical problems of renumbering a /20 are nonzero but
not large.

I've done it.

Why should someone with significant installed base do it at all?

Explaining that they'll get "better connectivity" rings hollow. Their
obvious question would then be "uh, what's wrong with our connectivity
now?" followed by a few more that you might not want to answer.

Yes, it can be done. No, its not a reasonable request to make of a dedicated
line customer with significant infrastructure who you had, have, and want
to keep.

We have some customers right now which encompass multiple downline connected
parties over large geographic areas, and some of their equipment is incapable
of doing things like DHCP (one comes to mind that happens to be a state
agency). Renumbering THEM would be a job out of the depths of Hades
itself; even broaching the subject would likely cost us the account.

Any significant ISP has customers like this; there is no reason to impose
these costs on you because you're smaller than someone else - no technical
reason that is.

I see. So if you tell the customer that they need to renumber, then they
tell you to stuff it and switch to a new provider who... tells them that
they must renumber out of your soon-to-be-reassigned address space.

I just don't see this as a realistic example of a situation in which a
renumbering ISP is at a severe business disadvantage. In fact I can't
remember ever seeing any such realistic example nor do I ever remember
hearing of a case in which an ISP lost a significant amount of business
because of renumbering.

I can not speak of experience, but I'd suggest that renumbering would
strain an ISPs "good-will" with customers ... pissing off a large customer
is going to give an ISP a bad look particularly if it is known that other
(larger) ISPs don't need to force such things. Particularly if an ISP
places its reputation more on technical capability and convenience and less
on its user-friendly demeanor, this could really hurt. I haven't been
following this issue much, but I think Karl raises what may well be a
relevant point.

Just like to throw an interesting wrench into this whole discussion.

Our current allocations are a /18 and a /19.

Although we are growing fairly quickly here, we're actually seeing
negative address utilization here.

The reason?

We started to recommend to our larger customers that their
newly-redesigned switched 100Mb/s plus really-flat network might be better
served by the 10/8 or the equivalent /16 and /24 address blocks with a
proxy server. Better security, less address space utilization.

When a customer who you allocated a /20 to releases it back after
renumbering into one of the 10/8-type blocks it makes a big difference
when your total allocated space is only equivalent to 6 /20's.

Of course, this is only a temporary reduction, as we are adding several
POP's this summer which will consume more than has been reclaimed.

I would be interested if anyone else has seen anything similar.

- Forrest W. Christian (forrestc@imach.com)

(A)
Customer was reasonably happy to stay but gets prompted to look elsewhere
since the main pain of moving is one he's going to hit anyways. You can't
argue this as good for the ISP.

(B)
Customer is happy to stay and will - but the relationship may be soured
somewhat by the renumbering process. There's certainly a LOT more scope for
something to barf and a someone to need blaming then for someone to say
"gee thanks for making us renumber".

(C)
Customer decides the pain of renumbering is such that he decides to mocve
to one of the really big boys so he never has to do it after this once.
Maybe he's wrong and will have to re-address the issue at some point but
even so some people may take this not entirely unreasonable attitude.

I fully agree that all these people should be able to accept and handle a
renumber without too much hassle but that doesn't prevent the fact that
there's at least some scope for the customer winding up leaving the ISP
over this issue and no scope for the opposite. Thus growing ISPs which have
to renumebr more often are going to be disadvantaged.

Manar

Michael, you just love strawmen don't you?

If they renumber because of a change in provider, they KNOW IN ADVANCE that
this is going to be required and that they'll have to do it. They also know
that they'll only have to do it ONCE. There's a huge difference between
doing something out of choice and doing something out of FORCE.

Tell you what - when we force {Big Provider} to return a /16 to get a /15,
return a /15 to get a /14, etc - then it will be FAIR. Then everyone will
have to renumber as they grow. Then nobody will be at a disadvantage,
because everyone will be equally burdened (relative to size).

Why is it that the Worldcoms, MCIs, Sprints, etc of the world haven't rushed
forward to be the good citizens of the world, consolidating their route
tables dramatically (they ARE the biggest consumers) and do exactly this?

Answer THAT question and you'll be getting warm.

Yep. We've been doing the same thing for over a year; its temporary, but it
will hold us for quite some time.

I don't see that there's anything wrong with it, which makes your CC
exactly on point.

The only potential problem I see is the usual one: you want to put the
people who are most likely to expand at the bottom of the largest
blocks... but how do you tell whom they _are_. :slight_smile:

I have this exact problem pending myself... my new upstream is
perfectly willing to give me a /24... but I said "nah, let's be cool
about it: give me a /27, but put it at the bottom of a /24, and when we
need more, we'll ask. If we don't ask, in a reasonable amout of time,
then you can stuff someone else in there."

The question is, of course, what's a "reasonable" amount of time...

Cheers,
-- jra