- NANOG - lists.nanog.org

FCC outage filings
by Sean Donelan 07 Oct '98

07 Oct '98

I'm in Washington DC this week, so I decided to go down to the FCC and read the carrier outage reports myself. As I mentioned before, the outage reporting requirements are aimed mostly at local exchange carrier events. Therefore large LEC's tend to be over-represented in the reports. There also seems to be the usual corporate games with what gets reported and what doesn't. Here is a list of everyone who filed one ore more FCC outage reports in 1998 through Oct 5, 1998. Does it really tell you anything? Not really. For example, notice the absence of GTE and Illuminet from the list. Does this mean Illuminet and GTE were so reliable they didn't have a single outage in 1998. Or the filing requirements don't really capture today's business structures. Sometimes you find Worldcom filing an outage report about an MCI fiber cut which Worldcom was leasing some circuits, but I didn't find an equivalent filing by MCI about the fiber cut. You could really tell the confusion in the Illuminet SS7 failure which affected lots of carriers. Some other carriers filed outage reports, some withdrew their filings, others never reported anything. Because of the problems I see with who reports what, I'm not going to rank, or give counts for individual carriers. This list is in alphabetical order. alltel ameritech att bell atlantic bell south century telephone matanuska mci means pacbell pagenet puerto rico telephone qwest sbc snet sprint tcg uswest virgin islands islands worldcom It was interesting to read the reports. Anyone who has ever worked in a NOC would love some of the comments. Everyone really does go through the same stupid stuff. Here's my ranking of the most common reasons for FCC reportable outages, in order for most to least. Fiber/cable cuts Power (mostly weather related) Operator/Maintenance errors Hardware (C.O.) failures Software errors Sabotage Animal (gopher) I did find that Worldcom is getting a bit annoyed at the number of fiber cuts and service disruptions they are experiencing. In several of their most recent filings they've started identifying the responsible parties by name, e.g. Qwest, Metromedia Fiber Systems, CSX. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Wireless network at NANOG 14?
by Simon Lockhart 07 Oct '98

07 Oct '98

Now that I've booked my place at the conference, and a room in the hotel, I figure its time to work out how to connect to the wireless LAN. I can't see any reference to it on www.nanog.org, but have seen talk of it on this list. So that I beg/buy/borrow the correct card, has anyone got details of what I'll need to be able to connect to it? Thanks, Simon -- Simon Lockhart | Tel: 01737 836676 Senior Online Systems Engineer | Fax: 01737 836665 BBC Research & Development | Email: Simon.Lockhart(a)rd.bbc.co.uk Kingswood Warren, Tadworth, Surrey. | URL: http://www.bbc.co.uk/rd/

2 1

Re: Fog Bank in a co-locate
by David Lesher 07 Oct '98

07 Oct '98

Just curious -- anyone seen Ground Source Heat Pumps used for Machine rooms? -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Fog Bank in a co-locate
by Sean Donelan 07 Oct '98

07 Oct '98

