- Test - lists.nanog.org

NSF Solicitation for High Performance International Internet Services
by Steve Goldstein 20 May '97

20 May '97

"HIGH PERFORMANCE INTERNATIONAL INTERNET SERVICES "Solicitation NSF97-106 "I. Purpose "The U.S. National Science Foundation (NSF) seeks to assist the U.S. research and education community (R&E) in meeting its needs for next generation international Internet services. The goal is to provide the basis for the development of next generation applications supporting international collaborations and enabling interaction with global information and experimental resources. To this end, NSF solicits proposals for high-performance International Internet Services (HPIIS). " For those who might be interested, read/get it at http://www.cise.nsf.gov/ncri/nsf97-106.html. --Steve G. ---------------------------------------------------------------- Steven N. Goldstein, Ph.D. Program Director, International Networking Coordination Div. of Networking and Communications Research & Infrastructure National Science Foundation 4201 Wilson Boulevard, Room 1175 Arlington, VA 22230 USA Tel: +1-703-306-1949 (Extension 1119) FAX: +1-703-306-0621 sgoldste(a)NSF.GOV http://www.cise.nsf.gov/ncri/Stevehome.html ------- end of forwarded message -------

1 0

NSF Solicitation for High Performance International Internet Services
by Steve Goldstein 20 May '97

20 May '97

"HIGH PERFORMANCE INTERNATIONAL INTERNET SERVICES "Solicitation NSF97-106 "I. Purpose "The U.S. National Science Foundation (NSF) seeks to assist the U.S. research and education community (R&E) in meeting its needs for next generation international Internet services. The goal is to provide the basis for the development of next generation applications supporting international collaborations and enabling interaction with global information and experimental resources. To this end, NSF solicits proposals for high-performance International Internet Services (HPIIS). " For those who might be interested, read/get it at http://www.cise.nsf.gov/ncri/nsf97-106.html. --Steve G. ---------------------------------------------------------------- Steven N. Goldstein, Ph.D. Program Director, International Networking Coordination Div. of Networking and Communications Research & Infrastructure National Science Foundation 4201 Wilson Boulevard, Room 1175 Arlington, VA 22230 USA Tel: +1-703-306-1949 (Extension 1119) FAX: +1-703-306-0621 sgoldste(a)NSF.GOV http://www.cise.nsf.gov/ncri/Stevehome.html

1 0

REGISTRATION/PAYMENT REMINDER
by Pam Ciesla 20 May '97

20 May '97

The cutoff date for registration & the $100 fee is May 28. After the 28th the fee goes up to $120, also cancelations after the 28th will be charged $20. If you are not sure of your payment status you can check the Attendee LIst on the web page. If I have received any payment info it will show paid after your name. NOTE: I have not yet run credit cards. Speakers, host & a few others are not charged the registration fee and are indicated on the list. If you have questions please e-mail or call me. This list is current as of this morning. Also please allow for humane error, mine :*) xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

trawhoisd beta testing
by Xin Liu 20 May '97

20 May '97

ftp://ftp.merit.edu/routing.arbiter/tools/trabeta.tar.gz It needs perl5.003. It works with RtConfig. ---------------------------Liu, Xin------------------------------ Merit Network, Inc Phone: (313)936-2115 (o) http://home.merit.edu/~xliu -----------------------------------------------------------------

1 0

MEETING INFO CORRECTION
by Pam Ciesla 19 May '97

19 May '97

The Nanog Meeting in Tampa at the Hyatt will be held in the Audubon Ballroom, section B thru F. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

Feb 1997 notes are almost complete
by sob＠academ.com 18 May '97

18 May '97

Finally, I have been able to get all the notes (except those concerning the Gigaswitch) on line. I have also been able to get a number of slides on-line, but I don't have all of them. I expect to get the Gigaswitch notes on line later this week. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Emergency backup for a small net
by Hank Nussbacher 18 May '97

18 May '97

