- Test - lists.nanog.org

Mae Requirements
by Nathy Thongphok 13 Aug '98

13 Aug '98

I am trying to find out what is the requirements and procedures to present at the MAE nap. At Mae-West for example. Thanks, Nathy

1 0

FWD: Web backbone provider Priori mulls bankruptcy
by Eric Germann 13 Aug '98

13 Aug '98

>From Ziff-Davis newswire. Another one bites the dust? Comments? > > --------------------------------------------------------------------- > > This article is from ZDNN (http://www.zdnet.com/zdnn/) > Visit this page on the Web at: > http://www.zdnet.com/zdnn/stories/zdnn_smgraph_display/0,3441,2127660,00.ht… > > --------------------------------------------------------------------- > > By Ben Elgin, > Sm@rt Reseller > August 12, 1998 5:47 PM PT > [IMAGE] > > Less than one year after Priori Networks Inc. opened its doors for > business, the national Internet backbone provider is on the brink of > bankruptcy, Sm@rt Reseller has learned. > > All the company's employees have been laid off and the network > operation center is no longer functional, according to a source at > Priori. Temporary transit arrangements have been made for Priori > customers in the Portland, Ore., Chicago, Washington DC, and Palo > Alto, Calif. areas, but other customers may be left to fend for > themselves, the source added. > > Priori president and CEO Robert Shearing says severe financial > shortfalls will force Priori to file for Chapter Seven bankruptcy > within several days unless an acquisition offer is made. Under the > rules of Chapter Seven, the company will be forced to liquidate its > assets to pay off creditors. > > "It's not looking good -- we will have a final decision in the next > couple of days," concedes Shearing. > > The company, which launched last October, specialized in selling > backbone access to Internet service providers, usually at a lower cost > than its telecommunications competitors. > > High hopes dashed > With points of presence in Atlanta; Boston; Chicago; Dallas; Denver; > Los Angeles; Palo Alto, Calif.; Portland, Ore.; Seattle and > Washington, D.C., Priori executives once had high hopes for success in > the ISP backbone vertical market. > > But, with a new breed of well-funded backbone providers entering the > market, many industry observers believe Priori was a dollar short and > a year too late. > > "They came in when the window of opportunity was closing and they made > several key mistakes. Perhaps the biggest error was focusing too > heavily on engineering while ignoring the sales side," says ISP > consultant Michael Dillon, who worked for Priori Networks for six > months. > > --------------------------------------------------------------------- > > Copyright (c) 1998 ZDNet. All rights reserved. Reproduction in whole > or in part in any form or medium without express written permission of > ZDNet is prohibited. ZDNet and the ZDNet logo are trademarks of > Ziff-Davis Inc. > ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert, OH 45891 http://www.cctec.com Ph: 419 968 2640 Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

5 5

Presentations from the last NANOG
by Ron Muir 13 Aug '98

13 Aug '98

When will the presentations from the Dearborn NANOG be available on the NANOG home page. Thanks, Ron ______________________ Ron Muir IP Administration BellSouth.net ron.muir(a)bellsouth.net (770)522-6363

1 0

Re: BBN Peering issues
by Adam Rothschild 13 Aug '98

13 Aug '98

> They don't? > > Please check your facts first before making public assertions. Thanks. I checked before doing so, and I checked once again in light of your allegation. And, according to Exodus, this *IS* a PX. Please check your facts, kind sir. > 15 sl-gw3-sj-4-0-0-155M.sprintlink.net (144.232.3.50) 73.105 ms 72.920 ms 74.355 ms > 16 sl-exodus-5-0-T3.sprintlink.net (144.228.44.6) 81.004 ms 72.528 ms 80.386 ms > 17 scca-01-f8-0-0.core.exodus.net (209.1.169.21) 82.080 ms 72.649 ms 72.440 ms > > BBN will be getting to exodus' web sites just fine via Sprint. > > -dorian >

3 2

Peering with a big web farm (was Re: BBN Peering Issues)
by Sean M. Doran 13 Aug '98

13 Aug '98

Forgive me, but this raises an interesting engineering and traffic-management issue. Alex Rubenstein, turning John Curran's words around, suggested: | "The central problem is asymmetry of traffic between GTEI and the hosting | companies, Curran said. BBN/GTEI customers generally request webpages from | Exodus more than from other places." which is an interesting point IN FAVOUR OF peering with a large web hosting network at only one location. If one can force all outgoing to-the-webhosted-site queries through a single web cache, and the content is (or is made to be) relatively undynamic, one has a huge caching potential. With hot-potato routing towards a multiply-connected network, the egress funnel which allows one to intercept all queries disappears. The "firehose" of replies back is mitigated not by a large cache on the "large-audience" side of the peering, but by clever distributed caching combined with redirecting browsers from the "egress funnel intercpetor" to caches which are closer to them. Ideally one would only ever need one transfer per new piece of content to satisfy one's entire customer base. Moreover, depending on how static one required the content to be (or conversely, how dynamic one allowed it to be), the actual peering connection might even be intermittent. How one would contract for this sort of peering, of course, is a matter for com-priv, not for NANOG. Sean.

5 4

CISCO ADMINISTRATORS: Operational - URGENT
by kbrown＠teamhuber.com 13 Aug '98

13 Aug '98

Cisco will be releasing a field notice of an IOS vulnerability to *most* IOS images. Attackers need not be able to actually login to the device to cause it to reboot/crash. Details of the notice are available @ http://www.cisco.com/warp/public/770/ioslogin-pub.shtml Information contained is provided for your use only...I claim no repsonsibility for the content, just thought I would give Nanog a good heads-up. Contributions for the Kevin CCIE fund accepted graciously :=) Kevin Brown - Network Engineer Huber & Associates, Inc. - Networking Technologies kbrown(a)teamhuber.com www.teamhuber.com 573.634.5000

2 1

FW: BBN Peering issues
by Lawrence A. Deleski 13 Aug '98

13 Aug '98

Sorry to have to state the obvious, but it seems to me that if BBN wishes to terminate peering with Exodus then let them; perhaps their customers will follow suit by terminating their agreements with BBN. It seems like the only logical thing that could happen. BBN is almost certainly doing their customers a huge disservice by terminating peering with the largest web hosting facility in the business. I have to assume that BBN users *like* using HotBot and GeoCities, just two of the many major players hosted at Exodus. The Internet has always been about sharing, in this case, the free exchange of traffic and routes by peers. If BBN wants to screw with that then I hope they're willing to live with the consequences. BTW, it was mentioned somewhere else in this thread that someone thought that Exodus buys transit. They don't, I know, I used to work there. Rob would never do that... :) Henry R. Linneweh said: > ...toasted ISP's and carriers destroyed by blind people's greed and > inability to manage a global network... > Failure of management is the crux to this issue and maintaining what has worked > for over 20 years. That to states there are some people in serious need of sacking in some > boardrooms..... You said a mouthful there, Henry. My thoughts exactly... --- Lawrence A. Deleski lad(a)inficad.com "Give a man a fish and he'll eat for a day. Teach a man how to fish and he'll sit in his boat and drink beer all day". ---------- >From: "Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> >To: nanog(a)merit.edu >Subject: Re: BBN Peering issues >Date: Thu, Aug 13, 1998, 9:41 PM > >On Wed, Aug 12, 1998 at 09:39:46AM -0400, Adam Rothschild wrote: >> > If anyone would like to communicate privately about the BBN Peering issues, >> > please drop me an email, or call. >> >> I would like to communicate openly and publicly about this. >> >> What I would like more than anything right now is some official word from >> high-up's at BBN regarding what this policy entails exactly, and what >> their rationale is behind it. >> >> That is, a public explanation other than the all-too-obvious "We're >> greedy. Welcome to the business world. We're not going to change our >> minds, so shut the fuck up and buy some transit, you dumb suckers." > >Based on just that little slice of the conversation, is BBN doing what >UUnet apparently failed in _it's_ attempt to do last fall, to Jack >Rickard's (and my) vast amusement? > >Cheers, >-- jra >-- >Jay R. Ashworth jra(a)baylink.com >Member of the Technical Staff Unsolicited Commercial Emailers Sued >The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, >Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 > >Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com >

