- Test - lists.nanog.org

Re: Out of date contact information
by Sean Doran 01 May '96

01 May '96

Oops, sorry about that. Fat Fingers Sean. (trouble(a)sprint.net)

1 0

Re: Out of date contact information
by Sean Doran 01 May '96

01 May '96

1 0

that observation....
by bmanning＠isi.edu 01 May '96

01 May '96

Forwarded w/o attribution. (perhaps this is not appropriate but I do feel this way alot... :) -bill There are really only <n> discussions on NANOG/CIDRD, which occasionally flare up like spontaneously combusting drunks on rs-talk, iepg, and ietf as well. Herein, a kind of Meta-FAQ, a Field Guide to the Meta-Wars: 1. InterNIC-bashing, complete with loud revisitings of the legitimacy of the InterNIC in particular and the entire registry concept in general. Recently this is characterized also by thundering herds of lawyers explaining how the Internet must change to accommodate American trademark law and repeated threats to sue the IANA by various people with 386s and 56k lines who want to run top-level domain registries. Inevitable conclusion: We need a heavily regulated, global free market in DNS registries, as well as more root servers and the IANA to be shot or elected or crowned king or something. 2. The IP Address Allocation wars, complete with Noel Chiappa's brilliant explanations of the relevant graph theory, "Life is unfair" lectures from large (or non) ISPs, "The net is unfair" whines from small (or wannabe) ISPs, and many non-lawyers ranting about restraint of trade and other topics in antitrust law and public policy. Inevitable conclusion: We need a heavily regulated, global free market in address space and routing advertisements, as well as bigger routers and faster light. 3. ISP bashing, with elements of both the above plus much more, inevitably including Sprint bashing wrt route filtering and NAP policy. Inevitable conclusion: Sprint is Babylon and Sean Doran is the antiChrist. Inevitable conclusion: everybody should peer with the Route Servers, except for when everybody should blow them up and peer with everybody down to Bill's Bait & Sushi Shoppe for free. Coming attraction: Will MFuuSoftNet be an Even Bigger Threat to The Net As We Know It. Meta-conclusion: it's sort of reassuring. "Imminent collapse of the Internet, GIFs at 11:00".....

2 2

Re: that observation....
by Paul Ferguson 01 May '96

01 May '96

This definately a keeper for the personal archives. :-) - paul At 01:08 PM 5/1/96 -0700, bmanning(a)ISI.EDU wrote: >Forwarded w/o attribution. >(perhaps this is not appropriate but I do feel this way alot... :) > -bill > >There are really only <n> discussions on NANOG/CIDRD, which >occasionally flare up like spontaneously combusting drunks on rs-talk, >iepg, and ietf as well. Herein, a kind of Meta-FAQ, a Field Guide to >the Meta-Wars: >

3 2

Re: Sprints definition on NAPs (question)
by Justin W. Newton 01 May '96

01 May '96

At 09:14 AM 5/1/96 -0400, you wrote: >On Wed, 1 May 1996, Jeremy Porter wrote: > >> >|} > the Sherman Act (if memory serves). These types of problems can be quite >> >|} > nasty, involving treble punitive damages. >> >> Unfortunately for Nathan, this above is wrong. >> >> There are very real engineering reasons for not peering >> if someone is at one NAP/MAE. Also since Sprint and MCI >> do have published policies, if they made exceptions to them >> they could get sued for discriminating against some competators >> (not all, makes a big legal difference). > >Ok, so what about Interpath, CAIS, and a bunch more that are peering with >MCI and are at only 1 NAP? Probably because they were peering with MCI before the policy, but thats just a guess. Justin Newton * You have to change just to stay Internet Architect * caught up. Erol's Internet Services *

1 0

Re: Peering Policies and Route Servers
by Justin W. Newton 01 May '96

01 May '96