wb8foz(a)nrk.COM (David Lesher) writes: >I'm less sure. IMHE, anything running will not promote condensation. >It will be warmer than ambient. The concern is greatest if you have any external doors opening directly into the co-locate area (no vestibule or 'air lock'). Since it is "Relative" humidity, what will happen when the warm, humid outside air enters a cold area? The supersaturated air will condense when it hits any relatively cool object, such as the supporting superstructure and rack rails. Water will then do what it does best, start dripping onto the equipment in the racks. I actually learned this lesson in high school when I opened a window in the school computer room on a hot, muggy summer day. The same thing will happen in the winter, if you let very, very cold air into a warm area with 40%-50% relative humidity. The real lesson is avoid external doors and windows opening directly into the controlled area. This tends to be a religious issue. To make matters worse, for a major data center you really need about four different environmental zones: people, magnetic media, paper, and electronic equipment. Most of the time you compromise and pick a happy medium set of environmental settings. One misconception is the idea of "Telco environment" being better. In fact, most times the telco environment is worse. The reason you need more robustly built telco equipment is C.O.'s have a harsh environment. So, with that in mind, here is one person's opinion on a good comprise set of environmental parameters for a data/telco/isp co-locate space. This assumes the space is used for mostly EDP/network equipment, and only incidental people, tapes, and paper are in the area. Donelan's Climate Settings: 8,500 BTU/hr heat dissipation per full rack Not all of it must be installed on day 1, but I want to see pre-planning how the HVAC will be expanded to meet the load (e.g. enough room reserved, aisles wide enough, to bring in additional units later, pre-plumbed for the outside heat exchangers, compressors, etc). Minimum 1 air change per hour This is actually a 'clue-check' question. How the co-locate operator answers it will tell you if they really know their HVAC systems. Unoccupied areas can get by with as little as 1 air change per 24 hours, but if you are doing an install or other work in the area, you'll appreciate more frequent air changes. Humidity: 35% to 50% R.H., non-condensing, max 2% change per hour Ideal: 40%-45% R.H., measured at three locations with max 5% variation. Humidity is expensive to control, so it is common to have R.H. at the high end of the range (e.g. 45% R.H.) in areas naturally more humid (e.g. northeast) and R.H. at the low end of the range (e.g. 40% R.H.) in areas naturally drier (e.g. southwest). Maximum (not to exceed 24 hours/annually): 20%-60% R.H., non-condensing Temperature: 59f to 77f (15c to 25c), max 4f (2c) change per hour Ideal: 72f (22c) at my rack, but since it is econmically infeasible to control the temperature at the rack level, I normally ask for 68f (20c) as a room average, measured at three different points, with a maximum of 4f(2c) variation. The assumption is at worst I'll end up with 72f(22c) at my rack. Anything much colder than 68f(20c) is a bit harsh on humans that need to work in the area. A tech thinking about how cold he is, isn't thinking carefully enough about the job he is supposed to be doing. Maximum (not to exceed 24 hours/annually): 49f(10c) to 85f(30c) You'll notice I tend to be metric-centric in my measurements. These are much stricter than your typical C.O. environments. Its more a practical matter of negotiating with the co-locate operator, and asking for more than you really need on the assumption even if they deliver just 50% of what they promise it won't be an immediate disaster. They may have no problem delivering 68f(20c) when the co-locate is 90% empty. But when it fills up, I'm betting with the lower the starting point, the less likely I'll run into my upper limit. I choose most of the values to give myself enough of a buffer before exceeding any equipment parameters, so I can try to negotiate a resolution with the co-locate operator before the levels start to causing equipment to shutdown. Otherwise if you set the limits at the maximum your equipment will tolerate, a co-locate operator may not do anything until after the temperature goes over 104f(40c), but by then its too late. Obviously the co-locate operator wants to write the contract with the largest acceptable environmental ranges possible, and the co-locate lessee wants the narrowest acceptable environmental ranges. Its a barginning point, how much do you really want to pay for +- 1 degree, or +- 10 degrees. In reality, most modern electronic equipment will operate well in a wide range of human-habitable enviroments, as long as the enviroment is stable. Its the oscillations that will kill your equipment every time. And in most cases, if the price is the same, I am willing to trade a particular value for tighter tolerances, e.g. 75f+-1f. But the price is rarely the same, so I generally choose the bigger range as shown above. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: [YA] Fwd: Class B Purchase
by Sean M. Doran 07 Oct '98

07 Oct '98

Uhm but an AS-path is a trail of bread-crumbs to prevent an announcement loop, not a proper predictor of the forwarding-path towards the origin. Indeed, because of hop-by-hop routing, the ultimate destination may have nothing to do with the originating AS. Fun fun fun! Consider what happens when, at an IX, one of the ASes in an AS path gives you someone else's router address as a next-hop... Sean. - -- Jared Mauch wrote: | second, if they (AS5662) were connected to MCI/CW rather than | Sprint, they would be unreachable with this announcement, other | than the fact that ANS would be announcing the aggregate, and following | that path, rather than having the actual as-path be traversed.

2 1

Re: [YA] Fwd: Class B Purchase
by Hank Nussbacher 07 Oct '98

07 Oct '98

At 10:48 PM 10/6/98 -0400, Jared Mauch wrote: >On Tue, Oct 06, 1998 at 07:56:59PM -0400, Kim Hubbard wrote: >> Michael, >> >> Could you define "legitimately multihomed" please? > > I think that a prime example would be a site such as >progressive networks, cnn (turner), msbnc, or any other high >traffic site. > > They will be multiply connected to major providers, >but most use some sort of ip director, and all their >machines sit on the same /24. > > Although I don't like the way some of these peoples networks >are built, they don't have enough machines/servers to justify anything >more than a /24 or even at most a /22, but still need provider >independent space as they may show up at regional exchange points. Been there. Done that. See: http://www.isoc.org.il/ipnum.html Requires me to scan Mae-East 4x a year and check whether they are still multihomed. Can such a method scale? Don't know. -Hank > > The best bet for these people in some cases is to go hunt for >space that is "available", as ARIN and folks won't allocate such space. > > Their other option is to sit on the network block of >one of their providers, but some people do have issues with >announcing other providers address space (like it's against their >internal policies). > > This would be a semi-justfiable use of a portable block >less than a /19, would it not? > > - Jared > >

