- Test - lists.nanog.org

Registering in the RADB
by Elise Gerich 31 Mar '95

31 Mar '95

Many folks have been asking what is necessary to start registering information in the Routing Arbiter Database. Andy Adams from Merit has documented the three step procedure for registering in the RADB. This document, "Registering in the RADB", is available from: http://www.ra.net/rrinfo.html All registration information should be sent to db-admin(a)ra.net. Comments and suggestions concerning the documentation should be sent to merit-ie(a)merit.edu. WARNING: The RADB is not used to configure AS 690 (NSFNET Backbone Service and ANSnet) yet. It is used to configure the Route Servers at the NAPs. To have routes accepted by AS 690 (NSFNET Backbone Service and ANSnet), please continue to submit NACRs. Happy reading. --Elise

1 0

NOC Status Reports
by kwe＠6SigmaNets.com 31 Mar '95

31 Mar '95

At 4:42 PM 3/30/95, Hans-Werner Braun wrote: >I wonder by how much the problem could be reduced as such, if service >providers (including campus service providers) would have accessible >servers about network status information, being kept current by some >local NOC. At 4:56 PM 3/30/95, Chris Dorsey (510)422-4474 wrote: > .... Of course there will >always be some NSP's that would never implement such a server >for business purposes. H-W, Chris, et al; Some service providers already post system-wide planned outages and even system-wide unplanned outages (like NSFnet backbone outages) on public mailing lists. We don't need another protocol to support this -- it would be a simple matter for everyone to gateway system-wide trouble ticket reports to a Web page. As Chris points out, even if today we could do this, in future it will become more difficult as competitive pressures mount. In the past I have managed NOCs where there were pressures on the NOC to sugar-coat the public trouble tickets. A certain amount of this is appropriate, since it is possible for NOC controllers, network engineers and other technical support people to become frustrated with their peers and I have some vivid memories of particular frustrations coming out in system-wide trouble tickets. It doesn't help either party for shouting and name-calling to show up in trouble tickets, but it can easily happen, as we all know. So when the pressure inevitably mounts on everyone to treat their system-wide trouble tickets like press releases, the information content that we seek will tend toward zero. Therefore I feel that if such a public system were created it would inevitably devolve to minimize useful information, such as who is really screwing up or where the difference of opinion actually lies. We need a new pressure point, like traceroute became for routing or throughput became for router benchmarks. If you all kept incident notes and someone sent out a survey every quarter, would you be interested in a Consumer Reports style of NOC performance metric? :-) This might be worth thinking about in the IP Perf Metric BOF next week. I just don't see any other pressure point. There has to be an outside evaluation tool and a general understanding of how to interpret it. --Kent

1 0

Re: ENSS 133 retired
by phuston＠nsf.gov 30 Mar '95

30 Mar '95

Thanks to all of you and Merit for helping everyone confirm that the transition is solid before May 1. You have been among the leaders in stepping out front and assuring a smooth the transition . Priscilla. At 10:59 PM 3/30/95, epg(a)merit.edu wrote: >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 Priscilla Jane Huston Program Director of the NSFNET Program National Science Foundation Voice: (703)306-1949 or (713)527-4007 4201 Wilson Blvd Fax: (703) 306-0621 Arlington, VA 22230 Internet: phuston(a)nsf.gov or pjh(a)rice.edu

1 0

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