- Test - lists.nanog.org

Re: mae-west route servers are both down hard
by Paul Ferguson 25 May '96

25 May '96

At 09:50 PM 5/24/96 -0400, Jake Khuon wrote: > >The RA services at MAE-West were never declared production because we did >not have two operational RSes deployed there. The RSes at the other NAPs >that have been declared for production were able to sustain a single-machine >failure without loss of service. > Let me see if I correctly understand this. The RA services at MAE-West were never declared operational, yet there are service & transit providers using them for production services? If so, this will still be interpreted as a black eye for the RSs. - paul

2 1

Re: mae-west route servers are both down hard
by Paul Ferguson 25 May '96

25 May '96

At 09:50 PM 5/24/96 -0400, Jake Khuon wrote: > >The RA services at MAE-West were never declared production because we did >not have two operational RSes deployed there. The RSes at the other NAPs >that have been declared for production were able to sustain a single-machine >failure without loss of service. > Let me see if I correctly understand this. The RA services at MAE-West were never declared operational, yet there are service & transit providers using them for production services? If so, this will still be interpreted as a black eye for the RSs. - paul

1 0

Re: mae-west route servers are both down hard
by Sean Doran 25 May '96

25 May '96

I suppose this would be an incredibly tacky time to say I told you so? Sean.

3 2

Re: safety of route servers
by Sean Doran 25 May '96

25 May '96

| on the flip side, sean, i don't know of an instance yet where route | servers that merit had declared "in production" have screwed anybody's | pooch. you're passing from tacky toward catty, clearly the route servers | and N**2 peering at exchange points is an idea whose time has not yet | passed. So? I said already that I'd love to be proven wrong in my belief that (based on much history, some before the RA) route servers simply won't work in the current Internet. Just think of it this way: the ability to peer reliably and with a minimum of negative side-effects with _many_ NAP-or-MAE-attached networks and using fairly complicated policy under the control of my colleagues and me would be a potentially very profitable situation for Sprint Corp. Sean.

1 0

mae-west corrigenda
by Sean Doran 25 May '96

25 May '96

I wrote: | Indeed, one would have to be VERY uncharitable to MERIT and this in fact is true, but mostly because a source has indicated that it is ISI's responsibility to keep the RSes functioning. I also wrote about the RA's committment to MAE-WEST, indicating that I believed the RA had no formal responsiblity to offer an RS and support at MAE-WEST. I have found an EOWG (or is it FEPG?) document stating that: Currently there is one route server located at MAE-W/FIX-W. This is independent of the route servers at the NAPs. Ames has committed to having the RA service available at MAE-West and will recover the costs from the attached networks. All the agency networks have indicated that their organizations are willing to compensate Ames for operating the interconnection point on a cost recovery basis. ["Proposal for the Continued Interconnection of the Federal Agency Networks", December 11, 1995 Version 1.0] Which seems to confirm my belief. I wonder how many of the people who were cut off from the MAE-WEST RS and suffered as a consequence have paid NASA for their portion of the costs? Maybe this _isn't_ a requirement under the Space Act, but then again, maybe people using the RS at MAE-WEST are paying, or maybe nobody realized that the RS paid for by NASA Ames is being used by commercial entities (presumably both those that are NASA Ames tenants and those that are NOT tenants) making profit from that use? Sean. (account compromised by cook(a)cookreport.com?)

1 0

Re: mae-west route servers are both down hard
by Sean Doran 25 May '96

25 May '96

| Let me see if I correctly understand this. The RA services at MAE-West | were never declared operational, yet there are service & transit providers | using them for production services? | | If so, this will still be interpreted as a black eye for the RSs. Surely, since the RA services (AFAIK) have been explicitly experimental for some time, and it was no secret that there was a potential single point of failure at MAE-WEST, this should be interpreted as a black eye for those people who decided to use the RSes anyway? Sean. P.S.: Surely the RA has enough self-inflicted black eyes without people blaming them for something that some form of payment by the non-NSF93-52 clients of the RSes easily could have prevented? Remember that MAE-WEST is (unfortunately) not the priority NAP in the San Francisco Bay Area. Of course, this depends alot on how one inteprets: "Route servers are to support stable routing of the Internet and to provide for simplified routing information to NSPs and other attached networks" [nsf9352 s. C para. 2] and in particular what one considers an "attached network". (The term NSP is very clearly defined in the solicitation). Personally, I believe that given that the only other place in "NSF 93-52 - NETWORK ACCESS POINT MANAGER, ROUTING ARBITER, REGIONAL NETWORK PROVIDERS, AND VERY HIGH SPEED BACKBONE NETWORK SERVICES PROVIDER FOR NSFNET AND THE NREN(SM) PROGRAM" where these words are used are with respect to networks attached to the NSFNET NAPs, the folks at MAE-WEST may not really be covered by the award at all. Certainly the bulk of the people affected in the current outage aren't doing much with respect to the NSFNET and the NREN program. [One could also be a weasel and argue that there's not much more simple than no routing information at all...] Of course, I don't have a copy of the RA award handy, and I've never seen any of the NSF<->RA communications about the RA's obligations to MAE-WEST, so please take this for what it's worth until someone really in the know says something concrete.

