- NANOG - lists.nanog.org

new TERENA activity on European traffic measurements
by Ariel T. Sobelman 21 Nov '96

21 Nov '96

Hi all, Enclosed is the text of a project proposal for a TERENA activity on network metrics and statistics collection. As a kick off, we have created a task force mailing list for those interested. If you would like to join, send a message to: listserv(a)terena.nl containing only the text: subscribe tf-etm Your Real Name replacing "Your Real Name" as appropriate. Feel free to forward this to any parties you think might be interested. Regards, Ariel T. Sobelman Project name: TERENA Task Force on European Traffic Studies ----------------------------------------------------------- Justification --------------- The problem of network traffic growth prediction may be attributed to the difficulties associated with network operation. There is one common ground, however, that which is the end result: performance. Many network operators already collect basic statistics on their own network's performance and traffic flows. Typically, this includes measurement of throughput, delay and availability. However, the only baseline against which networks evaluate performance is their own past performance metrics. There is no data available for national-level comparisons with other networks' performance. It is vital for both users and providers to have access to information on end-to-end performance. Such information is beyond the realm of what is currently undertaken by individual networks. The project objective is to collect and analyse data, which will enable focusing on the causes of decreased performance, and proposing corrective actions. The activities include the development a mechanism and structure for collecting statistics of traffic loads on an end-to-end international level, measurements of delays, flow capacity and packet loss information. Objectives --------------- The vacuum created in national-level statistics/metric collection has significantly complicated planning by member countries and service providers. While detailed traffic and performance measurements are essential to identifying the causes of network problems and formulating corrective actions, it is trend analysis and accurate network/system monitoring which permit network managers to identify "hot spots", predict problems before they occur, and identify ways to avoid them by efficient deployment of resources and optimising of network configuration. As the explosive growth and dependence on the Information Infrastructure continues, it is critical that mechanisms be established to enable infrastructure planning and analysis. This proposal describes a possible mechanism for undertaking a project to concentrate current efforts. It is proposed to address these problems on two levels of relevance: 1. significance to analysis of network performance 2. relevance to Internet settlements These activities will include cross-European measurements of total traffic through specific links and the mapping of reachable destinations covered by a route, Delay measurements,flow capacity, continental averages of hops, and rate of packet loss monitoring. These measurements will be conducted using publicly available software packages. The project is not anticipated to require efforts beyond minor changes to some software. In order to enable reliable statistical analysis, the sampling periods have been set at 6 months per phase, from the starting date of phase I & II experiments. It is also intended to participate in the IPPM working group of the IETF Deliverables: ---------------- Software kit for all participating members - for total traffic stats: TCP dump samples, router stats, Network Probe Daemon - for delay measurements: ping-based utilities, Treno - for packet loss stats: To be discussed - Hop counts: traceroute Report: Guidelines for setting up a statistics-collection operation compatible with the rest of the project - guidelines for peering - topology of participating links Web site concentrating the European statistics collected - General database with all raw data - various views of the data (graphical and numeric) - analysed data, patterns, related papers, ongoing work etc. Report: Summary of network patterns and problems identified by the project Report: Results of phase I, and recommendation for immediate possible corrective steps. Final Report: Results of traffic model. A report on network patterns and identification of necessary long terms predictions and recommendation for corrective steps. Milestones -------------- Phase I 1. Web page with description of the project, participating partners and updates 2. List of issues that need to be addressed and agreed 3. Available equipment from participants (and document this on the Web site) 4. Structure of phase I statistics collection 5. Construction of data base 6. End of Phase I experiments and population of database 7. Analysis & evaluation Phase II 8. Planning of Phase 2 goals for predictive model 9. List of issues to be addressed and agreed 10. Planning experiments phase 2 11. Begin sampling 12. Analysis & final reporting Timeline Phase I November 1996: Milestone 1 & 2 December 1997: Milestone 3 April 1997: Milestone 4 June 1997 Milestone 5 June- Nov. 1997: Data collectioe phase November 1997: Milestone 7 Phase II January 1998: Milestone 8 , 9 March 1998: Milestone 10 April-Nov. 1998: Data collection phase December 1998: Milestone 12 Ariel T. Sobelman TERENA Singel 466-468 1017 AW Amsterdam The Netherlands +31-20-639-1131 (Tel) +31-20-639-3289 (Fax)

