May 2005 - Test - lists.nanog.org

ISP Issues in Texas?
by Paul Jasa 20 May '05

20 May '05

We're seeing different internet providers' circuits down/unreachable all over Texas, is anyone aware of anything major going on out there? Thanks. pj The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system.

2 1

The Cidr Report
by cidr-report＠potaroo.net 20 May '05

20 May '05

This report has been generated at Fri May 20 21:44:53 2005 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 13-05-05 158437 108358 14-05-05 158493 108273 15-05-05 158384 108308 16-05-05 158462 108354 17-05-05 158543 108072 18-05-05 158640 108055 19-05-05 158312 108113 20-05-05 158685 108158 AS Summary 19577 Number of ASes in routing system 8029 Number of ASes announcing only one prefix 1461 Largest number of prefixes announced by an AS AS7018 : ATT-INTERNET4 - AT&T WorldNet Services 90462976 Largest address span announced by an AS (/32s) AS721 : DLA-ASNBLOCK-AS - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 20May05 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 158916 108191 50725 31.9% All ASes AS4323 1102 220 882 80.0% TWTC - Time Warner Telecom AS18566 812 8 804 99.0% COVAD - Covad Communications AS4134 895 222 673 75.2% CHINANET-BACKBONE No.31,Jin-rong Street AS721 1111 562 549 49.4% DLA-ASNBLOCK-AS - DoD Network Information Center AS27364 565 22 543 96.1% ACS-INTERNET - Armstrong Cable Services AS7018 1461 940 521 35.7% ATT-INTERNET4 - AT&T WorldNet Services AS22773 484 23 461 95.2% CCINET-2 - Cox Communications Inc. AS7725 450 21 429 95.3% CCH-AS7 - Comcast Cable Communications Holdings, Inc AS6197 904 516 388 42.9% BATI-ATL - BellSouth Network Solutions, Inc AS3602 524 142 382 72.9% SPRINT-CA-AS - Sprint Canada Inc. AS6467 418 44 374 89.5% ESPIRECOMM - e.spire Communications, Inc. AS17676 431 78 353 81.9% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS9929 348 46 302 86.8% CNCNET-CN China Netcom Corp. AS4766 577 281 296 51.3% KIXS-AS-KR Korea Telecom AS6140 407 126 281 69.0% IMPSAT-USA - ImpSat AS14654 268 6 262 97.8% WAYPORT - Wayport AS9443 374 123 251 67.1% INTERNETPRIMUS-AS-AP Primus Telecommunications AS6478 400 152 248 62.0% ATT-INTERNET3 - AT&T WorldNet Services AS7545 497 250 247 49.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS15270 277 37 240 86.6% AS-PAETEC-NET - PaeTec.net -a division of PaeTecCommunications, Inc. AS1239 888 652 236 26.6% SPRINTLINK - Sprint AS23126 255 20 235 92.2% KMCTELCOM-DIA - KMC Telecom, Inc. AS4755 519 287 232 44.7% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS5668 487 260 227 46.6% AS-5668 - CenturyTel Internet Holdings, Inc. AS6198 464 238 226 48.7% BATI-MIA - BellSouth Network Solutions, Inc AS9498 292 66 226 77.4% BBIL-AP BHARTI BT INTERNET LTD. AS9583 729 506 223 30.6% SIFY-AS-IN Sify Limited AS2386 854 637 217 25.4% INS-AS - AT&T Data Communications Services AS11456 321 107 214 66.7% NUVOX - NuVox Communications, Inc. AS6167 265 68 197 74.3% CELLCO-PART - Cellco Partnership Total 17379 6660 10719 61.7% Top 30 total Possible Bogus Routes 172.32.0.0/24 AS7011 CITLINK - Citizens Utilities 172.122.28.0/24 AS210 WEST-NET-WEST - Utah Education Network 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.43.230.0/24 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 192.44.0.0/19 AS702 AS702 MCI EMEA - Commercial IP service provider in Europe 192.44.0.0/24 AS5501 FRAUNHOFER-CLUSTER-BW Fraunhofer Gesellschaft 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.81.182.0/24 AS719 ELISA-AS Elisa Oyj 192.81.183.0/24 AS719 ELISA-AS Elisa Oyj 192.81.184.0/24 AS719 ELISA-AS Elisa Oyj 192.119.135.0/24 AS270 PSCNI-AS - National Aeronautics and Space Administration 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.133.6.0/24 AS4004 GLOBALONE-EQUANT-UK Equant UK & Greece Autonomous System 192.135.50.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 192.136.53.0/24 AS8346 SONATEL-AS Autonomous System 192.153.144.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 192.172.0.0/19 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 192.188.208.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 192.200.100.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 196.2.95.0/24 AS8668 TELONE-AS TelOne Zimbabwe P/L 196.3.162.0/24 AS6083 AFRINIC African Network Information Center 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.97.72.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.97.80.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.97.88.0/24 AS89 NUSC-CSTLNET-AS - Naval Underwater Systems Center 198.97.240.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.97.247.0/24 AS3475 LANT-AFLOAT - Department of the Navy 198.101.4.0/22 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.136.32.0/20 AS19329 MCNET - Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY-NET - CityNet, Inc. 198.160.171.0/24 AS7046 UUNET-CUSTOMER - UUNET Technologies, Inc. 198.161.87.0/24 AS6539 GROUPTLCOM - GT Group Telecom Services Corp. 198.163.155.0/24 AS684 MBNET-AS - Manitoba Regional Network 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ALLST-15290 - Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 ALTERNET-AS - UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASKTEL - SaskTel 198.232.133.0/24 AS23075 SKOTOS-AS - Skotos Tech, Inc 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.60.0.0/20 AS271 BCNET-AS - University of British Columbia 199.96.44.0/23 AS19092 360NETWORKS-US - 360Networks (USA) Inc. 199.96.46.0/24 AS19092 360NETWORKS-US - 360Networks (USA) Inc. 199.114.0.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.128.0/18 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.130.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.132.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DISA/UNRRA 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DISA/UNRRA 199.114.142.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.144.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.148.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.150.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.120.32.0/19 AS16582 NEXTLEVELINTERNET - NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.123.0.0/18 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.123.16.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.123.80.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 ALTERNET-AS - UUNET Technologies, Inc. 202.86.252.0/22 AS4748 RESOLINK-AS Resources Linke Network Limited 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.164.224.0/19 AS7599 IPXC-AS-AP IP Exchange 203.32.4.0/23 AS7617 TELEONE-HK TeleTeleOne (HK) Limited 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.99.0.0/19 AS17746 ORCONINTERNET-NZ-AP Orcon Internet 203.99.142.0/24 AS9826 ILINK-HK-AP iLink.net Ltd 203.210.69.0/24 AS17536 PRODIGY-AS-AP Prodidgy Telecommunications 204.48.118.0/23 AS29912 CITIZENS-PROPERTY-INSURANCE-CORPORATION - Citizens Property Insurance Corporation 204.48.119.0/24 AS29912 CITIZENS-PROPERTY-INSURANCE-CORPORATION - Citizens Property Insurance Corporation 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBIT - Exobit Networks Inc. 205.150.0.0/15 AS701 ALTERNET-AS - UUNET Technologies, Inc. 206.108.96.0/19 AS577 BACOM - Bell Advanced Communications Inc. 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.167.57.0/24 AS376 RISQ-AS - Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ALLST-15290 - Allstream Corp. Corporation Allstream 206.191.96.0/19 AS15290 ALLST-15290 - Allstream Corp. Corporation Allstream 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc 208.53.224.0/19 AS13576 SDNET - SOUTH DAKOTA NETWORK 208.138.48.0/20 AS6971 ATG-1 - Advanced Telcom Group, Inc 209.40.208.0/21 AS16592 Cybernet El Salvador 209.40.216.0/21 AS16592 Cybernet El Salvador 209.134.0.0/18 AS8082 WORLDSITE - Worldsite Networks 209.205.69.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.70.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.81.0/24 AS15066 SkyNet de Colombia S.A. 209.205.82.0/24 AS15066 SkyNet de Colombia S.A. 209.205.84.0/24 AS15066 SkyNet de Colombia S.A. 209.213.32.0/19 AS10629 INTERPAC - Inter-Pacific Network Services 209.222.137.0/24 AS27429 TIL - Telesat International Ltd. 209.251.0.0/19 AS11036 SISCOM - SISCOM, Inc 216.37.110.0/23 AS4264 CERNET-ASN-BLOCK - California Education and Research Federation Network 216.82.160.0/20 AS13823 CALYX-USA - Calyx Internet Access Corp. 216.96.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.145.200.0/21 AS20304 JVLNET - JVLNET Internet Services 216.171.96.0/20 AS3356 LEVEL3 Level 3 Communications 216.178.37.0/24 AS3356 LEVEL3 Level 3 Communications 216.178.39.0/24 AS3356 LEVEL3 Level 3 Communications 216.178.42.0/24 AS3356 LEVEL3 Level 3 Communications 216.178.43.0/24 AS3356 LEVEL3 Level 3 Communications 216.228.64.0/21 AS6295 WHIDBEY1 - Whidbey Internet Services Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org swinog(a)swinog.ch

