|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Dealing with ARIN.. my experiences & tips
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 should). 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 answers. -- Jeff McAdams Email: [email protected] Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 Attachment:
pgp00018.pgp
|