- NANOG - lists.nanog.org

Re: BBN Peering issues
by Matt Sommer 14 Aug '98

14 Aug '98

you keep missing the most obvious interpretation: 1.85% of exodus's output goes to bbn. 10-30% of bbn's input is from exodus. this may still be a ridiculous figure, but maybe not, if exodus is hosting 30 of the top 100 web sites. >>>> >off. Let's face the facts, BBN is only 1.85% of my traffic. By all accounts, >>> >we estimate to be in the area of 10-30% of their traffic. Lots of luck. We >>> >actually see a massively inverted benefit scale in this particular situation. > >It seems intuitively reasonable to me that 1.85% of Exodus input comes from BBN. >No arguments there. I would like to know where the "By all accounts, we estimate >to be in the area of 10-30% of their traffic." sentence comes from. Are you suggesting >that 10-30% of BBN's total output goes to Exodus? Or that 10-30% of Exodus output >goes to BBN? > >The first scenario is ridiculous. The second scenario is possible, but I would suspect >it is closer to 10% than 30%. > >-dsr- > >...Still not speaking for the company... >

1 0

Re: BBN Peering issues
by sysadmin 14 Aug '98

14 Aug '98

you keep missing the most obvious interpretation: 1.85% of exodus's output goes to bbn. 10-30% of bbn's input is from exodus. this may still be a ridiculous figure, but maybe not, if exodus is hosting 30 of the top 100 web sites. matt sommer webkorner.com -----Original Message----- From: Dan Ritter <dsr(a)bbn.com> To: Robert Bowman <rob(a)elite.exodus.net> Cc: fez(a)mindspring.net <fez(a)mindspring.net>; nanog(a)merit.edu <nanog(a)merit.edu> Date: Friday, August 14, 1998 1:54 PM Subject: Re: BBN Peering issues >At 12:10 PM 19980813 -0700, Robert Bowman wrote: >>I am referring to output of Exodus traffic relative to input of BBN traffic, >>not vice versa. Exodus consumes very little of BBN's output (Exodus input). >>Isn't that the "supposed" problem? Our private exchange statistics show it >>very simply, if BBN disconnects, it will drop our traffic by 1.85%. I cannot >>speak for certain about BBN's traffic input as an aggregate, that is why >>I stated below that we are estimating. > > >>> >off. Let's face the facts, BBN is only 1.85% of my traffic. By all accounts, >>> >we estimate to be in the area of 10-30% of their traffic. Lots of luck. We >>> >actually see a massively inverted benefit scale in this particular situation. > >It seems intuitively reasonable to me that 1.85% of Exodus input comes from BBN. >No arguments there. I would like to know where the "By all accounts, we estimate >to be in the area of 10-30% of their traffic." sentence comes from. Are you suggesting >that 10-30% of BBN's total output goes to Exodus? Or that 10-30% of Exodus output >goes to BBN? > >The first scenario is ridiculous. The second scenario is possible, but I would suspect >it is closer to 10% than 30%. > >-dsr- > >...Still not speaking for the company... >

1 0

Re: BBN Peering issues
by Sean M. Doran 14 Aug '98

14 Aug '98

