August 1998 - Test - lists.nanog.org

Re: BBN Peering issues
by Lawrence A. Deleski 17 Aug '98

17 Aug '98

Sean, I'm not sure what the traceroutes prove, but there are at least 50 other reasonable, logical explanations that can cause the traffic to exit at different points. I was a Director at Exodus and I happen to know factually that it is the policy of Exodus engineering to not buy transit. The peering arrangement with Sprint is transit-free, and fee-free. It is a true PX. The disclaimer, of course, is that I don't work there anymore, but logically it wouldn't make too much sense to trade-in a fee-free PX with Sprint for a for-fee transit arrangement. This also assumes, of course, that Sprint didn't pull a "BBN" in complete secrecy and forced all of their private exchanges to buy transit. If they did, they should have told BBN how to keep the whole thing quiet. Is it more fun to presume that Exodus is buying transit and therefore easier to poke at in public? I'm not sure what constructive purpose this thread addresses. The larger issue is that BBN is trying to screw around with free exchange of traffic on the Internet, just like UUNet tried to do last year. This will only hurt BBN's customers, and subsequently BBN, as their customers bail in droves from their narrow-minded and self-serving moves. --- Lawrence A. Deleski lad(a)inficad.com ---------- >From: "Sean M. Doran" <smd(a)clock.org> >To: asr(a)millburn.net, dorian(a)blackrose.org, owen(a)DeLong.SJ.CA.US, smd(a)clock.org >Subject: Re: BBN Peering issues >Date: Fri, Aug 14, 1998, 4:38 PM > > >| Private Exchange. It is a private exchange between SPRINT and Exodus. > >I see. And is it your assertion that Exodus does not pay for this >peering, and that, moreover, the payment does not include transit >services? > >One of the reasons I wonder, of course, is that it is pretty >apparent from traceroutes that Sprint is not routing towards >Exodus uniformly (see below, note different exits). Not apparent at all. Can you explain further? > >Now why would Sprint do that on a settlement-free basis? Because that's what peering is all about? > >I'm also curious about the assertion that you have no transit >at all. Not even from Worldcom, maybe? > >I'm sure a public reassertion that there Exodus has NO >paid-for transit from ANYONE would be interesting to everyone. See above. > > Sean. > >... > 8 mlm1-core.hssi0-0.swip.net (130.244.194.145) 72.640 ms 79.000 ms 6.226 ms >17 scca-12-p1-0-0.core.exodus.net (209.185.9.29) 188.063 ms 183.958 ms >231.547 ms

1 0

RE: BBN Peering issues
by Goldstein_William＠bns.att.com 17 Aug '98

17 Aug '98

Thanks for the reality check. Whether the rest of us like it or not, you're right. Bill Goldstein Senior Internet Specialist AT&T wgoldstein(a)att.com TEL:(412)642-7288 ---------- From: shields Sent: Sunday, August 16, 1998 3:59 AM To: mark Cc: shields; nanog Subject: Re: BBN Peering issues > fundamentally important that these ideals be extended to the future of > the Internet, if it is to have a future. No company should have the > right to force another to pay for connectivity simply because the latter > has not been around since the beginning or they are not a telco. BBN is answerable to their customers and shareholders and not to your or my ideals of how the Internet should work. -- Shields, CrossLink. <<File: Re_ BBN Peering issues.TXT>>

7 7

RE: BBN Peering issues
by Goldstein_William＠bns.att.com 16 Aug '98

16 Aug '98

