- Test - lists.nanog.org

INCOMING: IP Provider Metrics
by Matt Mathis 15 Mar '95

15 Mar '95

Attached is my initial cut at an agenda and some introductory discussion for the upcoming IP Provider Metrics BOF at Danvers. I plan to circulate this to the main IETF list on Friday. Even though I am going to work hard to prevent it, this is likely to become quite political. My intent is to provide tools and methods (standard procedures) which will enable the market to reward providers who are true to their mission, what ever that may be. Although my historical point of view has always been in the operations community, I have clearly become "just a customer". Furthermore, there is a large pool of "experts" who think that they can do the job better than you. Therefor, it is crucial that current providers take an active role in this effort, if nothing else to offset the "experts". Comments are welcome. Thanks, --MM-- Draft agenda of the "IP Provider Metrics" BOF 6:00 - 11:30 Wednesday, April 5, 1995 ============================================= Consider a possible WG. (15 minutes at opening) * - Is a new WG needed? * - Relationship to BMWG/GISD/others - Inventory of possible tasks - Requirements for IP Provider Metrics * - Define scope and priorities * - Chair issues, Editor/secretary * - Charter (* introduce at the open, but postpone detailed discussion until the close) General Requirements for IP provider metrics (15 min) IP bulk data transfer performance (technical issues, 30 min) IP routing stability and robustness (technical issues, 30 min) Consider a possible WG...., part 2 (30 min) ---------------- Rough Draft Charter IP Provider Metrics (IPPM) The IPPM WG will develop a set of standard metrics that can be applied to the the quality, performance and reliability of an IP datagram service. These metrics will be designed such that they can be performed by the providers themselves, customers, potential customers or independent testing groups. The areas covered will include: I) Path Performance A) Bulk data transfer performance (ftp, etc) B) Interactive performance (Telnet, X11, etc) C) Real-time and multicast performance (delay statistics) II) Routing stability and robustness A) End to end availability B) Time to recover (e.g. switch to backup paths) C) Route stability (Spurious route transitions, etc) III) others TBD The IPPM WG will select or adapt existing tools and develop standard procedures for performing and documenting the measurements. ---------------- Notes on the Charter o Services peripheral to basic IP, such as NOC/NIS services, DNS, etc. are expressly excluded because there is vehement anti-consensus among Internet providers. Prior efforts to standardize these areas have failed because they impinge on the different business models held by the providers. For example some providers include full, high quality DNS service bundled with their IP service. Others provide inexpensive DNS "starter" services, but expect most customers to eventually run their own servers. o It is also important that the language not be pejorative, to permit providers to strategicly balance their price and performance. We want to encourage all market positions including "Inexpensive, good enough service" as well as "The best possible service". o The milestones will be weighted to address I.A. (bulk performance) and possibly parts of II first. The other goals will be addressed as an ongoing effort. The scope will start very narrow, and will be extended only as we have assured closure on the initial tasks. o I have a prototype bulk transfer diagnostic that can safely and accurately measure IP bulk performance. It is a combination of traceroute and Reno TCP, and can provide traceroute like path information under exactly the conditions induced by TCP. See the discussion below. o The difficulty with routing stability metrics, is that the best ones require collusion with the Internet providers themselves. This clashes with the provider-to-provider trust model that is a necessary for healthy operation of the Internet as a whole. BGP can easily be used to collect engineering, business and other data on competitors. I believe that there exists a good technological solution based on the global collection and archiving of sanitized BGP logs. Clearly, there is a substantial piece of this technology that belongs with the RA and other global routing agents. However, there are also parts that belong to the community in the form of a working group. There needs to be a discussion of the possible role for IPPM in this process. o The IETF is not "poised" to address "standard measurement procedures". Is this a problem? o The final draft of the charter should be completed after the WG is convened. o IPPM should have an editor other than the chair. ---------------- Comments on the bulk performance tool: I am working on a prototype diagnostic tool ("treno") designed to address bulk performance issues. It is derived from Windowed ping (Matt Mathis, INET'94, See ftp://ftp.psc.edu/pub/net_tools/WPing.ps) but designed to be safe for typical network administrators at user sites. It uses traceroute to emulate Reno TCP over any IP infrastructure. This approach has a number of strong advantages: - Its bandwidth consumption is bound by the same congestion mechanism as TCP. (Although this is more than might be tolerated for ongoing monitoring). - It measures the network under the same queue dynamics as inflicted by TCP. - Differences in the end systems need not affect the results. - Today it can identify the lowest performance provider in a long path if there is a suitable unix box near each interconnect. - Someday it will be able to diagnose (to a specific hop) any path across the Internet. Treno is not yet completed. There are some open issues which can best be addressed as part of an IETF WG, with open and public input from all interested parties. In the end this will make it a stronger tool for supporting the growth of the Internet. Incomplete Tasks: - Certify that treno emulates Idealized Reno TCP. Understand and evaluate the implications of differences between treno and Reno as it appears in the field. (IPPM and end2end research community) - Develop testing methodology for "data sheet" measurements: How to select and specify endpoints, sampling schedule, etc for measuremets to be used on a "data sheet" or service level language in a contract. (IPPM and the network operators community) - Document the need and utility for all router vendors to support full rate ICMP TTL exceeded messages. (IPPM and RREQ?)

1 0

First ENSS retired
by Elise Gerich 14 Mar '95

14 Mar '95

The first router of the NSFNET backbone service has been retired. ENSS 138 (in Atlanta, Georgia) was retired on March 11, 1995. It was a pleasure working with Georgia Tech and SURAnet to provide connectivity to the NSFNET Backbone for that part of the US. One down. --Elise

2 2

Rescheduled configuration window
by epg＠merit.edu 14 Mar '95

14 Mar '95

This morning at about 03:00 EST, Merit discovered that many of the configuration files which were to be distributed to the NSFNET Backbone were incorrect. There was insufficient time to regenerate all the files and propogate them throughout the backbone in time for the Tuesday morning configuration window. The configuration window was postponed until Wednesday morning. Unfortunately, we neglected to notify the broader community about this problem, so many folks have been worried about what happened to their configuration changes or additions. The new configuration files will be deployed Wednesday morning. --Elise

1 0

Re: IP provider performance measurement BOF
by Henry Clark 14 Mar '95

14 Mar '95

>> A first step of talking about the issues and how to do this (NSP performance) >> seems like a good idea to me. > >Mind, this was tried several times before with limited success. >We do, however, need updates to RFC 1291. Vikas's efforts live on in GISD. Developing new and different ways of measuring Internet performance is always a win, when said method tells us and the consumer something useful. Developing a sales checklist for ISPs is probably not the mission of the IETF. >We might also want to >look at the OP-STAT WG efforts that Henry Clark and Nevell have >been working on. Note that what we're doing is *COMPLETELY* unrelated to 1291 or GISD. Seen that hole and have successfully driven around it :-). henry

