October 1996 - Test - lists.nanog.org

Peering versus Transit
by William Allen Simpson 02 Oct '96

02 Oct '96

It has appeared to me for some time (and I've mentioned it before) that peering "restrictions" have gotten completely out of hand. I believe this is because terminology and agreements for "peering" and "transit" have become ill defined. I can see no justification under any circumstances why any provider would refuse to peer with another at an established exchange point for exchanging their _own_ customers' traffic! But note: this should not mean transit to others who are not customers of the provider, or to other exchange points around the world. I firmly believe that this is where the current model has gone awry. Worse, the current technology used at the exchange points could encourage abuse. What is to stop anyone connected to an exchange from simply dumping packets anonymously at the link level into the various inter-exchange providers' routers and getting free transit? Instead of negotiating with other providers for inter-exchange transit, I advocate that each attachment to an exchange negotiate with the exchange _operator_ for transit to other exchanges, and the exchange negotiate with inter-exchange providers for the aggregate. Separating the peering from transit provides greater clarity in agreements, with opportunity for better quality monitoring and control, while promoting greater redundancy in the Internet mesh, and greater competition in the inter-exchange transit market. ---- Until this happens, in the case in point, I would recommend that Wonderland (an org, not a net?) has no _transit_ peering to offer Sprint "in kind", as Sprint likely already has enough transit agreements to reach those same exchanges. Wonderland might have better spent its $5M+ per annum obtaining service from an existing trans-atlantic provider, or cooperating with another provider to join multiple links under existing transit agreements with Sprint and others, thereby reducing the trans-atlantic congestion. > From: Peter Galbavy <peter(a)wonderland.org> > > Besides, most of the major providers previously based the bulk of > > their peering 'requirements' on how many DS3s you had. Now most > > 'major' providers seem to have gone cold turkey. MCI, Sprint, and > > UUNET told me they won't peer with *anyone* new. > > But seriously, lets face it, DS3's are "cheap" and these people > want more customes no freeloaders. Like us, who are paying $5M+ a > year for a trans-atlantic DS3 and Sprint are very insistant that > we build a US network based on DS3s to peer with them, even with > the obvious fact that we have no US customers and have already paid > for a connection which in reality should be matched by the large > US carriers, rather than taking the piss once you have this > investment. I only mention Sprint, since the others you mention > are a tad more sensible, but still slow, while Sprint are in a > glacier. > 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

15 29

Re: Peering versus Transit
by Vadim Antonov 02 Oct '96

02 Oct '96

Sanjay Dani(maillists) <indus(a)professionals.com> wrote: > Heh. That's an example of how stupid technology is being > preserved by stupid legistlation. The laws regarding POTS are > generally legal fixes for techincal problems (like inability > to block annoying calls). >Forgotten the syn flood attack so quickly? Heard of IP spoofing? How long did it take for OS vendors to come up with fixes? A week. And for how long telcos can't do anything about annoying calls? A hundred years. That only confirms my point. >That does not make your one sided arguments stand any more than >they did. Goes to prove experience does not necessarily equate >insight into all aspects of the business. You have a stake in >perpetuating the status quo. Me in changing it because it >doesn't make sense. Sorry, to me what you tell does not make sense. If you want to change things you need to come up with something which actually works and build it. Then you'll get all the stake and will be as interested in perpetuating status quo. (BTW, hey, Sprint, where's my stake?) >No, it is beginning to suck. Have you checked reliability >of the backbones lately? I started a company to _do_ something about it, ok? >Sigh.. old hats like you have a >hard time realizing that old models have to, and will, >change. I suspect that i'm younger. I simply have better tuned B.S. detectors. Reading Pravda helps to learn that things often aren't what they appear to be. >PS. This is my last email on this topic. Thank you very much. --vadim

3 2

Re: "Basic BGP configuration problem"
by Mark Borchers 01 Oct '96

01 Oct '96

> > > >(a) In the past various Sprint people have suggested multihoming to > >different SprintLink POPs as a solution to their refusal to hear > >specifics of their aggregates from peers. Well, with four POPs having > >problems in the same day, perhaps a better term would be multi-screwed. > > We are working on adjusting our multihoming policies such that > multihoming with Sprint will be a viable solution for customers. > Excellent news. Is it official? Would you be willing to furnish any further details at this time? Mark Borchers InfiNet Network Engineering NOC: (757) 624-2295 ext. 3007 Disclaimer: My opinions, while sound, may or may not reflect those of the guys who own this outfit.

2 1

IRR route entries
by Marc Slemko 01 Oct '96

01 Oct '96

At http://compute.merit.edu/problems.html, there is a list of routes being advertised with ASs inconsistent with those in the IRR. I'm having a bit of trouble understading a few things. I will take an example of 192.139.72.0/24, which is one of our client's blocks. It shows up with an inconsistent origin AS in http://compute.merit.edu/stats/mae-east/problems/IRR/3561.960930.html: 192.139.72.0/24 192.41.177.181 (3561 577 852 6171 IGP) [ AS2493 AS2493] 6171 is the AS that it should be originating from, however according to this it appears that at least something thinks it should be coming from AS2493, who used to be our provider until perhaps six or eight months ago when we dropped them because they were simply too clueless to make things work. Our new provider is AS852; our advertisements were coming from them for a while until CA*net figured out how make things work with us talking BGP to AS852 who talks BGP to CA*net (AS577, at least for their backbone). You may remember me asking about advisory attributes a few weeks back; that was because CA*net was trying to tell us that the reason our route advertisements weren't making it past CA*net's borders was because our entries didn't have an advisory field in them. Thanks for the responses on that one; I thought the advisory attribute was obsolete, but CA*net insisted it was needed. Interestingly enough, the other change we told them to make in the routing database which they said wouldn't do anything was made and when it was made things did start working. <sigh> Anyway, back to the issue at hand: All our IRR updates are done into the CA*net routing database (crcd). current situation appears to be as follows: Script started on Tue Oct 1 09:24:40 1996 marcs@alive:/usr/var/tmp$ whois -h whois.canet.ca 192.139.72.0 route: 192.139.72.0/24 descr: NET-LI01 origin: AS6171 remarks: AGT Advanced Communications - WorldGate mnt-by: CANET-RC changed: wtowbin(a)agtac.net 960612 source: CANET route: 192.139.0.0/16 descr: NETBLK-CANET-192-139 origin: AS577 comm-list: CANET_PROXY_AGGRS mnt-by: CANET-RC changed: config(a)canet.ca 950419 source: CANET route: 192.139.72.0/24 descr: NET-LI01 origin: AS2493 mnt-by: CANET-RC changed: briand(a)nds.netsvc.istar.ca 960503 source: CANIX [From this, it appears to me like the first one should be preferred because of the date on it.] marcs@alive:/usr/var/tmp$ whois -h whois.ra.net 192.139.72.0 route: 192.139.72.0/24 descr: NET-LI01 origin: AS6171 advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(218) 5:3561(147) remarks: AGT Advanced Communications - WorldGate mnt-by: CANET-RC changed: wtowbin(a)agtac.net 960612 source: CANET route: 192.139.72.0/24 descr: NET-LI01 origin: AS852 advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(218) 5:3561(147) remarks: AGT Advanced Communications - WorldGate mnt-by: CANET-RC changed: wtowbin(a)agtac.net 960612 source: CANET [AFAIK, the above one was deleted from the crcd on 960612, at the same time the one above it was added.] route: 192.139.72.0/24 descr: NET-LI01 origin: AS542 advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(218) 5:3561(147) mnt-by: CANET-RC changed: config(a)canet.ca 960207 source: CANET [This one is left over from our old provider before I*Star bought them.] route: 192.139.72.0/24 descr: NET-LI01 origin: AS2493 mnt-by: MAINT-AS2493 changed: briand(a)nds.netsvc.istar.ca 960503 source: ANS route: 192.139.72.0/24 descr: NET-LI01 origin: AS2493 mnt-by: MAINT-AS2493 changed: briand(a)nds.netsvc.istar.ca 960503 source: MCI [The above two are from our old provider after they were bought by IStar, aka AS2493. Does the source mean that they are submitting them directly to ANS and MCI? My best guess on the situation is that, for some reason, AS2493 is submitting updates to MCI and ANS, who are their service providers, and they are being preferred over the correct ones.] marcs@alive:/usr/var/tmp$ whois -h whois.ans.net 192.139.72.0 route: 192.139.72.0/24 descr: NET-LI01 origin: AS2493 mnt-by: MAINT-AS2493 changed: briand(a)nds.netsvc.istar.ca 960503 source: ANS [ANS sure thinks AS2493 is the right one.] marcs@alive:/usr/var/tmp$ Script done on Tue Oct 1 09:25:15 1996 There are also a few different problems with some of our other addresses, for example (from http://compute.merit.edu/stats/aads/problems/IRR/3561.960929.html) 207.167.0.0/19 198.32.130.12 (3561 577 852 6171 IGP) [] There should be no old providers screwing anything up here, since this is a newish block. It shows up in the CA*net database, at whois.ra.net, but is still listed as not being properly registered. There are others that are showing up, but these seem to be the two types of problems that are showing up. Can anyone provide any helpful hints on what is going on? Thanks.

1 1

Re: CLASS B address sold (fwd)
by Vince Fuller 01 Oct '96

01 Oct '96

> I really didn't think that anyone would "buy" it. Two years ago when I was working on Wall St., we needed an entire class B, the brokerage payed $64,000 for it. Cool. If anyone else has $32,000 - $64,000 to spend on a /16 (aka class-B), please let me know. --Vince

1 0

Re: Peering versus Transit
by owen＠DeLong.SJ.CA.US 01 Oct '96

01 Oct '96

> Matt Zimmerman <mdz(a)netrail.net> writes: > > because you're using THEIR resources to do so, without > > explicit permission from them. > > That's a repetition of the same position that's been stated over and > over, without justification. If A sends to B directly in the absence > of an advertised route, A is "stealing" resources from B. If B sends > to A indirectly through A's transit provider, then B is "stealing" > resources from A. What makes the former case worse in your mind than > the latter, when it results in higher reliability, lower cost, and a > sounder architecture? > The latter is not "stealing", it's sending packets to the advertised route. The former is "stealing", it's sending packets to an unannounced route. Owen

1 0

Re: Advice on dealing with Sprint
by Darrel Lewis/TEIR/Thomson 01 Oct '96

01 Oct '96

Wait a sec, I was under the impression that multihoming with sprint was only a problem if you used PA addresses from Sprint. If you have PI addressing, or your addressing is from (for example) MCI, you shouldn't see a problem. Was I missing something? -D Darrel Lewis Network Engineer Thomson Electronic Information Resources dlewis(a)teir.com wsimpson @ greendragon.com ("William Allen Simpson") 09/30/96 04:57 PM To: jon @ worf.netins.net (Jon Green) @ Internet cc: nanog @ merit.edu @ Internet Subject: Re: Advice on dealing with Sprint Coming back to an old topic from whence we diverged, my advice would be _not_ to connect or multihome with Sprint unless they accept you as a peer and share the cost. Earlier, we have learned that Sprint doesn't multihome properly, as it deliberately ignores paths to its own "customers" seen from other ISPs even when its own lines are down. You learned that they have restrictive policies on routers. And more recently, we learned that Sprint has extremely restrictive policies on peering (exchanging routes). There really isn't much point to multihome with Sprint except to load share directly to Sprint's customers. You don't get any of the other benefits of redundancy. Why bother paying for the link and Sprint for the privilege? I can tell you, since my upstream provider switched a few weeks ago from multihome with Sprint and MCI, to nap.net and MCI, we've had _much_ better service! When nap.net has had problems, multihoming has actually worked correctly.... And multihoming with MCI and AlterNet seems to work well together, too. 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: Peering versus Transit
by William Allen Simpson 01 Oct '96

01 Oct '96

> From: "Craig A. Huegen" <c-huegen(a)quad.quadrunner.com> > Unfortunately, people who think non-operationally tend to have their heads > in the clouds. People who think both operationally and developmentally > are hard to find, but are the best at realizing better methods that are > scalable. > > "Old hats" might have a problem accepting some change, but they are a bit > wiser. Most "old hats" at least know what an RFC is. Or can at least > pass up marketing hype and find real-world results as a basis for judging > performance within a network (and I'm not just referring to hardware). > > The problem is that "new hats" tend to re-invent the wheel way too many > times. > I believe that you are being unfair to rather a large number of folks -- speaking as an "old hat", indeed probably much older hat than most of those on this list, who knows what an RFC is.... Indeed, I happen to think of folks like those that operate Sprint (et alia) as the "new" kids on the block. And we get more "new" kids all the time, such as yourself. Not everyone agrees on how the Internet should be operated, or what the model should be, or even that there should be a single model! We explicitly set things up so that many funding models could be tried. That assumed that all participants would peer with each other at neutral locations (the NAPs). The restrictive peering policies of a few large carriers are making that difficult. Some folks, both old and new, are exploring the issues and suggesting solutions. Please do not disparage such comments and questions. They were actually quite accurate and helpful. 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

Re: CLASS B address sold (fwd)
by Michael Dillon 01 Oct '96

01 Oct '96

---------- Forwarded message ---------- Date: Mon, 30 Sep 1996 20:42:46 -2900 (CDT) From: Jamie Downs <egon(a)atw.fullfeed.com> Reply-To: inet-access(a)earth.com To: inet-access(a)earth.com Subject: Re: CLASS B Resent-Date: Mon, 30 Sep 1996 19:42:57 -0600 (MDT) Resent-From: inet-access(a)earth.com > A few weeks ago...someone had a Class B for sale...is it still Too late. I'm told the closing bid was $32,000... > Rick egon ============================== ISP Mailing List ============================== Email ``unsubscribe'' to inet-access-request(a)earth.com to be removed. Wrap your text at 80 columns, don't post messages with long lines.

4 3

Re: "Basic BGP configuration problem"
by Vadim Antonov 01 Oct '96

01 Oct '96

William Allen Simpson <wsimpson(a)greendragon.com> wrote: >> For a good laugh, call: >> 800-669-8303 >> and select option 2. > >I did! Note that it was recorded at 7 pm, saying it would take 2 hours. >Here it is at midnight.... How many real engineers they got? One and unhappy one at that? When i was the only engineer there i had five times less customers to tend to; and i had quite a stressful life. The only reason for me leaving Sprint was woeful cluelessness of management about realities of labour market in the field. --vadim

1 0