September 1996 - Test - lists.nanog.org

RE: Peering versus Transit
by Chris A. Icide 30 Sep '96

30 Sep '96

Hrm, seems like only the To: and Subject: went through the first time?!? How I do love GUI mail interfaces....... > > From: Deepak Jain > > Subject: Re: Peering versus Transit > > Date: Sunday, September 29, 1996 5:31 PM > > > > > From: Deepak Jain > Subject: Re: Peering versus Transit > Date: Sunday, September 29, 1996 5:31 PM > .. > > What are the various opinions on this behavior? > Well, in most cases, the major provider will have a policy that states something like, "you are either a peer or a customer, pick one." Some providers MAY allow you to do both, under certain circumstances. As an upstream provider, allowing someone to peer while also buying transit requires special management. I would suggest two things. 1. If the ISP is using BGP for both sessions, have the ISP use two seperate AS numbers. 2. Have the ISP provide you a list of the specific routes of said ISP and ISP's customers, and implement a set of IP filters based on origin at your peer router. #1 really doesn't gain you much, but it does provide some assistance in trouble shooting a routing problem with the Peer/Customer. #2 is the big help. If the customer tries to default to you over the peer link, you would only take "peer" traffic. Also, it puts the onus of correct and sane route management on the Peer/Customer. If they don't manage thier routes correctly, they will experience some hard to trace routing problems. Chris A. Icide Nap.Net

1 0

RE: Peering versus Transit
by Chris A. Icide 29 Sep '96

29 Sep '96

> From: Deepak Jain > Subject: Re: Peering versus Transit > Date: Sunday, September 29, 1996 5:31 PM >

1 0

Re: Peering versus Transit
by Bill Woodcock 29 Sep '96

29 Sep '96

> * _Stealing_ is when B uses A's resources without permission or > agreement. Okay, for the sake of perpetuating an argument which should be at least a little more interesting to you, Randy, than you let on, let's try reversing those labels... A = Little ISP B = Sprint or MCI C = Other transit provider B collects money from B's customers in exchange for giving them access to resources on the Internet. Let's say that A, which uses C for transit, sells a connection to, for instance, a library, with the assumption that they're providing a connection which library patrons will use to browse resources on the Internet. Instead, the library, A's customer, puts up their card catalog and a popular reference web site. B's customers all want to get to A and download big honking gifs. The "legitimate" path for this would be through C, to whom A has to pay money, but B does not. So let's look at the proposed definition of "stealing" again: > * _Stealing_ is when B uses A's resources without permission or > agreement. In this case, the resource is transit purchased by A from C, for the use of A's customers. In this case, B is "stealing" A's transit resource for the use of B's customers, without compensating A. C is a hapless bystander who now has to carry a lot of unneccessary traffic which could be flowing directly between A and B. Please explain to me how this creates a better, faster, cheaper, more reliable Internet. -Bill ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

2 1

Re: Peering versus Transit
by Sanjay Dani 29 Sep '96

29 Sep '96

> What, providers not wanting to toast their backbone? When you are > connected to every major exchange and have a huge DS3 network, it cost > big bucks. We are building a small network and will be spending about > $250K a month on telco. Why should someone be able to just pay MFS $5700 a > month and make everybody transit bandwidth to him at just MAE-East? Perhaps the total amount of traffic the small guy exchanges with the rest of the Internet is that many times less than, say, MCI's traffic? No? I do see you point. You forgot to mention the other side. Why should a small ISP who carries, say, less than 5 GB of traffic a day, be forced to spend several million dollars a year to get optimum traffic patterns? I can see him making the choice of $20K/mo in order to be at a nearby exchange instead of $2k/mo for a T1 to a transit provider. Not $200K/mo. >It is asymmetrical, but say you are hosting a lot of www sites and have >mostly out-going traffic this solution will work and give you 10, or even >100 meg FDDI out, but only the size of your transit pipe in. > >The main problem with is is that A) It is not ethical B) the provider >you are doing this to will figure it out someday and see you in court C) >it is not nice. :-) Allow me to ignore A and C, but I can see the small guy making the following argument in court: Why should I pay transit provider X in order to send web contents to big guy Y's customers when Y is directly connected at an exchange? Seriously, if these issues are not resolved within the ISP community it won't be too long before courts force the issues like they did for domain name ownership. Sanjay.