Please note that, by identifying "what is", I'm not equating it with "what should be." And don't knock the idea of promoting the janitor to NOC director. At least the likelihood of the OpenView workstation going down due to spilled Mountain Dew or leftover pizza crumbs would be reduced--which is more benefit than you would get, say, if the typical MBA were promoted to the same position... ;-) (speaking for myself, not for my employer) Bill Goldstein Senior Internet Specialist AT&T wgoldstein(a)att.com TEL:(412)642-7288 ---------- From: linneweh Sent: Sunday, August 16, 1998 3:51 PM To: Goldstein, William Cc: linneweh; mark; shields; nanog Subject: Re: BBN Peering issues Well that's all fine and dandy. however the internet has worked for 20 years that I have been asssociated with it, on the working principal that no one hassled or encumbered peering charges and there were no board rooms or stockholders and that is why it worked, because people knew what they were doing. The admins and network engineers that do this daily for a living or scientific researcher that develope codes and methods to do it better made this happen and certainly not the latter and from my view it WORKED. Adding Joe Blow to the picture is like elevating A Janitor to Director of Network Services and turning him/her loose in the NOC. Goldstein_William(a)bns.att.com wrote: > Thanks for the reality check. Whether the rest of us like it or not, > you're right. > > Bill Goldstein > Senior Internet Specialist > AT&T > wgoldstein(a)att.com > TEL:(412)642-7288 > > ---------- > From: shields > Sent: Sunday, August 16, 1998 3:59 AM > To: mark > Cc: shields; nanog > Subject: Re: BBN Peering issues > > > fundamentally important that these ideals be extended to the future > of > > the Internet, if it is to have a future. No company should have the > > right to force another to pay for connectivity simply because the > latter > > has not been around since the beginning or they are not a telco. > > BBN is answerable to their customers and shareholders and not to your > or my ideals of how the Internet should work. > -- > Shields, CrossLink. > <<File: Re_ BBN Peering issues.TXT>> > > > -- ¢4i1å <<File: Re_ BBN Peering issues.TXT>>

1 0

Re: BBN Peering issues
by Lawrence A. Deleski 16 Aug '98

16 Aug '98

Perhaps BBN is not answerable to you and I, but they should care deeply about and be answerable to the community that makes the Internet work, which, in some cases, just might *be* you and I. Or maybe they should find a new business where they can operate unobstructed by convention, guidelines, consensus, and historical precedent. --- Lawrence A. Deleski lad(a)inficad.com ---------- >From: shields(a)crosslink.net (Michael Shields) >To: mark(a)exodus.net (Mark Tripod) >Subject: Re: BBN Peering issues >Date: Sun, Aug 16, 1998, 7:59 AM > >> fundamentally important that these ideals be extended to the future of >> the Internet, if it is to have a future. No company should have the >> right to force another to pay for connectivity simply because the latter >> has not been around since the beginning or they are not a telco. > >BBN is answerable to their customers and shareholders and not to your >or my ideals of how the Internet should work. >-- >Shields, CrossLink. >

1 0

Re: BBN Peering issues
by Hank Nussbacher 15 Aug '98

15 Aug '98

On Thu, 13 Aug 1998, Jay R. Ashworth wrote: > > What I would like more than anything right now is some official word from > > high-up's at BBN regarding what this policy entails exactly, and what > > their rationale is behind it. > > > Based on just that little slice of the conversation, is BBN doing what > UUnet apparently failed in _it's_ attempt to do last fall, to Jack > Rickard's (and my) vast amusement? Now it all fits in to something I didn't quite understand 2 weeks ago. I consult for a university network planning the purchase of a T3 to the Chicago NAP for access to StarTap and Internet-2. Part of the cost planning is finding Internet-1 access via an ATM VC of 8Mb. I sent around to a number of major ISPs at the Chicago NAP asking to *pay* for full peering at the Chicago NAP via an 8Mb VC. A number of them came back with good answers. But BBN's sales droids indicated very clearly that they will not peer with me unless I purchase the line into the NAP from them: >Date: Thu, 23 Jul 1998 11:34:33 -0500 >Organization: GTE Internetworking > >We will allow the peering if you get the lines from us. So if you order the >T3 through GTE Internetworking, you can peer with us at a NAP. Where are >you getting the T3 from now? > >-----Original Message----- >From: Hank Nussbacher [SMTP:hank@ibm.net.il] >Sent: Saturday, July 18, 1998 1:25 PM >To: xxxxx >Subject: RE: T3s > >On Fri, 17 Jul 1998, xxxxx wrote: > >Even to pay you won't allow a university to peer with you at a NAP?! >-Hank > >> Hank, we only do private peering with telco companies. The only way to >do the peering you want to do with us is to order the T3 through us. Needless to say, they are now off my short list. Tis a shame though. The BBN NOC is by far the most responsive I have seen. When sending our Smurf complaints to UUnet, MCI, Sprint, BBN, etc., I will usually get 5 responses in 24 hours from their NOC (different people). The others just send an automated trouble ticket and I never hear from them again. Hank

