December 1999 - Test - lists.nanog.org

Re: Internet Y2K Conference Call
by Sean Donelan 23 Dec '99

23 Dec '99

On Thu, 23 December 1999, "Alan Hannan" wrote: > Global Crossing is sponsoring a year-end Y2K Voice Conference Call > for ISPs and NSPs. Does anyone know how many conference calls will be in progress over New Year's. AT&T is providing most of the teleconference bridges for the big Y2K groups (ICC, I0PS, etc). There's something to be said for one of the few telephone companies that has experience with '00 rollovers, being incorporated in 1885. But I've also seen press on MCI Worldcom having many different conference bridges operating over New Year's. And I assume the same is true of other teleconference providers. Will this be the "mother's day" of conference bridges? How many simultaneous conference calls can the current voice bridge infrastructure support?

1 0

Silly season
by Sean Donelan 23 Dec '99

23 Dec '99

As Alan points out, it looks like silly season will be in full swing. Here is a site claiming it will check the top web sites in the world, and if 5% aren't responding at 1 minute before midnight (pick your time zone) a major disaster has happened. http://biz.yahoo.com/prnews/991222/inferno200_1.html As has been pointed out before, many sites plan to shutdown their web sites or disconnect from the Internet over the New Year's weekend. Which I guess is a self-fulling prediction. The Internet is still considered an "extra" and not a necessary connection like the telephone or ATM. I haven't heard anyone suggesting they would turn off their ATMs, even though they are Y2K ready, just to be safe. You can read ATM as representing either acronym.

4 5

Re: Replacement for NPD
by Vern Paxson 22 Dec '99

22 Dec '99

> Does anyone know of a replacement for the Network Probe Daemon software = > that was distributed through the IPMA website? I've been working with colleagues at PSC on a successor called "NIMI". Its goals are: (1) accommodate a wide range of measurement policies; (2) accommodate a wide range of measurement tools; (3) take security seriously; (4) take scaling seriously. There's a paper giving an overview available from: V. Paxson, J. Mahdavi, A. Adams, and M. Mathis, An Architecture for Large-Scale Internet Measurement. IEEE Communications, Vol.36, No.8, pp 48-54, August 1998. ftp://ftp.ee.lbl.gov/papers/nimi-ieee-comm98.ps.gz The software is alpha level and under active development. The current infrastructure is 28 hosts, which we're in the process of trying to grow to double that size within the next few months. Volunteers who can host a box are highly welcomed - drop me a line at vern(a)ee.lbl.gov if interested. Vern

1 0

RE: [announce-all] NAC Maintenance this weekend (fwd)
by Sean Donelan 22 Dec '99

22 Dec '99

On Fri, 10 December 1999, Alex Rubenstein wrote: > Something interesting for all you operational folks... got this from a > customer. I've seen some amazing disasters, but I think your customer passed along an urban legend. 38 people taken to a hospital, 8 cars destroyed, coverage by television in five states; and I can't find any published reports in the newswire databases. Unless my math is very wrong, I don't understand how a 300 amp surge could damage that much stuff.

9 9

Replacement for NPD
by Sindhu Xirasagar 22 Dec '99

22 Dec '99

Does anyone know of a replacement for the Network Probe Daemon software that was distributed through the IPMA website? Thanks Sindhu Xirasagar

1 0

Re: Need help from UUNet's routing specialist!
by Brian Dickson 22 Dec '99

22 Dec '99

> We (as8470) are Teleglobe customer. And we experience terrible > delays on Teleglobe to UUNet interconnect points. Teleglobe's customer > support engineers insist, that the problem caused by UUNet's routes > prioritization. > But I belive that this assymetric routing initiated by Teleglobe, not > UUNet. We apologise for this customer-provider issue propogating to NANOG. For the information of interested folks, and to clear up any incorrect perceptions, I have copied the list on my reply. Currently, private interconnects from Teleglobe to UUnet are multiple DS-3's, in multiple cities. However, as a result of incremental load, the management and load-balancing of these is tenuous, and event-sensitive. Specifically, internal events on either network, can cause congestion as a new closest-exit path is chosen. We are currently waiting for delivery of several OC-12 circuits to replace the plethora of DS-3's. Unfortunately, provisioning OC-12's is not something many LEC's can do, let alone in a timely manner. When these are in place, the problems should go away for the forseeable future. Provisioning of additional OC-12's should be feasible in the timelines anticipated for further growth of traffic. Until then, there is some traffic engineering being done via MEDs, for the purposes of avoiding congestion. Some of this is steady-state (since certain peerin glocations are currently under-provisioned), and some is in response to congestion events. In the absence of inter-provider MPLS, to handle such things inter-provider and intra-provider outages in a semi-optimal fashion, and in the absense of excess interconnect bandwidth (to handle outage-based peak loads), there will be instances where asymmetry is required to minimize network impact of such outages. The selection of routes for application of MEDs is done on a random basis, for scalability reasons. The choice of exit modulo these MEDs is still closest exit, and will vary based on the geographic location of the end system. (The MEDs are used to de-prefer a couple of peering locations; all others operate naturally, ie closest-exit.) I hope this explanation is clear enough; if anyone has questions about this or other Teleglobe issues, please feel free to contact me directly. -- Brian Dickson, Email: briand(a)teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com