1 0

Re: Internic address allocation policy (fwd)
by William Allen Simpson 21 Nov '96

21 Nov '96

> From: Bradley Dunn <bradley(a)dunn.org> > > I do not know of any organization that would allow internal network information > > to be made available to an outside party. I think this ranks pretty > > high up on any security policy. It would probably not even be possible on > > correctly secured network. And on one that wasn't properly secured, you > > would probably hear lots of complaints about scanning or searching that > > network. > > If the internal network is that "top secret" it should be behind a > firewall and using RFC 1918 space. > Yes. Last year, when I was scanning the Class A's to determine number of actually connected hosts, my service provider kept getting complaints from so-called security folks at the affected companies. Oh, and I found a lot of routing problems (loops, etc) which are really aggravated when you hit them 255 times (each address in the range, all of them looping).... WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

RE: Internic address allocation policy (fwd)
by Jim Fleming 21 Nov '96

21 Nov '96

On Wednesday, November 20, 1996 4:54 PM, Kamau Wanguhu[SMTP:kamau@africaonline.com] wrote: @ Kim Hubbard wrote: @ > @ > > @ > Now that we've established that I don't have fangs or horns (thanks to @ > Chris and Matt for clearing that up :-)) I would like to urge you all @ > to join the IRE mailing list to discuss the IP polices. @ @ Please post the subscription address. @ -- @ ================================================================ @ E. Kamau Wanguhu mailto:kamau@AfricaOnline.com @ Africa Online Inc mailto:kamau@BORGcube.com @ Medford, Massachusetts http://www.AfricaOnline.com @ TEL: 1.617.494.1515 FAX: 1.617.494.9422 @ ================================================================ @ @ Also, I suggest that people be informed of the IRE Mailing List policies. When I joined the list, I was told by the list operator, Mr. David Conrad, that some people on the list requested that I "quietly be removed". Instead of removing my name, Mr. Conrad and I agreed that it would be best if I not post to the list. I think that people should be told that some people on the list would like to be able to control who participates. People should read the exchanges on the list with that in mind, and should probably also be cautious when they post to the list, because they might be "quietly removed". -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

2 1

RWHOIS, SWIP, and proving ownership
by Ehud Gavron 21 Nov '96

21 Nov '96

Consider this a side note to the preceding discussion. 1. Most of our clients understand that their ''lease'' on network address space is at our whim, by contract for IP connectivity, and is subject to renumbering if WE assign them new space, if WE are assigned new space, or if they move elsewhere. Therefore they don't ask us to SWIP the nets nor do they care. 2. RWHOIS doesn't run on any production operating system. I know Unix is in vogue, but since we do the 99.96% uptime schtick, we use operating systems that stay up (VMS). This means we can't run RWHOIS (even if we did want to, which if you read #1 above you'll see we don't.) 3. We currently use almost all of a /18, two thirds of a /19, a few /22s, and some /24s. It would be easy to justify a /17 based on all this, but if someone wanted to be rigid about RWHOIS and SWIP, even a bunch of traceroutes aren't going to convince them. Back in THE GOOD OLD DAYS (tm), we said "Be flexible with what you accept, be rigid with what you send out." (Others made it sound better and put it in RFCs... D.C. for one.. :) Nowadays I see the motto has become "Be rigid in what you accept, and modify your templates as often as possible." This criticism applies equally to the RA IRR as it does to the InterNIC. Gee, and this started out as one sentence that went "We don't run RWHOIS, our clients don't want it, our operating system won't support it, and you better listen when we ask for a /17 ;)" Ehud

2 1

IRR
by Brian Merritt 21 Nov '96

21 Nov '96