2 1

Re: Best way to deal with bad advertisements?
by Scott Bradner 29 Sep '96

29 Sep '96

> Nope. More and more people will peer with each other but not with the big > 6 thus eventually creating a parallel universe at the core of the net gee that sounds like a great idea - two Internets for the price of one Scott

2 1

Re: Best way to deal with bad advertisements?
by William Allen Simpson 29 Sep '96

29 Sep '96

I have to agree with Dillon, the report was much more clear when names were named, contacts tried were listed, and the actual numbers and routes were specified. Although the report still wasn't complete (phone numbers, etc), which might have allowed someone around here to give out a better phone (if the contacts were obsolete). Anyway, in future, let's not try to be quite so polite. Clarity is necessary. But, at least some solutions were suggested, and we _can_ demonstrate that we are self policing! Overall, I feel that this is yet another example of why the Routing Arbiter is so important. We've experienced regular problems with bogus routes for many years. Time to go back and re-read all those RFCs on "policy-based" routing, which lead to BGP..... > From: Matthew Petach <mpetach(a)netflight.com> > JVNC.net is blackholing my routes. We've called their NOC, their > techsupport, and everyone listed in the whois listing. > > > In this way you accomplish the following: > > > > 1) clear identification of the problem, i.e. blackholed routes > > > > 2) clear identification of who seems to be causing the problem > > > > 3) clear identification of the contact means that you tried and the > > results or lack thereof obtained. > > 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

1 0

PAPER: An Overview of NSFNET 4090 Awards 1986-1996
by Tim Bass 29 Sep '96

29 Sep '96

I promised NANOG a paper on NSFNET funding and then dropped off the map (to get some real work done...). It is now available: An Overview of NSFNET 4090 Awards 1986-1996 ------------------------------------------- http://www.silkroad.com/papers/ (postscript format only) There is certainly plenty of controversial issues for the readers enjoyment ;) Comments, both positive and negative welcome (however the chances of getting a reply are better with positive comments :-). Best Regards, Tim --FAB08813.843987723/cactus.silkroad.com--

1 0

Re: Advice on dealing with Sprint
by craig＠kludge.net 28 Sep '96

28 Sep '96

At 10:03 9/27/96, Neil J. McRae wrote: >On Thu, 26 Sep 1996 15:57:06 -0700 > Vadim Antonov <avg(a)quake.net> alleged: > >> When i was at Sprint it was customary to ask customers to >> provide some assurance that routing information Sprint takes >> from them is going to stay sane. That was usually achieved >> by asking customers to send in their border configurations for >> review by SL engineering, and some formal criteria (like "no >> unfiltered IGP to BGP redistribution") was applied and said >> configuration had problems worked out before the actual peering >> was enabled. yes, true, but custom engineering was a 'free' service back then for customers. it was not built into the business plan as a revenue stream. this is exactly what Randy is talking about now. and was thought about years ago. it is really a service to offer customers and not a duty. >The solution I recommend is for the provider to charge T&M for dealing >with CPE which they do not supply. When presented with the real costs, >consumers tend toward wiser decisions. > >randy >> Anyway, that automatically made every customer with BGP to go >> down SCA (Special Customer Arrangement) route. I think sales >> didn't like that, for whatever reason, and i saw several attempts >> to make BGP peering a regular sale during my tenure there. >> I guess they succeded after coming with some "guidelines", but >> without any understanding of the issues involved. and engineering didn't like sales giving so many custom solutions away. by the time the order got to engineering back then the contract was signed, so the goal was just make it work. >> Somehow i became a big fan of Dilbert back then. >> >Vadim, >When you were at Sprint, I was at Demon and we BGP peered with >Sprint first using NetBSD/sparc IPX's with Morningstar PPP >then using BSD/OS and RISCOM N2 cards. One thing that I remember is >that your routers went insane _far_ more often that ours did. that was me Neil. what a hack, but the business side of the issue is that the service was up. gees, i even remember connecting an old 3Com router just to say the service was up. the issue was not that engineering could not make it work, but when it broke the NOC had no policy or procedure for some special configurations and hardware. which led to the SprintLink Customer Handbook. >INSC were never much use and the only way we got things done was to >cc: you and Sean in any reporting of faults. Nevertheless, both you >and Sean where always very helpful. aren't a high percentage of NOC's manage trouble tickets vs actually the responsible group for fixing? >Cheers, >Neil. >-- >Neil J. McRae. Alive and Kicking. E A S Y N E T G R O U P P L C >neil(a)EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor) > Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A> >Tell your Sprint sales folks that I said it was fine and approve the >SCA. If they have any questions, have them call me. > >-Hank Kilmer >Mgr Sprint IP OPS Engineering like any large organization, you need to manage the mis-information and Hank obviously did a fine job of that. -craig -------------------------------------------------------------------- Craig A. Haney Cando Consulting - The Internetwork People 703-448-9826 :Tel 2031 Madrillon Springs Court 703-448-9786 :Fax Vienna, VA 22182-3764 http://seamless.kludge.net