1 0

Do you know tools that can analyze data files of cflowd??
by HongJin Choi 13 Aug '98

13 Aug '98

Hi all!! I would like to analyze traffic flows. Then I set up cflowd-1-3b2 package on my W/S. It Works very well. But, I want to the automatic analyzing data files periodily. Do you know tools or scripts for cflowd?? Thanks in advance!!

1 0

Re: Peering with a big web farm (was Re: BBN Peering Issues)
by Sean M. Doran 13 Aug '98

13 Aug '98

| If BBN wants to sell connectivity to a big web farm provider, how does | BBN's forcing all hits through a cache help BBN? The data all still | crosses BBN's backbone, and the the web farm provider won't need as big a | pipe. Maybe I'm missing something, but if BBN starts charging former | peers, I'd think caching at these edges would be a bad thing for BBN. Again, keeping this in the realm strictly of "how to build this", rather than "is this a good idea, is this moral bla bla bla", what one wants is a hierarchy of caches with the one cache you're thinking of at the apex, and the others scattered throughout the backbone. Alternatively, one might have a few duplicate caches, with content distributed by, for example, reliable multicast, or some other technique with the explicit goal of sending no more than one copy of the content per link. The thing that you are forcing traffic through is, indeed, an intercepting device, which lives directly in front of the peering line. It could do one of a number of strategies, for example, accepting the first hit and redirecting all subsequent transfers to one of it's hierarchical children or distributed copies. It could also intercept and rewrite all the DNS queries that happened to arrive at it bound for the peer in question, and answer back giving the addresses of the appropriate more-local child/copy caches, avoiding taking the first TCP connection in the first place. A neat project would be to think about the application layer "non-"gateways one would want beyond WWW. FTP comes to mind, of course, as does NNTP. Real Video etc. are of course other likely targets. Basically, I suppose the thought is that one could soundly engineer and operate a peering with a "content-hosting ISP" (big web farm/ ftp archive) which reduces the bandwidth requirement to one copy per new piece of static content, plus whatever level of properly dynamic content there might be, at the cost of some disk space per peering (the interceptor border device and the distributed child/copy caches can be shared among multiple peering connections). Again, issues of morality, how one could do a contract to do this, and the like are more appropriate to com-priv. Anyone who has actually experimented with things vaguely like this (Ed? Curtis?) and who has operational advice is on-topic for NANOG, however. Sean.

