- NANOG - lists.nanog.org

Re: APNIC IP-request procedures
by Arnd Vehling 11 Apr '01

11 Apr '01

Hi, Leigh Porter wrote: > > has anybody experience requesting a routable block from > > APNIC? > > > > Ive a a customer on the philippines and would like to know > > if the apnic staff can be as picky as RIPE and ARIN when > > it comes to obtaining a routable ip-block. > > Why, are they afraid that they will find out that they do not need it and > refuse the application? No way. I just wanted to know if the workload to be expected is the same as with ARIN and RIPE because i am doing this on a freelancer basis for ISP companies. Judging from the replies ive got so far now APNIC is as picky as RIPE and ARIN. It can be tough to get an routable assignment alltough the company really needs it, you know. And at least the RIPE became more and more picky within the last years. Like they allways want an deployment plan now which was only asked for on special occasion like 2-3 years ago. thanx for all that answered so far. regards, Arnd -- NetHead Network Design and Security Arnd Vehling av(a)nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Köln Fax : +49 221 8809212

2 1

Re: In search of perfection (was Re: Getting a "portable" /19 or /20)
by Sean Donelan 11 Apr '01

11 Apr '01

On Wed, 11 April 2001, Dave Crocker wrote: > Early IPv6 work explored use of geography-based addressing, but rejected it > essentially because it would require more localized provider > interconnections than existed, or else it requires some rather bizarre > routing information exchanges. Network chickens and eggs. The telephone system has tandems in every LATA because the network architecture requires it, or the network architecture developed because there was tandems in every LATA? International country codes are assigned by country because there was only a single PTT in each country, but now there are several companies. Is the lack of localized provider interconnections an accident of the Internet architecture or a requirement? Are other network architectures really bad, or has the current architecture driven the protocol development which in turns reinforces the same limitations of the current architecture? If you assign CIDR blocks by provider, and multi-homing becomes the norm, things grow worse on the global level. If you assign CIDR blocks by geography, and multi-homing becomes the norm, things grow worse on the local level. Which is worse for the global network, ugly local problems or ugly global problems? We seem to go through the same circle every time. People built the current network around the current limitations of the protocol. If we changed the protocol, perhaps folks could build a different architecture around its limitations. If we had an aggregation strategy which supported aggregation at the region/state/city level, perhaps network architecture would be built the same way. > Still, being able to avoid the tyranical capture effect imposed by > provider-based addressing, AND getting better route aggregation, sure does > make geography-based approaches appealing. > > If only someone could work out the technical kinks... Necessity is the mother of invention?

1 0

In search of perfection (was Re: Getting a "portable" /19 or /20)
by Sean Donelan 11 Apr '01

11 Apr '01

On Tue, 10 April 2001, Sean M. Doran wrote: > Perfectly aggregated networks are star-shaped. > > Any more complicated topology cannot be perfectly aggregated. > > In real networks, aggregation at best follows a "reasonable" > trade-off between optimizing and stabilizing route selection. > Not everyone will agree on what is a "reasonable" balance. Oh great, I'm having flash backs to my Data Structures class. A balanced tree is an example of something which can be perfectly aggregated. It also has a nasty habit of generating extremely long paths. A full mesh is an example of something which has no aggregation potential, but has the shortest possible paths for every link. When folks add a cost component, you generally end up with a set of interconnected hubs-and spokes. The current CIDR allocation method assumes aggregation (and the hubs and spokes) will occur along network providers and their network topologies. The other alternative, used by the telephone system, aggregates hubs and spokes along geographic boundaries. Which requires multiple providers within a geographic region exchange more data, but requires less network information visible on the global level.

1 0

RE: gigabit router (was Re: Getting a "portable" /19 or /20)
by Roeland Meyer 11 Apr '01

11 Apr '01