At 07:45 PM 4/30/96 -0400, you wrote: >> Heck, if all I needed was a connection to the MAE to get global routing, >> I'd run a ds-3 to my house and be done with it (its only about 3 miles >> from my house to MAE East, maybe 5). > >Hmm...how many PC's and workstations do you have at home to fill a DS3 >with? ;-) Well, it'd be good for IOS code downloads ;) > >> >(2) There is no connectivity gain for a national provider to peer >> > with a single-attached organizaiton as all these organizations have >> > transit providers that are present at multiple interconnects. >> This is a chicken and egg scenario. If CompanyX could get to everywhere >> without buying a link to an upstream as well as their connection to the MAE, >> well, then they wouldn't buy the connection to the upstream provider. The >> real point should be that losing connectivity to all whopping X,000 of their >> customers where X is between 1 and 9 is really not all that big a deal, >> netwise. > >Not a big deal to whom? It certainly is to those customers, and to >CompanyX. And probably to a percentage of the rest of the net.population, >who now can't get to Joe's Whiz-Bang homepage. And who's making a >decision on whether they have connectivity? > >(or what does this have to do with chickens and eggs?) Its no big deal to BigBackboneDude. That /seems/ to be the attitude that some of the larger backbone providers take, and I am not sure that I completely blame them. I.e. Is it worth this level of effort both for me and for my routers to add connectivity to this level of hosts? If the number of hosts is large it obviously is. If it is small it may not be. The problem is deciding where that line is. >[RS peering] >> As a representative of Erol's I can say that I would want to directly peer >> with MCI. Sprint, ANS, UUnet and a few others, all of the people annoucing >> one or two routes I would likely be better serverd as hearing through the RA >> until which time as I have lots of free processor/memory/everything else on >> my router doing the peering, at which point I would be more than willing to >> peer with anyone who I could be assured was technically competent. >> (Basical;ly I am not /dependant/ on getting to a lot of those smaller sites, >> so I don't very much care if I lose them somehow). > >This is a risky attitude. Simply because those sites are smaller than you >doesn't mean you can force them down by refusing to peer. You do have a >relatively large dialup customer base, but explaining to your customers >exactly why they can't get to <interesting route> from your service, but >can from GrumbleSmurf down the road, can be tricky when you burn bridges. >I'd place more emphasis on the "technically competent" aspect of your >policy than the "I don't much need your routes anyhow" motivation. You're misreading what I am saying, hopefully not intentionally. What I am saying is that Sprint, MCI et al are large snugh that they are absolutely critical that they work 100% of the time, or as close to 100% of the time as is possible. If the route server hiccups, or they start implementing wierd policies that cause me to lose connectivity to those people for /any/ amount of time I am in deep kimshee. If the route server screws up and decides I can no longer talk to JustinsTinyISP, I have a little time to ditch the route server and set up a private peering session with JustinsSmallISP before it becomes a critical issue. It is not that I don't want to hear the routes for that provider it is simply that it may not be worth the resources both on the router and in human manpower to setup a private peering session with them. The routers do have limits you know. There is no "I don't much need your routes anyhow" motivation anywhere. Justin Newton * You have to change just to stay Internet Architect * caught up. Erol's Internet Services *

1 0

re: Sprints definition on NAPs (question)
by John Scoggin 01 May '96

01 May '96

The other question that should be asked (and I hope some folks have looked at this) is whether this rule is in fact arbitrary. If there is no sound ENGINEERING reason, it may constitute "restraint of trade" under Chapter 2 of the Sherman Act (if memory serves). These types of problems can be quite nasty, involving treble punitive damages. I have never been a lawyer (or played one on TV :-), but I can recall handling disbursement of suit awards while a programmer in a bank Trust Department...

7 8

Re: Peering Policies and Route Servers
by Peter Lothberg 01 May '96

01 May '96

> > (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? > > I know of no case where an organization "may not" exchange routes > with the Route Servers. I do, AS1800.. --Peter

3 2

RE: MFS buys UUNET.
by Hank Nussbacher 01 May '96

01 May '96

On Tue, 30 Apr 1996 09:56:38 -0700 (PDT) Rob Gutierrez wrote: >As somebody mentioned today, an AP wire story came across this morning >that MFS is _buying_ UUNET for $2 billion. Shareholders are looking at >getting 1.78 shares of MFS for each of their shares. Apparently, they >got 62% of the voting shareholders to agree (ie: who owns a couple >of large chunks of UUNET?). > >Remember that Microsoft already has their claws into UUNET for 13% :) > According to the Internet Millionaire's Home Page: http://www.pulver.com/million/ Rick Adams, Chairman UUNT 4,875,000 $279,703,125 Microsoft UUNT 4,164,000 $238,909,500 Menlo Ventures, VC UUNT 3,229,698 $185,303,922 New Enterprise, VC UUNT 3,229,698 $185,303,922 Accel, VC UUNT 3,210,320 $184,192,110 New Enterprise/Barris, VC UUNT 3,229,698 $185,303,922 Menlo Ventures/Jarve, VC UUNT 3,229,698 $185,303,922 Accel/Patterson, VC UUNT 3,210,320 $184,192,110 John Sidgmore, Pres & CEO UUNT 1,244,100 $71,380,237 Ain't infotechnology fun :-) > > rob gutierrez / internex information services > ---------------------------------------------------------------------- Hank Nussbacher Manager, Internet Technology Programs Telephone: +972 3 6978852 Vnet: HANK at TELVM1 Fax: +972 3 6978115 Internet: hank(a)ibm.net.il ---------------------------------------------------------------------- IBM Israel 2, Weizmann St. Tel Aviv 61336 ====== ======= === === http://www.ibm.net.il/ ====== ======== ==== ==== Dialup registration: 177-022-3993 == == == ==== ==== Company services: 03-6978663 == ====== == === == Internet sales fax: 03-6978115 == == === == = == Enquiries: info(a)ibm.net.il ====== ======== === === Technical support: noc(a)ibm.net.il ====== ======= === === ----------------------------------------------------------------------

