- Test - lists.nanog.org

Re: The Cidr Report
by Brian Dickson 15 Sep '98

15 Sep '98

>Anyone care to comment on the fact that the top non-compliant companies >never really seem to make any significant changes? > >> --- 11Sep98 --- >> ASnum NetsNow NetsCIDR NetGain % Gain Description >> AS174 789 611 178 22.6% Performance Systems International >> AS2493 373 217 156 41.8% iSTAR Internet, Inc. Well, two things: (1) PSI acquired iSTAR; (2) most of the clueful people had left or have left iSTAR (myself being one). I have no specific knowledge of PSI's clue quotient, per se. Also of note: all of iSTAR's unaggregated routes are below 206.0.0.0/8, in geographically-assigned /16's (ie, some /24's belong to iSTAR customers, some to customers of other providers), where the %gain is achieved by aggregating in variable-length clumps (eg /23's, /22's, etc), at iSTAR's EBGP borders, since these are not aggregatable internally. And yes, iSTAR does redistribute its IGP into BGP, but only because Cisco's IOS has a limit (200) on how many "network" statements can exist in a router, which is exceeded by their NetsCIDR. :-( -- Brian Dickson, Email: briand(a)teleglobe.net Teleglobe USA, Inc., Tel : +1 703 821 4818 Suite 400, 8251 Greensboro Drive, Fax : +1 703 821 4885 McLean, Virginia, USA, 22102 http://www.teleglobe.com

1 0

Friday's Outage
by Tim Wolfe 14 Sep '98

14 Sep '98

Sean et al. Any further info on the results of Friday's train derailment as it relates to the Net slowdown/release of the Starr report? Also, how long were things down before Worldcom/MFS were able to get things spliced back together? Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

MAE ATM and distant connections
by Aleksi Suhonen 14 Sep '98

14 Sep '98

Hello, I'd like your opinion on the following concept. It is non-specific to any single MAE or continent but my original idea is of MAE-EAST and Europe. An overseas operator could get a circuit from one of its POPs directly to the MAE ATM switch (matrix) and set up peering PVCs between its peers and the router(s) in its POP overseas. This would eliminate the need for colo space and remote hands service for an overseas router from the operator's point of view. I can immediately think of four drawbacks to this: 1) Routing Protocol Latency This shouldn't be an issue with BGP. 2) Routing Protocol Bandwidth Waste This would only be an issue if the operator would receive lots of same routes from two or more peers. To be a constant issue those routes would need to flap a lot too. 3) Router Not On Shared Medium (Ethernet, FDDI) This could be overcome by some cooperation with a local provider that has a switch between its shared medium connection and its router. The switch should be capable of ATM LANE though and MAE ATM switches would need more complex configuration as well. Ideally the MAE ATM switches would do it directly, but I'm not sure thay are capable of it? 4) Bandwidth Waste From ATM Encapsulation A POS circuit would use the long distance bandwidth more efficiently. -- Aleksi Suhonen Network Development Saunalahden Serveri Oy AXU-RIPE Please keep me in the Cc:-field as I'm not subscribed to the list.

2 1

Re: Flash crowds and network management
by Leo Bicknell 14 Sep '98

14 Sep '98

In article <6thaou$rhd(a)gizmo.dimension.net> you write: >I'd like to chat someday with the webserver managers at some of >the large media web farms someday, not necessarily with a reporter >listening in, about what they were seeing. But at the moment there >isn't a real good way for us to communicate in real-time about what >is going on. Well, it's not quite talking to them, but CNN's web site does have an interested tidbit in it. See http://cnn.com/TECH/computing/9809/11/internet.congestion/index.html for the whole story, here's the interesting paragraph: At CNN's Web site, CNN Interactive, the number of hits peaked at an estimated 340,000 per minute, eclipsing all previous traffic volumes. To ease the crush, CNN.com stripped out pictures and graphics to present a text-only version. That's 5600 hits a second, for those who don't want to fire up bc. Not bad. -- Leo Bicknell - bicknell(a)dimension.net Network Engineer (CCIE #3440) - Dimension Enterprises 1-703-709-7500, fax, 1-703-709-7699

