- Test - lists.nanog.org

The Cidr Report
by Tony Bates 29 Oct '99

29 Oct '99

This is an auto-generated mail on Fri Oct 29 12:00:00 PDT 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 29Oct99 0) General Status Table History ------------- Date Prefixes 221099 65598 231099 65493 241099 65535 251099 65586 261099 66128 271099 65317 281099 65520 291099 65524 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 100.0.0.0 from AS2561 *** Bogus 110.30.236.0/24 from AS577 *** Bogus 126.0.0.0 from AS2561 AS Summary ---------- Number of ASes in routing system: 5916 Number of ASes announcing only one prefix: 3138 (1731 cidr, 1407 classful) Largest number of cidr routes: 601 announced by AS701 Largest number of classful routes: 1017 announced by AS701 1) Gains by aggregating at the origin AS level --- 29Oct99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 383 144 239 62.4% BCnet Backbone AS7046 426 255 171 40.1% UUNET-CUSTOMER AS2609 128 8 120 93.8% EUnet-TN AS6944 133 18 115 86.5% RapidSite, Inc. AS1221 625 515 110 17.6% TELSTRA-AS AS9269 131 30 101 77.1% Hong Kong CTI AS7657 250 162 88 35.2% The Internet Group Limited AS174 563 476 87 15.5% Performance Systems International AS577 265 180 85 32.1% Bell Canada Backbone AS4293 227 142 85 37.4% Internal ASN for C&W AS7545 140 64 76 54.3% TPG Internet Pty Ltd AS3749 140 64 76 54.3% TECNET AS7496 111 37 74 66.7% Power Up AS4200 183 110 73 39.9% AGIS (Apex Global Information Ser AS701 1017 954 63 6.2% Alternet AS209 321 268 53 16.5% Qwest Communications AS4740 339 287 52 15.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS816 226 181 45 19.9% UUNET Canada (ASN-UUNETCA-AS4) AS4755 109 68 41 37.6% Videsh Sanchar Nigam Ltd. India AS2493 132 92 40 30.3% iSTAR Internet, Inc. AS9304 54 15 39 72.2% Hutchcity AS6528 45 7 38 84.4% WORLD-LYNX AS549 213 175 38 17.8% ONet Backbone AS1 501 466 35 7.0% GTE Internetworking AS7568 47 13 34 72.3% C.S. Communications Co., Ltd. AS6172 143 110 33 23.1% HOME-NET-1 AS3737 99 66 33 33.3% PenTeleData Inc. (ASN-PTD) AS1785 237 205 32 13.5% NYSERNet Backbone AS9453 33 2 31 93.9% Soongsil University For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

I need someone clueful at Network Solutions
by Ehud Gavron 29 Oct '99

29 Oct '99

Operational help needed. Must register DNS server. Money available. Help? Details below. Note that the more you read the stupider you will get. Ehud Facts: I own WETWORK.NET, registered with the register.com registrar. I own LETOH.COM, registered with network solutions registrar. 20-oct I register a domain LETOH.COM with network solutions, and attempt to use the nameserver "server.wetwork.net" which is under my register.com domain wetwork.net. Network solutions says to [NIC-991020.1545c]: ERROR: Name Server <SERVER.WETWORK.NET>is not registered with InterNIC. 20-oct I send in a host template [NIC-991020.15848] but NetSol says: The <WETWORK.NET> domain is non-existent. First register this host through the host registration process or choose a different name-server. AT THE SAME TIME I get another mail message from them: All Host Forms must be submitted from the e-mail address of the current host contact...we have sent a notification message ... which they did not send anywhere I can tell. 22-oct I sent mail to help(a)internic.net and asked them to fix this. 26-oct Netsol says: The problem with your HOST registration was that you were trying to register a host but the TOP-Level part of the host is not a registered domain, i.e.WETWORK.NET. 26-oct I wrote netsol and said: Wetwork.net exists.. just not with your registry. However, I wish to use mail.wetwork.net as a DNS server with your registry future domains. Please register the host asap. 27-oct Help(a)internic.net says to send in a host template and includes one in the message... 27-oct I submit the host template [NIC-991027.75ef]. I also follow it up to help@ with: 991027.75ef duplicates 991020.15848 as per your request. 27-oct Once again I get the 'All host forms must be submitted from the email address of the current host contact...' 27-oct I forward the mess back to help@internic [NIC-991027.14981] I forward a copy to kimh@ with header Subject: 1. I submit host form. 2 you reject it. 3 I ask for help. 4 help says submit host templte. I DO. Here's the rejection again. Please fix 27-oct help@ responds with: Thank you for contacting Network Solutions. To register a domain name in the COM, NET, ORG, and EDU top-level domains, you should: 1. Make arrangements for Internet service. A company that can connect you to the Internet Ehud Gavron ACES Research, Inc., an RMI.NET company

1 0

Re: Traffic engineering tools
by Vadim Antonov 28 Oct '99

28 Oct '99

Prabhu -- > You continue to dismiss concepts (traffic engineering) that have proven > themselves in practice in large networks. And they continued to prove > themselves long after you predicted they would not (years ago). I continue to tell that there are simpler and more robust solutions to the same problems. And that it is much easier is not to create problems in the first place than to think up clever patches later. > Stating the obvious, "there's more fiber in the ground than all routers > can fill up" is not the point. The point is could we have built the Internet > to its present point without traffic engineering? The answer to that is a > resounding NO! If you consider Internet in its present shape working, i beg to differ. It's a horrible kludge which nobody really understands. It's extremely brittle. For one, i'm working for a company which takes the question "How can you put 911 service on the Internet" very seriously. If you look at the things from this perspective you'll see that we have a long way to go, and that making things even slightly more complicated than the bare necessity is not the right way to go - if we want to have it debugged in less than 100 years it took for telephony to become dependable. > The next question is whether traffic engineering is useful for the future. I see little use in discussing the present :) > Remember these practitioners do not build networks based upon theory, but on > practical implementations that prove themselves to work. Perhaps the > load-sharing mechanism you described for Pluris will work. Perhaps not. Works in Cisco's CEF. > But to promote what hasn't proven itself and dismiss what has sounds > suspicously like bad marketing dressed up in the language of mathematics. I do not do marketing. I do not speak for Pluris. If you checked the website you'll see that the company is doing all the TE bells and whistles you find in any other router box. In fact, if i behaved like a marketroid, i'd insist on doing them - because not providing something which is in vogue never wins a lot of customers. As for mathematics and logic reasoning - please, if you see flaws in the reasoning, pount them out. The fact that something sometimes works doesn't prove anything. Following that line of argument, we all should be doing X.25 - because some decade ago that was what nearly everyone was doing and the networks in their present shape at the time couldn't be built without it. --vadim

