- Test - lists.nanog.org

Re: Sprint Peering Requirements? WAS More network problems
by Donna McCole 01 Apr '96

01 Apr '96

Ackk, I have embarrased myself! The excellent first hand account of the incident at the wiltel pop was by Matt Petach. I enjoyed it so much that i forwarded it and, shame on me, overlooked the cc to the list. My apologies to all. All Credit to Matt. donna At 09:30 AM 03/31/96 -0500, you wrote: > >Donna, > >Your description of the events surrounding the 'much discussed' >outage was excellent. >

1 0

Re: Sprint Peering Requirements? WAS More network problems (fwd)
by Donna McCole 31 Mar '96

31 Mar '96

Recently, Paul Vixie wrote... > > > P.S. what is the deal with the Santa Clara POP anyway? I've seen gas > > main explosions, circuits cut by a blowtorch (gee? maybe they're related), > > "missing" fiber, "lost" circuits, and other shenangans. > > The story may be growing with the telling, but I was told that a gas main > ruptured, with or without a small explosion (depends on who you ask), and > the fire marshall came in, smelled natural fumes all over, and ordered that > power be cut to the surrounding buildings, presumably to prevent explosions > due to sparks and such. WilTel ultimately brought in a portable generator > and put this wonderful new spark generator out in the parking lot, closer > to the natural gas fumes than anything inside the building would have been. *sigh* I'd kinda hoped the issue would die down, but since it won't, I guess I'll actually speak up. I was driving to work, running a bit late at around 11:10 am, and turned west on Walsh Avenue from San Tomas. I pulled into the left turn lane leading into the business park, and noticed the driveway was blocked with orange cones and a backhoe digging. A woman in a dark, Pennsylvania green lincoln towncar pulled up into the left turn lane behind me. When the left turn arrow turned green, I made a u-turn on Walsh, and entered the business park via a secondary driveway closer to San Tomas. I glanced in my rear-view mirror, and saw that the woman in the green car was stopped midway through the intersection, blocking oncoming traffic, waiting for the construction crew to move the cones to let her into the parking lot via that driveway; I guess she figured the earth rotated around her, so why shouldn't everyone else change to fit? So, as I pulled into the parking lot in front of work, I looked over at the entrance, and saw that the construction workers were attempting to be nice, and were moving the cones out of the way, and trying to back up the backhoe so she could go past, and stop blocking the traffic that was now getting very irate. :-) As the worker in the backhoe was pulling the bucket out of the hole, he must have hit the main, because there was a very loud "kawoosh" and a blast of white condesation headed skyward. The construction crew started running away from the hole, and I headed into work to alert my coworkers to the problem. One of my coworkers called PG&E while a second one called 911. PG&E immediately said they were dispatching a crew to the site, and also told us to begin shutting down any exterior equipment that was likely to cause sparks. By this time, the smell of natural gas was nearly overpowering outside, and was becoming more so indoors. We began shutting down all the air conditioners on the roof, and began prepping the site for evacuation. Within about 15 minutes, the fire dept. had arrived, as had PG&E, and began roping off the area, and had us evacuate the building. We used cellular phones to call back in, and changed the outgoing messages for the NOC and tech support ACD queues to alert customers that we had been evacuated, and could not currently come to the phones. :-) PG&E began working on isolating the section of pipe, but within 15 minutes of their arrival, a spark triggered a fireball that roasted the dump truck, the backhoe, the tree nearby, the signs, and pretty much everything else in the vicinity. The one good offshoot of the fireball was that the pipe was actually burning now, and sending flames ~75 feet in a nice vertical column; the fire dept. immediately pulled hoses into place, to keep the fire contained to the single jet, and the nice folks next door at Wiltel rolled out their 75kVa generator out the BACK of the building, which was approx 150 yards from the actual gas leak, and fired it up, since there wasn't much danger of an explosion now that there was a constant flame source burning off the gas as it emerged. Since we couldn't get to our cars, we walked to lunch, and answered pages from various customers who noticed that network connectivity was spotty or nonexistent to large areas, and explained the situation. We got back to work by about 2:30pm, the fire was still going, but PG&E was working on clamping off the pipe physically a few dozen yards upstream; once the pipe was crushed, and the fire out, it only took about an hour to get clearance from the incident commander to air out the building, get santa clara electric to restore power, reset the PDU, reset the UPS's, and by 3:30 full network connectivity through our network was restored. Hopefully this clarifies the situation from a firsthand witness, and keeps people from blaming Wiltel for sparks or any other such nonsense. > > This time I'm > > glad we followed WorldCom's (WilTel, whatevertheirnameisthisweek) site > > recommendation and used DC power for our equipment. But this POP is > > like working out of a telecommunications war zone. > > That's one of several good reasons why CIX has installed a router up in > Digital's Palo Alto facility (I'd call it a NAP, since it has rack space > for rent and GIGAswitches all over the place, but "NAP" seems to indicate > congressional funding so I'll choose another word... "Interconnect/CoLo" > (ICL)). In addition to having both AC and DC on UPS and a generator, Palo > Alto has actual coffee houses for those late night adventures. > Matt Petach

