May 1996 - Test - lists.nanog.org

Metcalfe strikes again!
by Michael Dillon 07 May '96

07 May '96

---------- Forwarded message ---------- Date: Mon, 6 May 1996 09:49:10 +0100 From: Joe Bonin <webmaster(a)scescape.net> Reply-To: inet-access(a)earth.com To: inet-access(a)earth.com Subject: Recent article in US News Resent-Date: Mon, 6 May 1996 08:45:12 -0500 (CDT) Resent-From: inet-access(a)earth.com Interesting 1 page article in US News & WR May 6 issue page 59. Here is a summary of the article. --begin summary Quotes Bob Metcalfe inventor of Ethernet and founder of 3Com Corp. "The Internet is about to collapse and it's going to shake some of the naivete' right out of the industry." The most likely time will be July with the Olympic Committee and IBM planning to put the Summer Olympic video and sound on the Internet according to him. The problems stem from private companies. ANS, MCI, Netcom, UUNET and Sprint and others taking over the backbone in the last year from NSF. These companies now claim ownership of portions of the backbone. But where NSF gave out Internet traffic data the new players do not. As a result no single company has a decent gauge of what's going on. Also, the shared parts of the backbone has no single company incentive to improve them (i.e. no incentive to back each other up.) Rob Hagens, MCI director of Internet engineering views Metcalf's scenario as being extreme with others inspite of 1 1/2 hour brownout on its West Coast backbone early in April. He says "I believe we're going to be able to keep the Internet running." They are all racing to invest in high speed networks to keep ahead of demand which is growing 100% per year. --end summary

5 5

Re: I-D (Re: Out of date contact information )
by sthaug＠nethelp.no 07 May '96

07 May '96

> BTW - do we want to mention "root" as the system administration of a > specific host to report things like "your multicast implementation is > broken and spewing ICMP packets" or other "fix that beast" messages. I don't think it's a good idea to mention "root". I've seen far too many cases of email to root being read very seldom, or not at all. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: E.164 SMDS addresses
by George H. Clapp 06 May '96

06 May '96

SMDS addresses are E.164 addresses, or telephony addresses. In the USA, SMDS addresses are taken from the North American Numbering Plan (NANP), which is consistent with E.164 addresses and is administered by Bellcore. You should contact whoever administers the telephone numbers for Mexico. You might contact the administrator of the NANP for guidance on who administers Mexico's address space. His address is... Jim Deak North American Numbering Plan Administration 6 Corporate Place, PYA 1G-278 Piscataway, New Jersey 08854-4157 (908) 699-6612 (908) 336-3293 FAX jnd2(a)cc.bellcore.com George Clapp voice: 201-829-4610 fax: 201-829-2504 page: 800-980-1298 email: clapp(a)bellcore.com At 10:55 AM 5/5/96 -0600, you wrote: > >We are preparing an SMDS service offering on the AcNet Network. We have >been unable to locate the party responsable for the assignment of the >"Network" portion of our SMDS addressing schema. > >Does anyone out there know where one applies for such an identifier >(E.164) for a new SMDS Network? > >Thanks for any advice one might offer. > > >R S Ashton The Ashton Group >P O Box 1175 Ashton Systems Corporation >Chula Vista, CA 91912-1175 USA Ashton-International Corporation >Voice: (619) 424-5362 Ashton Communications Corporation >Fax: (619) 424-5621 AcNet, AcBone, AcNode (R) > >The Ashton Group >Latin America >Apartado Postal 11-436 >Mexico, DF 06101 MEXICO > >Voice: (011-525) 230-2700 or Direct from the USA: (210) 668-6000 >Fax: (011-525) 230-2701 or Direct from the USA: (210) 668-6001 > > >

1 0

Re: Inter-exchange media types
by Havard.Eidnes＠runit.sintef.no 06 May '96

06 May '96

Hm, I think Peter was too brief to be understood by all. Let me try to expand on his major point (buffering requirements). First, however, to this: Jeremy Porter <jerry(a)fc.net> wrote: > Since large amounts of traffic on the Net orginates from > modems which are typically plugged into terminal servers, which > virtually all have ethernet interfaces, very large > amounts of internet traffic have MTUs smaller than the > 1500. > > [Continues argument in the line of "if little traffic uses more > than 1500 bytes MTU, ethernet will be better/cheaper/etc."] I would claim that the average packet size doesn't really matter much -- the average packet size is usually in the order of 2-300 bytes anyway. However, restricting the MTU of an IX to 1500 bytes *will* matter for those fortunate enough to have FDDI and DS3 (or better) equipment all the way, forcing them to use smaller packets than they otherwise could. Some hosts get noticeably higher performance when they are able to use FDDI- sized packets compared to Ethernet-sized packets, and restricting the packet size to 1500 bytes will put a limit on the maximum performance these people will see. In some cases it is important to cater to these needs. The claim that switched fast full-duplex Ethernet will perform better than switched, full-duplex FDDI for small packets doesn't really make sense -- not to me at least. I mean, it's not like FDDI doesn't use variable-sized packets... Now, over to the rather important point Peter made. In some common cases what really matters is the behaviour of these boxes under high load or congestion. The Digital GigaSwitch is reportedly able to "steal" the token on one of the access ports if that port sends too much traffic to another port where there currently is congestion. This causes the router on the port where the token was stolen to buffer the packets it has to send until it sees the token again. Thus, the total buffering capacity of the system will be the sum of the buffering internal to the switch and the buffering in each connected router. I have a hard time seeing how similar effects could be achieved with ethernet-type switches. (If I'm not badly mistaken, this is a variant of one of the architectural problems with the current ATM based IXes as well.) Thanks to Curtis Villamizar it should be fairly well known by now what insufficient buffering can do to your effective utilization under high offered load (it's not pretty), and that the requirements for buffering at a bottleneck scales approximately with the (end-to-end) bandwidth X delay product for the traffic you transport through that bottleneck. So, there you have it: if you foresee that you will push the technology to it's limits, switched ethernet (fast or full duplex) as part of a "total solution" for an IX point seems to be at a disadvantage compared to switched FDDI as currently implemented in the Digital GigaSwitch. This doesn't render switched ethernet unusable in all circumstances, of course. Regards, - Havard