2 1

Re: Questions about the new RADB Maintainer Fee (FAQ available)
by Sean Donelan 28 Oct '99

28 Oct '99

A note on the FAQ. BGP peering with the route servers does not mean you have to actively announce or listen to any routing information via the route servers. Some providers have used null BGP sessions, or announced routes only to the route servers for some academic-types to study; but not for peering with other providers.

2 1

RE: ** ANNOUNCE -- New RADB Fee Structure **
by Richard Jimmerson 28 Oct '99

28 Oct '99

On Wed, Oct 27, 1999, David Kessens wrote: >On an additonal note: ARIN recently setup an RPSL compatible IRR >registry which might look like a very attractive alternative for those >people that are currently using the RADB ... Thanks, David. ARIN does offer a routing registry which uses RPSL and we would like to encourage everyone to make use of this free service. Please visit the following URL for more information: http://www.arin.net/rr.htm Regards, Richard Jimmerson American Registry for Internet Numbers (ARIN)

1 0

Re: Traffic engineering tools
by Vadim Antonov 28 Oct '99

28 Oct '99

> You miss the point. As you well know, capacity is where it is, and not > where you need it. This is a pragmatic and practical problem that costs > people Real Money. Tony, there's more fiber in the ground than all routers together can fill up. And putting in fiber is not a highly skilled labour, quite unlike getting tons of buggy software to work in a production network. > I know one very large backbone operator who says something like "We couldn't >even begin to build our network without TE. It works and we must have it." Isn't it the same provider who's notorious for ATM-based network? If we think of the same provider - i had a pleasure of being a customer. Never again. > It's got nothing to do with latency and everything > to do with capacity. If you have the luxury of having fiber wherever and > whenever you want it, well, you're lucky. But not everyone is quite so > lucky. Luck is 99% a foresight. > I would claim that those _ARE_ real benefits. Numbers? > Perhaps it's not the elegant, desireable, or theoretically beautiful > solution. But it is a practical solution. Yes, sure. As Milo used to say: "With enough thrust even pigs will fly" :) > If you would like to wait for the elegant, desireable, and theoretically > beautiful solution, please be my guest. Those of us who engineer to reality > have more work to do. ;-) I'll simply remind you that there is also a > group of people waiting for the elegant, desireable, and theoretically > beautiful inter-domain routing protocol. I found that one cannot do IDR protocols for a living. Maybe, Yakov :) > Or..... it could be a requirement posed by the customer base that vendors > are trying to address. Yeah, sure. Like the conFusion. Or 7000 series. > You may not share in the problem. That's fine, I don't think anyone would > (ethically) suggest that you use a tool that solves a problem you don't > have. Unfortunately, the tool does not come free - any new code in a box makes the box flakier. And costlier. So what all these features do is shifting cost from those who screwed up network planning to those who did it properly, but have to pay for all bundled TE stuff and live with flaky complicated code. My memories of being dragged out of bed nearly every night because of router software being stuck in interesting ways are not particularly fond. I'll exchange complicated ultra-smart hot stuff for a dumb box which actually works - any time. --vadim

