- Test - lists.nanog.org

Re: Peering is a lot of work.
by Justin W. Newton 29 Oct '96

29 Oct '96

At 10:25 AM 10/29/96 -0800, Kent W. England wrote: > But that >still begs the question of adequate defenses against default-pointing and >other bad effects and the business plan which still calls for all of this >to go away. One can point default at someone whether or not they are peering with the person. I am somewhat confused by the thought that people believe that they need to be peering with someone to have that person point default at them. I could (I don't, but I could), point default at /anyone/ on the same switch fabric as me, whether they are peering with me or not. Why do people continue to tie these 2 issues together? > >I now take my large ISP hat off and return to the other side of the table. >I find that many of these same problems affect me if I am a small or new >ISP joining up to a public exchange like the NAPs or MAEs. Now I get 10 >peering requests per week and I run down the list of issues and before I >know it, I'm figuratively back on the other side of the table wondering >how clueless the other party is. > >The public exchanges are useful for a variety of things and they are and >will remain important, but the pressure for private peering points is >considerable as I outlined. Take your high bandwidth traffic to/from your >true peers off to private interconnects and avoid the hassle of the public >bazaar for that part of the bandwidth. The traffic level justifies high >bandwidth pipes for private peerings. > >My suggestion to newcomers and small ISPs is to help advance your cause by >latching onto the route servers and RA contractors as a way to help >yourselves >and your backbone peers. You need a process which can demonstrate that you >are >addressing the issues I outlined above. If that process were to be accepted by >all, then perhaps it would be easier to convince the backbones not to slow >the >peering process, but fix it and maintain it, while continuing private >interconnects as warranted. > >Flame away, but try to stay on point. (Please don't respond and say that the >true figure is 50 peerings per week, even though it may be more accurate.) > >--Kent >Speaking as a PacBell NAP consultant. > > > > Justin Newton Network Architect Erol's Internet Services

3 2

Re: Should NSF declare victory and leave?
by William Allen Simpson 29 Oct '96

29 Oct '96

> From: Avi Freedman <freedman(a)netaxs.com> > Of course, I argues vehemently against the $10k/year CIX "tax", and this > would be a "tax" of sorts. > > Perhaps there's a better forum than the nanog list for discussion of this - > perhaps a BOF at the next NANOG meeting would be better. > Sorry, Avi, but I disagree. This is about group operations, and this _is_ the operations group! At least the discussion need to start and end here, so that everyone knowns what is going on. Although, technical details discussion could be a new separate list. Anyway, I'd be very happy if Daniel could help us figure out a way to be self-sustaining. If the CIX wanted to offer a RIPE-style of services, I'd be interested in participating! I think that the CIX bylaws and member agreement would need a few changes, but other than that, it seems positioned to take the role. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

Re: Airplane crashing into Atlanta-NAP
by Vadim Antonov 29 Oct '96

29 Oct '96

Michael Dillon <michael(a)memra.com> wrote: >The only joke here is that some people think that the Internet exchange in >a city the size and importance of Atlanta can be adequately housed on the >5th story of an office building. Hey, UUNET moved out of a 5th floor of an office building only two years ago... SprintLink's operations are at 4th floor of a building with a nice view on landing airplanes (so i can merge two threads :) --vadim

3 2

Peering is a lot of work.
by Kent W. England 29 Oct '96

29 Oct '96

At 04:21 PM 26-10-96 -0400, Robert Laughlin wrote: >I am trying to feel sorry for the poor burdened Large ISP.....:) > I sincerely do feel sympathy for those large ISP network engineers. I see their faces at NANOG over the years and wonder when they will ever get out from under it all. Sometimes I'm sure it feels like they would only ever be free of the pressure if they were to slip an ampersand in the wrong place in a cisco config file. :-) Being sympathetic, I could present some arguments in favor of private peerings from an outsider's point of view. 1) Workload. If I get 20 peering requests per week, how many are significant in terms of traffic flows? 2) Cluelessness. If I get 20 peering requests each week from people I never heard of, how do I estimate my level of effort to complete a standard agreement? 3) Damage. Since any peering I setup is subject to default-pointing, BGP route flaps, inaccurate prefix data, and a host of other problems that I find difficult to proactively defend, how much work am I going to take on maintaining any given peering? See 2) above. 4) Provisioning. With 20 peering requests per week, what is my level of effort for their provisioning process? How much work will I have to expend while my peer gets their connections up, their routers running, and their end of the BGP session going? 5) Staffing. How do I explain to my boss the value of putting 1.5 FTE on peering agreements out of my total staff of 3 FTE, when he is anxious for me to complete my AGS+ swap-out, my DS-3 backbone buildout, and the web farm facility? Sometimes I worry that the big ISPs are going to stop peering altogether (actually they stop and start) and sometimes I wonder why they keep going turning the crank on endless peerings with telcos, CAPs, regional ISPs, garage ISPs, Web-farms-masquerading-as-ISPs, etc. Of course, it's because it's good for business when market shares are less than 15%. Now, on the other hand, if there were a process (and it is forming) whereby an ISP went through a natural process registering routes, setting up connections, peering with the route server, attending NANOG tutorials given by the Routing Arbiter, reading the drafts and RFCs, asking questions of the route server support staff... it might be a whole lot easier to turn the crank on a lot of peerings and perhaps the backbone ISPs would start to think that this is the way to handle 20 peer requests per week. But that still begs the question of adequate defenses against default-pointing and other bad effects and the business plan which still calls for all of this to go away. I now take my large ISP hat off and return to the other side of the table. I find that many of these same problems affect me if I am a small or new ISP joining up to a public exchange like the NAPs or MAEs. Now I get 10 peering requests per week and I run down the list of issues and before I know it, I'm figuratively back on the other side of the table wondering how clueless the other party is. The public exchanges are useful for a variety of things and they are and will remain important, but the pressure for private peering points is considerable as I outlined. Take your high bandwidth traffic to/from your true peers off to private interconnects and avoid the hassle of the public bazaar for that part of the bandwidth. The traffic level justifies high bandwidth pipes for private peerings. My suggestion to newcomers and small ISPs is to help advance your cause by latching onto the route servers and RA contractors as a way to help yourselves and your backbone peers. You need a process which can demonstrate that you are addressing the issues I outlined above. If that process were to be accepted by all, then perhaps it would be easier to convince the backbones not to slow the peering process, but fix it and maintain it, while continuing private interconnects as warranted. Flame away, but try to stay on point. (Please don't respond and say that the true figure is 50 peerings per week, even though it may be more accurate.) --Kent Speaking as a PacBell NAP consultant.

