September 1995 - Test - lists.nanog.org

Re: Sprint violations (setting space aside for slow-start allocations)
by Sean Doran 08 Oct '95

08 Oct '95

Nick - Good points. You also join the registries in making one of the two very persuasive arguments in favour of relaxing (perhaps some, perhaps all) of 206.0.0.0/8 by one bit, to allow in /19s. Slow-start is a good idea, and we have the RIPE /19 legacy to prove it. Now we need to look at whether this can be done with /18s without exhausting IPv4 too soon, as there are some real concerns about doubling the maximum number of prefixes many routers will see. I also see no problem about working out case-by-case arrangements for putting holes into our filters in the future, taking everybody's various costs into consideration. | If Sprint is not doing a good job of aggregating its announcements, | filter them, eventually they'll get around to aggregating everything | they can. There certainly is some aggregation that should be done downstream from Sprint. We try to encourage people to aggregate what they can aggregate, but some outside pressure to do so probably would help... Sean. P.S.: | So how about agreeing on pools of address space for small allocations? I think you found a good topic!

3 4

Re: filtering long prefixes
by Sean Doran 08 Oct '95

08 Oct '95

Yes, Geert Jan, but if you look at the list I prepared, you'll note that the only chunks of old style Bs that are 18-bits long all come from one home-AS and most are in a pair of old-style class Bs which easily could be aggregated into a single /15 with the loss of some routing specificity (which is lost anyway when that provider's internal metrics don't propagate to its external peers). The remainder of the 'chunks' of old style Bs are all longer than 18 bits, and most are /24s or /26s, and I see none at all that appear difficult to aggregate, or which look like anything other than leaks due to misconfiguration. If you get to the point where someone needs to have a /18 in the old-style class B space and it can't be aggregated, we can return to this. Sean.

3 2

Re: number of unaggregated class C's in swamp?
by William Allen Simpson 02 Oct '95

02 Oct '95

> From: Michael Dillon <michael(a)junction.net> > On Fri, 29 Sep 1995, Mark Kent wrote: > > Announce now that by Oct 1, 1996 no individual /24 will be routed. > > This is a reasonable timetable. > > > Filter 204/24 and 205/24 on Oct 31, 1995 > > Filter 202/24 and 203/24 on Nov 30, 1995 > > This is not! > > The great bulk of the world, especially management types, gets their > technical news with a 4 to 6 month time delay from glossy technical > magazines. This delay is due to the time required for writers to I want to thank Mark Kent, and disagree with Michael Dillon. Last April, folks at IETF stood in the front of the room and said they were going to start reducing the prefixes. I heard within a _month_! Now, it has been 6 months. We've already had plenty of time for the news magazines to print and management types to absorb the news. Some competent providers have already informed their customers that they need to renumber, have already started planning, and are actually renumbering! Others are not so competent. Time to announce to them that we're sorry, but unless they pay out lots of money to upgrade their competitors and fund the research, their competitors aren't going to accept their /24 routes anymore. We are all in this together. Now, the pier wg is trying to help put together a list of OS's and pin-pointing "how to" work through renumbering. That should help. But there's no time like the present to get on with doing it! The only difference I'd make is to _START_ with 192, not end there. We get a lot more bang for the buck there, as renumbering will help aggregate both continentally and regionally, and also free up badly managed space for the future. That nice table from Dennis was an eye-opener (just what I was looking for, thanks)! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

5 6

geeting NANOG listed in Encyclopedia of Associations
by Nigel Allen 02 Oct '95

02 Oct '95

Groups like NANOG may find it useful to be listed in the _Encyclopedia of Associations_, a directory of national non-profit groups in the United States, so that journalists, researchers and potential new members can get in touch with you more easily. I have transcribed the questionnaire that the _Encyclopedia of Associations_ uses to compile its listings, and I would be happy to send a copy to anyone who would like their group listed. The Encyclopedia of Associations is published by Gale Research Inc. of Detroit, a well-known publisher of reference books. Your local library probably has a copy of the _Encyclopedia of Associations_ that you can look through to see how other progressive groups are listed. To request a questionnaire, send me e-mail (ndallen(a)io.org) or contact: Encyclopedia of Associations Gale Research Inc. 835 Penobscot Building Detroit, MI 48226-4094 U.S.A. telephone (313) 961-2242 or 800-877-GALE fax (313) 961-6815 -- Nigel Allen, Toronto, Ontario, Canada ndallen(a)io.org Web page: http://www.io.org/~ndallen