3 2

Re: Traffic engineering tools
by Vadim Antonov 28 Oct '99

28 Oct '99

Traffic Engineering is like Quality of Service - it doesn't create any more bandwidth by magic, and simply reallocates existing resources differently. That established, we have two courses of action - the first, is to bulild overcomplicated networks and then try to fix resulting suboptimal routing with TE. The second option is to simplify topologies by replacing clusters of routers with scalable and inherently fault-tolerant devices (guess which ones i have in mind :) In a long-distance backbone where routers connected directly to fibers, and where there's no overlay of level-2 topology, the cost of deliberate misrouting (sending packets down paths different from shortest) is simply too high to justify any benefits it brings. The intermediate virtual circuit layers simply obscure the fundamentals by making paths inherently non-optimal (if you do not plan to use SONET or ATM VCs to create topologies which do not match physical paths, why whould you want to install it?) Note that customers do not generally care about bandwidth. The name of the game is latency at a given load. Misrouting packets simply increases latency. So. Benefits of TE as compared with simpler and more robust techniques (such as adequate provisioning and capacity planning :) weren't demonstrated in practice. I have yet to see any real backbone operator saying something like "we've got 30% less latency because we do TE". I strongly suspect that is because there are no real measurable benefits - and that TE is being used mostly to cover up planning problems and as a short-term fix to idiocies at a transmission level. That is a very thin justification for replacing technology which is known to work with a very new can of worms. My personal theory on QoS and TE hoopla is that this is a FUD tactics used by Cisco to raise entry barriers for other vendors - and to con customers into buying more of their irrelevant ATM stuff. --vadim PS There were tons of research and articles on best methods of CPU and memory scheduling. In restrospective, building faster processors turned out to be the soultion. Even if they're 99% idle. Meanwhile, the vendors which were keen on doing detailed accounting stuff nearly all are history by now. >From: Jerry Scharf <scharf(a)vix.com> ... >I do believe that some of the TE folks are punting the general case >solution by only attempting to do TE and protection on a small potion of >their traffic. If you have a glut of web traffic that acts as a sponge, >you can get away with nonoptimal management of the subset without causing >meltdowns.

2 1

** ANNOUNCE -- New RADB Fee Structure **
by Craig Labovitz 27 Oct '99

27 Oct '99