6 6

Re: I-D (Re: Out of date contact information )
by Paul A Vixie 06 May '96

06 May '96

> > I've added ROUTING to do what TROUBLE is often used to do. > > I question whether this is a good idea -- some providers have a > "routing" mailing list that isn't really intended for public > dissemination and use. For instance, routing(a)uunet.uu.net and > routing(a)es.net both bypass their respective NOCs and go straight to > engineering types -- perhaps we need to pick a new name for those > sorts of lists, but I really don't see what having a "routing" > buys us over "noc". This is the kind of collision that makes this "standard" expensive to implement. Folks elsewhere use ROUTING as a way to reach the folks who want to hear about externally visible routing problems; NETCOM for example advertises this address in its RADB elements. I think that folks like UUNET and ESNET will have to pick new addresses if they don't want their engineers getting spammed. Sorry about that.

2 1

Network management
by Distributed Tech. Inc. 06 May '96

06 May '96

I an not sure if it is appropriate to ask this here, but i will anyway! Is there a network mamangement platform of choice fo r building a NOC. We are in the process of designing our noc from the groud up and would appriechite some input. We rare leaning twards Openview, but would like comments from others. thanks, Stan Helewics, Network Arcitect DTI Inteernet

3 2

Peering Policies and Route Servers
by Ali Marashi 06 May '96

06 May '96

I had a few questions to direct to the group at large that I believe are of a "network operational" nature. (1) I have heard that Sprint and MCI currently require an organization to peer with them at a minimum of three exchange points, where one must be on a different coast. I have been unable to confirm this directly from the sources yet. Would anyone care to share what knowledge they have on the subject? Are any other large providers (e.g., ANS) adhering to similar policies? As Internet traffic increases across the large backbones, could this be a trend that continues with other providers? (2) Could anyone share opinions/facts regarding why organizations may or may not exchange routes via the Route Servers rather than direct peering relationships at the NAPs? Thank you for any information/enlightenment. Ali.... +----------------------------------------+ | Ali Marashi | | interGlobe Networks, Inc. | | phone: 206.623.2222 fax: 206.623.0885 | | http://www.interglobe.com | +----------------------------------------+

17 22

Paul V's draft / origin of the "trouble" alias
by Dave O'Leary 05 May '96

05 May '96

As Cathy mentioned, we came up with the "trouble" alias at an IETf NJM meeting or some such a few years back. The reason it wasn't developed with the granularity that Dorian and others have described is that at that time, most of the providers only had a couple of people who did everything, so it didn't really matter how many aliases were used since the same couple of people answered them all :-). I expect that there are still quite a few providers who are running in this mode now.... dave

2 1

E.164 SMDS addresses
by R. S. Ashton 05 May '96

05 May '96

We are preparing an SMDS service offering on the AcNet Network. We have been unable to locate the party responsable for the assignment of the "Network" portion of our SMDS addressing schema. Does anyone out there know where one applies for such an identifier (E.164) for a new SMDS Network? Thanks for any advice one might offer. R S Ashton The Ashton Group P O Box 1175 Ashton Systems Corporation Chula Vista, CA 91912-1175 USA Ashton-International Corporation Voice: (619) 424-5362 Ashton Communications Corporation Fax: (619) 424-5621 AcNet, AcBone, AcNode (R) The Ashton Group Latin America Apartado Postal 11-436 Mexico, DF 06101 MEXICO Voice: (011-525) 230-2700 or Direct from the USA: (210) 668-6000 Fax: (011-525) 230-2701 or Direct from the USA: (210) 668-6001

2 1

Re: I-D (Re: Out of date contact information )
by Sean Donelan 04 May '96

04 May '96

Since an amazing number of sites can't even implement "Postmaster" I don't think expanding the number of aliases improves things. Also, I think some people may have the problem statement reversed. It isn't the "newbie" sites with the worst problem (Ok, they can be a problem), but the older, established sites. Information entropy sets in. When people move on to new jobs, old aliases don't get updated. With dozens of mailing lists, the probability all the lists get updated correctly approches zero. "Postmaster" (or any of the dozen more aliases Vixie's document sets out) will end up pointing to someone's mailbox who left years ago. The more specific the aliases, the less it will get used, and the less anyone will notice it isn't working until its too late (the smoke detector battery problem). I'd much rather concentrate on getting *ONE* point of contact working, following the axiom, put all your eggs in one basket and watch the basket. The other more specific aliases are nice, but things break. And when those other aliases break, who are you going to contact? If folks like Vixie's I-D, all I would add is an opening paragraph which says.... Before doing anything else, make sure POSTMASTER works, we mean it this time. BTW, whatever happened to Dan Long's second-edition of the NOC telephone book? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0