- Test - lists.nanog.org

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

Re: MFS buys UUNET.
by John Curran 01 May '96

01 May '96

At 4:17 PM 4/30/96, Sean Doran wrote: >... >In my opinion, provided that the relationship between Alternet's >engineering and the team at MFS Datanet which manages >the MAEs continues as it has, and the new merger continues >to support both sets of customers at least as well as the >individual companies used to, I see no issue on this particular front. I concur. /John

1 0

Re: Peering Policies and Route Servers
by rmg＠internex.net 01 May '96

01 May '96

> > >In other words, what is the value for an organization to utilize the Route > > >Servers? And if there is value, why is everyone not doing it? > > > > One detractor, to the best of my knowledge, is that the route servers are > > not exactly 'dynamic', meaning that they are updated a couple of times > > during the course of the day to reflect any changes in routing policy. > > Therefore, the possibility for blackhole'ing packets exists. > > There is no possibility for blackholing packets. Blackholing means > advertising a route and then not delivering the packet. I'm afraid that I did run into a situation where the route was advertised and the packet was blackholed. I started to peer with AS-2882 at the PB NAP, and I accepted routes from it for another ISP (no finger pointing today -- sorry). Well, the ISP didn't have the VC map config'd in their router, and that route became preferred after a glitch somewhere in their network. Well, since the med's were the same in the routes we were sending to them, they preferred the PB NAP route after their glitch. Needless to say, not a happy situation. Then, of course, there was yet another ISP we were waiting for their router to be config'd, etc. Well, I didn't have time to wait for my advisory to be updated, so, brute force was utilized: (config-router)# no neighbor 198.32.128.130 This was more out of frustration in that I had my config's ready and I agreed to accept and give routes via the R/S. Needless to say, I'll decline to accept/advertise to that peer until I can ping them. Yes, I know this is more of a initial config issue, but the route servers were "in the way" at this point. Can You Say "neighbor x weight 1" next time :) rob gutierrez / internex information services

2 1

Re: Inter-exchange media types
by Peter Lothberg 30 Apr '96

30 Apr '96

> Peter Lothberg <roll(a)stupi.se> writes > * > Dtatacom tests were performed in the 10/100 setup. Obviously > * > the Fast ethernet switches had an advantage over the FDDI > * > switches since Fast ethernet and conventional ethernet work > * > with the same frame types. FDDI switches on the other hand > * > has to convert ethernet frames to FDDI frames and vice versa. > * > Todays NAPs in most cases are not 10/100 set up. It is more like > * > DS3/100/100 setup where routers are feeding traffic into the Gigaswitch > * > using FDDI and since HSSI and FDDI is using same MTU size, no > * > fragmentation is involved. > * > * Both 10 and 100 ethernet use 1500 byte mtu. > * > * And remember that the characteristics of a loaded exchange is very > * diffrent between ethernet and token-ring. > > And then there is always the possibility to run 100BT in > full-duplex rather than half duplex... > Asuming that you have a switch in the middle that can buffer the BW/Delay quota. How many of the 100Mbit ether switches has 4MB per port in buffering? (token out for lunch and the router buffers) ((and some fddi switches can talk full-duplex)) --Peter

2 1