| 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). Now why would Sprint do that on a settlement-free basis? 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. Sean. ... 8 mlm1-core.hssi0-0.swip.net (130.244.194.145) 72.640 ms 79.000 ms 6.226 ms 9 198.67.142.137 (198.67.142.137) 7.338 ms 8.505 ms 7.945 ms 10 198.67.142.77 (198.67.142.77) 97.600 ms 96.253 ms 95.975 ms 11 144.232.5.157 (144.232.5.157) 96.336 ms 95.309 ms 95.644 ms 12 sl-bb22-stk-6-0.sprintlink.net (144.232.8.178) 148.940 ms 149.329 ms 149.583 ms 13 sl-bb23-stk-8-0.sprintlink.net (144.232.4.110) 149.705 ms 149.598 ms 150.050 ms 14 sl-bb10-sj-6-0.sprintlink.net (144.232.8.193) 150.645 ms 150.973 ms 151.126 ms 15 144.232.3.26 (144.232.3.26) 151.027 ms 154.151 ms 152.050 ms 16 sl-gw3-sj-4-0-0-155M.sprintlink.net (144.232.3.50) 151.511 ms 151.648 ms 151.472 ms 17 sl-exodus-5-0-T3.sprintlink.net (144.228.44.6) 156.324 ms 175.375 ms 158.908 ms 18 scca-01-f8-0-0.core.exodus.net (209.1.169.21) 163.182 ms 164.906 ms 168.566 ms 19 sc3-f0-1-0.exodus.net (209.1.169.14) 153.999 ms 155.180 ms 159.556 ms 20 santaclara-cisco75.exodus.net (207.82.200.75) 156.249 ms 231.899 ms 167.273 ms 21 209.1.231.2 (209.1.231.2) 170.068 ms 167.423 ms 169.606 ms 22 dixon.delong.sj.ca.us (192.159.10.1) 166.376 ms 173.019 ms 159.060 ms versus (towards what used to be cam.vio.com) 8 mlm1-core.hssi0-0.swip.net (130.244.194.145) 7.232 ms 6.630 ms 6.842 ms 9 198.67.142.137 (198.67.142.137) 7.145 ms 6.821 ms 6.979 ms 10 198.67.142.77 (198.67.142.77) 95.533 ms 96.899 ms 95.645 ms 11 144.232.5.157 (144.232.5.157) 96.509 ms 97.051 ms 95.386 ms 12 144.232.5.2 (144.232.5.2) 96.226 ms 95.588 ms 96.827 ms 13 sl-bb10-pen-3-0.sprintlink.net (144.232.8.217) 151.164 ms 151.616 ms 152.558 ms 14 sl-gw6-sea-0-0-0.sprintlink.net (144.232.6.66) 154.156 ms 153.385 ms 151.895 ms 15 sl-exodus-4-0-T3.sprintlink.net (144.224.113.26) 155.599 ms 151.810 ms 154.255 ms 16 scca-21-pos-0-0-0.core.exodus.net (209.185.9.185) 229.000 ms 178.663 ms 187.497 ms 17 scca-12-p1-0-0.core.exodus.net (209.185.9.29) 188.063 ms 183.958 ms 231.547 ms 18 sc1-f6-0-0.exodus.net (209.1.169.2) 527.453 ms 561.012 ms 503.870 ms 19 sc1-f6-0-0.exodus.net (209.1.169.2) 572.187 ms 633.966 ms 547.594 ms 20 * * * note Seattle versus San Jose. Interestingly: vio.com SOA NS.CARAVAN.com hostmaster.NS.CARAVAN.com NS.CARAVAN.COM seems to live behind bayarea.net, a BBN Planet customer. Sean. (again)

2 1

Re: BBN Peering issues
by Sean M. Doran 14 Aug '98

14 Aug '98

Sean Doran wrote: > [suspicious stuff] Oops, I forgot that I was on NANOG rather than, say, inet-access or somesuch. Please forgive my not-very-operational posting. I suppose I could have framed it as, "gee, is there a misconfiguration causing Sprint not to route uniformly towards Exodus? I see strange stuff." Please forgive me. Sean.

1 0

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

14 Aug '98

> | I checked before doing so, and I checked once again in light of your > | allegation. And, according to Exodus, this *IS* a PX. > > If by PX you mean "public exchange point", then Sprint is > being unusually inconsistent with its naming, numbering, and > topology conventions. > Private Exchange. It is a private exchange between SPRINT and Exodus. > I'm curious as to which exchange point it is, if that in fact is > what PX means. > > Of course, whatever type of connection it is, I'm curious about > the fact that packets are always drawn towards this one connection. > Are there others? If so, are they down or something? > > Sean. (wondering why Sprint would give away a single free T3) >

1 0

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

14 Aug '98

The following is purely my opinion and has nothing to do with my employer, although in this case, my employment situation prevents me from saying what I really think should be said. There are a lot of things that should be said here. However, due to NDAs and company policies, I am not allowed to say most of them. However, I will say this: 1. At least one provider being cut off is a peer. 2. BBN's customers will feel pain when that provider is cut off. 3. That provider's customers will also feel pain. 4. BBN has not worked with that provider to resolve this privately under NDA. 5. The NDA which was part of the soon-to-be former peering arrangement prohibits the disclosure of many details that would be important here. 6. I suspect it will take much more than an hour for BBN to resolve this once they have taken the actual step of disconnecting any of these providers. Owen > Well basically you need to think of it like this. If the providers that > are getting cut were actually "peers" of BBN, then BBN would feal the > pain, in fact they are not "peers". BBN can cut them off their network and > will not feal a thing. BBN customers will still be able to reach the cut > ISPs from their transit providers. If the providers were "peer" then when > BBN tried to cut them they both would feal the pain and BBN would most > likley turn it back up in a hour or so. > > > Rather than limit this issue to within the confines of private > > communication, I would like to see it carried out as a very vocal and > > lively public one. That way, the general public will be able to make an > > educated decision regarding whether or not to purchase transit from > > BBN/GTE, in light of this. > > Well, in the past this stuff was resolved under NDAs. If you don't see a > lot of ISPs talking then most likely BBN just had them sign a NDA and > worked something out.