1 0

Re: GigaRouter (Was Re: Cisco as Big Brother))
by Rob Liebschutz 29 Oct '96

29 Oct '96

> Jim Dixon writes: > > > Gated IMO is a good thing. The problem is the OS/hardware that it > > > runs on top of. I would dred having to install something that needs > > > a hard drive to route packets in a light-out POP. > > > > You don't need a hard drive. Use some of the money you saved by not > > buying C***o to buy lots of DRAM. Boot from floppy. > > > > Or even buy a flash-based hard drive emulator. Or combine the two > > solutions. > > I've been thinking about this. A while ago I saw a product that emulated > dual 1.4MB floppies in flash on an ISA card. This seemed like a good way > to start. Has anyone actually tried this? What flash product did you use? > > /a > > --- > Alexis Rosen Owner/Sysadmin, > PANIX Public Access Unix & Internet, NYC. > alexis(a)panix.com > I've been thinking about doing this for a while now. The only product that I've found so far is made by a company called MCSI ((619) 598-2177) , but the only thing I've been able to get out of them so far is that the darn thing emulates a DOS filesystem through the bios, though they referred me to another company that does the firmware for their card, and claimed that this company could do custom firmware for me. I think MCSI has a card that emulates a dual floppy as well. I'd love a card that just provided a single raw drive emulations, even IDE would be fine, so I could just copy a whole bootable file sytem image into it, but I guess 2 floppy images would suffice. The card that emulated an 8mb DOS filesystem was only around $300. Rob

25 43

RE: You are right [was Re: Ungodly packet loss rates]
by David Whipple 29 Oct '96

29 Oct '96