2 1

Re: SONET Interconnect (was RE: MCI)
by Sean Doran 30 Mar '96

30 Mar '96

| Ok, NDA aside then, too. Assume you had to decide now. You go multi | DS3 and wait for new options because you do not need more than 2xDS3 | = OC3c + ATM? Would you go 3xDS3 and load share? Yes to the latter. When we were thinking about scale some time ago, Vadim sketched out a very reasonable proposal for a stacking network topology to build a 3xDS3 network immediately or incrementally. Router technology has changed to the degree that we could now do this fairly cheaply in comparison to any solution which offered comparable bandwidth in a unified form; the key additional costs would involve space for CSU/DSUs, and the extra slots to make up for the poor port density HIP cards give you. This compares favourably with the space requirements of ATM switching equipment, especially when factoring in other cost items such as configuration and maintenance. If building a network with a relatively small set of POPs and circuits that follow fibre paths, the trade off thus would be less space/power/heat/capital costs and more complexity and the ability to do sustained traffic flows at more than DS3. Packet forwarding technology changes in the 75xx architecture appear to have ameliorated the latter too. In networks with very different topologies, YMMV. I suppose the proper quip would be, "gee, wouldn't you have better luck talking with your vendor rather than your competitor?" (or even gee, ATM is neat, go for it!), but I'm in a helpful mood for some reason today. Sean.

2 1

Re: SONET Interconnect (was RE: MCI)
by Sean Doran 30 Mar '96

30 Mar '96

| Ok, I will bite. Let's assume for a moment that dual DS3 is not | acceptible and I want IMUXed DS3s or a real optical interface. What do | you recommend for a Cisco? I would recommend talking to your sales representative about getting an NDA presentation. | ATM has the annoying advantage of having alot of people building for it. Gee, there are lots of OSI vendors too. Go for it. You can leverage the fun stuff done by CDNNET. :-) Sean.

2 1

Re: SONET Interconnect (was RE: MCI)
by Paul Ferguson 30 Mar '96

30 Mar '96

At 12:36 AM 3/29/96 -0500, Shikhar Bajaj wrote: > >Several of our clients seriously consider >ATM/SONET the best way to go because they feel that a switched >technology like ATM is the best single technology (currently) >to offer them high speed and support for multiple applications (like >video and voice, as well as data). They are not just sending around >200-byte IP packets. Furthermore, the ability to get >quality of service support and guarantees is important them. They don't >think that RSVP, when it comes, will be enough. Finally, >to them, the economics makes sense. They understand the limitations >(i.e. overheads) and believe that they are acceptable. > What you fail to mention, however, is that in an effort to achieve these noble goals across the Internet, you are relegated to using IP over ATM. This is the fatal flaw. Sorry. I remain unconvinced. Unless you begin building massive [native] long-haul ATM networks, this is not an acceptable transport for the reasons I mentioned earlier. - paul

6 5

Re: SONET Interconnect (was RE: MCI)
by Sean Doran 30 Mar '96

30 Mar '96

| Doesn't the fact that they recover the investment mean that enough | people wanted the product and were willing to pay for it? Well, I dunno, it could also mean that an organization with enormously successful marketing skills was able to make hay out of an alternative that makes heedless yompers pay excessively for often really unsuitable machinery. No? Sean. (looking for better suggestions for a 'y' word)

2 1

Re: SONET Interconnect (was RE: MCI)
by avg＠postman.ncube.com 30 Mar '96

30 Mar '96

> NO. Name the single application which couldn't be run over > lossy protocol. Thats an easy one.... >Any generic system that receives time sensitive real-time information from >numerous distributed nodes that must be processsed and relayed to >other processing stations *and* run the typical IP e-mail, ftp, httpd, >etc. packet services concurrently over the same pipes, as well as >network management traffic ad. infinitum..... Real application, not theory, please? I've had some real experience with telemetry networks (did some harware design for my dad's Constructor Bureau For Tele-Mechanics And Automated Systems) and can say for sure that anybody who needs lossless telemetry with millisecond delay tolerance must be insane to do it over any public networks. 99.99% of real-life telemetry can live with losses just fine. In fact, telemetry stuff often designed to receive several measurements and do sanity check on them before anything actually happens. Practically all real-life sensors are prone to fluctuations (splashes for liquid level sensors, falling leaves for light brigtness sensors, ad infinitum). >Running real time sensory data, for example that must arrive at remote >locations within a few milliseconds on a packet switched network, >for example.... Real application, please? I never seen one, not in large controlling systems, not in military crap, not in scientific experiments (i've got more than few friends who did lots of data collection & networking stuff for high-energy physics research; in fact, my old e-mail address at Kurchatov Institute for Atomic Energy is still valid :) It is always either delay-tolerant in range of seconds, or it is "collect data now, analyze later" or it is dedicated lines because you can't afford delays in switches. >I'll attach a few references for those who don't wish nor >have the time to pull down the 12 page postscript draft mentioned >earlier... It seems to me that a lot of people are very busy solving a non-existant problem. Anything new? --vadim

