- NANOG - lists.nanog.org

ATM text
by Vadim Antonov 23 Nov '96

23 Nov '96

I placed a PostScript copy of the text (unfortunately, hi-res pictures come in separate files) at Pluris homepage, http://www.pluris.com If you won't see new links, reload the page, or clear the browser's cache. Thanks to everybody for comments and suggestions! --vadim

1 0

Re: the promised text
by Mike Trest 22 Nov '96

22 Nov '96

Dima, Good observation. However, I did not miss Vadim's point. It is well stated. But I would like to see a clearer path to deterministic behaviour in routing technology before we use it for integrated voice service, as an example. "No worse than ATM" is not a good enough starting point. Indeed, today we use ATM to transport IP traffic and also multiple technologies including some non-ATM stuff like broadcast video/voice, laser disk playback, Video Conferencing, and ordinary T1 AMI/D4 PSTN voice service. I wonder, however, if an IP address (even at terabit speeds) will help to sort out which DS0 is going to which IXC. Likewise, we should never think that IP traffic will ever be limited to any specific L1/L2 technology. Because I can do these things with ATM today does not mean that better IP routing engines are not needed! I mean no disrespect to Vadim. I think is work is good. I actually hope we do see better IP routing technology. If the resultant product is deterministic at L3, ATMnet would probably be one of the first to sign up to give it a try. ..mike.. At 11:37 AM 11/22/96 -0500, Dima Volodin wrote: >Mike Trest writes: >> >> Even though ATMnet has been delivering IP-over-ATM to commercial users >> longer than any other provider, we never claim that the Internet should >> exist *EXCLUSVELY* as ATM technology. Quite the contrary, we (and our >> customers) see the technical and economic power of ATM technology in the >> ability to support fully integrated services. > >It's either you missed another point or I invented this another point in my >mind - a large chunk of Vadim's paper is devoted to the topic of pure IP's >being no worse that ATM for "integrated" services. > >> Mike Trest, ATMNET Voice: 619 643-1805 > >Dima > > Mike Trest, ATMNET Voice: 619 643-1805 5440 Morehouse Drive Fax: 619 643-1801 San Diego, CA USA 92121 EMAIL: trest(a)ATMnet.net

2 1

Re: the promised text
by Mike Trest 22 Nov '96

22 Nov '96

>To: Vadim Antonov <avg(a)pluris.com> >I loaded the text on merits of ATM vs native IP routing >to the Pluris Inc's web server. >I'll also appreciate your comments. > >--vadim > vadim, I finally satisfied that someone who has a clue on IP and Internet has written clearly on my favorite topic. Indeed, I do not dispute many of your points regards route-flap and role of IX. However, IMHO you have constructed a non-existent foe solely for the purposes of argument. Specifically your statement: "The following ... argue that native IP routing is the only currently existing technology which can hold a global data network together." This is a point that no one with a clue is disputing WRT Internet IP traffic. Even though ATMnet has been delivering IP-over-ATM to commercial users longer than any other provider, we never claim that the Internet should exist *EXCLUSVELY* as ATM technology. Quite the contrary, we (and our customers) see the technical and economic power of ATM technology in the ability to support fully integrated services. On the other hand, no one with a clue can dispute that we need to push for better IP routing technologies, regardless of the L1/L2 medium used. ..mike.. Mike Trest, ATMNET Voice: 619 643-1805 5440 Morehouse Drive Fax: 619 643-1801 San Diego, CA USA 92121 EMAIL: trest(a)ATMnet.net

2 1

the promised text
by Vadim Antonov 22 Nov '96

22 Nov '96

I loaded the text on merits of ATM vs native IP routing to the Pluris Inc's web server. You may find it at http://www.pluris.com Please contact me if you have any problems with the text. I'll also appreciate your comments. --vadim

1 0

Re: RWHOIS, SWIP, and proving ownership
by owen＠DeLong.SJ.CA.US 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. > So... > 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.) > I don't see any reason you couldn't modify RWHOIS to compile/run on VMS. It's pretty straightforward C code with very few UNIX specific calls in it. Admittedly, we run UNIX (which has been up 99.96%+ at our site). In fact, the last time I worked in a shop with a bunch of VMS users, the VMS system was down alot more often than our UNIX systems. Oh well... Guess it's religion. > 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.. :) > That applies to network protocols and interactions between machines. > 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. > I will support this criticism of the NIC, but the RA has not refused any of my submissions based on templates over a year old. > 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 ;)" > We don't conform to any standard, we don't care what the rest of the net does, and you better give us what we want when we want it. Cute. I expected better from you of all people, Ehud. > Ehud > Owen

1 0

RFC - Roots For Consensus
by Jim Fleming 21 Nov '96

21 Nov '96