Jeremy, I would have to strongly disagree with you on many of your points below: First I have had experience running a 200 router network, made fully of Bay BCN/BNX's. This network was running OSPF, with several areas, and route aggregation. When the network was first implemented, we had some problems, however Bay was quick to resolve them. In addition, I have seen several case of Bay routers BGP peering, with Cisco's. This is a fairly straight forward thing to do (now), and Bay could probably give you a white paper describing any potential differences they have with Cisco. As for not supporting SNMP, that is simply crap, I have written SNMP code to pull many thousand entry route tables, and while this did have performance implications, most routers have performance implications when doing lot's of SNMP. I would throw away site manager (Bay's SNMP Manager), and learn the MIB if I had a large Bay network. Yes I would agree you have to have a good understanding of the MIB. But, I would add that with a Cisco you have to have a good understanding of IOS. Generally, I think Cisco has a stronger software platform, Bay a stronger hardware platform, but both are viable options, depending on your environment. Could you be running some 5.xx series code? Haven't we beat this Bay/Cisco thing to death yet... Thanks. David Whipple. >---------- >From: Mr. Jeremy Hall[SMTP:jhall@rex.isdn.net] >Sent: Tuesday, October 29, 1996 3:39 AM >To: alex(a)relcom.eu.net >Cc: nanog(a)merit.edu >Subject: Re: You are right [was Re: Ungodly packet loss rates] > >well if you're going to compare ciscos and bay networks routers, consider >that Bay networks supports Rip, OSPF, BGP, and EGP. They do *NOT* >support communities in their production software, and they have *NO* >intentions of *EVER* supporting confederations. In adition, to handle >subnets, where you want the thing to summarise a subnet into a classful >route, the Bay's solution is to drop the route entirely. They also don't >seem to understand how to aggregate routes. Their solution there is also >to drop the route. They do not appear to have the option to announce the >aggregate with the routes. They also do not appear to have the option of >aggregating since the option they provide does not work. Their SNMP >agent only works on a few platforms, and in order to adequately solve a >routing problem, you need to have a *GOOD* understanding of the MIB. The >last time I enabled syslog on the box, the router reloaded several times >within a 5 hour period, causing instability in our small network, small >meaning under 200 routes. I have fought with these things for 3 years >now and haven't seen much improvements. They have been promising NTP >support for quite some time now, since their routers don't have a >battery-powered clock. Maybe the reason they can switch packets faster >and more reliably than ciscos is because they are unable to be placed in >a situation to really test their skills. The items I have shown here >make it VERRY difficult to allow one of these things to perform with >full routing because you cannot determine what it will do. > -- > ------------------------------------------- > | Jeremy Hall Network Engineer | > | ISDN-Net, Inc Office +1-615-371-1625 | > | Nashville, TN and the southeast USA | > | jhall(a)isdn.net Pager +1-615-702-0750 | > ------------------------------------------- > >

1 0

RE: You are right [was Re: Ungodly packet loss rates]
by Peter Ford 29 Oct '96

29 Oct '96

Another pragmatic solution is to call the editors of comm week, network world, data communications and suggest that they might get a lot of mileage writing a story comparing and contrasting the performance of ISPs. They do this for routers, bridges, FR services so they can probably find a respectable consulting/measurement group to collect information. Some of this could be live empirical data and some of this could be survey. cheers, peter >>>> From Kent England > >Unfortunately, the practical solution to your problem is to shop around and >the more you know about your unique topological concerns the better off >you'll be. I wish there was a Net Consumers Report service that you could >subscribe to, but we aren't quite there yet. > >So, John, relax a little knowing you are fundamentally right and your >expectations are entirely reasonable and please accept my apology that the >Internet isn't quite ready yet to meet your needs. I take solace in the >fact that it has never been better and that it will continue to get better. > >--Kent >speaking as a long time Internet services person > >

7 13

Should NSF declare victory and leave?
by William Allen Simpson 29 Oct '96

29 Oct '96

> From: Gordon Cook <cook(a)netaxs.com> > According to reports posted to several mailing lists, the FNCAC > recommended that NSF wrap up its cooperative agreement with Network > Solutions after 4 years rather than 5. This would mean the agreement > would end March 31, 1997. What would happen were NSF to take this advice? > Much rejoicing! WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

6 5

Re: sprintlink filtering???
by Justin W. Newton 29 Oct '96

29 Oct '96

At 10:18 PM 10/28/96 -0500, Avi Freedman wrote: >Sprintlink has only ever claimed to implement inbound filtering. >Sean was hoping that other providers would filter inbound as well, >but that didn't happen for quite a while... Actually AGIS is filtering now according to Ptere's talk at NANOG. (Well, they will be as soon as he figures out what the swamp is I suppose). Justin "Some people never get sick of having a bad reputation" Newton Justin Newton Network Architect Erol's Internet Services

1 0

sprintlink filtering???
by Scott Mace 29 Oct '96

29 Oct '96

Hmmm. AS6302 a multihomed sprint/mci customer is announcing 204.70.195/24 (a MCI backbone network) to sprintlink, and spintlink is accepting it and announcing it to the world. Is sprintlink not filtering announcments they get from customers? Scott -- smace(a)neosoft.com - KC5NUA - Scott Mace - Network Engineer - Neosoft Inc. Any opinions expressed are mine.

4 4