- Test - lists.nanog.org

IP Provider Metrics (IPPM) WG/BOF
by Matt Mathis 30 Mar '95

30 Mar '95

A number of people missed this the first time. To: nanog(a)merit.edu Subject: INCOMING: IP Provider Metrics Date: Wed, 15 Mar 1995 11:53:01 -0500 From: "Matt Mathis" <mathis> [... out of date adminstrivia deleted ...] 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?) ------- End of Forwarded Message

1 0

ENSS 133 retired
by epg＠merit.edu 30 Mar '95

30 Mar '95

As of March 31, 1995, the NSFNET Backbone Service to NYSERnet, Cornell Theory Center, and PSI at Ithaca, NY (ENSS 133) will be retired. This termination of service means that there are two regional networks, SURAnet and NYSERnet, which are totally dependent on their new service providers, internetMCI and Sprintlink. In addition, the Cornell Theory Center is the first super- computer center to terminate its dependence on the NSFNET Backbone Service. Merit thanks NYSERnet, Cornell Theory Center, and PSI for their cooperation since 1988 and during the transition. --Elise

1 0

Mailing list for IPPM
by Matt Mathis 30 Mar '95

30 Mar '95

I would like to pre-load the IPPM mailing list with the NANOG list. (Note that the IPPM list is not really up yet.) I can: 1) Ask everyone to send mail to.... no - bad idea, out of the question. 2) Preload the IPPM list with a copy of the nanog list from Merit 3) Preload the IPPM list with the EXPN of nanog@merit 4) put the nanog list on the IPPM list. I believe that #2 is the best solution, failing that #3. Choices #1 and #4 are for last resort only. Does anybody have any objections to #2? I will send another note to NANOG when we are ready to accept individual membership requests. Let me get the preload done first.... Thanks, --MM--

1 0

Re: loose source route
by Chris Dorsey (510)422-4474 30 Mar '95

30 Mar '95

I agree with Matt, if a network turns off LSRR, then I try to hand them the ticket. However, it seems that lots of sites either yield no human response at all, or get back to you a few days later. Not very helpful in the face of intermittent problems. So you're the one holding the trouble ticket with no tools and no help. I've thought a little about this over the past few months as more sites shut off LSRR, and it seems like a "ping" or "traceroute" server-client would really come in handy. No human interaction needed, I just request a ping/trace from site A going from A to B. Has anyone explored this or is it a silly idea and I'm being dense. /chris Chris Dorsey ESnet dorsey(a)es.net

3 3

loose source route
by C. Philip Wood 30 Mar '95

30 Mar '95

On occasion, I use traceroute with the option that allows a different viewpoint (as in the IP loose source route option). Today, I tried to: traceroute -g 134.164.8.2 192.156.135.34 traceroute to 192.156.135.34 (192.156.135.34), 30 hops max, 40 byte packets 1 esnet-rt2 (192.16.1.244) 6 ms 4 ms 18 ms 2 lanl3-e-lanl1.es.net (134.55.20.139) 4 ms 4 ms 4 ms 3 llnl-e-llnl2.es.net (134.55.12.225) 40 ms 37 ms 56 ms 4 fix-west-cpe.SanFrancisco.mci.net (192.203.230.18) 53 ms 42 ms 52 ms 5 border3-hssi2-0.SanFrancisco.mci.net (204.70.34.9) 52 ms 49 ms 56 ms 6 core-fddi-0.SanFrancisco.mci.net (204.70.2.161) 55 ms 66 ms 55 ms 7 core-hssi-2.LosAngeles.mci.net (204.70.1.41) 55 ms 78 ms 64 ms 8 core-hssi-2.Houston.mci.net (204.70.1.33) 88 ms 87 ms 90 ms 9 core-hssi-2.Atlanta.mci.net (204.70.1.25) 105 ms 113 ms 110 ms 10 border1-fddi0-0.Atlanta.mci.net (204.70.2.50) 171 ms 119 ms 112 ms 11 suranet-cpe.Atlanta.mci.net (204.70.16.6) 121 ms 120 ms 111 ms 12 atu2-atu-cf.sura.net (192.221.42.2) 111 ms 142 ms 111 ms 13 jck1-atu2-c1.sura.net (128.167.2.2) 142 ms jck1-atu2-c3mb.sura.net (128.167.4.2) 143 ms jck1-atu2-c1.sura.net (128.167.2.2) 226 ms 14 wes-jck1-c1.sura.net (192.221.5.34) 176 ms !S I thought that it was still reasonable for service providers to allow that option while possibly denying it on an interface to a customers network. What's the ruling on that? Thanks, Phil