2 1

Route filtering
by Kummer, Joerg {PYN~Basel} 14 Aug '98

14 Aug '98

Q:Is there a common denominator in terms of route filtering policies on different ISP transit networks ? I know of - http://www.sprintlink.net/filter.htm - A message in the NANOG mailing list archive http://www.cctec.com/maillists/nanog/historical/9701/msg00645.html indicates that AGIS used to do route filtering - excerpt: >Essentially, they will filter on /19 in the 206+. >They will filter on /24 for the 192-205 range. >Everything else (0-191) will be filtered in the /16. However, I did not see any confirmation of that on AGIS' web server. Q: Does anybody know more about (current/planned) AGIS' policies ? I did not find more info in the NANOG mailing list archive... The info on http://www.nanog.org/filter.html is somehow disappointing We are customer of several ISPs and are trying to get an overview of filtering policies. We plan to run around 10 Internet access lines with different ISPs internationally in the next year (current: 6). We use NAT, no BGP; we would prefer using our own addresses rather than ISP-provided addresses. ->> Q: what should we ask the ISPs to advertise for us to get the best routeability ? We have the following public addresses: 145.245.0.0/16 151.120.0.0/16 141.167.0.0/16 162.132.0.0/16 196.3.32.0/20 196.3.48.0/21 (there are some more Class Cs) Previous plan was: - access #1 : 145.245.0.0/16 - access #2 : 151.120.0.0/16 - access #3 : 141.167.0.0/16 - access #4 : 162.132.0.0/16 - access #5 : 145.245.160.0/19 ... more /19s because we thought /19 would be safer than /24. and then we found out about the Sprintlink filtering policies. Current plan: - access #1 : 145.245.0.0/16 - access #2 : 151.120.0.0/16 - access #3 : 141.167.0.0/16 - access #4 : 162.132.0.0/16 - access #5 : 196.3.32.0/24 - access #6 : 196.3.33.0/24 /24s in 196 range seem to be ok for AGIS and Sprintlink... regards joerg ______________________________________ F. Hoffmann-La Roche LTD Joerg Kummer, Dipl. El.Ing. ETH Pharma Informatics/Network Engineering CH-4070 Basel Switzerland Phone : +41 61 688 81 32 Fax : +41 61 688 16 72 mailto:joerg.kummer@roche.com ______________________________________

1 0

Re: BBN Peering issues
by Scott Huddle 14 Aug '98

14 Aug '98

At 07:49 AM 19980813 -0700, Robert Bowman wrote: >[...] Let's face the facts, BBN is only 1.85% of my traffic. By all accounts, >we estimate to be in the area of 10-30% of their traffic. Source of data? -scott

1 0

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

14 Aug '98

Er, SPRINT's been doing this forever. Owen > Err, you are missing something. Obviously GTE knows this, that is the > point of killing the peering. The question is, is the method the GTE is > using to determine who should pay for transit accurate? Turn it around; > why shouldn't BBN pay Exodus to terminate the traffic for them? > > It just strikes me as odd that BBN is trying to [essentially] apply a > telecom-accepted/FCC-tarrifed method of termination payments to IP > packets. > > In effect, what BBN is doing is revolutionary. However, in my opinion, it > is sad to see essentially one of the founders of the Internet to bend the > Internet over and break out the Vaseline. However, that is just my > opinion. > > I wonder what Sprint and MCI's position is on this... Will we see them > doing that same? > > > > > As for any comments made by GTE/BBN regarding uneven traffic flow, I would > > sure as hell hope that is the case. Surely an HTTP 'GET' request consumes > > less bandwidth than the content spewed back. Then again, GTE/BBN may be > > too caught up to realize this, as they could very well be laughing their > > asses off all the way to the bank. > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Atheism is a non-prophet organization. > I route, therefore I am. > Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member > Father of the Network and Head Bottle-Washer > Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 > Don't choose a spineless ISP! We have more backbone! http://www.nac.net > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > >

1 0

NANOG Archives and Searching
by Eric Germann 14 Aug '98

14 Aug '98

Folks, Update on the NANOG Channel. We bust it up, HTMLize it and make it available as an IE Channel/NetCaster Channel as well as a content search tool. We updated the search engine this evening. Now you'll get more than 10 hits for a query and hopefully better performance. Go ahead and kick the tires. Let us know what you think. http://www.cctec.com/maillists/nanog Also, if you take the channel, Altavista Discovery is a great local search tool for indexing locally the fabulous technical content of this list :) Eric ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert, OH 45891 http://www.cctec.com Ph: 419 968 2640 Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0