- Test - lists.nanog.org

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

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