- Test - lists.nanog.org

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

Re: Worldly Thoughts - Regionalizing Peering
by Alec H. Peterson 24 May '96

24 May '96

Dave Siegel writes: > >Since these are designed to be regional exchanges, one would presume that >transit is still available elsewhere. > >Even at the large carrier level, I should think that the priority NAPs, >as well as the private interconnects, would contain complete information >on the other networks to back up any failure to route at a regional exchange. Er, um, well yes, but ideally if you get peering from all the big boys, you wouldn't need to purchase transit from someone. I think the idea of only exchanging local routes at any given regional exchange is not a bad idea, but I don't see how it would really end up working properly in a fluctuating environment. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie(a)panix.com | Panix Public Access Internet and UNIX| |Network Administrator | New York City, NY | +------------------------------------+--------------------------------------+

2 1

Re: Worldly Thoughts - Regionalizing Peering
by Alan Hannan 24 May '96

24 May '96

Toodles, ] > 2. Even better, accept my routes into your network but only use them ] > within region... I know this isn't nearly as easy as #1, so I don't ] > expect it to happen, but it would be a significant performance benefit ] > for the local traffic your customers in the region are generating which ] > is headed towards me. Once outside the region, of course, you ignore the ] > direct routes from me and just give them to my transit provider. ] ] It becomes very entertaining to scale the above model (although it does ] provide an excuse to use nearly every BGP routing feature in IOS. :-) The model scales well, imho. Regionalize your network into pieces. Apply each of the pieces into 1 or more proximities to a NAP|MAE. Apply set filter lists onto peering sessions for appropriate peers. Let me expound. I run Internet-Net.net. I have a POP in every city w/ over 10,000 people. I aggregate M number of POPs to N number of Hubs. (use acronym NXP to mean network exchange point.....) I am connected to P number of NXPs. I go through each of my N Hubs, and identify if he is or is not in Pn's region. If he is, I add NXPn's peers to the allow list. If he's not, I don't. Won't this work? Is it "too confusing"? Let's say I have 1 HUB in Arizona. I decide that they are in the region of MAE-W, PACBELL, and the NXP in Phoenix. So, I accept routes from everyone at any of those NXPs, and I give my routes for this HUB only, to everyone at the NXP. I don't tell them about my route to customers homed to San Mateo, because I don't want to carry their traffic there, only stuff that's topolgically 'close' to them, as I feel that benefit to my customers is worth the peering relationship. I have a HUB in San Mateo. I decide that he's in the region of MAE-W and PACBELL and MAE-LA, but not the NXP in Phoenix. So, I accept routes from the folks at those NXPs, and only give the routes for my folks homed to my San Mateo HUB. My San Mateo Customers get to the folks at the NXP, and the other providers customers get to my customers CLOSE to the NXP in San Mateo. However, I don't have to backhaul them to another larger aggragation point, or to another NXP at which I hand off packets to their transit provider. Benefit: I gain low latency transit to most everyone. Drawback: It is technically challenging to create an automate system to regionalize and create appropriate filter lists. ---- Perhaps this is a problem that's only challenging to the smaller folks, those of us w/out the nationwide DS3|OC3 networks. However, I do feel it's a worthy problem, and one that would benefit the NANOG community were it intelligently solved. -a

5 4

Re: RFC 1597
by Craig Labovitz 23 May '96

23 May '96

Might be a good time to mention that there is a web page that tracks all of the bogus routing information sent each day. See http://www.ra.net/statistics and select "routing problems." There is also now a mailing list where you can receive a daily list of all the bogus routes (RFC-1918, IANA reserved nets, host announcements, etc.) sent the previous day. To subscribe, send mail to routing-problems-request(a)ra.net. - Craig ------- Forwarded Message Return-Path: nanog-owner(a)merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by home.merit.edu (8.7.5/merit-2.0) with ESMTP id DAA07017; Thu, 23 May 1996 03:41:14 -0400 (EDT) Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id DAA09256 for nanog-outgoing; Thu, 23 May 1996 03:39:20 -0400 (EDT) Received: from chops.icp.net (chops.icp.net [199.0.55.71]) by merit.edu (8.7.5/merit-2.0) with ESMTP id DAA09251 for <nanog(a)merit.edu>; Thu, 23 May 1996 03:39:17 -0400 (EDT) Received: by chops.icp.net id <20677>; Thu, 23 May 1996 03:39:05 +0100 From: Sean Doran <smd(a)icp.net> To: djs(a)secure.net, nanog(a)merit.edu Subject: Re: RFC 1597 Cc: dfk(a)ripe.net, hank(a)sprint.net, insc(a)sprintlink.net, rv(a)INFORMATIK.UNI-DORTMUND.DE Message-Id: <96May23.033905+0100_edt.20677+12(a)chops.icp.net> Date: Thu, 23 May 1996 03:38:58 +0100 Sender: owner-nanog(a)merit.edu Precedence: bulk | I need a few class Cs. Hope nobody will mind if I take | 192.168.0.0/20. ;) Knock yourself out. :-) | *> 192.168.100.0/22 144.228.71.5 0 1239 1794 ? This appears to be a truly ancient (before 17 Jan 1996) typo or thinko or somesuch, and has been corrected. Sean. ------- End of Forwarded Message -- Craig Labovitz labovit(a)merit.edu Merit Network, Inc. (313) 764-0252 (office) 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) Ann Arbor, MI 48105-2785

1 0