1 0

Re: mae-west route servers are both down hard
by Sean Doran 25 May '96

25 May '96

| SD> I suppose this would be an incredibly tacky time to say I told you so? | | s/tacky/misleading/g Huh? I was completely agreeing with you. Strange that you should call that "misleading"! | The RA services at MAE-West were never declared production because we did | not have two operational RSes deployed there. Only a strange group of people could assign blame to MERIT for Paul's "quite a few peerships" which failed because they relied upon something that was not a production service, unless they were uncharitable and asserted that it was MERIT's duty to push back against people using it even as an explicitly experimental service. I wouldn't. People should be free to have unsafe peerings if they want. Indeed, one would have to be VERY uncharitable to MERIT because "the strength of Merit's publicity" is in itself pretty weak. Moreover, given the countless times Vadim Antonov, many others and I have spent saying "relying upon the RSes and the RA is a baaaaaaaad idea" (whether you agree or not: the pro and con side are both debatable, and arguments for either side are forms of publicity), it's practically not much more than sour grapes on the part of people who never believe an iota of the argument that the current Internet will not safely sustain large numbers of bilateral and multilateral peerings. The RS failure at MAE-WEST is just one example of the problems one likely will encounter when refusing to accept that as a current (but not necessarily permanent) reality. However, I do welcome people's efforts to prove me wrong, especially where such efforts advance IP routing technologies in potentially useful ways. Sean.

1 0

mae-west route servers are both down hard
by Paul A Vixie 24 May '96

24 May '96

This... >From: noc(a)noc.ns.itd.umich.edu >Date: Thursday, May 23, 1996 4:26 PM >Subject: rs2.mae-west down indefinately > >The route server rs2.mae-west.ra.net has crashed with the same symptoms as >rs1.mae-west. Both servers will be down indefinately. Further >information will be passed on as it becomes available. We apologize for >any inconvenience this may cause. > >------------------------------------------------------------------------ > UMNet MichNet CICNet >Merit RA >------------------------------------------------------------------------ >Network Systems Consultant Network Operations Center >trouble(a)noc.ns.itd.umich.edu U of M Information Technology Division ...is not just an inconvenience. On the strength of Merit's publicity, quite a few peerships have been done through route servers, and to have both route servers down at the same time is a massive disruption to many of the folks who connect at MAE-W. I have two heavily overconfigured Alpha machines loaded in my van, with Stephen Stuart's port of RSd all ready for someone from Merit or ISI to load up their configuration tables. I've got a driver and a technician. I need someone from Merit or ISI to call me and arrange physical access as well as scheduling the download of the initial configuration files and turnover of the root account and other "system keys". The use of the machines, and the time to deliver and install them, have all been donated by people who are suffering due to MAE-West's ills. It is most extraordinary that we have let things suffer this long, and if the current plan is to wait until after the three day weekend, I consider that flatly unacceptable. E-mail me (paul(a)vix.com) or call me (1 415 747 0204) to arrange details.

2 1

NANOG Registration
by Pam Ciesla 24 May '96

24 May '96

Is closed for the May meeting. Pam

1 0

Automated processing of InterNIC changes?
by Steve Rubin 24 May '96

24 May '96

I thought all of you would find this amusing. Network Solutions, Inc. (INTERNIC-DOM) 505 Huntmar Park Drive Herndon, VA 22070 Domain Name: INTERNIC.NET Administrative Contact: Network Solutions, Inc. (HOSTMASTER) hostmaster(a)FUTURE-FOCUS.COM 619-452-4365 (FAX) (703) 742-4811 ^^^^^^^^^^^^^^^^ Neat.. -- Steven Eric Rubin <ser(a)aimnet.net> Aimnet Corporation Senior Network Engineer 2350 Mission College Blvd Phone: (408) 567-3820 x511 Santa Clara, CA 95054 Fax: (408) 567-3990 http://www.aimnet.com

3 2