- Test - lists.nanog.org

IOPS.ORG Press Release
by Kent W. England 20 May '97

20 May '97

Folks; Of interest to the ops community. Of course, many of you already know about this new organization of ISPs. I would give you a better URL, but there does not yet seem to be a web site http://www.iops.org or anything at CNRI. See: http://biz.yahoo.com/bw/97/05/20/bbn_y0007_1.html for the press release. Header paragraphs below. --Kent RESTON, Va.--(BUSINESS WIRE)--May 20, 1997-- Inter-ISP Group Will Work to Improve Operational Performance and Technical Integrity of the Internet Nine of the nation's major Internet service providers announced today the formation of IOPS.ORG, a group of Internet service providers (ISPs) dedicated to making the commercial Internet more robust and reliable. IOPS.ORG will focus primarily on resolving and preventing network integrity problems, addressing issues that require technical coordination and technical information-sharing across and among ISPs. These issues include joint problem resolution, technology assessment, and global Internet scaling and integrity. IOPS.ORG will provide a point-of-contact for these industry-wide technical issues. The founding members of IOPS.ORG are ANS Communications, AT&T, BBN Corporation, EarthLink Network, GTE, MCI, NETCOM, PSINet, and UUNET, and it is expected that additional national and international Internet operators will join. IOPS.ORG will work with other Internet organizations, with Internet equipment vendors, and with businesses that rely on the Internet. IOPS.ORG members individually will continue to support other Internet organizations such as the Internet Engineering Task Force (IETF), the North American Network Operators Group (NANOG), and the Internet Society. ...

1 0

routing dump / routing registry checks
by Curtis Villamizar 20 May '97

20 May '97

There is a new report at: http://figaro.ans.net/route-dumps/970520/overlap-summary.html Summary: There are 114 AS in which aggregates are registered and unregistered more specific prefixes announced but for which the aggregate is not announced. Some of these may be cases where the aggregate is not being formed due to a configuration error. There are 197 of these registered but unannounced aggregates. These aggregates overlapped 840 prefixes. There is an updated report on unregistered prefixes at: http://figaro.ans.net/route-dumps/970520/ These two reports used the May 9 routing dumps but use copies of the routing registries from May 19, reflecting changes made since May 9. The original reports are at: http://figaro.ans.net/route-dumps/ The main page has not been updated to reflect this third iteration. Curtis btw- This was previously announced to NANOG only. I'm not sure what distribution list is appropriate. Suggestions by private response please to avoid clogging the mailing lists.

1 0

Emergency backup for a small net
by Bradley Dunn 20 May '97

20 May '97

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.

5 6

Update on Feb 1997 notes
by sob＠academ.com 20 May '97

20 May '97

The Gigaswitch notes are now on-line. As some of you know, there was a scheduling snafu with my return flight from San Francisco and I was unable to stay for Paul Vixie's second talk or the closing comments from Bill Norton. If someone else has notes from either of these they are willing to share, please send them along to me and I will put them up on the notes page for the Feb 1997 meeting. Thanks in advance and my sincere apologies for Paul and Bill for not being able to take notes from their presentations. I have already taken steps to insure that I don't have this problem for the June meeting. For those of you in the US, have a good Memorial Day Holiday. -- 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: Root Nameserver Changes
by Peter Galbavy 20 May '97

20 May '97

On Tuesday, May 20, 1997 2:25 PM, Jim Fleming [SMTP:JimFleming@unety.net] wrote: > It would be good if the various continents had > their own Root Name Server Confederations. > If that were the case, traffic would not be shuttled > across the various oceans just to give the > illusion that there is operational redundancy. But does the fact that these packets cross continents imply less redundancy ? Given the number of transatlantic cables in place and the new ones on the way, I do not think it is reasonable to assume that (in this instance) that all of Europe will disappear at once ? > To add European root name servers to the > list that North American operators use does > not do them a service. Well, we Europeans have *suffered* because of the lack (all one of) non-North American root name servers. "You" did not seem so worried then (note the quotes around the word "you"). Distributing name servers is an operational issue, and given enough transit services to them, this is not really a redundancy problem, mearly political. Peter Galbavy Demon Internet Ltd http://www.demon.net/

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

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

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