2 1

Re: SONET Interconnect (was RE: MCI)
by avg＠postman.ncube.com 29 Mar '96

29 Mar '96

Tim Bass wrote: >As pointed out by Zhang et. al. in the late 80's, real-time applications >over a store-and-forward datagram service is very problematic >because IP is a best-effort service and there are no bandwidth/delay >guarantees in the IP paradigm. Real time applications are about as problematic with any transport method in a public network, period. Bandwidth reservation is nothing more than another name for "higher priority". It works fine until your high priority traffic does not overload the network -- with or without resource reservation of any kind. As soon as that point reached (i.e. network is overloaded) resource-reservation starts to deny service; simple per-packet prioritization starts to drop packets "fairly". That's the real difference. >On the other hand, ATM (based on the original ATM charter) was envisioned >to offer a guaranteed QoS. As pointed out by numerous people in >this thread and before, IP/ATM is not efficient; and it is for >this reason and others that many IP protagonists love to bash >ATM, and with good reason from an IP perspective. Worse than that, ATM is unable to fulfill its promise of "guaranteed QoS" in global networks. ATM folks didn't appear to understand that all routing stability problems won't disappear just because somebody shreds packets; in fact, it is easily demonstrable that those problems will be worse than with IP. >There is no current architecture to *guarantee* a close to zero >packet loss in the IP world. Moreover, nobody needs it. Packet loss is a necessary component of distributed congestion control, and works better than previously implemented ECN schemes. (That intuitively makes sense, as packet loss removes packets from congested network, while ECN doesn't). >Do we need a real-time protocol that is highly reliable in the >world? The answer, is of course YES. NO. Name the single application which couldn't be run over lossy protocol. >Finally, as pointed out TCP/IP/ATM is not efficient. On the other >hand, transmitting packets, losing them in the network and >retransmitting them or just dropping packets from the stream >is not the most efficient method of delivery either. Yawn. ATM also loses packets, in a screwy way. It was a way worse since it used to lose _cells_. >I am not necessarily a protagonist for ATM, and my personal >opinion is that ATM is too complex and tries to be all things >to everyone, and that rarely if ever works. No, it is simply a bell-head's idea of a data network. If they no longer can shred things to bits they would shred them to cells. --vadim

2 1

Re: SONET Interconnect (was RE: MCI)
by avg＠postman.ncube.com 29 Mar '96

29 Mar '96

>According to Sean Doran: > Someone suggested to me that it's because so much money has > been spent on developing the technology that it HAS to be > used in order to recover the investment. > >Doesn't the fact that they recover the investment mean that enough >people wanted the product and were willing to pay for it? > >Shikhar Nah, rather that they woudln't get a choice or would not know better. ATM is like a pyramid craze. --vadim PS Can you say that loss writeoff is a way to recover investment? I've certainly seen some clever accounting going on :)

2 1

RE: SONET Interconnect (was RE: MCI)
by Bharat Ranjan 29 Mar '96

29 Mar '96

>A worldwide fabric of IP-over-SONET and IP-over-bent-coathangers and IP-over- >tin-cups-and-string is _going_ to occur, and soon. >A worldwide fabric of end-to-end ATM may or may not occur, depending on the >PR capabilities of the folks who think it's the right way to go. The reality here is that today there is a wide deployment of SONET and it is accelerating. A year ago, ATM was the hottest "new" technology and everyone was rushing to integrate it into their products. Since ATM assumes a high speed, reliable transport network, SONET is the best choice. Thus began a movement by SONET equipment vendors to merge the ATM switch functions with the already available SONET mux. Of course, the growth of the Internet has changed all that and IP has emerged as a end-to-end protocol that is here today with fairly ubiquitous deployment. I suspect you will see the emergence of a IP/SONET mux this year. mm mm sssss nnnnnn * Bharat Ranjan * m m m s nnnnnnn * Network Engineer * m m m sssss nn nn * Microsoft On-Line Services * m m s nn nn * (206)-936-0471 * m m sssss nn nn * bharatr(a)microsoft.com * ******************************************************* * The opinions/ideas in this memo are not necessarily * * those of Microsoft Corp. * ******************************************************* >

1 0