2 1

Comments on Routing and Allocation Policy Wanted
by Forrest W. Christian 30 Sep '95

30 Sep '95

I'm currently in the process of working on a "rough draft" of a policy on IP number usage. I'd like to solicit a few comments from those of you who seem to be making the majority of the routing decisions. Here's a copy of what I'm presently working on. Please feel free to rip it to shreds if necessary.... THE MONTANA INTERNET COOPERATIVE INTERNET ADDRESS ASSIGNMENT AND ROUTING POLICY September 29, 1995 Standard Dialup SLIP, CSLIP and PPP customers will be allocated a Single Static IP Address to be used to configure their software. There are many advantages to be gained by Statically allocating the numbers, including the ability to have multiple mailboxes by using SMTP, etc. Dedicated and Routed-Dialup customers will be allocated a block of numbers from MIC's CIDR block. The size and quantity of blocks will depend on the number of machines to be connected to the network at the customer's premises and the customer's network architecture. MIC currently allocates blocks containing 8, 16, 32, 64 or 256 "individual" addresses. Multiple consecutive blocks will be allocated depending on need of the customer. Dedicated and Routed-Dialup customers who already have a set of Internic allocated addresses may continue to use those numbers as long as the following conditions are met: 1) The numbers MUST be listed and registered in the internic database. 2) Only blocks addressable with a prefix of /21 or smaller for addresses with an initial octet less than 205, and blocks addressable with a prefix of /19 or smaller for addresses with an initial octet of 205 or higher will be permitted. If you are uncertain whether certain addresses meet these criteria, contact MIC support for details. 3) The customer is aware that MIC will not guarantee the routablity of any customer provided numbers. The customer should also be aware that routing policies can and will change, and as a result, the customer's numbers may not be routed by various Service Providers at any point in the future. forrestc(a)imach.com

3 4

Re: number of unaggregated class C's in swamp?
by Walter O. Haas 30 Sep '95

30 Sep '95

Seems to me like the logical place to start renumbering, if that's going to be forced, is by outlawing new CIDR block exceptions - if you switch providers you renumber. It's a hateful approach in that it raises the barrier to new providers entering the market, but it's more understandable to customers. The next step would seem to be outlawing *existing* CIDR block exceptions. Give up your portable numbers and get back under the provider's umbrella. We renumbered a group of machines by hand once. Not an experience any of us want to repeat. Flag Day turned into Flag Week! At least if you're switching to another provider you have the chance of running with two addresses on each machine for a month or two. Has a chance of being managed less disruptively. Would be nice if everybody supported DHCP. Reprogram the server then go shut off the main circuit breaker ;-) Anybody care to bet when that will actually happen? Ugh. Renumbering is *NOT* going to be popular. -- Walt

1 0

Re: number of unaggregated class C's in swamp?
by William Allen Simpson 30 Sep '95

30 Sep '95

> Date: Fri, 29 Sep 1995 20:16:54 -0400 > From: Dennis Ferguson <dennis(a)mci.net> > The one thing that hasn't been done, however, is to set an actual > goal for routing efficiency. Excellent! > I'd like to state my guess that a good number to aim at might be > about 1200 routes per fully-utilized class-A-sized chunk of address > space. This would put the IPv4 end state at a maximum of about 250,000 > routes, ... > I like the idea of measuring each and every class-A-sized block > against some standard separately, since a lot of the class-C space has > been allocated to regional registries this way and it inconveniences > those places which have done the best the least. I'm less attached to > the number 1200 in particular, but I do think an explicit target should > be chosen which represents both a tractable limit to design big routers for > and which allows the implementation of efficient address allocation strategies > which won't have to be tighened over time. I suggest that it be 2048 for each _pair_ of class As, since that's how they were assigned in RFC-1366 & 1466. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: number of unaggregated class C's in swamp?
by jnc＠ginger.lcs.mit.edu 30 Sep '95

