- Test - lists.nanog.org

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

30 Sep '96

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. Analogy was wrong. They're guilty of fraud if you want legal definition. They promised sender to deliver parcel, took money and didn't. >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? --vadim

1 0

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

30 Sep '96

>From avg(a)quake.net Mon Sep 30 16:14 PDT 1996 > > >Why is it any different than the big ISP's customers dumping > >packets on small ISP's web server? > > 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. I've a public telephone number, that doesn't mean you can keep calling the number as often you want. 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 new evolving usage patterns may not be convenient to you because they are different from what you've been used to or prove that you made a bad infrastructure investments or maybe you are not used to looking beyond the nuts and bolts, the DS3's, backbones and BGP sessions. We are not arguing technical issues here. 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. 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. I look forward to competitive offerings from big providers of the kind Sean Doran envisioned in his essay. >I'm sick of net.socialists who think that universal connectivity is an Sure, start labeling when you run out of arguments. A certain losing politician could use your help. Sanjay.

1 0

Best way to deal with bad advertisements?
by Matthew Petach 30 Sep '96

30 Sep '96

Hi! I'm going to ask the rest of the NANOG community for their thoughts/opinions on a problem that's been plaguing us periodically that we haven't been able to find a satisfactory solution for yet. There's an ISP back on the East Coast that has been periodically advertising more specific routes for /24's out of our CIDR blocks and black-holing the traffic within their network. We've called all the listed numbers for their technical, admin, billing, and any other contacts we can find, and haven't been able to reach a human; we've left messages of various levels of nastyness, from very sugary on up to vaguely threatening. In every case, including the current one, it's been more than 24 hours, and they still haven't made any response to the problem; in fact, I just got paged by our NOC early this morning informing me they've stolen another one of our /24's. As you can well imagine, all the customers on those blocks are _very_ unhappy. Each time this happens, we end up with dissatisfied customers, many of whom leave, deciding that we're too unstable, and can't provide quality network connectivity, even though to the best of my knowledge, there's nothing we can do to prevent these people from stealing our blocks. My question to the NANOG community is twofold and simple: Am I overlooking some solution that would allow us to 'negate' their advertisement of our blocks (205.159.193.0/24 and 207.88.102.0/24 in this case) and secondly, is there a formal process within the community to seek recompense, or formal action against a clueless and net-unfriendly ISP, perhaps one as simple as the net equivalent of Mennonite 'shunning'? Or are we simply out of luck, and have to simply tell our customers "Sorry, everyone is at the mercy of the morons who can steal IP blocks simply by advertising more specific routes with higher weights?" It's getting really tempting to advertise the networks they have their nameservers on from *our* network with a weight of 65535, just to get them to call us back. :-( :-( Anyhow, enough frustrated venting, I *am* very interested in what the community feels is the best policy to follow in situations like this. Thanks again! Matt Petach Network Engineer (writing from home)

7 17

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

30 Sep '96

Bill Woodcock <woody(a)zocalo.net> wrote: > WRT the former, I simply cannot fathom, and no one other than Sean has > yet presented an argument explaining why it's malicious to deliver a > packet to its addressee's ISP. You should always add "without consent of the said ISP". It is no different from dumping a pile of bricks at somebody's property. Are bricks useful? You bet. Will it get you dragged in court on charges trespassing and defacing the property? Sure as hell. It is not a "theft", it is more like trespassing. It is illegal and covered by codes related to unauthorized use of equipment. > Why should I, as an ISP, not prefer > that all other ISPs deliver packets to my customers as quickly, > efficiently, directly, and inexpensively as possible? Efficiently, directly and inexpesively from whose point of view? Refer to the example of ISP in Mukhosransk. > Why should I > prefer a more expensive or less reliable route, or expect any other > ISP to do so? There is a million reasons to do that -- economical, legal, technical. One technical reason is pretty obvious -- it is called "traffic engineering". Large ISPs often use nudged routing advertisements as means to balance load between peering points. That assumes that nobody is sending unsolicited traffic. --vadim

2 1

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

30 Sep '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? Reiterating the same position over and over without any basis or logical foundation does nothing to convince anyone that your position is of any merit. -Bill ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

3 2

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

30 Sep '96

> You should always add "without consent of the said ISP". > > It is no different from dumping a pile of bricks at somebody's property. >Why is it any different than the big ISP's customers dumping >packets on small ISP's web server? 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. If the small ISP does not want customers of other ISPs accessing its server(s) it can simply not advertise its routes. It is their decision. A Web conternt providers will then go and seek a place which would take their business. >Sanjay. I'm sick of net.socialists who think that universal connectivity is an Unalienable Right Of Every Living Person and that All ISPs Are Born Equal. I've had a chance to learn very intimately what all that Free-For-All crap really means -- when related to pushing bits and when not. --vadim

1 0

Re: Peering versus Transit
by Sean Donelan 30 Sep '96

30 Sep '96

>These days peering agreements are business deals. They have always been business deals. I'm just amazed as some of the lengths some providers go to justify what should be a plain-old business decision. If you don't intend to peer with another provider, just say so. The only providers I tend to get really peeved at are the ones that keep changing their stories. AGIS told me in January '96 that their peering agreement was being revised by their lawyers and they would send it as soon as it was ready. Since I hadn't heard from AGIS in a while, I sent another note to AGIS and was told they now require DS3 connections to four exchange points. No idea what happened to that peering agreement from January. MCI told me in February '96 that their peering agreement as on hold pending review by their lawyers and they would let me know when it was ready. The last response I've received from MCI is the person in charge of peering had changed. No word from the new guy. And MCI took their peering policies off their web page. No idea what happened to MCI's policies in the mean time. Since March of 1995 (yes '95) I've gone through three product managers for Sprintlink who have told me their peering agreement is on the way, under legal review, on hold, or being revised. DRA met Sprint's peering 'requirements' a couple of times now. But by the time I hear back from their product manager du jure, they've changed their requirements again. I'm puzzled why these providers seem to have new peers show up at the same time they are telling me new peerings are on 'hold.' Should I start taking this personally? If you don't intend to peer with other providers, why not say so? Why go through the trouble of making peering questionaires and listing peering requirements, when you are just going to come up with a new excuse if you don't want to peer with the other provider. >They happen to >be business deals that have $0 attached to them for all sorts >of reasons Sean D et al explained far more eloquently than I could, >but they are still business agreements. Just like any other contract, >be in breach at your peril. Breach of contract is a civil matter, not criminal. If you have a peering agreement that says thou shalt not next-hop third-party routes, and they do, you get to terminate the agreement and/or sue the other provider, not arrest them. People seem to be very quick to call things they don't like illegal. Not all misrouted packets are the result of illegal activities, most of them are just misrouted packets. MCI didn't plan to send me packets across mae-east, they just happened to believe some bad routing information. If you are going to start arresting people simply because packets are misrouted, big providers misroute a lot more packets than little providers simply due to size. This is a dangerous game to start playing because it can easily blow up in your face. >Which leaves the case where you send traffic to say ISP X >*without* any form of peering agreement with ISP X. Contracts >with the IXP should prevent this from happening. If you >try this, I hope they filter your MAC address. Some IXPs do this, but the operators aren't always able to keep up with the changing arrangements of the various providers and end up blackholing a bunch of traffic every so often for varying lengths of time. The routing protocols have problems dealing with networks which don't have the 'shared- fate' property. Most other IXP contracts are silent about relationships between ISPs. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Best way to deal with bad advertisements?
by salo＠msc.edu 30 Sep '96

30 Sep '96

> Subject: Re: Best way to deal with bad advertisements? > To: SEAN(a)SDG.DRA.COM (Sean Donelan) > Date: Mon, 30 Sep 1996 12:53:18 -0500 (CDT) > Cc: nanog(a)merit.edu > > > This was to keep the old NSF mid-level networks from losing connectivity > > with each other if they happened to choose different NSPs. I'm guessing > > the NSF connection program has wound down by now, so this isn't that much > > of a factor any more. > > Erm, rather a large number of entities still receive NSF connection funding. > > It's rather amusing what some of them do with it. :-) Obviously, someone at the NSF is better qualified than I to comment on this, but the NSF New Connections program is _not_ being "wound down." If fact, it is being expanded. The current New Connections solicitation adds K-12 institutions and vBNS connections. What is being phased out is direct grants to regional networks. Many regional networks were started with direct NSF grants. Often, the regionals rather liked these funds, and pleaded with the NSF to keep them flowing for just a little while longer. NSF Solicitation 93-52 was the NSF's (successful, I believe) effort to end direct subsidies to regional networks. NSF 93-52 offered funds for regional connectivity, (connectivity out of the region, for example, via an NSP), decreasing to zero over four years. -tjs

1 0

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

30 Sep '96

> From: Vadim Antonov <avg(a)quake.net> > Bill Woodcock <woody(a)zocalo.net> wrote: > > > WRT the former, I simply cannot fathom, and no one other than Sean has > > yet presented an argument explaining why it's malicious to deliver a > > packet to its addressee's ISP. > > You should always add "without consent of the said ISP". > > It is no different from dumping a pile of bricks at somebody's property. Why is it any different than the big ISP's customers dumping packets on small ISP's web server? Sanjay.

1 0

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

30 Sep '96

> There are two ways to have packets go... > adding bogus static or whatever routes > or by pointing default. Both are malicious. WRT the latter, I completely agree that pointing a default at anyone whom you're not buying transit from is theft, and absolutely beyond condonement. WRT the former, I simply cannot fathom, and no one other than Sean has yet presented an argument explaining why it's malicious to deliver a packet to its addressee's ISP. Why should I, as an ISP, not prefer that all other ISPs deliver packets to my customers as quickly, efficiently, directly, and inexpensively as possible? Why should I prefer a more expensive or less reliable route, or expect any other ISP to do so? I realize that this is about the hundredth time somebody has asked exactly that question, but people are just going to keep asking until there's a convincing reason, or people stop suggesting that other people use less-efficient paths. It is, after all, an obvious question. > Example, please, when somebody conforming to the stated policies > was denied peering? (Plase note that the process... may be > rather lengthy... Okay, it's _widely rumored_ that it may be difficult to establish new peering sessions with some large ISPs, at the moment. :-) But this again distracts from the question at hand, since you assume that "stated policies" should institutionalize unequal relationships. Assuming that skirts the argument, just as nonsequiturs about default routes do. -Bill ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

3 2