1 0

http://xn--1lq90ic7fzpc.cn/
by Peter & Karin Dambier 20 May '05

20 May '05

Is it one third of the total internet population for whom it makes sense to see "--" in hostnames? Just have a look at this page http://xn--1lq90ic7fzpc.cn/ You can trust your eyes :) Regards, Peter and Karin Dambier Public-Root -- Peter und Karin Dambier Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-6252-599091 (O2 Genion) +1-360-226-6583-9738 (INAIC) peter(a)peter-dambier.de http://iason.site.voila.fr

3 2

Level3 issues in Dallas?
by William R. Charnock 19 May '05

19 May '05

Greetings, Is anyone else seeing any problems with Level(3) in the Dallas area? I've got 3 Gig-E ports that are dropping packets like crazy. Thanks, William Charnock SVP Operations and Engineering ThePlanet Internet Services

1 0

Re: Running soBGP
by J. Oquendo 19 May '05

19 May '05

On Thu, 19 May 2005, vijay gill wrote: > > If you are an operator, would you deploy soBGP or something like it? If > not, why not. > > http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac236/about_cisco_ipj_ar… > > /vijay On a large network wouldn't this add overhaul being certs would have to be processed, possible slow things down. What happens if someone does some crafty route poisoning pretending to be a cert server sending all types of TLV options. I read into this before but didn't bother following up on RFC stuff. soBGP ... SBGP ... What about an entirely knew telekineticBGP where the other router just knows and bends its peer according to its will! =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 To conquer the enemy without resorting to war is the most desirable. The highest form of generalship is to conquer the enemy by strategy." - Sun Tzu

