ARIN Proposal

Jeffrey C. Ollie jeff at ollie.clive.ia.us
Thu Jan 23 10:03:02 EST 1997


-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 23 Jan 1997 00:56:42 -0600 (CST), karl at mcs.net writes:
>
>> On Wed, 22 Jan 1997 22:35:00 -0600 (CST), karl at mcs.net writes:
>> >
>> > [ on renumbering ]
>> >
>> >But the point is, they shouldn't *HAVE TO* if you change a
>> >vendor relationship.
>>
>> So you've come up with some magical patch to the Cisco IOS and the
>> BayRS that will keep MCI and Sprint running as the routing tables grow
>> past the 100,000 mark? Unless you have, people will *HAVE TO* renumber
>> when they move around. Letting everyone keep their IP addresses when
>> vendors are switched will cause the routing table size to skyrocket.
>
>You are MISSING THE POINT.  Please, please read what I have written before
>and what is below.  Arguing points that aren't being made is non-productive.
>
>One last time:
>
>NOBODY is arguing for end customers who get assignments in the /32 to /20
>range NOW being able to "take them with".
>
>Including me.

Uh, if people don't have to renumber when business relationships
change then they must be "taking their networks with them". Allowing
someone to break up a CIDR block when business relationships change is
BAD.

>HOWEVER, you *MUST* recognize past practice, you *MUST* recognize that
>people relied on representations made to them in the past (which are in
>fact CODIFIED in RFC2008; there is SPECIFIC language in there reflecting
>PAST HISTORY AND PRACTICE), and you *MUST NOT* try to abrogate those past
>policies and practices for *EXISTING* assignments.
>
>If you DO attempt any of these things you will create legal causes of action
>(if you don't believe me go talk to a real lawyer; I have).  Some of these
>are *extremely* serious and will lead to multi-million dollar lawsuits, TROs
>and damage claims, and it is NOT in anyone's interest to foster lawsuits.
>We do NOT need to do things in policy that will engender legal fights.
>It is not in the best interest of the net to do so.  LET'S AGREE NOT TO
>DO THOSE THINGS.
>
>RFC2008 recognized this as FACT -- that people HAVE had this represented
>to them until recently, and that they have relied on it when building their
>businesses.  In fact, the entire reason that 2008 was WRITTEN was to *change
>this going forward*.  Fine.  We change it going forward.  But you must
>recognize HISTORICAL allocation policies (which 2008 ALSO does) as well.

Then those ISPs that made those mis-representations are going to have
to live with the repercussions, aren't they?

The last paragraph of section 5.3 of RFC 2008 states:

    The above shows that the absence of an explicit "address lending"
    policy from a current provider in no way ensures that renumbering
    will not be required in the future when changing providers.
    Organizations should be aware of this fact should they encounter a
    provider making claims to the contrary.

Seems to me that RFC 2008 recognizes the need for renumbering.

>ISPs who intend to multihome MUST have portable space.  Period.  It is
>NECESSARY for a multi-homed connection to *WORK AT ALL*.  Further, if EVERY
>ISP in the United States had a /19 given to them TODAY it would add some
>3,000 or so prefixes to the tables.  This would NOT break the network.  The
>HUGE majority of those ISPs will NEVER need more space; this is a ONE TIME
>hit.
>
>THE INTERNET WILL NOT BREAK IF WE RECOGNIZE THAT ISPS NEED PORTABLE SPACE.
>Again, I am *NOT* arguing that every customer who attaches to the network
>should be able to walk around with /24s that they get assigned *TODAY*.
>I *AM* saying that if you're in the ISP business, you should get assigned
>a /19 initially, and THAT SPACE IS YOURS.  If you need MORE, then justify
>that you have ACTUALLY USED the /19 (and it should then be provided).

Well, then let each ISP write up a justification, submit it to ARIN,
and pay their fees. I wouldn't think think that there would be much
difficulty, especially if they are able explain themselves clearly.

>Finally, Cisco and Bay aren't the only router vendors out there.  Nor is
>the state of the art static.  We are testing a device right now that claims
>to handle 150,000 prefixes with a recomputation rate of 20 full passes/second;
>if this is true then flapping is a non-issue (seriously folks; you can't
>really consider a route instability that lasts FIFTY MILLISECONDS to be
>significant!)  Further, the architecture of that device should scale easily
>to the 500,000 prefix range with ~5-10 recomputations per second; this is
>STILL an instability boundary of ~200ms at worst, which is some two to three
>orders of magnitude better than ANYTHING that CISCO or Bay make right now.

New hardware is a LONG term solution. Face it, no one's going to
unload millions of dollars of Bay or Cisco equipment virtually
overnight for a relatively untested piece of hardware. And I haven't
seen anything that will give Bay or Cisco equipment the ability to
handle orders of magnitude more routes or routing updates.

So for the short term (on the order of 2-3 years, at least), we are
stuck with ARIN or something ARIN-like because we need to limit the
growth of the global routing table.

There will be fees of some sort because the people that work for ARIN
won't work for free and they need computers and ofice supplies, etc.


[A copy of the headers and the PGP signature follow.]

Date: Thu, 23 Jan 1997 09:03:02 -0600
From: "Jeffrey C. Ollie" <jeff at ollie.clive.ia.us>
In-reply-to: Your message of "Thu, 23 Jan 1997 00:56:42 CST."
             <199701230656.AAA18517 at Jupiter.Mcs.Net>
Subject: Re: ARIN Proposal
To: naipr at INTERNIC.NET

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news.

iQCVAwUBMud9rJwkOQz8sbZFAQHFvgP+LvNV0xKIwdOO7n1qKicFzCuHmtTVcKx+
LbaLrqlyShjOSyjsx48Wt0L0EBcYZGFr6xqWz73yc8lEDy0rCyxW7NLxDCLtgTGI
qybsyoEEq6JneLFNCe0Hsmjd4OHbc04KNdi4vqZkuvvy4zsFmZhQEoK/TNbe/jAh
FaSGk7YJADE=
=+wH6
-----END PGP SIGNATURE-----
--
Jeffrey C. Ollie                     |            Should Work Now (TM)
Python Hacker, Mac Lover             |



More information about the Naipr mailing list