4 3

Re: IISP Congress (fwd)
by epg＠merit.edu 14 Mar '95

14 Mar '95

Well, the results are in. Folks pointed out several conflicts with the proposed meeting dates of April 10-12: Internet Spring ATM Forum Coalition for Network Information. So we are proposing alternate dates and location. Merit is able to host the meeting in Ann Arbor, Michigan any of the following dates: May 8-9 May 11-12 May 22-23 May 25-26 (preceeding Memorial Day Weekend) Please let me know of any conflicts which may occur with those proposed dates and which of the dates seem most likely. When you respond, please rank your first and second choices. Thanks. --Elise -------------------------------forwarded mail------------ From: Elise Gerich <epg(a)merit.edu> Message-Id: <199502222300.SAA12080(a)home.merit.edu> Subject: IISP Congress (fwd) To: nanog(a)merit.edu Date: Wed, 22 Feb 1995 18:00:21 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7201 Status: RO At the NANOG meeting in Boulder, we decided to discuss the date and location of the next meeting on line. Enclosed is the announcment of the IISP which has offered to host the next NANOG meeting in San Diego on April 10, 1995. Please send email to the list indicating whether this would be a good date for the next meeting, and if you would consider attending then. If this is not a good time/place, please make recommendations to the list or to me privately as to an alternate date/place. Thanks. --Elise > > ----- Begin Included Message ----- > > >From @snoopy.isoc.org:amr@linus.isoc.org Wed Feb 22 10:20:18 1995 > Date: Wed, 22 Feb 1995 13:11:23 -0500 > To: isoc-trustees(a)linus.isoc.org, isoc-advisory-council(a)linus.isoc.org > From: Tony Rutkowski <amr(a)linus.isoc.org> > Subject: IISP Congress > Cc: ops-exec(a)linus.isoc.org > > ======================================================================= > 22 Feb 1994 > > INTERNATIONAL CONGRESS OF INTERNET SERVICE PROVIDERS > San Diego CA USA 11-12 Apr 1995 > ANNOUNCEMENT > > This worldwide congress is being jointly hosted by the Internet Society, > the Commercial Internet Exchange (CIX), and FARNET, Inc., in cooperation > with other organizations to allow Internet Service Providers and Network > Information Center administrators to identify and explore shared problems > and a broad range of alternatives in Internet provisioning and administration. > For the purposes of this congress, a service provider is regarded as any > entity that itself has an Internet transport capability which it provides > to others. > > The objective of the congress is to promote a discussion framework for future > meetings and activities that may occur among the interested parties, as well > as some initial convergences on major issues. It is not intended to displace > existing operations engineering forums. > > The congress is proceeding via its programme committee to focus on key topic > areas, earmarking individuals to develop both an overview of the area, as well > as range of views on possible alternatives. Discussants and rapporteurs will > be named for each session, and conference report will be widely available. > This report is expected to constitute a continuing and growing set of materials > to assure the continued global scaling, universal connectivity, and effective > operation of the Internet. > > In light of the importance of this congress, the complexity of the issues, > and the need for a robust exchange of views, the aim is to strongly > encourage one key policy and one key technical attendee from each provider > or NIC organization. Space constraints may limit the number of participants. > > The congress co-chairs are Scott Bradner (Internet Society and Harvard), Bob > Collet (Commercial Internet Exchange and Sprint), and Jim Williams (FARNet). > > The congress home page is: http://www.isoc.org/iisp/iisp-home.html > and will provide continually updated information on the congress. > > ------------------------------------------------------------------------- > Registration Template > > Organization: ___________________________ > > > Internet Service Provider: __ Yes __ No > Network Administrative Center (e.g., NIC): __ Yes __ No > Other (type ______________): __ Yes __ No > > > Provider policy rep > --------------------- > > Family Name: ___________________________ > > First Name: ___________________________ > > Title: ___________________________ > > Street Address: ___________________________ > > ___________________________ > > City: ___________________________ > > State or Province: _________ > > Postal Code: _________ > > Country: ________________________ > > Email: ___________________________ > > Fax: ___________________________ > > Telephone: ___________________________ > > Preferred Badge Name: _______________________________ > > > Service provider technical rep > ------------------------ > > Family Name: ___________________________ > > First Name: ___________________________ > > Title: ___________________________ > > Street Address: ___________________________ > > ___________________________ > > City: ___________________________ > > State or Province: _________ > > Postal Code: _________ > > Country: ________________________ > > Email: ___________________________ > > Fax: ___________________________ > > Telephone: ___________________________ > > Preferred Badge Name: _______________________________ > > ----------------------------------------------------------------------- > > REGISTRATION FEES > > The registration fee for an organization is US$ 600. This fee covers two > attendees from the organization. The aim is to have one policy and one > technical attendee. > > The registration fee for additional person from an organization is > US$ 600 EACH. A registration form for an additional person will be sent > upon request. > > How would you like to pay? > > __ Credit card: > > __ Mastercard > __ Visa > __ American Express > > Credit Card Number: _____________________ > Expiration Date: _____________________ > Name on Card: _____________________ > > Do we have your authorization to charge the indicated total > against your card number? (Type YES or Sign) > > ____________________ > > __ Bank Transfer: > > Send to: Riggs Bank of Virginia Bank ABA no. 056001260 > 8315 Lee Highway Account: Internet Society 148-387-10 > Fairfax VA 22031 > USA > > Please indicate your family name, IIOC, and your organization > > __ Money Order or Personal Cheque. > > > ----------------------------------------------------------------------- > > SEND THIS COMPLETED TEMPLATE TO: <ops-register(a)linus.isoc.org> or > > FAX THIS COMPLETED TEMPLATE TO: +1 703 648 9887 > > POST THIS COMPLETED TEMPLATE TO: Internet Society > 12020 Sunrise Valley Dr. Suite 270 > Reston VA 22091 > USA > > ----------------------------------------------------------------------- > > Hotel Registration > ------------------ > Sheraton Harbor Island > 1380 Harbor Island Drive > San Diego CA 92101 > USA > > 1. Contact the hotel registration directly using their reservation line: > +1 619 692-2265 or fax: +1 619 692-2363 > 2. Indicate you are attending the Internet Society International Conference > on Internet Operations. > 3. Single or double occupancy rooms are $130 per night. > 4. Most popular forms of payment are accepted for reservations. > > Space is limited for this conference. Register soon. > > Thank you. > > ======================================================================= > > > > > ----- End Included Message ----- > >

