- NANOG - lists.nanog.org

Re: MFS buys UUNET.
by Sean Doran 30 Apr '96

30 Apr '96

Sprintlink traditionally has approached the NAP on a customer basis to the greatest extent possible. We have tried quite hard to maintain both the appearance and fact of an arm's-length between NAP management and technical decisions and the two large public internets that Sprint runs. The NAP is a creature of the Government Systems Division, and there has always been a team of co-Principal Investigators who are not Sprint employees, who have done an excellent job of representing the Sprint NAP in public and in helping operate it and plan its future. Sprintlink, on the other hand, is a part of Sprint Business. The bulk of the engineering at the NAP has been done by my colleague in GSD, Steve Schnell, whom some of you will remember from IETFs and the like. Steve is (unfortunately, because he's VERY good) not directly involved with Sprintlink. The general policy at the NAP had been managed by its most recently departed P.I., Bob Collet, who had not been directly involved with Sprintlink for some months either. Naturally, we do talk, share opinions back and forth, support each other's efforts and products when practical, and so on, but I have observed that this talking and sharing opinions back and forth occurs between the NAP folks and other NAP customers too. 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. Sean.

1 0

Tucson Internet players team up
by Ehud Gavron 30 Apr '96

30 Apr '96

For Immediate Release: Tucson Interconnect Reaches New Milestone Wednesday, May 1st, 1996 08:00AM EST Contact: Ehud Gavron, ACES Research, +1 520 322 6500 ext 5 Fax: +1 520 322 9755 TUCSON, AZ -- Another group of Internet Service Providers have teamed up to avoid network congestion. While other providers fill up the clogged arteries of the national backbones, ACES Research, Tucson's High-Speed provider has created a local point where Tucson-serving providers can communicate with each other. ACES is happy to welcome Primenet and Internet Direct to the Interconnect. They join StarNet, RTD, The River, Opus One, Zekes (Safford), and El Imparcial (Hermosillo, Mexico). The Tucson Interconnect avoids and prevents Internet network slowdown by keeping local communication traffic in town, and utilizing the national backbones for external traffic. "We don't waste bandwidth, " explained Matt Ramsey, ACES Network Manager, "this way if we need to send packets to Primenet, or Internet Direct, we send them directly. Not through Sprint, or MCI, any other crowded part of the Internet backbones. Packets from one side of Tucson to the other don't go through California, Texas, or Colorado." "The addition of Primenet and Internet Direct to our interconnect allows all of Southern Arizona traffic to stay in Southern Arizona," said Ehud Gavron, Senior Partner of ACES Research. "All the big providers except the University are now exchanging packets here." The Tucson Interconnect is a local interconnect offering high-speed access to Internet Service Providers serving the Tucson area. It is located at 4003 East Speedway, Suite 123, Tucson Arizona, 85712. Connection is via point-to- point circuits or PSDNs.

1 0

Re: Peering Policies and Route Servers
by John Curran 30 Apr '96

30 Apr '96

At 2:12 PM 4/30/96, Matt Zimmerman wrote: >... >Setting aside the technological barriers to such an arrangement, an >optimal configuration would be one in which all routing entities peer with >one another at all available locations, so as to provide the shortest path >between routing communities. I believe that the optimal configuration would actually involve only one routing entity and no peering at all. I'm pleased that instead we've implemented a model which (while not optimal) allows for a growing Internet service provider industry. Solutions which are optimal under one constraint tend to degenerate in the real world. Shortest-exit routing and equivalent distributed peering is used to avoid settlements for transit costs. If there's a strong demand for dissimiliar peering, then it's likely to appear with settlements. /John

2 1

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

30 Apr '96

> 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. ---Peter

2 1

Re: Peering Policies and Route Servers
by salo＠msc.edu 30 Apr '96

30 Apr '96

> To: NANOG <nanog(a)merit.edu> > Subject: Re: Peering Policies and Route Servers > Date: Tue, 30 Apr 1996 10:49:02 -0400 > From: Enke Chen <enke(a)mci.net> > [...] > Regarding the RS (I have many friends there, and they have done many > good work), let me echo the fundamental issues that Steve Heimlich > has pointed out, would you rather have your peering policy enforced by > yourself or by a third party? Would you rather develop a dependency > on a third party (which may not be there a few years down the road) > to deliver the critical service or depend on yourself? This sounds like an argument for an NSP to build their own routers. (Oh,I forgot, that has already been tried...) More seriously, I would like to think that the analysis performed by the NSPs is a bit more detailed. Perhaps the challenges include: o the routing arbiter not having a long-term track record as a vendor against which to compare internal efforts, or as you mention an uncertain future; o the route servers don't save an NSP all that much work; o the NSPs haven't bothered to do the analysis; or o ... -tjs -tjs

3 2

Re: MFS buys UUNET.
by Paul Ferguson 30 Apr '96

30 Apr '96

The press release is on the UUNET homepage at http://www.uu.net. - paul At 09:56 AM 4/30/96 -0700, 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% :) > >The wire story was short on content. Noone of the on-line newspapers >have the story up yet. Needless to say, UUNET's gonna be inundated >with questions at I-World today. > >Speaking of which, I gotta go there right now ... :) > > rob gutierrez / internex information services > > >

1 0

enormous instabilities @ CA 0800 EDT daily?
by Sean Doran 30 Apr '96

30 Apr '96

I was looking over some trend graphs which I remember to look at from time to time and noticed that there recently has been a large level of instability between 7 and 9 a.m. Eastern (D.C.) time, with the worst period occurring at about 0800. The instability graphs that compute.merit.edu puts together shows a very similar trend, at least for the past few days. Is anyone else seeing this? If so, does anyone have any theories? I'd really like to see this fixed. Sean.

2 1

Re: Peering Policies and Route Servers
by Paul Ferguson 30 Apr '96

30 Apr '96

At 10:12 AM 4/30/96 -0700, Cengiz Alaettinoglu wrote: > >Route Servers are dynamic, they process upto 6000 routing updates a >minute (see http://compute.merit.edu/stats/mae-east/instability) > >Route Servers are reconfigured with up to date policy 6 times a day, >i.e. every four hours. Hence, a brand new route registered in IRR may >not be announced by the route servers to the NSPs whose policies are >prefix based for up to at most 4 hours. I think this is what you are >referring to. > Cengiz, thanks for the clarification. - paul

1 0

Re: Peering Policies and Route Servers
by Paul Ferguson 30 Apr '96

30 Apr '96

At 12:09 PM 4/29/96 -0700, Ali Marashi wrote: > >I did not mean to imply that an organization was "not allowed" to exchange >routes with the Route Servers. I was trying to learn why an organization >"may choose" or "may not choose" to exchange routes with the Route Servers >rather than use direct peering relationships with other organizations. > >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. I'm sure someone will correct me if I'm remiss. :-) - paul

3 2

MFS buys UUNET.
by rmg＠internex.net 30 Apr '96

30 Apr '96

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% :) The wire story was short on content. Noone of the on-line newspapers have the story up yet. Needless to say, UUNET's gonna be inundated with questions at I-World today. Speaking of which, I gotta go there right now ... :) rob gutierrez / internex information services

1 0