1 0

Network Value
by Leo Bicknell 13 Aug '98

13 Aug '98

The BGP peering issues that have recently come up really come directly from a disagreement about what constitutes network value. I think by now we all realize that peering is a sort of quid pro quo, where both parties get some value from the deal. Traditionally, this was an easy thing to assess. Large backbone providers tend to have a a nice mix of dial-up users, content providers, and everything in between. Measuring the "value" they bring to the table could easily be qualified by a traffic study. In the brave new world this isn't the case. One can easily argue that a dial-up only provider and a content hoster should peer. Each brings value to the relationship, but the traffic distribution will be highly asymmetrical. In this situation what metrics do you use to assess the value of the peering arrangement? Is there a good metric like number of users, or number of flows that you can use to measure value? Does value have to be something that only a human can determine with lots of subjective measures? Has anyone tried to qualify the value of a network for such purposes? I'd be interested to know the details about that process. If you are able to find a value, can you then move to a "price / performance" ratio by determining the cost of the peering session? I suspect this is more difficult to determine than the wealth of the network, at least over shared peering points where the direct cost for a single peer is not a line item. Possibly the most difficult question of all, is there any value to everyone using the same metrics? Ignore the problems with creating a suitable metric, but if one existed that ranked all providers from say, 1-10, do you think it would have a positive or negative effect on peering arrangements? I welcome public and private discussion, but hope to avoid any current issues (for fear of a flame war). :-) -- Leo Bicknell - bicknell(a)dimension.net Network Engineer (CCIE #3440) - Dimension Enterprises 1-703-709-7500, fax, 1-703-709-7699

3 2