- Test - lists.nanog.org

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

Re: "Basic BGP configuration problem"
by William Allen Simpson 01 Oct '96

01 Oct '96

> From: "Bradley Dunn" <bradley(a)dunn.org> > Date: Mon, 30 Sep 1996 23:34:48 -0400 > > 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.... You know how it is, those small, naive ISPs are having trouble with a correct BGP configuration, ruining everyone's peering! ;-) Anyway, I'm actually thankful they _have_ such a status message! This is a real improvement over recent times past, as folks can figure out what is wrong, and know what trouble ticket has been registered. I thank Sprint for improving that part of their service.... 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: Peering versus Transit
by Sanjay Dani 30 Sep '96

30 Sep '96

> From avg(a)quake.net Mon Sep 30 19:05 PDT 1996 > >I didn't know access service providers are not paid by their > >web browsing clients. > > The cost of transaction is split between content providers and > clients. Is this that hard to understand? I guess you missed the sarcasm. Try applying your statement to your own argument and see who is trying to fleece whom? This is homework. No need to fill up my mailbox anymore. > 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? > FYI -- i had a more than an engineering role in service providers > covering together all time zones on this planet. One of them > was the first ISP in 16-odd countries. Another was the first > commercial DS-3 backbone in the world. 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. > So why you just don't learn why the present system is here, > and why it delivers while others only promise. No, it is beginning to suck. Have you checked reliability of the backbones lately? Sigh.. old hats like you have a hard time realizing that old models have to, and will, change. Sanjay. PS. This is my last email on this topic.

2 1

Re: Peering versus Transit
by Eric Sobocinski 30 Sep '96

30 Sep '96

On Mon, 30 Sep 1996 at 18:44 PDT, Vadim Antonov <avg(a)quake.net> wrote: > > Michael Dillon <michael(a)memra.com> wrote: > > >What if you are FlyBite Couriers Inc. and you have a parcel for Bigco > >Inc's art department. The sign on the door at BigCo says "No deliveries, > >go to the back door, this means you!". But you are to lazy so you walk in, > >argue with the receptionist for a minute and dump your package on the > >floor. She has to call in one of the mailroom people from the far end of > >the building complex to deliver the package. > > Er. That situation may actually end up in court. Legally, the parcel > is still in posession of FBC Inc. -- nobody signed the receipt and > nobody left drop-shipment authorization. So sender of the packet > has all reasons to sue FBC Inc. > > So, thank you for playing, but the analogy is somehow wrong. > > > It is not a "theft", it is more like trespassing. It is illegal and > > covered by codes related to unauthorized use of equipment. > > FlyBite Couriers has caused Bigco to spend their own resources in order to > deliver the package to teh art department. Is FlyBite Couriers guilty of > theft? No. Are they guilty of trespass? I don't think so. Actually, they *are* guilty of trespass! The owner has the right to restrict some or all uses of a piece of property. BigCo clearly posted that a particular use (delivery of packages) was banned on their property. Legally, this would be no different than if they had posted "no hunting" and would be enforced the same way. The fact that the owner encourages the same activity on an adjacent property (at the back of the building) is irrelevant. Equally irrelevant is suitability: It doesn't matter that delivery in the lobby might seem preferable. The analogy holds well enough that you could apply the same legal remedies to unwanted delivery of network packets as you would for physical trespass. Upon discovery, the "trespassed" party somehow warns the offending party of their transgression in some sort of well-documented way (grievance, cease-and-desist order, injunction). Should the offending party repeat the action, you have evidence of at least negligence and should have no problem pressing a suit in an appropriate court. All of this is void, of course, if there's some law or superceding agreement that allows such deliveries, regardless of what is "posted". I admit that I don't know what the NSF and various NAP hosts require as far as peering at NAPs, but everything I've heard so far implies that they don't require peering except in very specific circumstances. > Analogy was wrong. They're guilty of fraud if you want legal definition. > They promised sender to deliver parcel, took money and didn't. I find the analogy was right, but they may also be guilty of fraud depending upon the local legal definition of delivery. If so, it could probably be prosecuted with or without an accompanying trespass charge. And, of course, your mileage may vary in an international or non-USA situation. > >This makes good sense too. However, there are always two sides to every > >traffic engineeriung question... > > Exactly. That's why traffic engineering at IXPs is always is a matter > of mutual agreement. Dumping packets at somebody is doing something > without an agreement, ok? Agreed. > --vadim --eric Disclaimer: Of course I'm not an attorney, else the above advice would have cost you plenty. :-) Eric P. Sobocinski | Internet: sobo(a)merit.net | 1075 Beal #2220 Merit Computer Network | or sobo(a)merit.edu | Ann Arbor, MI 48109-2112 Hardware Engineering | | 1.313.763.4895 (USA)

1 0

Re: Peering versus Transit
by Vadim Antonov 30 Sep '96

30 Sep '96

Bill Woodcock <woody(a)zocalo.net> wrote: > 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? I'm sorry if you are unable to comprehend the difference between going to somebody's place when you were given a key and going to the same place without consent of its owner. And it doesn't matter at all if you want to throw out their old TV and replace it with one offering higher reliability, lower cost and a sounder architecture. --vadim

1 0

Re: Peering versus Transit
by Vadim Antonov 30 Sep '96

30 Sep '96

Sanjay Dani(maillists) <indus(a)professionals.com> wrote: > > The Web page owners pay for that, ok? If they do not want other people > accessing their data they wouldn't put it there for open and pay for it, too. >I didn't know access service providers are not paid by their >web browsing clients. The cost of transaction is split between content providers and clients. Is this that hard to understand? Everybody placing information on Web _pays_, like those people who place ads in magazines or newspapers. That does not mean magazines must be free. People actually pay more for ads in popular places, ok? >I've a public telephone number, that doesn't mean you can keep >calling the number as often you want. 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). >You have conveniently ignored to address the main issue of how >bandwidth and traffic usage should be charged as the nature >of network usage changes. The issue of per-connection charges on Internet is dead. It is not technically feasible due to fundamental scaling problems. The volume of connections on Internet surpassed what multimillion telco boxes can handle years ago. >We are not arguing technical issues here. Yawn. Sure. Let's argue the benefits of perpetuum mobile. "Technical issues" are the hard boundaries between possible and just blabbering. >I do not like the model where established players will >contiue to pay only for telco costs, but not IP traffic >costs to anyone else whatsoever even though their clients' >usage is affecting someone else's network and their customers >pay them for the ability to browse contents elsewhere, and >therefore are effectively subsidized to some extent by what >a relatively small ISP content provider pays for IP traffic. Cool. Why won't you write a business plan and go ahead with your new pricing model. You should be able to convince more than few VCs, it's a hot stuff nowadays. FYI -- i had a more than an engineering role in service providers covering together all time zones on this planet. One of them was the first ISP in 16-odd countries. Another was the first commercial DS-3 backbone in the world. >There might very well be a caller-pays-for-the-session model >or settlement charges based on who initiates how much traffic. >I don't know. So why you just don't learn why the present system is here, and why it delivers while others only promise. >I look forward to competitive offerings from >big providers of the kind Sean Doran envisioned in his >essay. They are already here. Just ask somebody more clueful than a regular salesdroid who doesn't know Internet from Istanbul. >Sure, start labeling when you run out of arguments. A certain >losing politician could use your help. It is not labeling. It is diagnosis. --vadim

1 0