---------- From: Jim Fleming[SMTP:JimFleming@unety.net.] Sent: Thursday, November 21, 1996 9:38 AM To: 'New Newdom'; 'paul(a)vix.com'; Bob Allisat Cc: bobm(a)nic.ddn.mil; jamesf(a)arl.mil; Jim Fleming; koda(a)isi.edu; marcel(a)nsipo.nasa.gov; 'Mark Kosters'; markk(a)netsol.com; matti(a)comedia.se; psinet-domain-admin(a)psi.com; sneeri(a)ni.umd.edu Subject: RE: FW: RFC - Roots For Consensus On Wednesday, November 20, 1996 11:42 PM, Paul A Vixie[SMTP:paul@vix.com] wrote: @ > Paul A Vixie wrote: @ > >(edit)... Each root name server operator (*.ROOT-SERVERS.NET) @ > >carries exactly the data that the IANA has approved. Never more and @ > >never less. @ > @ > IANA was one fellow with a few @ > assistants. So this one fellow @ > tells nine other guys who run these @ > root servers exactly what names @ > will or will not be recognized? @ @ Yes. Think of the root name servers (not "the popular..." or "the old..." @ but simply THE ROOT NAME SERVERS) as common carriers. They are respon sible @ for accuracy and delivery but not content. @ Paul, I think it might be useful to define some common terminology. Root Name Server Primarily directs ISP Name Servers to TLD Name Servers TLD Name Server Primarily directs ISP Name Servers to SLD Name Servers SLD Name Server Primarily directs ISP Name Servers to Web and Mail Servers ISP Name Server Primarily serve customers' stub resolvers and interface with all of the above name servers in a frequency that decreases from the top (Root) to the Bottom (SLD and below) because of caching. No one argues that accuracy and coherence are not important. In fact, one way to gain better accuracy and coherence is to make sure that name servers are properly classified, configured, and maintained. One of the current problems with the overall DNS system is that the 9 "popular" Root Name Servers mix (or combine) the function of a Root Name Server and a TLD Name Server. In a similar manner, many ISPs combine the function of their ISP Name Server and one or more SLD Name Servers. This is especially true in the case where "virtual" domains are used. There are many reasons why accuracy and coherence are important. One of the main reasons is to ensure accuracy in financial accounting records, interstate commerce, and accurate fullfillment of Federal and State tax laws. I suggest that everyone operating a Root Name Server and a TLD Name Server consult with their attorneys and accountants regarding how income derived from the operation of those servers has to be properly and "accurately" attributed to the proper taxing authority at the Federal and State levels. One of the reasons why it is important to separate the Root Name Servers from the TLD Name Servers is because there may be no income and/or profits derived from operating a Root Name Server. On the other hand, operating a .COM TLD Name Server, in a particular State (let's say Kansas) means that some portion of the income derived from operating that server and service has to be attributed to the State of Kansas. That way there will be accuracy and coherence when companies file their tax returns. @ > And this is how a critical element @ > in the communications of 50+ @ > million people was being governed? @ @ Yes. This is a "principle" and its name is "coherence". (I'm quoting those @ words for the benefit of Mr. Fleming, who will probably need to look both of @ them up in a dictionary.) @ @ > What an amateurish, closed and @ > utterly bankrupt process! Bring @ > on Root 64 Mr Fleming! NOW! At @ > least there will be 64 or more @ > participants. That makes abuses @ > far more unlikely. @ > Bob Allisat @ @ You are arguing in favour of "the tyranny of the majority" and if you'll @ check your history books you'll see that it hasn't worked out well whenever @ it's been tried. @ @ If you would rather have 64 root name servers that DO NOT LISTEN TO SOME @ CENTRAL AUTHORITY and each offer their own version of the DNS name space, @ then you do not understand (a) history, (b) politics, (c) economics, @ (d) engineering, (e) science, and (f) ethics. @ Once again, I suggest that people check with their attorney's and accountants on how tax laws work at the Federal and State levels. I believe that these laws have been developed over hundreds of years and certainly cover (a), (b), (c), and (f). It seems to me that people who are focused on (d) and (e) may not understand all of the ramifications of their actions. @ "Coherence" is how we got "here" and it's how we'll get from here onward. @ IANA is changing the authority model so that there will be more lawyers and @ more insurance policies and more people able to take the heat, and under @ that expanded shield there is room for a mechanism that admits more iTLD's. @ @ But while we will see an end to the single-person authority model, we will @ NOT see an end to the need for, and the presence of, DNS coherence. You can @ rail against this and you can wail about this but DNS just will not work @ without coherence and the Internet citizenry will not be able to get useful @ work done without coherence. @ @ I have directed followups to a mailing list that I do not read. Please @ continue this discussion there without me. @ @ Paul, as long as you operate a Root Name Server and more importantly a TLD Name Server for the "commercial" .COM domain in the State of California then I would think that you would want to keep up with how the laws of that State apply to you. Also, since you appear to be operating this commercial venture as a non-profit operation (ISC?), I would think that you would also be interested in Federal Tax laws and how accuracy and coherence are key to making that system work. You can bury your head in the sand, but if you do, I suggest that it be in International waters off the coast of California, because at this point in time you are standing on Federal and State soil, and that makes you, your companies and your servers subject to the laws of those regions. If you have some special "dispensation" from the IANA or the ISOC that makes you immune from Federal and State laws, please let everyone know. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

1 0

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