> From: Craig Partridge [mailto:craig@aland.bbn.com] > Sent: Tuesday, April 10, 2001 4:36 PM > > In message > <Pine.BSF.4.21.0104101753540.98098-100000(a)overlord.e-gerbil.net>, "R > ichard A. Steenbergen" writes: > > >Don't be absurd, I can walk into fry's and pick up a motherboard with > >64bit/66mhz PCI, some Netgear GA620's, and all the other > >components for a 1GHz computer for under $1000. > > OK, so your bus has 4.2 Gb/s of bandwidth. But, alas, you're in a PC > so you have to copy each packet from the line card, into main memory, > examine it, and push it back out to a line card. So each > packet consumes > twice its size in bus bandwidth. So 2 1 Gb/s line cards will consume > 4 Gb/s backplane. Assuming you can run the PCI at full rate (which in > my experience is a big big if), you can connect two Ethernets. There are a few server-class motherboards that have dual PCI-66 buses. One on each bus and there's no problem. Incidently, those same MBs usually have dual or quad CPUs. > Incidentally, this isn't the full story either. You have to > do a route lookup on each of those packets. That's typically 5 to 10 memory > accesses... 5 memory access times 1 Mpps per gigabit times 2 gigabits > is 10 million lookups per second or 100 ns per lookup. Allowing for > time spent getting through the chip to the pins, you probably > need 60 or 70ns DRAM, which is doable. Except, oops!, that completely consumes > your memory bandwidth... where are you going to find the cycles to > get the packets in and out? Huh?! We haven't had the 60ns limitation for over three years. What time-vault have you been living in? PC100 RAM is error correcting at 10ns and PC133 runs at ~8ns. In fact, I challenge you to show me where you can even buy 60ns RAM these days. That's right up there with 3 GB HDDs, not available because they can't find customers for any thing that small/slow, except propriatary applications (they make you pay ... large). I just paid $104 for 256MB of ECC PC100 RAM, at the local computer store. The discount wasn't even worth the gas/hr to drive down to San Jose for (1989 Chevy Suburban, in San Jose rush hour). > PS: Side note, this illustrates where router vendors earn their bucks. Router vendors earn their bucks by building routing/switching appliances. The fact that they manage to get corps to cough up $200K for $15K worth of hardware (COGm, generous) is yet another issue. I expect to see some serious price drops in the next 6 months. I also expect to see commodity hardware start making some serious in-roads (cause of the price-drop). COGr = 1/2 COGm, manufacturers cost of raw material (chips, labor, copper, and such) COGm = Cost of Goods manufactured (fully burdened) 2*COGm = The resellers cost (including mfg's margins) 4*COGm = The distributors price 8*COGm = Retail price (What you pay, full retail) [yeah, that's right. This means that, said RAM, cost $13 to make. econ 101] > Find a way to move data over each bus only once (double your > bandwidth!). Dual PCI66 bus. > Design your memory subsystems to keep packets and routing > data separate (increase your memory bandwidth!). PC133 ECC RAM (8ns). > Find a processor that > doesn't waste cycles doing virtual memory (improve your memory access > times!). Dual/Quad 1Ghz PIIIs, anyone? > Oh yes, and then add hot board swap, How many routers actually do this? Even when they do, it is more prudent to find the time to shut it down for 5 minutes. It's not like solid-state devices die all the time...no moving parts. Keep them cool and they'll go obsolete before they fail. Unless it's a combat situation (where you don't have time to swap anyway) there isn't much that warrants this level of maintenance. You're much better off with a redundant hot fail-over configuration so that you can bring one down for PM and replacement/upgrade. > a working BGP implementation (quick, where's Tony Li working these days:-)), I actually like GateD. It ain't fancy, but it works. > a CLI, Linux is handy. RT Linux might be better (maybe). > and a power subsystem for a CO, If you must include that, then my choice is a Liebert GT3600. > and you're in business. With current commodity price drops, in less than 6 months, the cost of doing this will fall well below $1000, retail. Considering potential market volume. A 100% proprietary hardware solution may not be feasible, at that price-point. They will *have* to use commodity hardware, just to keep up the margins.

2 1

Re: Getting a "portable" /19 or /20
by smd＠clock.org 11 Apr '01

11 Apr '01

| > Perfectly aggregated networks are star-shaped. | | No. They are tree shaped. It seems pretty difficult to have all elements in a network except one have only a default route if you have a tree shape, assuming you don't mean a 3-node network... | > This is a result of the CIDR addressing architecture and is | > INDEPENDENT OF THE NUMBER OF BITS IN AN ADDRESS. | | I disagree, if insted we didn't aggregate into /19s or /20s but into /22s | and /23 there would be less unoptimum routing and larger (less scalable) | route tables. Yeah, and if you deaggregate from /[overhead]s into /[overhead+2 or 3] in any length CIDR routing system, you get 4 or 8 times the number of prefixes, and make some people happy that they get more optimal routing and make some people unhappy that they have to bear the extra dynamism. In the interest of obviousness, "overhead" is the number of bits necessary to identify a unicast address, and if you want to use a larger value (like 19 or 20) just for fun, you get the same number of potential prefixes whether your field is 32 bits or 128 bits or 2³² bits. Sean. (g'night)

1 0

Re: Getting a "portable" /19 or /20
by smd＠clock.org 11 Apr '01

11 Apr '01

Greg Maxwell <gmaxwell(a)martin.fl.us> writes: | > Aggregation buys time, that's it. Aggregation does not make the | > current routing methods any more scalable. | | In IPv4 yes, because you can't have perfect aggregation, too much network | multihoming and old prefixes and it's to painful to change address blocks. | | In IPv6, if implimented right aggregation provides for virtually limitless | scalability for unicast traffic. Perfectly aggregated networks are star-shaped. Any more complicated topology cannot be perfectly aggregated. In real networks, aggregation at best follows a "reasonable" trade-off between optimizing and stabilizing route selection. Not everyone will agree on what is a "reasonable" balance. Result: some people unhappy about suboptimal routing ("my packets to my neighbour across the street go through another country") and some people unhappy about too-great dynamicism ("damn, time to upgrade to a faster processor, more memory, faster memory, etc etc etc"). This is a result of the CIDR addressing architecture and is INDEPENDENT OF THE NUMBER OF BITS IN AN ADDRESS. Sean.

2 1

RE: Getting a "portable" /19 or /20
by Roeland Meyer 11 Apr '01

11 Apr '01

> From: Majdi S. Abbas [mailto:msa@samurai.sfo.dead-dog.com] > Sent: Tuesday, April 10, 2001 1:20 PM > Please let me know when your Linux box is capable of doing > line rate forwarding on an OC-192. I actually saw a Linux box capable of doing this. It was on IBM S/390 hardware. Admitedly, that would be a waste of horsepower. OC-192 is far to slow to keep that box busy. <GRIN>

4 3

MultiBind Testers Wanted
by John Palmer (NANOG Acct) 11 Apr '01

11 Apr '01

American Webmasters is completing modifications to Bind 9.1.1 in a new version called MultiBind. MultiBind solves the problem of multiple root networks on the internet by allowing the specification of more than one root.cache file. Cache files are processed in order of sysadmin-specified preference. When looking for a TLD, MultiBind searches each of the RSNs until a match is found. MultiBind will also allow the sysadmin to specify RSN-TLD preferences so that control is not just at the root server level. We are looking for testers - anyone who would like the code, please respond here. The beta release will be ready on May 1, 2001 http://www.nic.lion

6 5

RE: Getting a "portable" /19 or /20
by Roeland Meyer 11 Apr '01

11 Apr '01

> From: Christopher A. Woodfield [mailto:rekoil@electro.semihuman.com] > Sent: Tuesday, April 10, 2001 2:15 PM > Oh, and when you can > > (a) have Linux shut down a failing interface card on the fly and keep > humming along, > > and > > (b) be able to replace said card without shutting down, > > lemme know. IMHO, you are being short-sighted. Linux doesn't just run on PC boxen. That was my point earlier about the S/390. You assume too much. BTW, let's see you do the same thing with Sun gear, even Netras. How about hot-swapping a blade in a Cisco Catalyst 6509(not sure, here. I usually shut 'em down to do that.)? BTW, if you can find the hot-swap gear you want to run then I can probably get Linux to run on it (it just takes a while). Linux runs everywhere from Pal Pilots to S/390s (has any one seen it on a Sun e10K yet?) In this day and age, such absolute statements are a little hazardous. Their shelf-life, even if true, is measured in micro-secs. -- The only absolute is that there are no absolutes.

2 1

Re: Getting a "portable" /19 or /20
by Richard A. Steenbergen 11 Apr '01

11 Apr '01

On Tue, 10 Apr 2001, Dan Hollis wrote: > On Tue, 10 Apr 2001, mike harrison wrote: > > They do not compare on the same scale as purpose built hardware and > > OS's like the Cisco's, Lucent, Ascend... equipment. Anyone that thinks > > that they compare directly is delusional, as I was. > > Can't exactly run down to the local Wal*Mart or Fry's and pick up a spare > Cisco power supply, ram, or 100mb ethernet card though... > > Never quite understand how Cisco can charge $1800 for a $1.25 10/100 PCI > ethernet controller, either... Don't be silly, a good 10/100 PCI ethernet controller costs $10 retail, or about $3 in parts... (I have to admit to being a fan of the netgear FA31x as well, it has never done me wrong and for the price if it ever does it goes to the parking lot for Bryan Blank to run over). -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0