6 7

RE: Best way to deal with bad advertisements?
by Chris A. Icide 28 Sep '96

28 Sep '96

---------- > From: Avi Freedman > Subject: Re: Best way to deal with bad advertisements? > Date: Saturday, September 28, 1996 11:35 AM > > > 3) You can post to NANOG and other lists in an attempt to embarrass/ > get someone who knows the jokers to poke them. > IMVHO.. These are some of the problems that has resulted in some (if not all) of the major networks to re-evaluate thier routing policies. Weve had some routing problems generated by both customers and peers, including: A Peer re-advertising our routes to thier peers (and not being able to handle the traffic), causing service degradations. The same black-holing discussed previously (accidental). A multi-homed customer advertising our backbone routes. And of course the ever-present flapping peer who runs your router CPU out the ceiling. Because of problems like these, and the general trustworthiness of BGP4, the re-evaluation of peer requirements have been all but forced upon major backbone providers. Just imagine if you were UUNET, (or Sprint, or MCI, or anyone with heavy backbone traffic in general) and one of your BGP4 routing partners black holed part of your backbone... I've spent alot of time in a government regulated industry, and it's becoming evident that if we don't provide some sort of self-regulation, the government has a high likelyhood of sticking thier noses into this industry. Something gave us some freedom in my previous career was a self-policing industry organization. The whole idea was to not give the government any legitimate reason to have to regulate the industry. It was too late, but it did provide a little more freedom, that having the government do all policing. Pretty soon, something is going to happen here thats going to result in a fairly strong financial affect on some entity that will appeal to some authority, and the sprial will begin. It's my suggestion that the industry discuss the possiblity, and obviously problems of forming such an entity. It seems that the right people to start such a discussion will be present at NANOG. Just to toss some fuel on the fire, some topics might be..... * The evolution of peering agreements into "Traffic Intechange Settlements" * Methods of determining "value" of exchanged traffic. * A standard policy or requirement for peering at public exchanges etc... just a drop in the bucket. I'd be more than interested in such a discussion, BTW. Chris A. Icide Nap.Net

1 0

Re: Advice on dealing with Sprint
by Vadim Antonov 28 Sep '96

28 Sep '96

Neil J. McRae <neil(a)EASYNET.NET> wrote: >When you were at Sprint, I was at Demon and we BGP peered with >Sprint first using NetBSD/sparc IPX's with Morningstar PPP >then using BSD/OS and RISCOM N2 cards. One thing that I remember is >that your routers went insane _far_ more often that ours did. Take a look someday in the BSD/OS sources to find out who wrote RISCOM and ethernet drivers and PPP stack for it :) Unfortunately you're comparing apples and elephants. ICM routers were (and still are) the most convolutedly configured and most overtaxed routers in the universe. Running a week-old revision of cisco code, at that, because previous releases had bugs which made it even less useful. >INSC were never much use and the only way we got things done was to >cc: you and Sean in any reporting of faults. Nevertheless, both you >and Sean where always very helpful. INSC had a big staffing problem -- as soon as a new person learned stuff he's leaving for a salary two times higher, and for a much less stressful environment. Sprint management was never able to recognize the fact that Internet backbone skills is a seller's market. --vadim

2 1