Ok, this is in follow up to a discussion Bill Woodcock, John Hawkinson, Kim Claffy and I had on the IPNMoo (or CAIDAnce or whatever it's called) regarding the IRR. This discussion led me to ask a bunch of questions. I'd like to present these questions for discussion, and share a few of my comments. How accurately does the IRR represent the actual routing policy of the various participating networks and of the Internet as a whole? Well, according to the IRR Violations statistics at http://compute.merit.edu/problems.html, not very well. Since MAE-East is the "most important" (don't even start on that one) exchange on the Internet, let's look at the very few datapoints available. 10187 IRR violations at MAE-East on 11/13/96 9873 IRR violations at MAE-East on 11/12/96 There is no data available on the web page for any other days. Barring all of the obvious flames about the "if's" involved (number of data points, statistical methodology, what constitutes a violation, multiple violations, Merit stats don't mean anything, etc.) this doesn't look real good. If there are about 42000 paths in the "default-free" routing table (this part we know), and every last one of them is registered in the IRR (which isn't true), ~25% of the routes on the Internet do not jive with the IRR, according to these Merit stats. Obviously, this calculation isn't exactly statistically sound, but it's something to think about. The fact that there are so many if's is kind of the point, too. If you don't trust Merit stats, whose? Is there anything else available to base any sort of conclusions on? I know of at least one example of a reported "IRR violation" that isn't, so there could certainly be (many) more. Anyone from Merit care to explain how these stats are collected, and/or if they should be considered accurate? There's nothing on the web pages concerning IRR violation statistic collection methodology so far as I can tell. To quote the eloquent folks at Merit: "Maintaining accurate IRR information is important as several providers base their router configurations on IRR information. Incorrect IRR data may result in loss of connectivity. The IRR also provides a valuable source of information for analysis and debugging tools." How many providers are basing their policy solely on IRR information? Are these providers (if they exist) at all concerned with the notion that (if the RA statistics on IRR violations are at all useful) they may not be able to get to up to 25% of the Internet at any one time? Might the IRR be more harmful than goodful if it's actually used to generate router config's by any small group of providers, and not by everyone? (Unless you think segmentation is good). Is the IRR more valuable as a "source of information for analysis and debugging tools" than as a source of information to base routing policy on? I would say apparently so. Is the IRR supported? Well, as far as I can tell almost everyone that should be participating (in some form) is. Is it supported in the sense that everyone that is participating is commited to maintaining accurate information? I would say apparently not. Is it supported in the sense that it is actually used for anything other than "analysis and debugging"? (And what sort of useful analysis can be done with data that is 25% bad anyhow?) I don't know. Should the IRR be used for anything presumed to be "actually useful"? Well, I certainly wouldn't rely (solely) upon it. How about you? If the IRR were useless would it break the Internet? Nope. Could the IRR improve the Internet if it were used by everyone? Maybe. Should the IRR exist? I think yes. This whole "discussion" begs a lot of other questions. Adressing them is "beyond the scope of this document". :) To be Scott Bradner for a moment, here's a disclaimer. I don't have large sums of grant money to do statistics, and I have to rely on people who do, so don't complain about how terrible my stat is. I know many (all?) of these questions have been brought up before. I believe there is interest in discussion, and so I have brought them up again. If you don't want to talk about it, don't. These bits will not break your network (well, unless you're <insert anyones favorite congested network here>). Brian ___ Brian Merritt bmerritt(a)getnet.net ___ Principal Network Engineer GetNet International

5 4

RE: Internic address allocation policy (fwd)
by Jim Fleming 21 Nov '96

21 Nov '96

On Wednesday, November 20, 1996 3:34 PM, Snowdog[SMTP:snowdog@charm.net] wrote: @ Hello, @ @ I think that intentions of the original email is harmless and a good idea, @ however, I also think that the suggested implementation below simply 'should' @ not work. @ My main theme was that the Internet could be a nice self-policing sort of place. It is unfortunate that people and companies have grabbed addresses in the 80's and now sit on them and do not want to discuss how they are being used. Meanwhile, ISPs are asked to jump through hoops and justify tiny allocations. In my opinion, people are looking at the wrong end of the allocation food chain. While I understand that people might subscribe to the idea of..."counting the nickels and the dollars will take care of themselves..." It seems useful to point out that while this is occuring, the millions are being thrown out with the baby, the bath water and the kitchen sink. @ I do not know of any organization that would allow internal network information @ to be made available to an outside party. I think this ranks pretty @ high up on any security policy. It would probably not even be possible on @ correctly secured network. And on one that wasn't properly secured, you @ would probably hear lots of complaints about scanning or searching that @ network. @ I think that you might be jumping to conclusions as to what would go in a report. If only information went in the report which could be easily deduced via public methods would people be concerned ? Also, again I stress that the bulk of the reports would be self-generated. What we are talking about is a cultural shift, similar to what happened with Ecology. We had a neighbor who 10 years ago prided herself in telling everyone privately that she thought ecology was useless. When our city went to "vanity cans", she was one of the first to sign-up, because it was now culturally "cool" to have recycling bins at the curb. The idea is NOT to have people snooping on their neighbors. The idea is to have people check to see if their neighbors "checked" in and develop a simple report and maybe to send a reminder that the report is due. @ So, I think you are going to find in almost every instance, the other @ company telling you to politely mind your own business. Now, another @ solution might be to have one organization (InterNIC or sorts) to be @ responsible for obtaining and reviewing this information. They @ already do this to smaller providers trying to obtain new IP addresses. @ It might be possible to implement some sort of continued observations @ of issued IP addresses to ensure proper allocation. But this sounds @ like alot more potential work for an already busy entity like the InterNIC. @ That is a lot of work, and "centralized" intelligence agencies are not what the Internet world needs. @ I don't know, I just thought to mention that I liked the idea, but @ at the same time it just doesn't seem like a practical solution. @ @ Just my added thoughts... @ @ Sean Rolinson @ snowdog(a)charm.net @ Thanks for the comments. I think that it is fair to mention that I have found, in a limited survey, that people who are hording addresses hate this system and those that have nothing to hide and are PROUD of their frugal allocations and network management methods seem to endorse this sort of program. Again, the proposal is to encourage people and companies to be proud of their Internet ecology activities. In order to do that, people have to get to the PR departments of companies and show them how much GOOD publicity they will get for cleaning up their allocations. These clean-up efforts can be detected and recognized by their "binary neighbors" on the neighbor net. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

1 0

RE: Internic address allocation policy (fwd)
by Justin W. Newton 21 Nov '96

21 Nov '96

At 12:06 PM 11/20/96 -0600, Jim Fleming wrote: >I have suggested in the past a "neighbor net" approach. >It is a simple approach in which people on each side >of an allocation, be responsible for publishing a periodic >usage report. They would obtain this information from >their "neighboring" administrator. > >This approach can work for /24s, /16s and any size >allocations, as long as one is aware of who their binary >neighbor is in the IPv4 address space. > >To illustrate a /8 example, Hewlett Packard and Apple >Computer would be responsible for the report on >Digital Computer Corporation. > > Hewlett Packard - 15.0.0.0 > Digital Computer - 16.0.0.0 > Apple Computer - 17.0.0.0 > MIT - 18.0.0.0 Jim, This lynches it. You are absolutely insane. You whine and moan about having to tell the EvilInternic(tm) about your network, potential customers, etc etc, yet you believe that DEC would gladly give information to Apple about their internal network etc etc. More effort would be sepnt in court with lawyers haggeling over what DEC had to give Apple and Apple had to give DEC in order to properly be audited than would have originally been spent with an audit by an external agency doing the audit. Or wait, let me guess DISA wants to be audited by a foriegn company (30.0.0.0 for DISA and 32.0.0.0 for the foriegn company, 31 is IANA reserved, so I am assuming that it would be skipped). Yeah, that. Justin Newton Network Architect Erol's Internet Services

4 3

IP Allocation
by Pete Davis 21 Nov '96

21 Nov '96

With all this talk of IP Allocation, does anybody know of a time frame for Prodigy/AOL/Compuserve to become HTML 1.1 compliant? We have been trying to conserve IP space wherever possible, but the inability for 6+ million people to see "software virtuals" based on HTML 1.1 has prevented us from transitioning from /32's for each site to one single /32 for thousands. On another note, with the recent release of Bind 4.9.5 which supports IPV6 on the DNS layer, how long are we looking at before it will begin to be implemented on the IP layer? It seems that the NIC is doing whatever they can for the time being, but the only real solution to this problem is to expand the size of the available IP pool. -Pete (sorry if this is off topic) ========================================================================= Peter Davis - Sr. Systems & Network Engineer <pete(a)tiac.net> The Internet Access Company PO Box 1098 Bedford MA 617-276-7200 Mail info(a)tiac.net for a list of access-points! =========================================================================

8 8

Re: Re[2]: Compu$erve RFC 1123 5.3.3 violation
by Kevin Smith 20 Nov '96

20 Nov '96

At 03:12 PM 11/20/96 -0800, Brian Murrell wrote: >from the quill of Alan Barrett <apb(a)iafrica.com> on scroll ><Pine.NEB.3.95.961117113159.131G-100000(a)apb.iafrica.com> >> I certainly don't see that bouncing >> mail with a "mailbox is full" error is a violation of RFC1123 section >> 5.3.3. > >The fact that there was a bounce was not the complaint. The fact that the >bounce went back to the author of the article, not the sender was the >complaint. Hey, sounds just like Lotus NOTES :) ...hi Brian....:) Kevin Smith New Service and Support Technology Manager, Marketing Resources are now at: Ascend Communications http://www.ascend.com/service

1 0

Compu$erve RFC 1123 5.3.3 violation
by randy＠psg.com 20 Nov '96

20 Nov '96

The following bounce from Comp$Serve violates RFC 1123 5.3.3. They have been repeatedly informed of this and refuse to fix their mail system. Hence mailing lists here prevent subscription by Compu$erve addressees. I suggest that others, e.g. the nanog list, do the same. randy Message-ID: <961115221415_515664.456256_JHO109-62(a)CompuServe.COM> Date: 15 Nov 96 17:14:16 EST From: Electronic Postmaster <POSTMASTER(a)CompuServe.COM> Comments: Returned from: <103311.571(a)CompuServe.COM> Message-Type: Delivery Report To: Randy Bush <rbush(a)wna.net> Subject: Undeliverable message Your message could not be delivered for the following reason: Mailbox 103311.571 is currently full. Please resend your message at a later time. --- Returned message --- Sender: owner-nanog(a)merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by hil-img-2.compuserve.com (8.6.10/5.950515) id RAA08607; Fri, 15 Nov 1996 17:14:11 -0500 Received: from localhost (daemon@localhost) by merit.edu (8.7.6/merit-2.0) with SMTP id QAA12118; Fri, 15 Nov 1996 16:50:34 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 15 Nov 1996 16:50:32 -0500 Received: (from daemon@localhost) by merit.edu (8.7.6/merit-2.0) id QAA12106 for nanog-outgoing; Fri, 15 Nov 1996 16:50:32 -0500 (EST) Received: from rip.psg.com (root(a)rip.psg.com [147.28.0.39]) by merit.edu (8.7.6/merit-2.0) with SMTP id QAA12099 for <nanog(a)merit.edu>; Fri, 15 Nov 1996 16:50:28 -0500 (EST) Received: by rip.psg.com id m0vOW9V-0007zfC; Fri, 15 Nov 96 13:50 PST (Smail3.1.29.1#1) Message-Id: <m0vOW9V-0007zfC(a)rip.psg.com> Date: Fri, 15 Nov 96 13:50 PST To: Scott Huddle <huddle(a)mci.net> Cc: nanog(a)merit.edu From: Randy Bush <rbush(a)wna.net> Subject: Re: The Cidr Report References: <199611152058.PAA17223(a)new6.Reston.mci.net> Sender: owner-nanog(a)merit.edu >> Number of ASes announcing only one prefix: 737 (378 cidr, 359 classful > Wow! Is a correct assumption that some 40% of the ASs could be > reclaimed? I do not see how you get to this conclusion. He did not say number of ASs which only appear through one other unique AS, i.e. are single homed. Oh, Joel! >> Largest number of cidr routes: 461 announced by AS3561 >> Largest number of classful routes: 1266 announced by AS174 > Neat stuff. Could you list the top ten or five of each of these? What is a 'top' prefix? Lowest IP? Shortest prefix? Actually, for embarrassment sake, I would want to see the most likely candidates for aggregation. But if I wanna see it, I can look in one of my routers. >> Top 20 Withdrawn Routes from 08Nov96 to 15Nov96 >> -304 AS174 Performance Systems International > Are congrats due to PSI? Far out! Maybe so! >> -50 AS2914 WNA, premasticated for MCI :-) > ??? Sorry. I have to convert my RADB RPSL one into a placeholder RIPE-181++ for the MCI-RR, and that's the descr:. For the real aut-num: see the RADB. I would think Tony would be picking up the latter. Old habits, TB? randy

8 7