4 3

Routing flapping presentations at May meeting
by Susan R. Harris 28 Mar '95

28 Mar '95

Greetings - we're starting to plan the agenda for the May NANOG meeting. Would there be interest in presenting further results from the route flapping analyses some of you have been doing, to see what trends are emerging? Sean and Curtis gave reports at the February meeting; we'd be glad to hear from them again, and also are wondering if Andrew Partan, Mark Fedor, Jerry Crow, or Jack Waters might be interested in presenting any data. --Susan R. Harris

4 3

ENSS 136 retired
by Elise Gerich 28 Mar '95

28 Mar '95

As of March 22, 1995, the NSFNET Backbone Service to SURAnet at College Park, Maryland (ENSS 136) was retired. This node was also the interconnection point with MAE-East. All NSFNET service directly to the SURAnet regional was eliminated with the retirement of ENSS 136. SURAnet is the first regional to be totally dependent upon its new service provider. The NSFNET Backbone service will continue to have connectivity to MAE-East+ until April 30, 1995. --Elise

2 2

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

27 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 49957 = 30 5352 41298 3277 Configured Networks 47044 = 30 5295 38506 3213 Added Networks 226 = 0 8 148 70 Deleted Networks 3 = 0 0 1 2 IP address Net name Country Priority:AS ---------- -------- ------- ----------- 9.20.0/18 IBM C:GB 1:1849 3:701(134) 4:1800 132.220/16 NET-SOBECO-NET C:CA 1:701(147) 2:701(134) 137.72/16 NETCOMMAND C:US 1:3561(11) 2:3561(218) 3:200(128) 4:200(144) 137.118/16 MCS-PARK40-1 C:US 1:3407 2:1800 3:1240 164.60/16 SCHERING2 C:DE 1:701(147) 2:701(134) 3:1800 164.131/16 FR-DGLDT C:FR 1:1800 2:1240 3:1133 4:1674 164.166/16 NET-CALGARY-BD C:CA 1:1240 2:1800 3:1239 165.2.141/24 HOLIDAY-INN-WORLDWIDE C:US 1:3561(147) 2:3561(218) 4:3561(11) 5:3561(144) 165.2.142/24 HOLIDAY-INN-WORLDWIDE C:US 1:3561(147) 2:3561(218) 3:3561(27) 4:3561(11) 5:3561(144) 165.127/16 COGGCC-NET C:US 1:1239(144) 2:1800 3:1239(218) 4:209 5:210 168.189/16 CLOROX-B C:US 1:1239 2:1800 3:1240 192.67.208/24 HZD-NET C:DE 1:1800 2:1239(144) 3:1133 192.70.175/24 GGCC-NET C:US 1:1239(144) 2:1800 3:1239(218) 4:209 5:210 192.72.32/19 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.64/19 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.96/20 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.112/21 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.121/24 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.122/23 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.124/22 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.128/18 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.192/19 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.224/20 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.240/21 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.248/22 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.72.252/24 NET-HINET C:TW 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 192.107.118/24 NPI C:US 1:701(147) 2:701(134) 192.133.34/24 PDA C:US 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 192.133.254/24 SONOCO C:US 1:701(147) 2:701(134) 192.160.26/24 MARCSYS C:US 1:3830 2:1800 3:1240 192.207.43/24 WSI-1 C:US 1:2551(147) 2:1321 192.233.142/24 LOTUS-14 C:US 1:3561(218) 2:3561(11) 3:560 4:701(147) 5:701(134) 193.48.233/24 FR-DCN-ING1 C:FR 1:1800 2:1240 3:1133 4:1674 193.51.133/24 FR-CICT4 C:FR 1:1800 2:1240 3:1133 4:1674 193.51.255/24 FR-CYCERON C:FR 1:1800 2:1240 3:1133 4:1674 193.55.146/24 FR-NCY-ENSG C:FR 1:1800 2:1240 3:1133 4:1674 193.67.63/24 LS-DIGITAL C:NL 1:701(147) 2:701(134) 3:1800 193.105.9/24 FR-DCN83-SO2 C:FR 1:1800 2:1240 3:1133 4:1674 193.210.150/23 HEBELNET-1 C:CH 1:701(147) 2:701(134) 193.210.152/24 INFOBOARD-NET2 C:BE 1:701 193.210.153/24 INFOBOARD-NET2 C:BE 1:701 193.210.154/24 UNICALL-NET C:BE 1:701 193.210.155/24 UNICALL-NET C:BE 1:701 193.210.156/24 SKYNET C:BE 1:701 193.210.157/24 SKYNET C:BE 1:701 193.210.158/24 MENDEZ-NET C:BE 1:701 193.210.159/24 MENDEZ-NET C:BE 1:701 194.10.192/24 RIPE-CBLK2 C:NL 1:2685 2:701(147) 3:701(134) 4:3561(218) 5:3561(11) 194.10.193/24 RIPE-CBLK2 C:NL 1:2685 2:701(147) 3:701(134) 4:3561(218) 5:3561(11) 194.28.0/24 NET-TIZETA C:IT 1:1800 2:1239(218) 3:1239(144) 194.49.88/24 BMW-RR-NET C:DE 1:701(147) 2:701(134) 3:1800 194.49.89/24 BMW-RR-NET C:DE 1:701(147) 2:701(134) 3:1800 194.49.90/24 BMW-RR-NET C:DE 1:701(147) 2:701(134) 3:1800 194.49.91/24 BMW-RR-NET C:DE 1:701(147) 2:701(134) 3:1800 194.57.129/24 FR-DRCNRS C:FR 1:1800 2:1240 3:1133 4:1674 194.108.0/21 CESNET-B-AGGR C:CZ 1:1800 2:1133 3:1240 194.108.8/21 CESNET-A-AGGR C:CZ 1:1800 2:1133 3:1240 194.108.32/19 CESNET-A-AGGR C:CZ 1:1800 2:1133 3:1240 194.108.128/21 CESNET-B-AGGR C:CZ 1:1800 2:1133 3:1240 194.111.178/24 ARCADIS-NET C:BE 1:701 194.111.179/24 ARCADIS-NET C:BE 1:701 194.113.65/24 CTCNET C:DE 1:1800 2:1239(144) 3:1133 196.7.142/24 IAFRICA-NET1 C:ZA 1:701(147) 2:701(134) 3:3561(11) 4:3561(218) 5:1240 198.74.14/24 BUG-7 C:US 1:2149 2:174 198.81.193/24 IBMDFW C:US 1:701(147) 2:701(134) 198.83.138/24 ATUFDDI-NET C:US 1:1697 198.139.67/24 NTBLK-SARNOFF-C-139-6 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 198.139.68/24 NTBLK-SARNOFF-C-139-6 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 198.150.32/23 PERSOFT C:US 1:3561(218) 2:3561(11) 3:1225(130) 4:1225(131) 5:1225(129) 198.150.40/21 SCLS C:US 1:3561(218) 2:3561(11) 3:1225(130) 4:1225(131) 5:1225(129) 198.150.173/24 WN-DIAL-STURGEON C:US 1:3561(218) 2:3561(11) 3:1225(130) 4:1225(131) 5:1225(129) 198.150.175/24 DOORNET C:US 1:3561(218) 2:3561(11) 3:1225(130) 4:1225(131) 5:1225(129) 198.151.195/24 NET-CONCORS C:US 1:1332 198.164.250/24 NET-ITCHY250 C:CA 1:1240 2:1800 3:1239 198.164.251/24 NET-ITCHY251 C:CA 1:1240 2:1800 3:1239 198.164.252/24 NET-ITCHY252 C:CA 1:1240 2:1800 3:1239 198.164.253/24 NET-ITCHY253 C:CA 1:1240 2:1800 3:1239 198.165.242/24 NET-ITCHY242 C:CA 1:1240 2:1800 3:1239 198.165.243/24 NET-ITCHY243 C:CA 1:1240 2:1800 3:1239 199.3.180/24 BASENET.NET C:US 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 199.34.153/24 NETBLK-MICROAGE-CBLK C:US 1:2551(147) 2:1321 199.45.111/24 ITCA C:CA 1:701(147) 2:701(134) 199.120.108/24 NET-MARYCREST-3 C:US 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 5:1323 199.123.104/23 NETBLK-APPOC C:US 1:1800 2:1239(144) 3:1239(218) 4:210 199.123.104/24 HAITI-NET1 C:US 1:568(144) 2:568(145) 199.166.206/24 NET-ORBONLINE C:CA 1:701(147) 2:701(134) 199.166.211/24 NET-SILVERRUN C:CA 1:701(147) 2:701(134) 199.166.220/22 NETBLK-TERRAPORT C:CA 1:701(147) 2:701(134) 199.185.4/24 ITC3 C:CA 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 199.203.40/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.41/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.42/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.43/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.44/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.45/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.46/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.47/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.48/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.49/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.50/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.52/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.53/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.203.54/24 ELRON-C-BLK1 C:US 1:1324(32) 2:1324(35) 199.221.25/24 OKCU-NET3 C:US 1:1328 199.221.225/24 RRNET C:US 1:1323 199.233.127/24 SGA C:US 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 199.233.154/23 LASIERRA199 C:US 1:1740(218) 2:1740(135) 199.240.84/22 MID-SPRINT-TEST C:US 1:1239(144) 2:1800 3:1239(218) 4:3561(218) 5:93 200.9.216/24 NETBLK-FJ-ICL C:JM 1:1800 2:1239(144) 3:1239(218) 4:2386 5:1321 200.9.217/24 NETBLK-FJ-ICL C:JM 1:1800 2:1239(144) 3:1239(218) 4:2386 5:1321 200.9.218/24 NETBLK-FJ-ICL C:JM 1:1800 2:1239(144) 3:1239(218) 4:2386 5:1321 202.18.248/23 STAFFNET1 C:JP 1:297(144) 2:297(145) 3:1239 4:1240 202.146.0/23 NET-RAD C:ID 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 202.146.15/24 NET-RAD C:ID 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 202.154.0/24 RADNET-ID-C-154-0 C:ID : 202.154.1/24 RADNET-ID-C-154-1 C:ID : 202.154.2/24 RADNET-ID-C-154-2 C:ID : 202.154.3/24 RADNET-ID-C-154-3 C:ID : 202.154.4/24 RADNET-ID-C-154-4 C:ID : 202.154.5/24 RADNET-ID-C-154-5 C:ID : 202.154.6/24 RADNET-ID-C-154-6 C:ID : 202.154.7/24 RADNET-ID-C-154-7 C:ID : 202.154.8/24 RADNET-ID-C-154-8 C:ID : 202.154.9/24 RADNET-ID-C-154-9 C:ID : 202.154.10/24 RADNET-ID-C-154-10 C:ID : 202.154.11/24 RADNET-ID-C-154-11 C:ID : 202.154.12/24 RADNET-ID-C-154-12 C:ID : 202.154.13/24 RADNET-ID-C-154-13 C:ID : 202.154.14/24 RADNET-ID-C-154-14 C:ID : 202.154.15/24 RADNET-ID-C-154-15 C:ID : 202.243.160/24 NET-IAC C:JP 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 202.243.166/24 NET-IAC C:JP 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 202.251.0/19 CTIE-NET C:JP 1:701(147) 2:701(134) 3:1800 4:1239 5:1240 204.27.221/24 GLENHS-SD-1 C:US 1:1800 2:1239(144) 3:1239(218) 4:210 204.50.68/24 NET-EDIWISE C:CA 1:1240 2:1800 3:1239 204.52.135/24 HAL-PC C:US 1:3561(218) 2:3561(11) 3:114 204.58.216/22 FRS-FL-GOV C:US 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 204.69.157/24 NETBLK-AHM2 C:US 1:3561(11) 2:3561(218) 3:200(128) 4:200(144) 204.69.158/23 NETBLK-AHM2 C:US 1:3561(11) 2:3561(218) 3:200(128) 4:200(144) 204.69.160/23 NETBLK-AHM2 C:US 1:3561(11) 2:3561(218) 3:200(128) 4:200(144) 204.71.232/21 MCI-POP-AGG C:US 1:3561(147) 2:3561(218) 3:3561(27) 4:3561(11) 5:3561(144) 204.92.2/24 NET-MOORECORP C:CA 1:701(147) 2:701(134) 204.92.12/22 NET-TTS1-MKM C:CA 1:701(147) 2:701(134) 204.92.86/24 SHADS C:CA 1:701(147) 2:701(134) 204.92.95/24 CYBERPERK-NET C:CA 1:701(147) 2:701(134) 204.92.210/24 NET-IWH-NET C:CA 1:701(147) 2:701(134) 204.92.211/24 CONVOKE-NET C:CA 1:701(147) 2:701(134) 204.94.192/20 GALAXY.ORG C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 204.95.39/24 BASENET.NET C:US 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 204.96.133/24 NET-BRBA2 C:US 1:1240 2:1800 204.128.208/24 DIGINETINC C:US 1:3561(218) 2:3561(11) 3:114 204.140.32/19 DOE-YMP C:US 1:2551(147) 2:1321 204.142.148/24 MCCC16 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.149/24 MCCC17 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.150/24 MCCC18 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.151/24 MCCC19 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.152/24 MCCC20 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.153/24 MCCC21 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.154/24 MCCC22 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.155/24 MCCC23 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.156/24 MCCC24 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.157/24 MCCC25 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.158/24 MCCC26 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.159/24 MCCC27 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.160/24 MCCC28 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.161/24 MCCC29 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.162/24 MCCC30 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.142.163/24 MCCC31 C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 6:97 204.145.225/24 NET-PARANOIA C:US 1:3830 204.153.224/22 GLENHS-SD-2 C:US 1:1800 2:1239(144) 3:1239(218) 4:210 204.164.188/24 FRANKLIN-188 C:US 1:3561(218) 2:3561(11) 3:560 4:701(147) 5:701(134) 204.165.68/24 HARTFORD-68 C:US 1:3561(218) 2:3561(11) 3:560 4:701(147) 5:701(134) 204.165.69/24 HARTFORD-69 C:US 1:3561(218) 2:3561(11) 3:560 4:701(147) 5:701(134) 204.165.212/24 NESC-212 C:US 1:3561(218) 2:3561(11) 3:560 4:701(147) 5:701(134) 204.181.90/24 PRODATA1.COM C:US 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 204.181.192/21 UNICOMP-TECHNOLOGIES C:US 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 204.188.32/19 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(218) 5:3561(147) 204.188.128/17 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) 204.189.64/19 MCI-POP-AGG C:US 1:3561(27) 2:3561(218) 3:3561(147) 4:3561(11) 5:3561(144) 204.189.96/19 MCI-POP-AGG C:US 1:3561(27) 2:3561(147) 3:3561(11) 4:3561(218) 5:3561(144) 204.189.128/21 MCI-POP-AGG C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 204.189.136/21 MCI-POP-AGG C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 204.189.152/21 MCI-POP-AGG C:US 1:3561(147) 2:3561(218) 3:3561(27) 4:3561(11) 5:3561(144) 204.189.160/21 MCI-POP-AGG C:US 1:3561(147) 2:3561(218) 3:3561(27) 4:3561(11) 5:3561(144) 204.189.168/21 MCI-POP-AGG C:US 1:3561(27) 2:3561(218) 3:3561(147) 4:3561(11) 5:3561(144) 204.189.176/21 MCI-POP-AGG C:US 1:3561(27) 2:3561(218) 3:3561(147) 4:3561(11) 5:3561(144) 204.189.192/21 MCI-POP-AGG C:US 1:3561(27) 2:3561(147) 3:3561(11) 4:3561(218) 5:3561(144) 204.189.200/21 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(147) 4:3561(218) 5:3561(27) 204.189.216/21 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) 204.189.224/21 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(218) 5:3561(147) 204.189.232/21 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(147) 4:3561(218) 5:3561(27) 204.189.240/20 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(147) 4:3561(218) 5:3561(27) 204.225.64/24 NET-BEACHNET C:CA 1:1240 2:1800 3:1239 204.246.192/19 GLOBALCENTER C:US 1:701(147) 2:701(134) 204.248.80/24 TEZ-NETBLK3 C:US 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 204.248.81/24 TEZ-NETBLK6 C:US 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 204.248.82/24 TEZ-NETBLK7 C:US 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 204.248.83/24 TEZ-NETBLK8 C:US 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 204.250.24/24 INTELE-NET C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 204.250.25/24 NET-INTELE C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 204.250.26/24 NET-INTELE C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 204.250.27/24 NET-INTELE C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 204.250.28/24 NET-INTELE C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 204.250.29/24 NET-INTELE C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 204.250.30/24 NET-INTELE C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 204.250.31/24 NET-INTELE C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 204.251.144/20 NETBLK-QNS-BLKC C:US 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 204.251.174/24 OUTERNET C:US 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 204.251.175/24 OUTERNET C:US 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 205.132.56/24 S4SNET C:US 1:3561(27) 2:3561(147) 3:3561(11) 4:3561(218) 5:3561(144) 205.138.0/19 MCI-POP-AGG C:US 1:3561(147) 2:3561(218) 3:3561(27) 4:3561(11) 5:3561(144) 205.138.32/19 MCI-POP-AGG C:US 1:3561(147) 2:3561(218) 3:3561(27) 4:3561(11) 5:3561(144) 205.138.64/19 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) 205.138.96/19 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(147) 4:3561(218) 5:3561(27) 205.138.128/19 MCI-POP-AGG C:US 1:3561(27) 2:3561(218) 3:3561(147) 4:3561(11) 5:3561(144) 205.138.160/19 MCI-POP-AGG C:US 1:3561(27) 2:3561(218) 3:3561(147) 4:3561(11) 5:3561(144) 205.138.192/19 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) 205.138.224/19 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) 205.139.0/19 MCI-POP-AGG C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 205.139.32/19 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) 205.139.64/19 MCI-POP-AGG C:US 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) 205.159.27/24 EDENVALE C:US 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 205.160.80/22 NET-CIA C:ES 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 205.164/16 NET99-CIDR3 C:US 1:3830 2:4388 205.184/15 NETCOM-BLK C:US 1:2551(147) 2:1321 205.186/15 NETCOM-BLK C:US 1:2551(147) 2:1321 Deletions: --199.212.218/23 NETBLK-SOUTHAM-COM C:CA 1:1239(144) 2:1800 3:1239(218) --199.212.220/22 NETBLK-SOUTHAM-COM C:CA 1:1239(144) 2:1800 3:1239(218) --204.233.40/24 OK-ST-HIGHER-ED C:US 1:3561(27) 2:3561(147) 3:3561(11) 4:3561(144) 5:3561(218) 6:93 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 3561 - MCI-RESTON - DNSS 27 Peer: 198.32.130.97 - MCI - cpe3.chicago.mci.net AS690 CIDR Squeezings Report: 11460 Nets, 185 ASs, 3223 Aggregates ------------------------------------------------------------------- 11460 (85%) of the ever-announced more-specific routes within aggregates have been withdrawn. 218 of those were withdrawn within the last week. 1269 the week before that. 238 the week before that. 185 ASs have registered aggregates in the PRDB. 167 of those are announcing aggregates. 91 have withdrawn at least one more specific route. 3223 Aggregates are configured. 2175 of these were Top-Level Aggregates (not nested in another aggregate). 1669 of these are being announced to AS690. 1051 of those have at least one subnet configured (the other 618 may be saving the Internet future subnet announcements). 912 have stopped announcing at least one configured more specific route. 886 have stopped announcing half of their configured more specific routes. 844 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

