- Test - lists.nanog.org

Re: IP allocations, renumbering, and RFC 2050
by Tony Li 08 Oct '98

08 Oct '98

brad(a)null0.qual.net (Bradley Reynolds) writes: > After taking a cursory glance at RFC2050, i happened upon > the ambiguous and unintelligable wording 'best current > practice'. Even though the definition of this term was thoroughly > obfuscated, i did not find LAW or JESUS SPAKE preceding any > of the edicts contained within the mentioned rfc. Please see RFC 1818. Tony

1 0

[YA] Fwd: Class B Purchase
by David R. Conrad 08 Oct '98

08 Oct '98

Hi, Seems scanning ARIN's database for B's is becoming a trend. Anybody want to provide the procmail incantation to forward flems and other wasted bits (like this message) to Gabriel automatically? Don't these people realize addresses have no value? After all, addresses are just integers. Right, Bill? :-) Hmmm. At last! A way to cover the upkeep costs for my black helicopter (they're so useful, I didn't want to return it when I left APNIC)! As APNIC's 16 Bs are still registered to me, I see a _wonderful_ profit potential -- anybody got the URL for the Address Black Market, I seem to have misplaced it...? Regards, -drc --------------- >Date: Sat, 3 Oct 1998 06:57:07 GMT >From: "CommuniTech.Net, Inc." <gabriel(a)communitech.net> >Subject: Class B Purchase >To: <davidc(a)apnic.net>, <gabriel(a)communitech.net> > >My name is Gabriel Murphy and I am with CommuniTech.Net, a rapidly growing >Internet Presence Provider. I am writing you today to inquire if you might >be interested in selling the Class B you have registered through the American >Registry of Internet Numbers. > >As you may or may not know, ARIN is no longer issuing Class B blocks. Our >business is growing quickly and the availability of IP Addresses is fundamental >to our business going forward. > >If you are interested in selling the Class B you have through ARIN, please >contact me personally at gabriel(a)communitech.net. We realize that an outright >purchase of a Class B would be expensive, but it is extremly important to the >future of our business. We are quite serious about this inquiry and hope to >hear from you soon. > > >Best Regards, > > >Gabriel Murphy >CommuniTech.Net Inc. >http://www.communitech.net >

20 38

Re: Sprint's filtering
by Scott Bradner 08 Oct '98

08 Oct '98

it was said > I have been told that ARIN did make an effort to have Sprint remove its > filter so that ARIN could allocate blocks longer than /19, but I have not > confirmed this with ARIN. this is not true - ARIN has not, nor will it, ask an ISP to add or delete any filters - dealing with filters is far outside of ARIN's mission ARIN has discussed changing alocation policies but this did not include asking Sprint or anyone to change their policies before I get asked- changes to ARIN policies are posted on the ARIN web site Scott

2 1

Looking for cabinet vendors.
by Geoff Lisk 08 Oct '98

08 Oct '98

I'm unhappy with my current cabinet vendor and am looking for a new one. Does anyone have suggestions on cabinet vendors that they've had good experiences with? Since this is only marginally an network operations issue, I'd appreciate private responses. Thanks. -Geoff ---------------------------------------------------------------------- Geoff Lisk Phone: 415-228-4170 Network Engineer E-mail:glisk@digisle.net Digital Island Pager: glisk(a)airnote.net One hop to the world... www.digisle.net ----------------------------------------------------------------------

1 0

2MB Internet Connection Needed In Sao Paulo, Brazil
by Michael R. Johnson 07 Oct '98

07 Oct '98

Network+Interop is looking for a 2MB internet connection in Sao Paulo, Brazil for the N+I Show on November 3rd thur the 6th. Time is running out, we will use a terrestrial or satellite circuit. If anyone has any contacts, please send them ASAP. Thanks MJ

1 0

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