1 0

Devious data thieves actually joy-riding script kiddies
by Fergie (Paul Ferguson) 19 May '05

19 May '05

Well, it appears that the infamous Paris Hilton hack and the LexisNexis hack may be related: http://fergdawg.blogspot.com/2005/05/lexisnexis-hacking-probe-examined.html - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Fwd: Request for IETF Input: Reuse of Protocol Number 33
by Fergie (Paul Ferguson) 19 May '05

19 May '05

FYI, - ferg ---------- Forwarded Message ---------- Protocols which can be encapsulated in IP datagrams must be assigned a Protocol Number as defined in RFC2780. This number is used in an 8 bit field the IP header ("Protocol" in IPv4, "Next Header" in IPv6) to identify the encapsulated protocol. Due to the limited range of available values, it is desirable to recycle numbers, although not sought in general by the IESG. Current assignments may be found at http://www.iana.org/assignments/protocol-numbers. The Datagram Congestion Control Protocol (recently approved) has requested from IANA that it be permitted to reuse the Protocol Number 33, currently assigned to the Sequential Exchange Protocol (SEP). It is believed that this protocol has not been used for many years. The protocol author, Jon Crowcroft, confirms this view. This note initiates a two week last call (to end 3 June 2005) to solicit any indication that SEP is in active use. If there is no indication by the date above, the IESG will let IANA know that Protocol Number 33 may be assigned to DCCP, and that the use of 33 for SEP will be considered OBSOLETE. Public comments may be sent to ietf(a)ietf.org. Private comments may be sent to the Responsible Area Director, Allison Mankin, <mankin-at-psg.com>. _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce

1 0

Re: VoIP operators given 120-day deadline to implement E911 services
by Robert Bonomi 19 May '05

19 May '05

