- Test - lists.nanog.org

RE: UUNET stops peering at MAE-West
by Jim Browning 25 Mar '96

25 Mar '96

Why haven't more networks taken advantage of the PacBell NAP facility in San Francisco?? -- Jim Browning ---------- From: Roy[SMTP:garlic@garlic.com] According to the night shift at UUNET's NOC, they have stopped peering at MAE-West. <snip> The fellow I spoke with said this will remain until the GigaSwitch is installed at MAE West scheduled for this week. <snip>

3 2

Re: MCI [ATM overhead]
by avg＠postman.ncube.com 25 Mar '96

25 Mar '96

This is betting on ATM prices being low for a long time -- long enough for investments to ATM equipment to pay off. >From the point of view of ISPs which get lines at cost this is a no-brainer choice. --vadim >From salo(a)msc.edu Mon Mar 25 14:49 PST 1996 Return-Path: <salo(a)msc.edu> Received: from postman.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA28341; Mon, 25 Mar 1996 14:49:36 +0800 Received: from noc.msc.edu by postman.ncube.com (4.1/SMI-4.1) id AA08921; Mon, 25 Mar 96 14:50:57 PST Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA12387; Mon, 25 Mar 96 16:50:22 -0600 Received: (salo@localhost) by uh.msc.edu (8.7.1/8.6.6) id QAA04516; Mon, 25 Mar 1996 16:50:29 -0600 (CST) From: salo(a)msc.edu (Tim Salo) Date: Mon, 25 Mar 1996 16:50:29 -0600 (CST) Message-Id: <199603252250.QAA04516(a)uh.msc.edu> To: avg(a)postman.ncube.com Subject: Re: MCI [ATM overhead] Cc: nanog(a)merit.edu Content-Type: text Content-Length: 667 Status: R > Date: Thu, 21 Mar 1996 15:09:51 +0800 > From: avg(a)postman.ncube.com (Vadim Antonov) > To: jogden(a)merit.edu, nanog(a)merit.edu > Subject: Re: MCI [ATM overhead] > [...] > The pricing on ATM transport is merely an artefact of "pilot" > status of ATM networks. Carriers lose money on that. When > market will be established the prices are bound to rise to > that of native IP transport, or, likely, more (as ATM does not handle > levels of overcommitment found in IP backbones now). > [...] Hmmm... Does that imply that the NSP that can take advantage of underpriced services, (perhaps including ATM, if you are correct), will have a competitive advantage? -tjs

1 0

Pac Bell NAP [Was: RE: UUNET stops peering at MAE-West]
by Paul Ferguson 25 Mar '96

25 Mar '96

At 10:35 PM 3/23/96 -0800, Jim Browning wrote: >Why haven't more networks taken advantage of the PacBell NAP facility in San Francisco?? >-- >Jim Browning > ATM? :-) - paul

2 1

ATM overhead [WAS: Re: UUNET stops peering at MAE-West]
by Paul Ferguson 24 Mar '96

24 Mar '96

Kent, Have you done any statistical gathering on the overhead required to route IP traffic in the Pac Bell ATM NAP? I'd be interested in seeing this, for certain. :-) - paul At 05:50 PM 3/24/96 -0800, Kent W. England wrote: > >Give it a try. Pacific Bell has upgraded the Bay Area NAP to Stratacom BPX >ATM switches and the new PacBell LA NAP will also be a BPX switch. These >switches have sufficient buffer size to manage OC-3 connections. > >Check out our NAP stats page http://www.PacBell.COM/Products/NAP/Stats/ to >see how much aggregate traffic is already flowing through the Bay Area NAP. >Still some headroom left and no cell loss! > >--Kent >

1 0

Re: UUNET stops peering at MAE-West
by Kent W. England 24 Mar '96

24 Mar '96

At 12:07 AM 3/24/96 -0800, Mark Kent wrote: >>> Why haven't more networks taken advantage of the PacBell NAP facility >>> in San Francisco?? > >I should note that I don't see any issues going over the SF NAP from >my neck of the woods. > >-mark > Give it a try. Pacific Bell has upgraded the Bay Area NAP to Stratacom BPX ATM switches and the new PacBell LA NAP will also be a BPX switch. These switches have sufficient buffer size to manage OC-3 connections. Check out our NAP stats page http://www.PacBell.COM/Products/NAP/Stats/ to see how much aggregate traffic is already flowing through the Bay Area NAP. Still some headroom left and no cell loss! --Kent

1 0