RADB Fee Structure ------------------ Since 1995 Merit Network, Inc., has operated the RADB Internet Routing Registry as a free service to the community. Initial funding for the service came from the National Science Foundation as part of the Routing Arbiter project. In recent years, donations from a number of commercial Internet providers provided continued support for RADB operations. As Internet Routing Registry technology has matured, the RADB service has experienced explosive growth. Today, the RADB database handles well over a million queries a day from several thousand unique Internet end-sites. This growth in RADB usage, including a dramatically increased volume of email and telephone calls to the RADB help desk, has placed significant demands on RADB staff and equipment resources. In an effort to maintain the high level of RADB service as well as encourage the migration to a distributed database, Merit has implemented the following RADB fee structure: Beginning November 1, 1999, Merit Network, Inc., will begin charging RADB users a $200 yearly fee per maintainer object registered in the RADB Internet Routing Registry database. Credit card payment must be made by all RADB maintainer object owners within 60 days. Unpaid maintainer objects and all related objects will be disabled from the registry. Internet providers may register via the web by reading and accepting the Internet Routing Registry Maintainer Object Agreement, <https://www.radb.net/radb/agreement.html> and then by supplying the appropriate payment information. IMPORTANT: The registration fee for Internet providers PEERING with Route Server Next Generation <http://www.rsng.net> machines at the PAIX, Mae-East, Mae-West, AADS and PacBell exchange points is included as part of the RSNG service at these exchanges. Providers peering with the RSNG route servers at one or more of these five exchange points do *NOT* need to submit a $200 payment for any maintainer objects registered with their autonomous system number in the RADB. Alternatives to Registering in the RADB --------------------------------------- As an alternative to the RADB, Internet providers are welcome to maintain their own local registry. Several groups, including Merit Network, have recently developed RPSL-capable Internet Routing Registry database servers. These *FREELY* available IRR server daemons, including IRRd, provide a simple mechanism for providers to maintain a mirror of Internet registry data and a local repository of customer routing information. As part of the transition to RPSL and RPS-DIST, Merit now strongly encourages RADB users to begin operating their own local routing registries. Merit will continue to freely mirror and permit mirroring by other local ISP registries. For more information on running your own IRR registry, see: http://www.irrd.net http://www.ripe.net/db http://www.isi.edu/ra As an alternative to the RADB or running a local registry, RADB users may also choose to register in several alternative IRR databases. Several providers, including Cable & Wireless and Bell Canada, offer IRR registration service for their downstream customers. For a complete list of participating Internet Routing Registries, please see http://www.radb.net/list.html. More Information ---------------- For more information, please see the RADB web page at http://www.radb.net Or feel free to send email to db-admin(a)radb.net -- Craig Labovitz (425) 605-4296 (office) (425) 936-7329 (fax)

9 10

RE: Major asia pacific public exchange points
by K Dhanaseker 27 Oct '99

27 Oct '99

Hello, Data.com has compiled an article on the APIX . http://www.data.com/global_networks/backbones.html Though it is dated , might be a good starting point. There is another article on APIX peering w/ PAIX. http://www.data.com/story/DCM19990730S0001 Thanks ! Regards, Dhanaseker Network Engineer Trinus Corp Glendale,CA 91203 Ph: 908-230-2578 -----Original Message----- From: Sean Donelan To: nanog(a)merit.edu Sent: 10/26/99 3:34 PM Subject: Major asia pacific public exchange points What are the, or are there any, major international public exchange points in the Asia-Pacific region? I know about the wwww.ep.net web page listing lots of exchange points. For example, an exchange point with at least two multi-regional/multi-continent ISPs. Europe has the LINX, AMS-IX, dGIX, etc.

1 0

WC outage?
by Tatsuya Kawasaki 27 Oct '99

27 Oct '99

It appeared WC is experiencing some major outage somewhere. Any idea? Tatsuya /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Tatsuya Kawasaki KIVEX.com (Division of Allegiance Telecom) Unlock the Power of the Internet http://www.kivex.com Phone 301.215.6777 Fax 301.215.5991 Affiliation given for identification not representation /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

2 1