- Test - lists.nanog.org

Re: Peering Policies and Route Servers
by Justin W. Newton 30 Apr '96

30 Apr '96

At 10:49 AM 4/30/96 -0400, you wrote: > Unrestricted peering policy would accelerate rolling of the > snowball, and lead to the collapse of an interconnect. In order > for Internet to survive, this snowball effect got to stop. ... or the hardware has to be manufactured to support it. /Some day/ there are going to be 500 companies at the interconnects, and they are /all/ going to be important players, or that is at least a likely scenario. Will this be next year? No. Unrestricted peering policies are gone, the internet is not what it once was. "There was a day when anyone could peer with anyone..." Yeah, there was also a day when the backbone was uucp serial links, I don't hear you mourning that. (generic you, not specific) The internet has frown. There are some things which can be done on a handshake and a smile, a global network isn't one of them. 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). > >(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. > >(3) There is a huge investment involved to build a national backbone. > Many providers currently do "hot-potato" routing (closed-exit) > because of this cost. Peering with a single-attached organization > would require much more backbone investment as traffic to this > organization needs to be carried across the backbone, while the > cost for this single-attached organization would be small (one > DS3 to an interconnect). This is somewhat of a paper tiger. This singly homed is also not nearly so likely to generate as much traffic as some of the larger backbones, and you are only carrying /your customers'/ traffic to them. One way or another, so long as you are peering and not transiting, any packets that cross your network are for the good of /your customers/. Please keep that in mind, but I digress... > >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? 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). > >-- Enke (speaking only for myself) > > > Justin Newton * You have to change just to stay Internet Architect * caught up. Erol's Internet Services *

3 2

Re: MFS buys UUNET.
by matthew＠scruz.net 30 Apr '96

30 Apr '96

Original message <199604301656.JAA02668(a)victory.InterNex.Net> From: rmg(a)internex.net (Rob Gutierrez) Date: Apr 30, 9:56 Subject: MFS buys UUNET. > > As somebody mentioned today, an AP wire story came across this morning > that MFS is _buying_ UUNET for $2 billion.... Many months ago, it was explained to me in great detail why Sprint, et. al., liked peering at MFS exchange points (because MFS is a neutral party, ie. not an NSP) and didn't like hearing about exchange points run by NSPs or ISPs (as some of the smaller regional points are). Any comment from the larger NSPs about what this does to that theory? -matthew kaufman matthew(a)scruz.net

2 1

Re: MFS buys UUNET.
by jbrowne＠alink.net 30 Apr '96

30 Apr '96

At 09:56 4/30/96, Rob Gutierrez wrote: >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. Strangely enough, I first heard of this on CBS Radio News. There is quite a bit of content at www.uu.net. I'm happy with the announcement. Hopefully, access to cheaper physical transport will mean lower rates from UUNet. Jim Browne | |jbrowne(a)alink.net V.P., Engineering | http://www.alink.net |(408) 720-6161 A-Link Network Services, Inc.| Go Illini! |(408) 720-6160 FAX

1 0

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