4 3

Re: Using NAT for best-exit routing
by Paul Vixie 14 Sep '98

14 Sep '98

> I work for a Finnish ISP and from my perspective all you American > providers are "one huge Exodus." We battle with the issue by providing > customers with an efficient web cache system. So basically what I'm > saying is that GTEI could go a long way in solving the problem of > asymmetric peering traffic due to web farm providers with an efficient > web cache system for their customers. > > On my continent this is almost an unwritten responsibility of an ISP. I don't know where it will end, but at the moment 55% of the web traffic I see from my transparent cache customer log files is dynamic. That means 55% of the bytes flowing through port 80 at various chokepoints is marked uncacheable by the origins. My product finesses this up to and a little bit beyond what the HTTP spec allows, trying to distinguish between stuff that's marked uncacheable for advertising hit-rate reasons but is in fact quite static, compared to stuff that really is dynamically (usually CGI) generated and really isn't cacheable. Inktomi breaks even more rules than we do but their hit rate is still pretty marginal. The web pretty much just does not cache well, primarily because the people who generate content aren't the ones who get hurt by its uncacheability. During the time between October 1996 and now (September 1998), I've watched the percentage-uncacheable mark rise from 20% to 55%. It could stabilize at 55%. I don't think it will go down though. More likely it will rise a little further, since there are so many web site construction kits on the market that don't care one whit for cacheability (or the HTTP standard, but that's another story.) If you're still thinking of web objects as files, go spend some time with some marketing people and learn about "web-enabled applications" which is not about files at all. (You'd also learn the reason why I'm not expecting to sell very many more of my transparent web caches.) So, I'm all for having ISP's run caches and either offer transparent interception or some other automatic browser/cache relationship builder. But until we get a reasonable mechanism for _generating_ the content in multiple places we're going to have to provision the paths and servers and peering points with the brute force needed to move data from single sources to an outrageous and growing number of destinations. I'd say (returning to the topic of the message I'm replying to) that GTE/I and other carriers will have to argue about peering and assymetry for another six months at least before the right content distributions start to emerge. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

2 1

NY times appears to have had a rough morning..
by Richard Irving 14 Sep '98

14 Sep '98

Hrmm.. This sunday am I logged into www.nytimes.com, and got an unusual front page. Someone may want to take a look...... Richard :(

5 4

nytimes?
by Andy Walden 14 Sep '98

14 Sep '98

I can't get to it, what did you see? Sincerely, Andy Walden System Administrator MTCO Communications 1-800-859-6826

2 1

RE: Starr report - as seen from MAE East
by Martin, Christian 14 Sep '98

14 Sep '98

We haven't passed this much web traffic since the OJ trial... -----Original Message----- From: Dave Siegel [mailto:dave@siegelie.com] Sent: Saturday, September 12, 1998 11:13 AM To: scott(a)digisle.net Cc: feldman(a)mfst.com; nanog(a)merit.edu Subject: Re: Starr report - as seen from MAE East > Maybe folks are not as interested as the press thinks. > > On Fri, 11 Sep 1998, Steve Feldman wrote: > > > There was no sigificant change in traffic at MAE West. Two of our customers had the report. The increase in egress traffic was quite noticable. Based on the bw reports from yesterday, folks were *very* interested. Dave -- Sr. Network Engineer Network Architecture Frontier GlobalCenter

1 0

Re: The Cidr Report
by John M. Brown 14 Sep '98

14 Sep '98

Why should they, there is no reason for them to. Personally I wonder what would happen if we (the rest of us) started filtering on /19's or /20's :) But then you take UUNET (Alternet) and for example 207.170.32.0 /19 is advertised as a /19 AND a stack of /24's all with the same AS path and from what I can tell no special routes, at least not via nitrous.digex.net But what do I know, I am a lonely little guy... :) At 01:19 PM 9/11/98 -0700, Tim Wolfe wrote: >Anyone care to comment on the fact that the top non-compliant companies never really seem >to make any significant changes? > >> --- 11Sep98 --- >> ASnum NetsNow NetsCIDR NetGain % Gain Description >> >> AS701 1185 956 229 19.3% Alternet >> AS271 349 152 197 56.4% BCnet Backbone >> AS4293 445 258 187 42.0% IMCI >> AS174 789 611 178 22.6% Performance Systems International >> AS3749 225 68 157 69.8% TECNET >> AS2493 373 217 156 41.8% iSTAR Internet, Inc. >> AS4200 192 100 92 47.9% AGIS (Apex Global Information Ser >> AS5668 128 41 87 68.0% Century Telephone Inc. >> AS2685 229 151 78 34.1% IBM Global Network - US >> AS4755 125 49 76 60.8% Videsh Sanchar Nigam Ltd. India >> AS3221 117 44 73 62.4% EENet Autonomous System >> AS4740 404 336 68 16.8% Ozemail Pty Ltd (ASN-OZEMAIL) >> AS3493 251 183 68 27.1% INTERLINK >> AS7046 239 172 67 28.0% UUNET-CUSTOMER >> AS3804 215 157 58 27.0% Bell Solutions >> AS10928 101 46 55 54.5% UNKNOWN >> AS549 204 151 53 26.0% ONet Backbone >> AS8517 123 71 52 42.3% ULAKNET-ASN >> AS6335 69 20 49 71.0% NTRNET >> AS72 87 39 48 55.2% Schlumberger Information Network >> AS1239 548 501 47 8.6% SprintLink Backbone >> AS803 78 34 44 56.4% SaskNet Backbone >> AS6181 66 26 40 60.6% FUSE-NET >> AS4539 67 27 40 59.7% NETROPOLIS >> AS852 159 120 39 24.5% AGT Advance Communication >> AS3403 159 120 39 24.5% TIAC >> AS7122 118 80 38 32.2% MTS ADVANCED Network Policy >> AS10459 45 10 35 77.8% WANSASN >> AS2707 64 31 33 51.6% WEC >> AS6332 89 58 31 34.8% TELNOR > >--------------------------------------------------- > Tim Wolfe, Network Administrator > ClipperNet Internet Access Services >tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax > ...Across the Desktop and around the World... >--------------------------------------------------- >

3 3

Re: Routing, Forwarding, and the Legacy Internet
by Jim Fleming 13 Sep '98

13 Sep '98

-----Original Message----- From: Chrisy Luke <chrisy(a)flix.net> <snip> > >Even in your simplistic view, you would have to transfer 16meg of data Please note, I did not suggest that people implement the simplistic view. I suggested that people focus on routing and not forwarding. Also, if one did implement a brut-force approach 16meg would not be transferred. You could transfer exactly what you transfer now and the table would be built inside the device where the 16 meg is stored. For example, if information was obtained that all traffic for a /8 needed to be sent via a certain interface then 65,636 entries in the brut-force table would be filled in with that small amount of information from an external device. Keep in mind the premise was that we would look at the entire address space as /24s and have an entry for each. That does not mean that the forwarding device needs to be told about each of the /24s. It can be told about large groups of them. That does not require 16meg of data to be transferred. Again, this discussion started with someone claiming that /24s could be added to the routing tables. My point was that current technology does not encourage this and the Internet governance of the industry has been developed to support what the hardware vendors have to sell. In other words, we can not start with a clean sheet and ignore the way current devices work (or do not work). My other point is that I do not think that vendors will worry that much about fixing the forwarding technology because "routing" is going to become very key to the hardware vendor's survival. I do not think that many Internet operators have begun to address what is going to happen when they have to deal with the world of routing vs. forwarding. Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+@---<IPv8>---C+@---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm

1 0