> From owner-nanog(a)merit.edu Thu May 19 13:38:03 2005 > Date: Thu, 19 May 2005 14:37:54 -0400 > From: Jason Frisvold <xenophage0(a)gmail.com> > Subject: Re: VoIP operators given 120-day deadline to implement E911 services > > > On 5/19/05, Bruce Pinsky <bep(a)whack.org> wrote: > > That last part ought to be interesting to try and implement in 120 days: > > > > "...must provide the emergency operator with the customer's callback number > > and location, regardless of whether the call is being made from the > > customer's home or elsewhere." > > I'm not sure how VoIP operators are going to accomplish this.. The > ugly method would be requiring the user to put in their location > information when the VoIP device first goes online, but I'm not sure > that's even remotely practical... > > I know you can sometimes get generalized location information from an > IP, but nowhere near what's needed for 911 operations.. > > Any insight on how this is going to be handled? The story says the FCC is requiring a capability for the _customer_ to update their location/callback information when those things change. Now, since the VoIP _provider_ is being required to provide valid 'location' info, "regardless" of where the call originates, I suspect that we're going to see a lot of "phone disabled, until location info confirmed" if the IP address of the customer changes. > > So what's the local 911 center I should be routed to when I'm at the Cebu > > Phillipines airport and making a VoIP call? I favor routing _that_ emergency call directly to the Commisioner's desk and let *them* figure out what the necessary compliance action is! Seriously, though, if the phone is 'registered' as being in an area for which there _is_no_ U.S. 911/E-911 service, then any attempt to dial that 'number' should get an interecept message. Preferalbly a "useful" one, not just a generic "your call cannot be completed as dialed" or similar.

1 0

Re: http://xn--1lq90ic7fzpc.cn/
by Peter & Karin Dambier 19 May '05

19 May '05

> --- original message --- > from: Joe St Sauver <JOE(a)OREGON.UOREGON.EDU> > to: peter(a)peter-dambier.de > Re: http://xn--1lq90ic7fzpc.cn/ > Datum: Thu, 19 May 2005 12:55:22 -0700 (PDT) > > Presumably an internationalized domain name in what, punycode? > Yes, it is. It is amazing to see them in reality, not in discussion. > Regards, > > Joe > Regards, Peter and Karin Public-Root -- Peter und Karin Dambier Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-6252-599091 (O2 Genion) +1-360-226-6583-9738 (INAIC) peter(a)peter-dambier.de http://iason.site.voila.fr

1 0

Peering BOF IX Meeting Minutes
by William B. Norton 19 May '05

19 May '05

