Dealing with ARIN.. my experiences & tips
jeffm at iglou.com
Mon Apr 14 20:43:16 UTC 2003
Also Sprach Brian Johnson
>OK. Let's all assume that Reform is necessary.
>Please state, in detail, how you would reform ARIN and all of the
>policy changes that you would instate (asside from giving you whatever
>you want) to make ARIN "reformed" in the yes of it's membership.
>I await, with baited breath, the answers form the Maha-Jeffy. :-)
Alas...I agree with what some others have said. The answers aren't
easy, and I don't have them all easily at hand. I think there are some
steps that could be taken. Some comments off the top of my head...
First and foremost...ARIN seems disconnected from the realities of
running an ISP...particularly a smaller ISP. There needs to be more
effort to understand the business needs of ISPs in general (again,
particularly smaller ISPs) to understand *why* so many people (even
those that do it on a regular basis and are "experts" in it) find
dealing with ARIN to be such a PITA.
They need to consider whether the policies that they have in place
really and truly do accomplish the goals that they are supposed to
accomplish. I think its pretty clear at this point that they don't.
They need some common sense discussion about really how to accomplish
the goals, the current policies clearly aren't doing it...even can be
counter-productive wrt to the whole point of why ARIN was created (ie,
more common sense policies would have resulted in me advertising half
the number of routes in BGP than I am now...the goal of reducing routing
table growth has most definitely not been accomplished in my case...and,
as I've pointed out...I'm really *trying* to do the Right Thing...not
all ISPs do).
They need to "normalize" (for lack of a better word) their published
policies...as well as "normalize" their actual policies with what's
published. The feel that I get (this is a perception...not much hard
evidence to back it up...but I'd be surprised if I'm alone in this) is
that ARIN has put policies up on its web site, and then totally
independantly, developed policies for operation...with the same basic
set of goals in mind. The result being policies in real life that are
similar, but not the same, as what's published. If there's a change in
the real-life policy, that needs to be reflected on their website.
As for some specific policy points that I think are bogus. Obviously, I
feel the allocating for 3-months needs to be expanded...I'd say probably
to a year would be reasonable. Basing it on past usage growth...ok...I
don't have any inherent problems with that, but specific situations,
such as a desire to renumber out of PA space, should be considered much
more strongly than it is currently.
Limiting SWIP to /29 or shorter prefixes doesn't seem to have much merit
to me...I imagine a lot of ISPs wouldn't want to SWIP longer prefixes
because of the administrative overhead (of which there certainly would
be some)...our system allows us to do it pretty easily, so it wouldn't
be a big deal here. And, as bdragon pointed out, circuit size (and I'll
add network size) doesn't correlate precisely with ip address space
consumption (ie, the idea that you can put a very large corporate
network behind a single, or very small number of ip addresses).
Certainly, large networks like that, should probably have their own
records...even if only a single public IP address is in use. So, what
guideline would I come up for this? As a discussion starting point,
require anything shorter than /29 to be SWIP'ed, but leave longer up to
the ISP...yes, not many ISPs would SWIP anything longer than /29, but we
would, *particularly* if it made dealing with ARIN easier (which is
Anyway...some starting points...I'm sure...with more thought and more
experience dealing with ARIN, I could come up with some more
suggestions...but I'll be the first to admit that I don't have all the
Jeff McAdams Email: jeffm at iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the NANOG