1 0

DNS Headaches.
by max＠inc.net 15 Aug '98

15 Aug '98

I am having some very bizzare DNS issues and am wondering if anyone will be able to shed some light on this. A customer of ours started recieving thousands of DNS requests for a wide range of domains, mostly foreign. The requests are coming from a wide range of ips most of which respond to nslookups "ie are nameservers". I have done a whois on some of the domains and the 2 name servers having the problems don't show up, I have also check to root servers and dont see anything which would direct those domains to the name servers. Their entire T1 is full from these requests about 1.2 meg. As the customer is in the business of web hosting they can kill named nor can they put up a packet filter to fix this. Also because there are literally hundreds of diffrent domains both preforming the lookups and being looked up it is not feasable to call the admin of each one to work this out. Anyone have any ideas? Max Spaulding Internet Connect, INC. max(a)inc.net

6 8

Re: BBN peering, a technical issue
by Sean M. Doran 15 Aug '98

15 Aug '98

Jerry - The problem boils down to making traffic move the right way, and making sure the traffic is well-behaved. The biggest problem with using MEDs to attract traffic to the right places, in your model, is simply route aggregation. The next-biggest -- and less immediately soluble -- problem is policing the MEDs. How do you tell whether your rival is obeying your MED announcements faithfully, and what do you do when they don't? (Conversely, how can you tell if the MEDs are being fair to you?) There are other small issues involving what happens in the face of failures -- peering routers crash, peering infrastructure fails, people mess up configurations, etc. In other words, even if you design for traffic going the right way, sometimes it doesn't. What do you do then? Finally, my own concern is what happens if the big colo site ends up playing with devices which deliberately over-ack -- adding fractional ACKs into the stream coming back from web browsers -- and other techniques for opening the congestion window larger or faster than it should be opened, or otherwise sending traffic that does not back off in the face of congestion in your network. It would be ironic if a business race was triggered by people deliberately breaking congestion-avoidance. "Come buy colo from us -- your web pages will seem faster even than web pages on our peers' networks!" would be pretty bad. I say bad not for business reasons, but because TCP's timers and other congestion-avoiding mechanisms are *THE* key mechanism for stability in the Internet. Classic congestion collapse would not be nice for anyone. Sean.

2 1

Re: DNS Headaches.
by Sean Donelan 15 Aug '98

15 Aug '98

That'll teach me not to ignore the first lesson in all the 'security awareness' classes. If something seems odd, it probally is, and should be reported. Name resolution was sluggish enough I thought Hmm? when I first logged in yesterday. But the name resolved, and I had fun-filled day pending with the United States Post Office about something else so the odd DNS delay was quickly forgotten. Any reports if this was just an "Oops"(tm), or another Kasporov-type incident? a.root-servers.net is running BIND 8.1.2-T3B. I didn't notice any security patches between the beta and the final release of 8.1.2. >This wouldn't be webteam.net, would it? =) > >This morning, Chris Yarnell from NASA pointed out the response >to "dig @a.root-servers.net . soa": > >. 2D IN NS PANIC.WEBTEAM.NET. >. 2D IN NS TORGO.WEBTEAM.NET. >PANIC.WEBTEAM.NET. 2D IN A 207.67.50.8 >TORGO.WEBTEAM.NET. 2D IN A 207.67.50.7 > >I don't know how this happened, but it doesn't look pretty. =) > >(The "standard" zone files were okay -- .COM, .NET, etc...) -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: BBN Peering issues
by owen＠DeLong.SJ.CA.US 15 Aug '98

15 Aug '98