2 3

Internet Y2K and Europe, South America, and Middle East
by Sean Donelan 22 Dec '99

22 Dec '99

Is anyone aware of any regional joint ISP monitoring and communication efforts over New Year's for European, South American and Middle East ISPs? Or are most ISPs in those areas relying on a US-based backbone provider to keep them informed? North America, Asia, Australia/New Zealand seem to have a plethora of groups.

4 3

All the chemical factories are OK, but their web page will be down..
by Alan Clegg 21 Dec '99

21 Dec '99

Subject line says it all. I got this today from the Chemical Safety Board.. Silly season is definitely upon us. Have a happy and safe new year! AlanC ------- Forwarded Message From: csb_automailer(a)csb.gov To: abc-chem(a)firehouse.net Subject: CHEMICAL SAFETY BOARD WEB SITE TO UNDERGO PRECAUTIONARY 24-HOUR Y2K SHUT DOWN; ALSO, YEAR 2000 CHEMICAL SAFETY CARD AVAILABLE Date: Tue, 21 Dec 1999 17:54:45 -0500 The following message is from the United States Chemical Safety and Hazard Investigation Board (CSB), Washington D.C. As a precaution and to protect critical information systems, the CSB web site will be shut down, temporarily, for approximately 24 hours beginning at 8 a.m. Eastern Standard Time (U.S.A.) on December 31st. This is a precautionary Y2K-related shutdown. The web site is scheduled to return to operation on the Internet at Saturday morning, Jan. 1, 2000. Chemsafety.gov users are advised to download information from the site prior to the shutdown. We regret this inconvenience. On a positive Year 2000 note, the CSB advises that copies of its "fully Y2K-compliant" chemical safety calendar wallet card are available for distribution. For details visit http://www.chemsafety.gov/about/cards.htm . This message was transmitted at 5:31 PM Eastern Time (U.S.A.) on December 21, 1999. ________________________________________________________ Visit us on the World Wide Web at http://www.chemsafety.gov - -- This mailing came from the csbnews list maintained by the Office of External Relations, U.S. Chemical Safety and Hazard Investigation Board, Washington, D.C. - -- To unsubscribe to this list please send a message from the subscribed email account to csbinfo(a)csb.gov with the subject line blank and the words "unsubscribe csbnews" (no quotation marks) in the body of the message. Please note: if the "from" address at the top of this message is from an address other than csb_automailer(a)csb.gov please contact the sender. ------- End of Forwarded Message

1 0

NANOG 18
by Pam Ciesla 21 Dec '99

21 Dec '99

Merit Network will be closed for the holidays starting Friday, 12/24 thru January 3rd :*). NANOG-support will be checking mail, but not regularly. While you can still register durning this time the registration page will not be updated until our return. The registration page is current at this time. Check the NANOG webpage for agenda topics http://www.nanog.org. Happy holidays and hope to see you in the next century. Pam Pam Ciesla Events Coordinator Merit Network,Inc. 734-936-0172 - phone 4251 Plymouth Road 734-647-3185 - fax Bldg.I, Suite 2000 pam(a)merit.edu Ann Arbor, MI 48105

1 0

Re: Internet Y2K and Europe, South America, and Middle East
by Sean Donelan 21 Dec '99

21 Dec '99

On Mon, 20 December 1999, "Alex P. Rudnev" wrote: > What do you want to monitor? real time problems are not supposed to appear, > billing and accounting problems are not monitored at all. Why so many people > aware unexisting problems (some computer refuse to work due to Y2K - let me > smile for a 10 minutes hearing this - and so few people really understand Y2K > problems (billing systems, accounting systems, daily-log-analysing systems, and > so on). But this means that real Y2K problems appear approximateky 3 - 10 of > january, not at 12:00 31-December. > > And this means all this ISP monitoring is useless, you'll monitor not more than > people's paranoia about Y2K and will not monitor any real problems. I don't actually think the monitoring will pick up any Y2K problems. I'm interested in the communications and monitoring to pickup all the other problems, and trying to head off rumors when something inevitably doesn't work. For example, tonight if you go to the US government's Y2K web site it's not working. It appears to be a server problem with http://www.y2k.gov/ and not a network problem. You get an error "The request did not specify a valid virtual host." I don't think its Y2K problem, and if we could contact the operators, we might find out what's wrong. If something like that happened in the early morning of January 1, without good information, rumors will spread.

2 1