2 1

Is there a Web site for CERT advisories?
by wolf＠beowulf.ho.att.com 14 Mar '95

14 Mar '95

Is there an "official" (or even unofficial but maintained) site for CERT alerts/advisories? I tried to keep a list on my Web server for local users - but it was always hopelessly out-of-date. Thnx for any URLs. tom -- +------------------------------------------+ | Thomas Wolf | (908) 949-6283 |...Still can't think of anything | Bell Labs, NJ | wolf(a)honshu.ho.att.com | original to put in my sig... | HO 2M-203 | wolf(a)beowulf.ho.att.com |...So this valuable real-estate +------------------------------------------+ is for sale... Disclaimer: These are my opinions and not necessarily those of my employer.

1 0

Additions to the NSFNET policy-based routing database
by smm＠twain.merit.edu 13 Mar '95

13 Mar '95

------------------------------------------------------------------------------ The PRDB and this "NWG report" will be retired very soon. Details below. ------------------------------------------------------------------------------ The following changes have been made to the NSFNET policy-based routing database and will be installed on the backbone by 08:00 EST : Total = As + Bs + Cs + Aggs Registered Networks 49153 = 30 5328 40691 3104 Configured Networks 46240 = 30 5271 37899 3040 Added Networks 135 = 0 7 71 57 Deleted Networks 7 = 0 1 6 0 IP address Net name Country Priority:AS ---------- -------- ------- ----------- 132.107/16 NG-CONC3 C:US 1:568(145) 133.33/16 USIZ-KEN-NET C:JP 1:1239(144) 2:1800 3:1239(218) 147.181/16 MIN-VROM C:NL 1:1128 2:1800 3:1133 4:1674 5:1240 168.215/16 TWCOM-COM C:US 1:2551(136) 2:1321 170.77/16 DANBURY-HOSP C:US 1:2551(136) 2:1321 170.108/16 AMH-TOR C:US 1:2551(136) 2:1321 170.147/16 ICG C:US 1:2551(136) 2:1321 192.11.35/24 3D-NET2 C:US 1:2149 2:174 3:1239 4:1800 5:1240 192.47.180/22 TOHOKU-INET C:JP 1:297(144) 2:297(145) 192.50.14/23 KARRN C:JP 1:297(144) 2:297(145) 192.50.192/23 KJNET C:JP 1:297(144) 2:297(145) 192.51.208/20 JERNET C:JP 1:297(144) 2:297(145) 192.58.216/24 LIAS1 C:US 1:2551(136) 2:1321 192.65.196/24 CERN-DEMOS C:CH 1:1133 2:1674 3:1800 4:1240 192.104.107/24 TEAM-NETS C:US 1:1800 2:1239(144) 3:1239(218) 4:1323 192.104.108/24 TEAM-NETS C:US 1:1800 2:1239(144) 3:1239(218) 4:1323 192.104.109/24 TEAM-NETS C:US 1:1800 2:1239(144) 3:1239(218) 4:1323 192.104.110/24 TEAM-NETS C:US 1:1800 2:1239(144) 3:1239(218) 4:1323 192.112.66/24 NET-NATURE C:US 1:2548 192.190.97/24 SVGL-COM C:US 1:2551(136) 2:1321 192.206.89/24 LEARJET3 C:US 1:93 192.234.26/24 RANDMEDIA C:US 1:2551(136) 2:1321 193.56.40/24 FR-AERO-SU C:FR 1:701(136) 2:701(134) 3:1800 193.81.122/23 EINSPLUS-NET C:AT 1:701(136) 2:701(134) 3:1800 193.81.225/24 RIZ-NET C:AT 1:701(136) 2:701(134) 3:1800 193.92.142/23 GR-ZZ-193-92 C:GR 1:1800 2:1133 3:1240 193.92.184/21 EOMMEX C:GR 1:1800 2:1133 3:1240 193.104.55/24 FR-EU-ADE C:FR 1:701(136) 2:701(134) 3:1800 193.104.85/24 FR-EU-ATRIA C:FR 1:701(136) 2:701(134) 3:1800 193.114.45/24 UNI.US C:US 1:1333 193.252.249/24 FR-FTDG C:FR 1:1800 2:1240 3:1133 4:1674 194.5.49/24 FR-GRAME C:FR 1:1133 2:1674 3:1800 4:1240 194.12.128/18 CERN-BLK1 C:CH 1:1133 2:1674 3:1800 4:1240 194.20.32/24 NET-VOL C:IT 1:1800 2:1239(218) 3:1239(144) 194.53.224/19 KEMANET C:NL 1:1128 2:1800 3:1133 4:1674 5:1240 194.58.190/24 MUCTR C:RU 1:701(136) 2:701(134) 3:1800 194.58.191/24 MUCTR C:RU 1:701(136) 2:701(134) 3:1800 194.58.234/24 CRIMEAN-INKO C:UA 1:701(136) 2:701(134) 3:1800 194.62.24/22 SCOTHOMES-AGGR C:GB 1:1800 2:1133 3:1239(144) 4:3561(218) 5:3561(11) 194.85.32/20 RUNNET-BLOCK-1 C:RU 1:1800 2:1240 198.79.128/23 LSU-EUNICE C:US 1:3561(218) 2:3561(11) 4:86 198.83.40/24 MCGRAW-NETS C:US 1:1324(36) 2:1324(32) 198.83.55/24 QVC-NET1 C:US 1:1324(35) 2:1324(32) 198.99.123/24 NET-HANSEN C:US 1:2551(136) 2:1321 198.114.174/24 IDX-174 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 198.114.175/24 IDX-175 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 198.178.254/24 NET-CO-ACADEMY C:US 1:2551(136) 2:1321 198.201.5/24 TAMC-NET2 C:US 1:568(144) 198.235.53/24 NET-SOLECT53 C:CA 1:1240 2:1800 3:1239 199.5.138/23 NDLINK C:US 1:701(136) 2:701(134) 199.5.140/24 NDLINK C:US 1:701(136) 2:701(134) 199.94.216/24 BBN-216 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 199.114.102/24 NETBLK-GCC C:US 1:568(145) 199.123.81/24 DVISCH-NET2 C:US 1:568(145) 199.123.82/24 ALEXANDRIA-NET8 C:US 1:568(145) 199.164.228/24 SYNAPTEK C:US 1:701(136) 2:701(134) 199.165.156/24 BSP C:US 1:2551(136) 2:1321 199.184.118/24 QUADREP C:US 1:2551(136) 2:1321 199.221.108/24 JWAC-NET1 C:US 1:1327 199.222.6/24 IBMVT-NET1 C:US 1:1326 199.244.180/22 NETBLK-SVG100 C:US 1:2551(136) 2:1321 199.244.184/24 NETBLK-SVG100 C:US 1:2551(136) 2:1321 199.249.160/24 BCSNET C:US 1:701(136) 2:701(134) 202.11.12/22 ORIENT C:JP 1:297(144) 2:297(145) 202.11.156/22 STCNET C:JP 1:297(144) 2:297(145) 202.11.184/23 KWUNET C:JP 1:297(144) 2:297(145) 202.12.127/24 NET-ASSTDC C:AU 1:297(144) 2:297(145) 202.13.4/23 TUFSNET C:JP 1:297(144) 2:297(145) 202.13.62/23 TECNOVA C:JP 1:297(144) 2:297(145) 202.16.120/23 NMS-IS C:JP 1:297(144) 2:297(145) 202.17.180/23 IEICE-NET C:JP 1:297(144) 2:297(145) 202.18.152/22 KCT-NET C:JP 1:297(144) 2:297(145) 202.19.40/22 TJKNET C:JP 1:297(144) 2:297(145) 202.19.96/22 YMU-NET C:JP 1:297(144) 2:297(145) 202.24.92/22 KIRI-NET C:JP 1:297(144) 2:297(145) 202.24.140/22 KUNET C:JP 1:297(144) 2:297(145) 202.24.248/22 TAKANCTNET C:JP 1:297(144) 2:297(145) 202.25.164/22 SRL-NET C:JP 1:297(144) 2:297(145) 202.25.254/24 TTCNET C:JP 1:1239(144) 2:1800 3:1239(218) 202.26.140/22 OSAKA-GU-NET C:JP 1:297(144) 2:297(145) 202.26.186/24 NBP-PLANNING C:JP 1:701(136) 2:701(134) 3:1800 4:1239 5:1240 202.26.250/23 NUENET C:JP 1:297(144) 2:297(145) 202.30.64/19 KOSINET C:KR 1:297(144) 2:297(145) 202.240.226/24 CONGNET C:JP 1:297(144) 2:297(145) 202.240.227/24 SP-NET C:JP 1:1239(144) 2:1800 3:1239(218) 202.242.55/24 JWCPE-NET C:JP 1:297(144) 2:297(145) 202.242.80/24 SUNET C:JP 1:297(144) 2:297(145) 202.244.40/21 NET-NTTPC C:JP 1:1800 2:1239(218) 3:1239(144) 202.244.112/20 SHIKOKU C:JP 1:297(144) 2:297(145) 202.250.156/23 TAKACHIHONET C:JP 1:297(144) 2:297(145) 202.250.176/22 KNCT-NET C:JP 1:297(144) 2:297(145) 202.250.224/22 YGU-NET C:JP 1:297(144) 2:297(145) 202.251.172/23 TMCTNET C:JP 1:297(144) 2:297(145) 202.252.116/22 SUZUNET C:JP 1:297(144) 2:297(145) 202.252.250/23 ORIENT C:JP 1:297(144) 2:297(145) 202.253.88/22 OITA-MED C:JP 1:297(144) 2:297(145) 202.253.224/20 KAEDE-NET C:JP 1:297(144) 2:297(145) 202.253.252/23 TOYAKU-NET C:JP 1:297(144) 2:297(145) 202.254.132/23 WIDE C:JP 1:297(144) 2:297(145) 202.255.8/22 CHIBA-KC-NET C:JP 1:297(144) 2:297(145) 202.255.40/22 MSANET C:JP 1:297(144) 2:297(145) 202.255.244/22 OKNET C:JP 1:297(144) 2:297(145) 203.254.79/24 ICCNET1 C:KR 1:297(144) 2:297(145) 203.254.81/24 KPCNET1 C:KR 1:297(144) 2:297(145) 203.254.83/24 KPCNET2 C:KR 1:297(144) 2:297(145) 204.19.135/24 CEANET C:CA 1:1324(36) 2:1324(32) 3:2493(35) 4:2493(91) 204.80.239/24 KISNET-1 C:US 1:701(136) 2:701(134) 204.87.171/24 NET-MDX C:US 1:1332 204.90.102/24 DSM1 C:US 1:2551(136) 2:1321 204.97.251/24 NET-ELRONET C:US 1:1239 2:1800 3:1240 204.126.174/23 NETSOFT C:US 1:1740(218) 2:1740(135) 204.145.233/24 BEYOND2000 C:US 1:2551(136) 2:1321 204.165.154/24 SALSEM-154 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 204.165.190/24 BOSFIN-190 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 204.168.139/24 NET-RIA C:US 1:1239(218) 2:1800 3:1239(144) 204.168.157/24 NET-STRATASYS C:US 1:1239 2:1800 3:1240 204.187.141/24 UNIQUEST-1 C:CA 1:2493(35) 2:2493(91) 204.187.142/24 UNIQUEST-1 C:CA 1:2493(35) 2:2493(91) 204.187.143/24 UNIQUEST-1 C:CA 1:2493(35) 2:2493(91) 204.193.128/19 B3NET-EC C:US 1:690 204.214.143/24 NET-OLIGOS C:US 1:1800 2:1239(218) 3:1239(144) 204.215.214/24 NET-INTERNET C:VE 1:1800 2:1239(218) 3:1239(144) 204.235.80/20 IOS-1 C:US 1:4136 204.238.35/24 CEROS.EDU C:US 1:3381 204.239.244/24 NCP.BC.CA C:CA 1:1331 204.248.37/24 NET-US1CONX C:US 1:1239(218) 2:1800 3:1239(144) 204.249.12/22 NET-COMPASSWARE C:US 1:1239(218) 2:1800 3:1240(144) 204.250.15/24 NET-HPSTARLINK C:US 1:1239(144) 2:1800 3:1239(218) 204.253.64/20 JTM C:US 1:701(136) 2:701(134) 204.253.116/22 NDLINK C:US 1:701(136) 2:701(134) 205.160/15 SL-EAST C:US 1:1239(218) 2:1800 3:1239(144) 205.160.12/22 MRJ-INC C:US 1:1800 2:1239(218) 3:1239(144) 205.160.16/20 NET-RANDOMC C:US 1:1800 2:1239(218) 3:1239(144) 205.160.32/22 NET-SIMSCI C:US 1:1800 2:1239(218) 3:1239(144) 205.162/15 SL-WEST C:US 1:1239(218) 2:1800 3:1239(144) Deletions: --133.107/16 HSK-NET C:JP 1:297(144) 2:372 3:297(145) --192.50.36/24 WIDE-EXP-NET C:JP 1:297(144) 2:372 3:297(145) --192.50.43/24 WIDE-EXP-NET2 C:JP 1:297(144) 2:372 3:297(145) --192.50.44/24 WIDE-MOBILE1 C:JP 1:297(144) 2:372 3:297(145) --192.50.45/24 WIDE-MOBILE2 C:JP 1:297(144) 2:372 3:297(145) --192.50.62/24 WIDE-ISDN C:JP 1:297(144) 2:372 3:297(145) --192.218.228/24 WIDE-SAT-NET2 C:JP 1:297(144) 2:372 3:297(145) Expanded listing, sorted by country, then by organization: ========================================================== The "Expanded Listings" section of this NWG report has been retired since it is sorted by countries and network organization addresses. The replacement configuration generation system is based on the Internet Routing Registry (briefly called the "Global Routing Registry"). See the file ftp.ra.net:pub/radb/OVERVIEW for more information. The remainder of this report will also be retired shortly. ========================================================== The following Midlevel/Regional peering sessions have also been added: AS 1325 - ANS Cleveland - DNSS 43 (US) - CNSS 40 Peer: 140.222.40.198 - ANS - cnss46.t3.ans.net AS690 CIDR Squeezings Report: 10177 Nets, 181 ASs, 3061 Aggregates ------------------------------------------------------------------- 10177 (76%) of the ever-announced more-specific routes within aggregates have been withdrawn. 322 of those were withdrawn within the last week. 379 the week before that. 163 the week before that. 181 ASs have registered aggregates in the PRDB. 160 of those are announcing aggregates. 89 have withdrawn at least one more specific route. 3061 Aggregates are configured. 2056 of these were Top-Level Aggregates (not nested in another aggregate). 1597 of these are being announced to AS690. 1008 of those have at least one subnet configured (the other 589 may be saving the Internet future subnet announcements). 865 have stopped announcing at least one configured more specific route. 826 have stopped announcing half of their configured more specific routes. 787 have stopped announcing most (80%) of their more specific routes. See home.merit.edu:pub/nsfnet/cidr/cidr_savings for more detail. ----------------------------------------------------------- ========================================================== The configuration reports which reflect today's update will be available for anonymous ftp on nic.merit.edu by 08:00 EST : configuration reports -- nic.merit.edu:nsfnet/announced.networks: as-as.now as-gw.now ans_core.now country.now net-comp.now nets.doc nets.non-classful nets.tag.now nets.unl.now NSS routing software configuration files -- nic.merit.edu:nsfnet/backbone.configuration: gated.nss<NSS number>.t3p Information is also avaiable through the PRDB whois server. Type "whois -h prdb.merit.edu help" for details. -------------------------------------------------------------------------- PRDB CHANGES: (Updated January 19, 1994) As of 1/19/95, ACKs and NAKs will no loger be required (or even read) in the processing of NACRs. In early 1995, as part of the transition to the new Internet Routing Registry (IRR), the Policy Routing Database (PRDB) will be retired. Many of the functions of the PRDB (including generation of router configurations for NSFNET) will be produced based on data from the Global Routing Registry. This change to the NSFNET Backbone service will involve the following changes: - The method for submitting new nets to be routed over AS690 will change. Instead of submitting a NACR to nsfnet-admin(a)merit.edu, you will need to submit a "route template" to auto-dbm(a)ra.net . - Additions and entries to the new registry will be made by the Home AS which creates the route for each net, rather than being submitted by a AS690 peer AS. - Most of the PRDB reports (listed above) will no longer be produced. Equivalent information for most of these reports is available from the global Routing Registry. These are major changes to the system. These changes are being made in order to migrate NSFNET customers and the global user community to a global Internet Routing Registry system, which will be more capable of supporting user needs after the termination of the NSFNET Backbone services in April 1995. For more information, set your web browser to http://www.ra.net/rrinfo.html , or use anonymous ftp to obtain the files "OVERVIEW" and from the directory "ftp.ra.net:pub/radb". Merit would like to minimize the number of problems that this transition may cause you. In order to help us help you through the transition, please send your concerns, your needs, and suggestions on how we can make this happen smoothly to merit-ie(a)merit.edu. The archived discussion list "db-disc(a)merit.edu" also exists for discussion of PRDB and RADB issues. Send a message to "db-disc-request(a)merit.edu" to subscribe. --Dale Johnson (dsj(a)merit.edu) -------------------------------------------------------------------------- Please send all requests for configuration changes to nsfnet-admin(a)merit.edu using the NSFNET configuration forms. The forms are available on-line from the nic.merit.edu machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfnet/announced.networks" and get the files template.net, template.net.README, template.gate, and template.as. *** Note: As of March 1, 1994, NSFNET AUP NACRs must use the template.net *** (NACR) version 7.1, or the NACR will be returned unprocessed. ******************************* --Stephen McNutt Merit/NSFNET smm(a)merit.edu --Steven J. Richardson Merit/NSFNET sjr(a)merit.edu

1 0