April 1996 - Test - lists.nanog.org

Peering Policies and Route Servers
by Ali Marashi 06 May '96

06 May '96

I had a few questions to direct to the group at large that I believe are of a "network operational" nature. (1) I have heard that Sprint and MCI currently require an organization to peer with them at a minimum of three exchange points, where one must be on a different coast. I have been unable to confirm this directly from the sources yet. Would anyone care to share what knowledge they have on the subject? Are any other large providers (e.g., ANS) adhering to similar policies? As Internet traffic increases across the large backbones, could this be a trend that continues with other providers? (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? Thank you for any information/enlightenment. Ali.... +----------------------------------------+ | Ali Marashi | | interGlobe Networks, Inc. | | phone: 206.623.2222 fax: 206.623.0885 | | http://www.interglobe.com | +----------------------------------------+

17 22

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: 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: Peering Policies and Route Servers
by rmg＠internex.net 30 Apr '96

30 Apr '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