UUNET stops peering at MAE-West
by Roy 24 Mar '96

24 Mar '96

According to the night shift at UUNET's NOC, they have stopped peering at MAE-West. Traceroutes show that they are using MAE-West for outbound trafiic but it doesn't look like they are advertising any routes there since I couldn't find anyone going to UUNET via MAE-West. The fellow I spoke with said this will remain until the GigaSwitch is installed at MAE West scheduled for this week. I have not seen an announcement to their customers of this policy change. On one particular route I use, I am now seeing 10% packet loss up from the previous 1-2%. The route has become unusable for telnet.

2 1

Blargh, Foo, Sabotage, and an RS/6000
by Alan B. Clegg 23 Mar '96

23 Mar '96

Sorry to change the current topic of interest & digress into a plea for help, BUT.... I'm looking for a little time (probably less than 12 hours total on-line) on an RS/6000 (AIX). I'm willing to talk $$$, but don't need a long-term (ie: month) contract. Anyone have a box somewhere that I can get an account on? I need about 40Meg disk space and access to the "standard" C compiler. I might even be interested in buying one of these things if anyone has one for sale (relatively cheap & in working order). [BTW, the project that I need the account for has nothing to do with Foo, Blargh, OR Sabotage] Happily Consulting for NOs across NA, -abc \ Alan B. Clegg Just because I can \ Network Technologist does not mean I will. \ gateway.com, inc. \ <http://www.gateway.com/>

1 0

Re: packet loss (was re: mae-west congestion)
by nicholas harteau 23 Mar '96

23 Mar '96

Peter Kaminski wrote: > > Matthew Kaufman writes about the Ames FDDI ring saturation: > > >What I don't understand is why that has _stayed_ saturated... it seems > >to me that some of the big players would have rerouted their traffic > >by now to avoid subjecting it to this, which would also have the side > >effect of causing the problem to, at least for the short term, go > >away. > > ...or why MFS hasn't installed a Gigaswitch there, or whatever. We're > seeing 20% - 30% packet loss through AGIS to MCI and Sprintlink during > the day, and it's not fun. Speaking of fddi rings, saturation, and packet loss.. has anyone taken a look at the peering between mcinet and cicnet at the chicago nap? i get about the same (20-30%) packet loss during the day. and no, it's not fun at all. -- panic(a)cyborganic.com

2 1

Re: Blargh sabotages Foo...
by Joe Provo 22 Mar '96

22 Mar '96

This drama has reminded me of something I had been meaning to ask "the community" for a while now. If InterNetBlargh has customer FooCo and breaks things badly, it is fairly obvious that they both should have their respective suits and legals hash things out over existing contracts. But if InterNetBlargh mangles one/more routes [by virtue of, say, a shorter AS path] for *non-customer* BazNet, without regard for WHOIS/RA data, currently-visible announcements, registered servers, etc., what sort of recourse is considered a Good Thing? Let's face it, typos happen, even at major transit providers, but that means squat when your /16 goes *poof*. Airing it as a made-for-mailinglist miniseries is just a waste of everyone's time. What sort of action would any propose to BazNet? Send email and I'll summarize. Cheers, Joe Provo Network Operations Center UltraNet Communications, Inc.

1 0

Re: MCI [ATM overhead]
by Paul Ferguson 22 Mar '96

22 Mar '96

At 08:38 AM 3/20/96 -0800, Wolfgang Henke wrote: > >Thank you for the reference. I will certainly check it out. Here is a >little table which I hope will help ISPs planning to upgrade bandwidth: > > >SONET (Synchronous Optical Network) speeds given in Mbps > > nominal w/o Sonet ATM TCP/IP > overhead > >OC-3 STS-3c 155.520 149 122 137 future net backbone > >OC-12 STS-12c 622.080 599 488 549 > >OC-48 STS-48c 2488.32 2396 1953 2197 current telco backbone > >OC-192 STS-192c 9953.28 9585 7813 8788 > >on single mode fiber >or multi mode fiber >or CATV 75 ohm coax (the lower speeds) > And here's one that [fills in the gaps] shows the relationship between STS and SDH: SONET/SDH Heirarchies SONET Bit Rate SDH STS-1/OC-1 51.84 Mb - STS-3/OC-3 155.52 Mb STM-1 STS-12/OC-12 622.08 Mb STM-4 STS-24/OC-24 1244.15 Mb - STS-48/OC-48 2488.32 Mb STM-16 STS-192/OC-192 9953.28 Mb STM-64 - paul

2 1