Internic address allocation policy
by Paul Lustgraaf 27 Mar '95

27 Mar '95

Does anyone but me agree that the Internic's current address allocation policy is counter-productive? I've been trying for three weeks now to get a block of addresses assigned to me for re-assignment to my customers. I run the non-profit Internet in the whole state of Iowa and the Internic asks me to tell them *ahead of time* how many hosts there will be and the subnet and masking policy for this block. How the H*** am I supposed to know that? Since I sent in this request, I have had *legitimate* requests for over 40 class C-sized blocks. If I have to go to my regional providers block to satisfy them, it will just contribute to the global routing table explosion. My regional provider, Midnet, tells me that to get the last CIDR block, they had to put in over 16 man-hours convincing the Internic that their request was valid. This is from a Regional that serves 7 states! Is this crazy, or what? Now, what do we do about it? Paul Lustgraaf "Its easier to apologize than to get permission." Network Specialist Grace Hopper Iowa State University Computation Center grpjl(a)iastate.edu Ames, IA 50011 515-294-0324

20 45

Re: loose source route
by Vadim Antonov 27 Mar '95

27 Mar '95

Source routing is dangerous. Hoever, i see no harm to allow source routing for a particular type of packets (for example, for ICMP echo requests). Cisco? Are you there? --vadim >From list-admin(a)merit.edu Fri Mar 24 16:40:49 1995 Received: from merit.edu (merit.edu [35.1.1.42]) by titan.sprintlink.net (8.6.9/8.6.8) with ESMTP id LAA16452 for <avg(a)titan.sprintlink.net>; Fri, 24 Mar 1995 11:40:48 -0500 Received: from sneezy.lanl.gov (sneezy.lanl.gov [128.165.114.1]) by merit.edu (8.6.10/merit-2.0) with ESMTP id LAA12539 for <nanog(a)merit.edu>; Fri, 24 Mar 1995 11:07:05 -0500 Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by sneezy.lanl.gov (8.6.10/8.6.10) with SMTP id JAA25814 for <nanog(a)merit.edu>; Fri, 24 Mar 1995 09:07:04 -0700 Message-Id: <199503241607.JAA25814(a)sneezy.lanl.gov> X-Authentication-Warning: sneezy.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: nanog(a)merit.edu Subject: loose source route Date: Fri, 24 Mar 1995 09:07:03 -0700 From: "C. Philip Wood" <cpw(a)lanl.gov> Status: R On occasion, I use traceroute with the option that allows a different viewpoint (as in the IP loose source route option). Today, I tried to: traceroute -g 134.164.8.2 192.156.135.34 traceroute to 192.156.135.34 (192.156.135.34), 30 hops max, 40 byte packets 1 esnet-rt2 (192.16.1.244) 6 ms 4 ms 18 ms 2 lanl3-e-lanl1.es.net (134.55.20.139) 4 ms 4 ms 4 ms 3 llnl-e-llnl2.es.net (134.55.12.225) 40 ms 37 ms 56 ms 4 fix-west-cpe.SanFrancisco.mci.net (192.203.230.18) 53 ms 42 ms 52 ms 5 border3-hssi2-0.SanFrancisco.mci.net (204.70.34.9) 52 ms 49 ms 56 ms 6 core-fddi-0.SanFrancisco.mci.net (204.70.2.161) 55 ms 66 ms 55 ms 7 core-hssi-2.LosAngeles.mci.net (204.70.1.41) 55 ms 78 ms 64 ms 8 core-hssi-2.Houston.mci.net (204.70.1.33) 88 ms 87 ms 90 ms 9 core-hssi-2.Atlanta.mci.net (204.70.1.25) 105 ms 113 ms 110 ms 10 border1-fddi0-0.Atlanta.mci.net (204.70.2.50) 171 ms 119 ms 112 ms 11 suranet-cpe.Atlanta.mci.net (204.70.16.6) 121 ms 120 ms 111 ms 12 atu2-atu-cf.sura.net (192.221.42.2) 111 ms 142 ms 111 ms 13 jck1-atu2-c1.sura.net (128.167.2.2) 142 ms jck1-atu2-c3mb.sura.net (128.167.4.2) 143 ms jck1-atu2-c1.sura.net (128.167.2.2) 226 ms 14 wes-jck1-c1.sura.net (192.221.5.34) 176 ms !S I thought that it was still reasonable for service providers to allow that option while possibly denying it on an interface to a customers network. What's the ruling on that? Thanks, Phil

3 2