> The question above is rather interesting, and what I'd like to know is > what are the various types of "peering" that various ISPs have arranged > between each other? > PEERING == Equal relation ship wher provider A announces routes to themselves and their customers to provider B and Provider B does likewise. There is no announcement by either party of non-customer 3rd party routes to the other. TRANSIT == Provider A is a customer of provider B. Provider A announces routes to itself and it's customers. Provider B announces a complete routing table and/or a default route to provider A. These are separate and distinct entities from Exchange points... Exchanges (places where traffic gets handed off) come in the following varieties: PUBLIC == An exchange point where multiple providers connect with each other across a shared media, such as ATM, FR, Ethernet, FDDI, etc. Generally most public exchanges are run by a third party to whom all of the ISPs connecting have a customer relationship. PRIVATE == A circuit or virtual circuit between two providers which does not provide a shared media type of environment with multiple providers. Generally, there is no third party customer relationship, other than possibly one or both ISPs paying a telco for a circuit. There are many different financial arrangements that can be made around private peering. One of the most common ones I've seen is to bring up multiple circuits and agree that provider A pays for one circuit while provider B pays for the other. No other money changes hands. Sometimes, provider A is willing to pay for all circuits just to get better connectivity for their customers. I hope this clarifies the terms. Owen > "public" - each ISP is at a public exchange point and traffic that is > destined to/from each provider moves across whatever hardware is provided > at the exchange point. This could exist at all exchange points where both > parties have an adequate presence. Possible additional cost if traffic > that would come from another peer is shifted here and bandwidth to the > exchange needs to be increased. > > "private" - A connection exists either via PTP, ATM, FR, or whatever else > you can think of between the involved parties. One or both parties pay > for the link. One time hardware outlay. Seems expensive. Less expensive > than "buying" an DS3 or higher port from the provider. Who buys from > whom? Who pays? These must be NDA'd. Can anyone cite some examples of > what some providers *might* do to make it a fair trade when this is an > NDA'd agreement? > > "public/private hybrid" - Existing exchange point equipment and > connections are used. Purchase ether/fddi cable from MFS to run between > your equipment. Cheap? No telco charges, consolidate your pipes. > > So what was the Exodus/GTEI agreement like? Did it fit neatly into one of > these categories? Are there other more esoteric arrangements? Is GTEI > basically trying to get Exodus as a "customer" in a round-about way? That > certainly seems like an easy way to make more cash. "I'll talk to you, > but only if you buy 'Peering Bundle #A13' from us at $100,000/mo. and you > have no other options. We are big, and this is what you need to do to > be a peer." > > Is this an accurate assessment? Please set me on track if I'm > misunderstanding the concepts at work here... > > Thanks, > > Charles > > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork(a)inch.com access(a)inch.com | > = =----------------= > >

2 1

Re: DNS Headaches
by max＠inc.net 15 Aug '98

15 Aug '98

Oh man thanks for finding this. Those are indeed the servers in question. Earlier in the day when I tried to get some help from internic on this they totally would not do anything for me. Think I am going to enjoy the return call. -Max Max Spaulding Internet Connect, INC. max(a)inc.net On 14 Aug, Robert Cantrel wrote: > I think it's related to something I noticed last night. It was gone > when I checked again around noon today. > > ; <<>> DiG 2.2 <<>> . soa @a.root-servers.net > ; (1 server found) > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 > ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 2, Addit: 2 > ;; QUESTIONS: > ;; ., type = SOA, class = IN > > ;; AUTHORITY RECORDS: > . 172800 NS PANIC.WEBTEAM.NET. > . 172800 NS TORGO.WEBTEAM.NET. > > ;; ADDITIONAL RECORDS: > PANIC.WEBTEAM.NET. 172800 A 207.67.50.8 > TORGO.WEBTEAM.NET. 172800 A 207.67.50.7 > > Some kind of technical glitch at InterNIC. None of the other > root servers displayed this behaviour when I checked. > >>I have an added note. Someone asked me about what domains are being >>looked up and if it might be something someone registered. I dont >>believe this to be the case. There are literally hundreds of domains >>being looked up to many to have had someone register them all. Also >>many of the domains are actual domains I know to be real such as >>excite.com. >> -Max > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com

1 0