2 1

Re: MAE NY?
by Aleksi.Suhonen＠saunalahti.fi 07 Oct '98

07 Oct '98

} Looks like a MFS MAE wins for me. Alex, you seem to be by an airconditioner } outlet in Newyork - Can we put a duct between our racks ;-) You're routing hot air now? ;-) } R -- Aleksi Suhonen Network Development Saunalahden Serveri Oy AXU-RIPE

1 0

Re: [YA] Fwd: Class B Purchase
by Hank Nussbacher 07 Oct '98

07 Oct '98

At 03:41 PM 10/6/98 -0700, David R. Conrad wrote: >Michael, > >>My advice in this instance would be to sue Sprint for antitrust violations >>because if you win then you get triple damages awarded and Sprint >>definitely has the bank account to pay out on the award. Forget the >>registries. They are just trying to do the best they can in the awkward >>situation that was created by Sprint. > >Wow. You're _really_ confused. > >The situation wasn't created by Sprint, it was created by the lack of self >control on the part of the other ISPs. Remember when the filters were >first instituted. Remember the growth of the routing tables. Remember the >maximum routing load the routers back then could handle. > >The registries _relied_ on Sprint's filters to give some teeth to "it's a >real good idea to go to your upstream". Sprint (read: Sean Doran) was the >ONLY isp to have the cajones to risk outrage to try to limit the >proliferation of long prefixes. If it wasn't for Sprint's filters, there AGIS used to have a page that stated the same routing filter policy as Sprint's. -Hank >would have been only registry whining as back pressure limiting the >allocation of provider independent prefixes. Geuss what: whining wasn't >particularly effective. RIPE-NCC and APNIC instituted fees for cost >recovery, and these had the side effect to limit organizations approaching >those registries for resources. InterNIC (at the time) was not able to >follow suit. Given the IAB's RFC 1814, there was _very_ little that >discouraged every Tom, Dick, and Mary consisting of two modems in a dorm >room that called themselves an "ISP" (or not) from demanding address space >from InterNIC. With the unilateral imposition of filters by Sprint there >was concrete evidence that prefixes longer than /19 were perhaps not a good >idea, thereby encouraging folk to go to their upstreams thus limiting the >proliferation of long prefixes. > >Yeah, let's sue. > >Frankly, with comments like this, I feel Sprint is approaching terminal >stupidity for keeping the filters in place. I'm sure they have a lovely >business case for keeping the filters active (or they wouldn't have lasted >this long), but at some point, natural selection has to be allowed to >function. I also think the registries should actually be registries and >not try to be the Internet's mommy. Internet service providers (or those >who think they are Internet service providers) ought to clean up their own >messes for a change instead of relying on Sprint and the registries to do >it for them. After all, everyone has a god-given inalienable right to >portable addresses, no? > >Disgustedly, >-drc > >

1 0

MAE NY?
by Brian Horvitz 07 Oct '98

07 Oct '98

Just curious to know who's exchanging traffic at MAE NY? If I am to believe what I see at www.mae.net, there's only two networks connected there, which would make it a pretty ineffective exchange point. With Pennsauken closed to new connections (anyone got extra rack space there?), I'd like to investigate an alternative for that area. Brian --- Brian Horvitz Shore.Net Network Engineering

10 16

Re: MAE NY?
by Richard Parker 07 Oct '98

07 Oct '98

On Tue, 6 Oct 1998, Jay Adelson wrote: > Too cold? Are you serious? Man, I just can't win. > > Our readouts were reporting 68-71F... Somebody tell me what this needs > to be set to for our exchange facilities. They're all pretty insanely > big, so this is something to do ONCE. Nows the time, we're deep into > engineering HVAC for the first fifteen. Oh, and I'd love to hear > humidity suggestions as well. Well, lets see... 1) Largest minimum operating RH for a communications device that I happen to have the specs for is 20%. 2) Smallest maximum operating RH for a communications device that I happen to have the specs for is 80%. 3) Static electricity is minimized when RH is at or above 35%. 4) RH below 25% can cause embrittlement of hygroscopic materials such as paper. 5) RH above 65% can cause mold growth and metal corrosion. 6) Humans are most comfortable when the RH is between 20% and 60%. 7) RH above 50% in cold weather can cause condensation inside of outer walls. So... perhaps a target humidity somewhere between 35% and 45% would be ideal. -Richard

1 0