Peering BOF IX Meeting Minutes Seattle, WA May 16, 2005 7:30-9:00PM ...Transcribing my notes here for those who couldn't make the Peering BOF... comments/corrections to wbn(a)equinix.com or wbn(a)umich.edu A 5 Minute Plea for Multicast Peering ------------------------------------------------- Celeste Anderson (ISI/Los Nettos) spoke about the need for greater peering of native multicast routing. The audience commented that the volume of multicast traffic was still relatively small (a few T1's worth) in comparison to unicast traffic, and that there is still not significant customer demand to do so. We discussed the chicken and egg problems for a bit. Transit Survey ------------------------ A few people in the community suggested it would be good to get a sense of transit prices, to see if they were continuing to fall, remaining constant, or were rising back up. In previous white papers I had polled the Peering Coordinator Community to get a sense of transit prices for comparison against peering costs, so with this previous data and an audience survey we to take a stab. I asserted that with transit you often get what you pay for, and we were not interested in identifying the "lowest price", the "bottom feeder" price points that have no customer service, and that there is in fact a qualitative difference between transit services. I was looking for approximations of "Tier 1 ISP" pricing – as expected, there was some debate here. To avoid the rathole of "Tier 1" etc. and to focus on "quality" of transit services for a quick price measure I pulled together some questions to disqualify some upstream providers from the survey: Q1: When you complain about packet loss to your Upstream, you are told A) I have Bob working on it, he will call you back in 15 minutes B) Call this other number (which rings busy) C) …Let me put you on hold for an hour(Barry Manilow sings the songs that make the whole world sing) D) You should have sent your packets earlier I told folks if they answered "C" or "D" to please not answer the poll – we were not interested in bottom feeder pricing for this poll. Q2: My Upstream Provider's Reliability is A) 6 9's B) Close to 6 9's C) Closer to 9 6's D) Don't know – I'll let you know when they stay up long enough to measure. I told folks if they answered "C" or "D" to please not answer the poll– we were not interested in bottom feeder pricing for this poll. Q3: My Upstream Provider's Customer Service Makes Me Feel… A) Like a VIP B) Like a Nuisance C) Very, very unclean. D) Like I was just traded to another inmate for 2 packs of menthol cigarettes. I told folks if they answered "C" or "D" to please not answer the poll– we were not interested in bottom feeder pricing for this poll. Source: A couple of these questions/answers came from a Wired magazine article I read on the flight up, which referenced http://www.5ives.com. While not a particularly scientific survey, we did get 28 viable data points with the averages being: 10Mbps commit: $41.75/Mbps 100Mbps commit: $33.83/Mbps 1000Mbps commit: $20.73/Mbps 10000Mbps commit: $13.80/Mbps About 6 months or so ago I did a similar poll with the Peering Coordinator Community and the #s were around $85, $60, $45, $30, indicating that perhaps the transit prices have indeed fallen. If any of you are interested in the raw data (thanks to Eric Troyer for putting the data points into a spreadsheet) let me know and I'll email you the spreadsheet. Peering at 10G – introduction to The Great (Public vs. Private) Peering Debate ---------------------------------------------------------------------------------------------------------------- The motivation for the Great Debate was a white paper I am working on called "The Great (Public vs. Private) Peering Debate: Peering at 10G" in which I documented the Peering Coordinator Community assertion and the math that the next best alternative to 10G Public Peering was many 1G Private Peering sessions. I walked through the models for both cases (10G Public and 1G Private) peering, specifying sample equipment (thanks ras!), cost estimates, etc. so we could compare the two alternatives side-by-side. There were many valid points raised during this discussion including: 1) In the modeling we were not including backbone costs, only IX and Peering equipment fees at one location, 2) There are other valid configurations of equipment, including removing the peering router and using switches by themselves (debate here as well), 3) There were a wide variety of redundancy configurations that could/should be considered as well in both cases. The nice thing about modeling this stuff is the ability to identify and discuss assumptions, to change #'s, to have something on the table to discuss, and it was a lively discussion before and after the BOF. The punch line for the current model I shared was that public peering at 10G and private peering at 1G both are very cost effective solutions, yielding less than $10/Mbps with a few gigabits of peering. Also, the more traffic peered, the more the cost of these two models of peering converged – so Public vs. Private becomes an architectural / religious issue. This leads to the Great Debate – when do people prefer Public Peering and when do they prefer Private Peering, and why? The Great (Public vs. Private) Peering Debate ------------------------------------------------------------------- I recruited Maurice Dean (who was the Peering Coordinator at Global Crossing and now at Google) to present and defend "The Strongest Arguments for Public Peering", and Peter Cohen (Peering Coordinator for Telia) to share "The Strongest Arguments for Private Peering". We used a modified Oxford Style Debate, providing each side three minutes for opening remarks, three minutes each to attack the other side's points and defend their own, a few minutes for the audience to ask clarification questions, and finally two minutes for the debaters to present summary remarks. The audience would then vote for "Who made the more compelling case." Maurice started out by pointing out that IXes today are not the IXEs of 1995, but rather are large and reliable infrastructure that provide access to a rich population of potential peers. Public peering provides instantaneous access to peers, provides aggregation benefits, ease of administration and is easy to scale peering capacity. He pointed also to the marketing benefits of public peering at the IXes. Peter opened by stating that Private Peering provided superior control over peering infrastructure. He went on that Private Peering scaled very well, that the same fiber pairs could be reused as both sides simply upgraded cards. Private Peering is simpler according to Peter since no NetFlow was needed, that there were not 20 peers all peering across the same 10G interface. For some he claimed ISPs, the only way to measure public peering traffic volume to a peer was to turn down a peering session and see the difference in traffic load. Maurice countered reinforcing that modern IXes have overcome the head of line blocking issues of the past and indeed scale very well, and in fact scale well even across a metro area. He defended the NetFlow attack by mentioning that some IXes have sFlow, providing public peering visibility on a per-peer traffic volume basis. Peter countered that Maurice was a "Stooly for the IXes", and depending on a single port for peering is asking for trouble. Further, participation in some IXes requires going to member meetings, and who has time for that. Finally that the added complexity of adding a public peering switch was problematic – he used the analogy of air travel. "How many of you prefer a direct flight over one with connections?" The audience asked a variety of questions next but I did not jot them all down. A few points did come up though – that circuit upgrades for private peering can take 6 months or more depending on which side is in a hurry to upgrade. Another point was that public peering was seen by some as easier to justify to their company since it would be used across many peers. The closing remarks were a rehash of the points above, but Maurice introduced a couple additional points – that 90 day trials could be effectively done over a public peering fabric without additional costs to those attached, and that public peering fabrics enabled more opportunities (for peering? For add'l services? For transit sales?...not sure what he meant here). Peter reasserted that placing all the eggs in one public peering port was just asking for trouble. The audience next voted "Who presented the more compelling case?" We had to count twice because it was so close. The final results: Public Peering presented the more compelling case: 37 Private Peering presented the more compelling case: 33 Maurice Dean won the Great Peering Debate. White Paper Available -------------------------------- I captured these and other arguments for and against private peering in the white paper mentioned above – I would love to have a few more reviewers give me some feedback/edits/etc. If you are interested in 10 Gigabit Ethernet Peering or the debate discussion, send me an email (wbn(a)equinix.com) with the Subject: "The Great (Public vs. Private) Peering Debate – Peering at 10G" and I'll send you a copy. If you provide comments on the draft I will add you to the acknowledgements section of the next version of the document. We were running out of time so we moved quickly to Peering Personals, giving Peering Coordinators a chance to introduce themselves to the group. Peering Personals – (jotted down everything on the sheets) -------------------------------------------------------------------------------------- Korea Telecom – 4766 – Bong-Hwa Song – 40 Gbps Capacity, peering in Seattle PAIX, Palo Alto PAIX, EQLA, LINX, AMSIX, songbh(a)kt.co.kr AARNET – 7575 – Mark Prior – Research Net, Seattle SIX, PAIX, LAIIX, LAAP, FixW, P|Wave, mark.prior(a)aarnet.edu.au Netflix – Vish Y – vish(a)netflix.com – Selective peer Steve Gibbard – PCH – 42, 3856 – Data Collection – Open Peering 0 25 locations all over the world (SIX, EQLA, LAIIX, NYIIX, PAIXNY, EQASH,NOTA,…) Steve Gibbard – Hurricane Electric – 6939 – scg(a)stevegibbard.com, peering(a)he.net – 2700 routes, public but migrating to private at EQSJO, EQLA, EQCHI, EQDAL, EQASH, PAIXPA,NYIIX, LINX, AMSIX Brokaw Price – Yahoo! – 10310 – OPEN – peering(a)yahoo-inc.com Todd Underwood – 64597 – todd(a)renesys.com – NOTA, LINX, Goofy peering, route collection only, store updates, Google – Maurice Dean – 15169 – selective peering – peering(a)google.com, NYIIX, EQ-CHI, EQCHI, EQASH, NOTA, PAIXPA,PAIXVA,1118th, TelX (60 Hudson)., LINX< AMSIX, LAIIX Akamai – 12222 – Patrick Gilmore – 20940 outside U.S., OPEN and at every IX, content heavy, peering(a)akamai.com ESNET – 293 – Yvonne – ipv4, ipv6, multicast, EQASH, EQSJO, MAEEast MAEWest, PAIX, AADS, FixW, Pacific NW Gigapop, peering(a)es.net, selective peering policy with AUP Celeste Anderson – AS4, AS27, AS2152/2153, ISI/Los Nettos, research net, lots of eyeballs, LAIIX, LAAP, Pacific Wave, PAIX LA, Mostly OPEN~selective, eyeballs, peering(a)pacificwave.net, celestea(a)usc.edu, Matt Peterson – SixApart , AS# pending, SIX, EQSJO, LiveJournal.com, matt(a)sixapart.com -------------------------------------------------------------------------------------------------------------- Hope this help! -- //------------------------------------------------ // William B. Norton <wbn(a)equinix.com> // Co-Founder and Chief Technical Liaison, Equinix, Inc. // GSM Mobile: 650-315-8635 // Skype, Y!IM: williambnorton

1 0