At 09:04 AM 5/18/97 -0400, Bradley Dunn wrote: This brings up a problem I have been trying to solve for a while that I have not found an answer to. A company with an old style Class B (/16) wants to be multihomed and split their incoming load between 2 ISPs (outgoing they can live with going via 1 and if the primary fails they fallback to the secondary conenction). In order to split the load on incoming, one ISP has to announce a /17 and the other ISP has to announce a /17 (or even the entire /16). But since this net is from the 147.x.x.x range, various ISPs around the globe will filter out the /17. This means that having a /16 from the 192.x.x.x range is better (these days), unless someone can show me a solution. Thanks, Hank >Hi, > >We have a small ISP customer that wants to run a circuit to another local >ISP and the ISPs would use that pipe only in the case of primary link >failure. The two ISPs would split the cost, etc. > >The obvious solution would be for both ISPs to set up BGP peering with >their upstreams and not announce anything in normal operation. The >upstreams would continue to statically route the smaller ISPs' blocks and >the smaller ISPs would default to their upstreams. The smaller ISPs would >also put in a default pointing at each other with a higher cost. Then in >the case of primary link failure the ISP who still has a path to the net >would begin announcing the other ISP's block(s) to their upstream. The >upstream would in turn see this as a valid announcement and propagate it >to the world. Therefore specificity should draw all the traffic to the >correct place. > >The problem is both ISPs are small and have /24s from their providers. The >/24s would be filtered by many, leading to only partial connectivity in >the case of failure. (Partial connectivity is better than no connectivity, >I guess...) > >Another possible solution I thought of is to use NAT. The small ISPs would >use RFC1918 internally and use a block from their provider to translate >into. When the primary link fails they switch over to using a block from >the other ISP's provider. They would also have to use very low TTLs for >their DNS zones and be prepared to switch the DNS zones to point to the >other block. Does the NIC consider this efficient utilization >to have a block lying around that only gets used when a link fails? > >An important thing to remember here is that the backup link will not be >used in normal operation. This is not multihoming. They do not want load >balancing. > >I would be interested to hear others' thoughts on this. If you reply >privately I will summarize any interesting replies to the list. > >Thanks! > >pbd >-- >You can make it illegal, but you can't make it unpopular. > >

3 2

Mbone help
by Forrest W. Christian 17 May '97

17 May '97

I know that this is slightly off subject so I'll keep it short. Is there a kind person out there who would like to help me with some basic questions about getting a mbone feed set up so I can watch nanog? I have read the FAQ's and the like and I am still a little lost with the whole thing. I understand the basic concepts but putting that into action is a different thing. Thanks, forrestc(a)imach.com P.S. Reply by e-mail. No need wasting additional bandwidth :)

1 0

Re: Yesterdays Spam....
by Dave O'Shea 17 May '97

17 May '97

Curt Howland <howland(a)conxion.com> writes: >I could not imagine anyone stupid enough to spam the NANOG >mailing list, until I did a WHOIS on their return mail domain.... Our friend Sanford must be even less intelligent than I had originally thought. I'm tired of trying to block off one bogus site after another, so last night I denied AS4200 in our core routers. No complaints so far. Shame, though, that all of AGIS's customers have to suffer because of one bad apple.

2 1

Yesterdays Spam....
by Curt Howland 16 May '97

16 May '97

I could not imagine anyone stupid enough to spam the NANOG mailing list, until I did a WHOIS on their return mail domain.... Curt- >From owner-nanog(a)merit.edu Thu May 15 18:29:19 1997 Return-Path: <owner-nanog(a)merit.edu> Received: from merit.edu by asilomar.noc.conxion.net (8.6.12/SMI-4.1) id SAA00293; Thu, 15 May 1997 18:29:18 -0700 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA21968; Thu, 15 May 1997 21:16:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 15 May 1997 21:15:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA21944 for nanog-outgoing; Thu, 15 May 1997 21:15:52 -0400 (EDT) Received: from hydrogen.inbe.net (root(a)hydrogen.inbe.net [194.7.1.8]) by merit.edu (8.8.5/8.8.5) with ESMTP id VAA21940 for <nanog(a)merit.net>; Thu, 15 May 1997 21:15:48 -0400 (EDT) >From: a8(a)04194.com Received: from mail.innet.be (1Cust105.Max3.Las-Vegas.NV.MS.UU.NET [153.34.59.233]) by hydrogen.inbe.net (8.8.5/8.8.5) with SMTP id DAA19412; Fri, 16 May 1997 03:10:20 +0200 (MET DST) Date: Thu, 15 May 97 16:58:29 EST To: Friend(a)public.com Subject: New Message-ID: <> Sender: owner-nanog(a)merit.edu Content-Length: 1268 X-Lines: 45 Status: RO > > Below are just two examples of which may be of interest to you. > We honor all request for removal from our mailing list, BUT YOU > MUST type in REMOVE in the subject heading to be removed. > Reply to: a8(a)mary-world.com > System is automated ONLY! All subcribers to any of the following information > MUST type the Subject heading: Subscribe JPA2, or BC1. > > Thank You [snip]

1 0