1 0

Re: Inter-exchange media types
by Hank Nussbacher 01 May '96

01 May '96

On Thu, 25 Apr 1996 12:34:25 -0400 Curtis Villamizar wrote: >For many products, there is a big difference between how many >interfaces physically fit in the card cage and how many actually work >under a fairly heavy load. Have you tested a 12 port switched 100 >Mb/s ethernet under load? The DEC gigaswitch has been tested under >load and has held up so far under load. The Cisco 5000 may bridge >better than it routes since there is no route change to deal with, but >I'd be a bit worried about deploying without stress testing. > >The problem for the major exchanges may soon be what to do when the >gigaswitch runs out of bandwidth. > >Curtis > The Feb 1996 issue of Data Communications ran a benchmark on these switches along with a few others. I will just summerize the Digital and Cisco info that they state: Cisco Catalyst 5000 - Full duplex Ethernet, half duplex FDDI, full duplex fast Ethernet; Max: 96 Ethernet, 4 FDDI, 50 Fast Ethernet; Price: $22K for chassis, 24 Ethernet ports, 2 FDDI Digital Gigaswitch - Ethernet, Full Duplex FDDI; Max: 12 Ethernet, 8 FDDI; Price: $21K for chassis, 24 Ethernet ports, 2 FDDI Benchmarks: a) % of frames delivered without loss (100% load on 40 ports): Burst size (in 64 byte frames) 24: Cisco 99% DEC 76% 62: Cisco 100% DEC 75% 124: Cisco 100% DEC 65% 372: Cisco 100% DEC 51% 744 Cisco 100% DEC 49% b) % of frames delivered without loss (64 byte frames, 24 frame bursts on 40 ports): 70%: Cisco: 100% DEC: 81% 80% Cisco 99% DEC 79% 90% Cisco 99% DEC 85% 100% Cisco 99% DEC 75% 150% Cisco 99% DEC 22% c) Per port thruput: 64 byte frame per second (24 frame bursts on 40 ports) Cisco: 4891 DEC: 4391 d) Latency (microseconds) - 64 byte unidirectional traffic across 100Mb backbone Cisco: 79 DEC 179 Bottom line: The Gigaswitch performed the almost the worst (Fibronics took that honor) and the Cisco performed the best. Perhaps it is time to revisit the Gigaswitch technology? ---------------------------------------------------------------------- Hank Nussbacher Manager, Internet Technology Programs Telephone: +972 3 6978852 Vnet: HANK at TELVM1 Fax: +972 3 6978115 Internet: hank(a)ibm.net.il ---------------------------------------------------------------------- IBM Israel 2, Weizmann St. Tel Aviv 61336 ====== ======= === === http://www.ibm.net.il/ ====== ======== ==== ==== Dialup registration: 177-022-3993 == == == ==== ==== Company services: 03-6978663 == ====== == === == Internet sales fax: 03-6978115 == == === == = == Enquiries: info(a)ibm.net.il ====== ======== === === Technical support: noc(a)ibm.net.il ====== ======= === === ----------------------------------------------------------------------

4 3