30 Sep '95

From: Dennis Ferguson <dennis(a)mci.net> I also wouldn't bet the farm on some amazing new routing architecture saving us Actually, I think you can safely bet the farm in the other direction, that there is no such thing possible. Yakov and I have some substantial non-agreements about routing architectures, but we are fully agreed that aggregation/abstraction is the only way to make the routing overhead scale, and that means connectivity-sensitive assignment of routing-names, aka renumbering. Sure, at a fixed point on the cost/performance curve, over time you can buy more powerful machines at the same price, and that will allow you to be able to run larger routing tables over time (imagine trying to stuff 28K routes into an IMP :-). There are other things going on too, e.g. some routing designs inherently have more or less overhead than others. However, the bottom line will always be the same, which is that free-form allocation of routing-names in a global-scale network will not be possible. To keep routing overhead within a workable (although probably slowly growing) bound, routign-names will *always* have to be assigned based primarily on network connectivity. I think not dealing with pre-existing allocations is going to mean putting an ever-tighter squeeze on future allocations in a way that is counter-productive, Yes. This also spreads the burden to everyone. what I think we should be doing is trying to pick a routing efficiency which gives us a number of routes ... which seems tractable Exactly. the IPv4 end state at a maximum of about 250,000 routes, a number which I think is not an unreasonable target for new high-end router designs Hmmm. I think this is probably a bit agressive for the next generation, but then again we aren't likely to arrive at the end state for at least several product cycles anyway. Also, the limit I most worried about is the stabilization time, and looking at individual router performance is unlikely to tell you if you can meet this. I'd much rather see each space filled .. as appropriate ... rather than picking an arbitrary, one-size-fits-all filter limit. The latter is a sign of failure. I agree, but the latter does have the advantage of being easier to "police". Getting a whole address block under a limit requires the cooperation of everyone in the block, whereas filters (as we have seen) are easy to impose... Noel

3 2

Re: number of unaggregated class C's in swamp?
by William Allen Simpson 30 Sep '95

30 Sep '95

> From: Barney Wolff <barney(a)databus.com> > > This is interesting, showing how bad assignment has been even > > _after_ CIDR. 5K sites migrating providers in 2 years. > > I believe the NIC was assigning out of 198 before CIDR went into > effect. I got a single C directly from them in late 1993, as I recall. > RFC-1366 was October 1992! And of course, an internet draft before that! Another fine example of the NIC level of competence. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

HK IT Expo Opens On Internet Traffic Jam 09/29/95
by postel＠ISI.EDU 29 Sep '95

29 Sep '95

----- Begin Included Message ----- Date: Fri, 29 Sep 1995 17:58:16 -0400 From: David Farber <farber(a)central.cis.upenn.edu> Subject: HK IT Expo Opens On Internet Traffic Jam 09/29/95 CENTRAL, HONG KONG, 1995 SEP 29 (NB) -- Hong Kong's IT Expo opened on Wednesday for a four-day spree and organizers said at 5pm on the opening day that 10,000 visitors had already been through the doors. It's the sixth Expo and so far the largest, with over 240 exhibitors attending. Unlike other years, major computer manufacturers were notable by their absence -- with only IBM, Digital and Microsoft making their presence felt with large stands. Most of the action on Day One was centered around Internet products and service providers. But Wednesday was not the best of days to start putting the Internet through its paces before the public. As the crowds turned up and providers began hyping the wonders of e-mail, databases and World Wide Web sites from Alabama to Zagreb, computer response became embarrassingly slow. One of the territory's largest providers, Asia On-Line, reported a major problem somewhere in the US "backbone" of the Internet. Technical staff were unsure which company was having problems, but noted that the system kept looking for alternative routes, indicating that one of the larger data highways was closed to traffic. (Nigel Armstrong & I.T. Daily/19950928) ----- End Included Message -----

1 0