- Test - lists.nanog.org

SMTP relaying policies for Commercial ISP customers...?
by Dan Ellis 13 Feb '04

13 Feb '04

My apologies for another annoying SMTP thread. So, while considering enabling SMTPAUTH for all our customers, I'm planning on placing firm policy on relaying. We're a regional broadband ISP/MSO that also serves a significant number of educational and commercial cable/DSL connections as well as a large number of T1/T3/OC3/Ethernet customers. That leaves with me needing to define how we will handle 3 situations: 1) Residential (a few dynamic IP computers) 2) Broadband Commercial (Static IP and a few forwarded IP's, a dozen end user PC's) 3) Dedicated commercial customers (t1/ds3/Ethernet/oc3) HISTORY: Old school thought was that as long as you are on an ISP's IP space, you can use them to relay. This made it easy for roamers as everyone would use the ISP's mailserver for outbound, and their mailserver for inbound. Yes - there was always a fuzzy line for t1/ds3/oc3 customers because some ISP's allowed their space to relay and some did not. I'm trying to determine what the "new school" thoughts are. Below are my thoughts and concerns on each. I'm interested in hearing what others have implemented regarding policy, what the large NSP's have implemented, and what your thoughts are. 1) Residential Policy: Enable SMTPAUTH and disallow relaying unless the customer has a valid username/password. If you're not paying for a mailbox, you don't get to relay outbound. This should not break anything except those residential accounts that *should* be commercial anyway. 2) Broadband commercial: This is the difficult one. These are the customers that aren't big enough to rightfully run their own mailserver, but they are big enough to have roaming users on their networks (coffee shops, branch offices, hotels, SOHO....). They expect relaying service for either their mailserver or for all their various PC's. At the same time, they don't have many, if any mailboxes through the ISP. My thought is that they should ONLY be allowed to relay via SMTPAUTH by using a residential mailbox login/pass OR they need to purchase a commercial relay service (expensive because of the openness of it) for their IP space. 3) T1+ : These customers should not be allowed to relay unless they purchase (expensive) relay services for their IP space. Of course, they can always use a residential mailbox, but will have to use SMTPAUTH for it and will be restrained by the same policies residential mailboxes have (low tolerance tarpitting,...). As always, thanks in advance. --Dan -- Daniel Ellis, CTO, PenTeleData (610)826-9293

4 3

Re: SMTP authentication for broadband providers
by Alex Bligh 13 Feb '04

13 Feb '04

--On 13 February 2004 08:47 -0500 Carl Hutzler <cdhutzler(a)aol.com> wrote: > Is this what is commonly referred to as STARTTLS? That would be good, but doesn't work when port 25 is blocked unless it's STARTTLS on submission. Alex

1 0

Nortel Optera 5200's
by Alex Rubenstein 13 Feb '04

13 Feb '04

I am looking for a folk or two who has operational experience on the above, and who can give me a couple pointers. Much appreciated. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

1 0

The Cidr Report
by cidr-report＠potaroo.net 13 Feb '04

13 Feb '04

This report has been generated at Fri Feb 13 21:47:46 2004 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 06-02-04 130549 91173 07-02-04 130555 91204 08-02-04 130702 91246 09-02-04 130759 91319 10-02-04 130872 91396 11-02-04 130759 91492 12-02-04 131091 91537 13-02-04 131225 91526 AS Summary 16536 Number of ASes in routing system 6635 Number of ASes announcing only one prefix 1371 Largest number of prefixes announced by an AS AS7018 : ATT-INTERNET4 AT&T WorldNet Services 73517312 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA 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'). --- 13Feb04 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 131255 91501 39754 30.3% All ASes AS4323 685 203 482 70.4% TW-COMM Time Warner Communications, Inc. AS6197 732 298 434 59.3% AS6197 AS7018 1371 963 408 29.8% ATT-INTERNET4 AT&T WorldNet Services AS701 1343 951 392 29.2% ALTERNET-AS UUNET Technologies, Inc. AS7843 506 128 378 74.7% ADELPHIA-AS Adelphia Corp. AS27364 382 33 349 91.4% ACS-INTERNET Armstrong Cable Services AS6198 545 214 331 60.7% BATI-MIA BellSouth Network Solutions, Inc AS4134 652 329 323 49.5% CHINANET-BACKBONE No.31,Jin-rong Street AS22909 340 20 320 94.1% DNEO-OSP1 Comcast Cable Communications, Inc. AS22773 342 34 308 90.1% CCINET-2 Cox Communications Inc. Atlanta AS1239 950 665 285 30.0% SPRINTLINK Sprint AS4355 385 101 284 73.8% AS4355 AS9583 341 77 264 77.4% SATYAMNET-AS Satyam Infoway Ltd., AS17676 294 41 253 86.1% GIGAINFRA Softbank BB Corp. AS1221 902 650 252 27.9% ASN-TELSTRA Telstra Pty Ltd AS6347 330 83 247 74.8% DIAMOND SAVVIS Communications Corporation AS6140 357 127 230 64.4% IMPSAT-USA ImpSat AS25844 243 16 227 93.4% SKADDEN1 Skadden, Arps, Slate, Meagher & Flom LLP AS6478 260 38 222 85.4% ATT-INTERNET3 AT&T WorldNet Services AS209 723 511 212 29.3% ASN-QWEST Qwest AS14654 214 3 211 98.6% WAYPORT Wayport AS13083 216 8 208 96.3% AS13083 Mannesmann Datenverarbeitung Autonomes System AS11305 242 41 201 83.1% INTERLAND-NET1 Interland Incorporated AS2386 419 231 188 44.9% INS-AS AT&T Data Communications Services AS20115 612 424 188 30.7% CHARTER-NET-HKY-NC Charter Communications AS5668 345 158 187 54.2% AS-5668 CenturyTel Internet Holdings, Inc. AS4519 203 20 183 90.1% MAAS Maas Communications AS6327 207 29 178 86.0% SHAW Shaw Communications Inc. AS9929 203 31 172 84.7% CNCNET-CN China Netcom Corp. AS15270 210 39 171 81.4% AS-PAETEC-NET PaeTec.net -a division of PaeTecCommunications, Inc. Total 14554 6466 8088 55.6% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 ANDARA-HSI Andara High Speed Internet c/o Halifax Cable Ltd. 63.0.0.0/8 AS705 ALTERNET-AS UUNET Technologies, Inc. 64.62.126.0/23 AS25700 SWIFTDESK SWIFTDESK VENTURE 66.114.0.0/19 AS16526 BIRCH-TELECOM Birch Telecom, Inc. 66.114.28.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 66.114.29.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 66.114.30.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 66.114.31.0/24 AS15083 INFOLINK-MIA-US Infolink Communication Services, Inc. 69.8.128.0/17 AS7260 NORLIGHT Norlight Telecommunications 132.0.0.0/10 AS568 SUMNET-AS DISO-UNRRA 137.0.0.0/13 AS568 SUMNET-AS DISO-UNRRA 138.136.0.0/13 AS568 SUMNET-AS DISO-UNRRA 156.246.0.0/16 AS9317 ITISNET-AS Inha University 158.0.0.0/13 AS568 SUMNET-AS DISO-UNRRA 192.43.230.0/24 AS4738 SAARDNET-AS South Australian Academic Research and Development Network 192.44.0.0/19 AS702 AS702 MCI EMEA 192.64.84.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.16.0/20 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.32.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.64.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.96.0/22 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.100.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.119.135.0/24 AS270 PSCNI-AS National Aeronautics and Space Administration 192.124.252.0/22 AS680 AS680 DFN-IP service G-WiN 192.135.50.0/24 AS7018 ATT-INTERNET4 AT&T WorldNet Services 192.136.71.0/24 AS719 LANLINK Elisa Oyj 192.136.79.0/24 AS719 LANLINK Elisa Oyj 192.153.144.0/21 AS568 SUMNET-AS DISO-UNRRA 192.172.0.0/19 AS568 SUMNET-AS DISO-UNRRA 192.188.208.0/20 AS568 SUMNET-AS DISO-UNRRA 192.243.32.0/23 AS2044 PALIN-AS Palin Aquisitions Inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM Bell Atlantic, Inc. 198.97.72.0/21 AS568 SUMNET-AS DISO-UNRRA 198.97.80.0/20 AS568 SUMNET-AS DISO-UNRRA 198.97.88.0/24 AS89 NUSC-CSTLNET-AS Naval Underwater Systems Center 198.97.192.0/20 AS568 SUMNET-AS DISO-UNRRA 198.97.240.0/20 AS568 SUMNET-AS DISO-UNRRA 198.101.4.0/22 AS568 SUMNET-AS DISO-UNRRA 198.136.32.0/20 AS19329 MCNET Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY-NET CityNet, Inc. 198.161.87.0/24 AS6539 GROUPTLCOM GT Group Telecom Services Corp. 198.161.165.0/24 AS852 ASN852 Telus Advanced Communications 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.10.0.0/16 AS568 SUMNET-AS DISO-UNRRA 199.60.0.0/20 AS271 BCNET-AS University of British Columbia 199.84.0.0/16 AS701 ALTERNET-AS UUNET Technologies, Inc. 199.114.0.0/18 AS568 SUMNET-AS DISO-UNRRA 199.114.0.0/21 AS568 SUMNET-AS DISO-UNRRA 199.114.128.0/18 AS568 SUMNET-AS DISO-UNRRA 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.136.0/24 AS1913 DLA4 Defense Logistics Agency 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 AS1913 DLA4 Defense Logistics Agency 199.114.154.0/24 AS1733 CENTAF-SWA AF DDN PMO 199.114.156.0/24 AS1913 DLA4 Defense Logistics Agency 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 AS568 SUMNET-AS DISO-UNRRA 199.123.0.0/18 AS568 SUMNET-AS DISO-UNRRA 199.123.16.0/20 AS568 SUMNET-AS DISO-UNRRA 199.123.80.0/21 AS568 SUMNET-AS DISO-UNRRA 199.189.32.0/19 AS7332 IQUEST-AS IQuest Internet 199.202.0.0/16 AS701 ALTERNET-AS UUNET Technologies, Inc. 202.47.1.0/24 AS7491 PI-PH-AS-AP PI-PHILIPINES 202.70.0.0/20 AS4658 NETFRONT-AS NETFRONT I.T. LIMITED (HONG KONG) 202.70.240.0/20 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.86.128.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.142.0/24 AS30362 HPT-ASN Hawaii-Pacific Teleport 202.86.171.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.172.0/23 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.190.0/24 AS4750 loxley-th Loxley Information Co., Ltd. 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.122.76.0/24 AS17553 TIMELESS-AP System Integration provider 202.133.3.0/24 AS9335 CIP-JAPAN-AS-AP ATT IPlus 202.143.56.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.240.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.248.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.155.243.0/24 AS4795 INDOSAT2-ID-AP INDOSATNET-ASN 203.32.4.0/23 AS7617 AS7617 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.86.2.0/23 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 203.132.107.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.108.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.111.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.118.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.122.0/24 AS4802 WANTREE-AS-AP Wantree Development 203.132.123.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.124.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 204.69.144.0/22 AS5668 AS-5668 CenturyTel Internet Holdings, Inc. 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.41.32.0/19 AS14824 NEWSOUTH NewSouth Communications Corp. 206.81.187.0/24 AS19194 JOVITA Sentris Network LLC 206.108.34.0/24 AS852 ASN852 Telus Advanced Communications 206.108.35.0/24 AS852 ASN852 Telus Advanced Communications 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.251.69.0/24 AS27429 TIL Telesat International Ltd. 207.162.192.0/19 AS4589 EASYNET Easynet Group Plc 207.231.96.0/19 AS11194 AS11194 208.81.187.0/24 AS19194 JOVITA Sentris Network LLC 209.169.219.0/24 AS189 GENUITY-AS189 Genuity 209.169.223.0/24 AS189 GENUITY-AS189 Genuity 209.213.32.0/19 AS10629 INTERPAC Inter-Pacific Network Services 209.213.50.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.51.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.55.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.56.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.222.137.0/24 AS27429 TIL Telesat International Ltd. 209.240.96.0/19 AS10815 KCNET KCnet, Inc. 209.251.0.0/19 AS11036 SISCOM SISCOM, Inc 209.251.64.0/19 AS10266 NETWAY-AS MDC, Inc. 210.213.0.0/19 AS6453 GIEUROPE Teleglobe America Inc. 216.18.224.0/21 AS11458 IMBRIS IMBRIS, INC. 216.18.224.0/22 AS11458 IMBRIS IMBRIS, INC. 216.18.228.0/22 AS11458 IMBRIS IMBRIS, INC. 216.36.46.0/24 AS7176 GENUITY-AS7176 Genuity 216.36.47.0/24 AS7176 GENUITY-AS7176 Genuity 216.96.128.0/18 AS7018 ATT-INTERNET4 AT&T WorldNet 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

1 0

Re: SMTP authentication for broadband providers
by Miquel van Smoorenburg 13 Feb '04

13 Feb '04

In article <cistron.20040212023825.GA77062(a)metron.com>, Lou Katz <lou(a)metron.com> wrote: > >On Wed, Feb 11, 2004 at 03:13:30PM -0500, Sean Donelan wrote: >> >> On Wed, 11 Feb 2004 Valdis.Kletnieks(a)vt.edu wrote: >> > On Wed, 11 Feb 2004 11:15:20 PST, Dave Crocker said: >> > > what about port 25 blocking that is now done by many access providers? >> > > this makes it impossible for mobile users, coming from those providers, >> > > to access your server and do the auth. >> > >> > Port 587. >> > >> >> So is it time for ISPs to start blocking port 587 too? >> >> If the complaints are going back to the IP address anwyay, why shouldn't >> an ISP force it subscribers to go through the ISPs mail servers so it can >> control any messages sent by its subscribers? > > >Because, maybe, I don't think it is a good idea for someone else to CONTROL >any messages I might send. Who will control the controllers? As if they don't yet CONTROL the messages you receive ? Where, exactly, is your POP3/IMAP mailbox located ? Ah, you run your own mailserver for your own domain. So, you can use the submission port on your own mailserver, right ? Mike.

4 4

Re: SMTP authentication for broadband providers -- A MODEST PROPOSAL
by Dr. Jeffrey Race 13 Feb '04

13 Feb '04

On Thu, 12 Feb 2004 22:58:18 -0800, Dave Crocker wrote: > To attack spam, we need to attack it at its core, not at some secondary or > tertiary side-effect, with a mechanism that also hurt legitimate users. > So, what, exactly, _is_ that core? > Unless and until there is broad community consensus that answers that > question in concrete and practical terms, then all our efforts are > losing and stop-gap. A concrete and practical solution, which has been proven to work in hours, engineered from well-known principles of human behavior: <http://www.camblab.com/misc/univ_std.txt> derived from <http://www.camblab.com/nugget/spam_03.pdf>. Suggestions welcome. When I get some time (maybe in April) I may get to put this into the RFC-draft hopper. Needs a day of reformatting I've not gotten to yet. Anyone who has done this and could volunteer to help, contact me offlist. Kind regards to all, Jeffrey Race, today in Bangkok Thailand ---------------------------------------- USA tieline (rings at Bangkok residence) TIME ZONE GMT +7 -------------+1 617 395-4111------------ Tel +66 2 291-2235 Fax +66 2 688-4540 Tel +66 6 709-7645 (mobile -- 24 hours) Tel +66 6 563-5682 (mobile -- odd times) ADVENTURES IN THAI JUSTICE Cautionary real-life case studies for potential investors or visitors <http://pws.prserv.net/studies/>

1 0

SMTP authentication for broadband providers
by Dan Ellis 13 Feb '04

13 Feb '04

Greetings, We're a medium sized regional MSO/broadband provider with 200k+ mailboxes, strongly considering enabling SMTP authentication on our customer-facing SMTP mail servers. We feel this is the next logical step to minimize our users UCE/virus impact (we already tarpit, virus scan, UCE scan, subscribe to RBL's, reject prior to SMTP close). I'm looking for comments on whether this is generally seen as a positive change or a waste of time (ie - will the next virus or worm gleam your SMTP username and password from Outlook Express and use it to replicate/SPAM)? Is anyone aware of any well known mail clients that do not support SMTP authentication (Unix, Windows or Mac)? Thanks in advance. --Dan -- Daniel Ellis, CTO, PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay

12 18

Interesting BIND error
by Brian Wallingford 13 Feb '04

13 Feb '04

We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same. Seems harmless enough, but the logging is eating a disproportionate amount of cpu. Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument >From socket.c: #undef ALWAYS_HARD /* * The other error types depend on whether or not the * socket is UDP or TCP. If it is UDP, some errors * that we expect to be fatal under TCP are merely * annoying, and are really soft errors. * * However, these soft errors are still returned as * a status. */ isc_sockaddr_format(&dev->address, addrbuf, sizeof(addrbuf)); isc__strerror(send_errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, "internal_send: %s: %s", addrbuf, strbuf); dev->result = isc__errno2result(send_errno); return (DOIO_HARD);

10 11

Where can I find a list of IPs and their regions.
by Matthew Crocker 12 Feb '04

12 Feb '04

I've look at IANA but it doesn't give enough detailed information. I would like to find a list of /8 or /16s and what geographic region the exist in. I know it isn't an exact science but something close would be nice. I know 210/8 & 211/8 are APNIC, I likes to know stuff like 210.100/16 is Korea and 210.120/16 is China, etc. Does anyone have a list I can pull from? -Matt

9 16

Peering BOF VII Meeting Minutes (NANOG 30 Miami)
by William B. Norton 12 Feb '04

12 Feb '04

Hi all - For those of you who could not attend the BOF, here are my notes from the Peering BOF. Comments welcome - Peering BOF VII - NANOG 30 - Miami 2/10/2004 7PM Moderator: William B. Norton We were at capacity in the room and started right at 7PM. The Great Debate -------------------------- The Peering BOF started with a refereed debate on "Restrictive Peering Policy: Makes Business Sense vs. Counter Productive." The debate at the Peering BOF was a first miniature stab at a Internet Operations debate focusing on an emotional charged topic, one area perceived as being concealed by NDAs, hidden agendas, greedy corporate interests, ill will: Restrictive Peering Policies. People attending the BOF heard in about 20 minutes some pretty good arguments why such a policy made business sense, and why it was also counter productive. I opened sharing some of the controversy, sharing the definitions of peering, transit, restrictive, selective and open peerign policies, etc. These should be on-line at http://www.nanog.org/mtg-0402/norton.html Vijay Gill (AOL) agreed to present the Affirmative Case, that Restrictive Peering Policies make business sense. He argued that Peering Policies are not emotional, not personal, but black & white decisions based on economics, a calculation on a spreadsheet. Peering is not free and there are scaling issues and associated operational costs that must be justified. Peering is also somewhat of a threat to revenue production as well, since peering between customers bypasses the ISP. Avi Freedman (Akamai) agreed to present the Counter Case, that Restrictive Peering Policies are counter-productive. He pointed to the overhead associated with peering as being a rare exception; peering sessions tends to stay up. Avi pointed to the counter productive aspects of a Restrictive Peering Policy: 1) It inspires the wrong thing. Sprint will never peer with anyone that ever bought transit from them, and that in fact drives the "End-run, peer with Sprint's customers" behavior that lowers revenue for Sprint. 2) Many large networks lose revenue by not peering more openly, as it turns off customers, and 3) Performance improvements from peering widely *increase* revenue. Avi eluded to his AboveNet experience where he witnessed a) customer behavior: customers spending more time on line because of a better experience, b) lower latency and lower packet loss lead to the TCP window opening up faster means more data is exchanged, thus leading to more $ for those that charge on a per-Mbps basis. Better performance drives more revenue. Vijay countered with the "reducto ad adsurdium" argument; the case of peering with each of 200 million laptops computers running zebra. The overhead of peering with 200M laptops would certainly fail the cost benefit analysis. As far as the performance argument, he claimed that the top visited sites from AOL show little performance difference ("imperceptible") between paths reached across peering versus transit links. Finally, he dismissed the selection of an ISP based on Peering Policy, claiming it is today all driven by price. The peering decision is business and mathematical, black & white, a pure economic decision that does what is best for the company. Avi finished up by dismissing the peer-with-all-laptops as not reasonable, not what anyone is advocating, not what is being debated. He argued that the debate is really speaking to the reasonable middle ground case, where both parties have infrastructure deployed. Around 50% of customer traffic will go around you if you do not peer more openly. Restrictive Peering Policies analysis must include the opportunity cost of lost business and lost revenue, a more difficult calculation to make but one that ultimately shows Restrictive Peering policies as counter productive. VERDICT: The audience voted on "which side presented the more compelling case". The winner: Restrictive Peering Policies are Counter Productive (35-43). (Editor's note: this was much closer than I think most people expected; the audience at the Peering BOFs are generally open or selective peers, and have or expect to be stubbed if trying to peer with a Restrictive Peering Policy peer. Both sides presented a good case.) Cable & Wireless: A Tier 1 Peering Policy evolution & C&W migration to Savvis ------------------------------------------------------------------------------------------------------------------ After the debate, Peter Jansen (Peering Coordinator for C&W) volunteered to share with the audience a bit about the evolution of the C&W Peering Policy and what led to their current Peering Policy. He positioned a restrictive policy as a natural outcome of commercial interests (peering costs money) and but said that they will in fact peer with those that meet the peering criteria. There is a committee that evaluates and verifies the requests and there are no personalities involved here. There was a good exchange in the group with a handful of Q&A. Peter did a great job - he put a face to what was otherwise seen as cold corporate interests. He also spoke about the transition C&W is going through, migrating its network to Savvis. The audience was definitely engaged and interactive during these two sessions. The correlation was brought up between Restrictive Peering Policies and Bankruptcy (Wcom, C&W, Genuity, TeleGlobe, ...). Someone made the point that many of the ISPs with Restrictive Peering Policies that had argued for making Peering decisions based on economic analysis had in fact gone bankrupt... How good can those spreadsheets be? The debate generated a good sized crowd at the Peering BOF. Everyone likes a good fight I suppose, and the Peering BOF is one of the few places where people understand and care about this stuff. Peering Personals --------------------------- We spent the second half of the Peering BOF with Peering Personals, a chance for Peering Coordinators to introduce themselves to each other in a 2 minute talk. On the screen behind them were Contact details, AS#, Peering Policies, and a US Map with Peering locations mapped out. They spoke about their network, their peering policy, what they look for in a peer and why others should want to peer with them. The following people participated in the Peering Personals: (I note below a couple remarkable points brought up during their 2 minutes...) Company AS Number First Name Last Name -------------- ----------------- ---------------- ---------------- Akamai 12222 Patrick Gilmore Broadwing 6395 Allison Feese Carpathia Hosting, Inc. 29748 Scott Bethke CENIC 2150++ Dave Reese CET Networks 22934 Dennis Nugent - 4Gbps of traffic, little peering (yet) FLAG Telecom, Ltd. 15412 Nigel Titley Global Crossing 3549 Maurice Dean Japan Telecom America 4725 Amir Arif - 3.5Gbps to the U.S. JENS Co. 2915, 4682 Daizo Tomigahara New Edge Networks 19029 Cathy Chen - DSL in many tier 2 cities Packet Clearing House 3856, 42 Steve Gibbard ServePath 26228 Steve Gibbard SingAREN 7610 Steve Gibbard TDS Telecom 4181 Chris Malayter TeleGlobe 6453, 8297 Sylvie LaPerriere - very strict peering policy, 300Mbps, US, Asia, Europe, 24x7 NOC, <2:1 ratio UPC 6830 Frank Hellemink - 10 countries, 14Gbps traffic, 65% peering today Los Nettos 226 Celeste Anderson Walmart.com 17374 Will Campbell Yahoo 5779, 10310 Brokaw Price - Brokaw contested the operational load argument from the debate; - they have over 600 peering sessions and the load is mostly virtual - they are saving "in the seven figures" annually by peering Microsoft 8068, 8075 Doug Wilson - Doug had a good sense of humor (I flashed the BSOD 25 seconds in ;-) ) Aleron 4200 Ryan McClune - requires multiple locations across the U.S. AARNet 7575+ Mark Prior China Telecom 4134 xiaoyi liu - 11 Gbps between US & China - 80% traffic in China is China Telecom Cable & Wireless 1273 Christian Kaufmann - (PLC) in U.S. will have a more open peering policy Adelphia Communications Corporation 18756, 19548 Dean Deback - 10 Gbps in, 6Gbps out - ~ 40% peer2peer (see slides) SoftbankBB 17676 Masato YAMANISHI - not peering in U.S. yet, 48Gbps ingress in Japan, 24Gbps outbound - 10G peering Google, Inc. 15169 Paul Nguyen UltraDNS 12008 Rodney Joffe - 12Gbps of traffic There were a lot of people on this list with "Pulse Peering Policies"; if you have a pulse, we will peer with you. (The previous name for this policy was replaced.) I produced a matrix showing those with open policies that were colocated at the same IXes, and there were a lot of green squares indicating that peering could/should/maybe already does occur between these companies. All in all I thought it was a useful and interesting Peering BOF. We ran over by about 20 minutes due to the late addition of Peter's C&W talk, and a couple Peering Personals that were past the cut off date but too important for this group to pass up. Both of these however represent significant changes in the U.S. Peering Ecosystem that they were worth the time. Comments welcome - Bill // // William B. Norton <wbn(a)equinix.com> +1.650.315.8635 // Co-Founder and Chief Technical Liaison Equinix, Inc. //

1 0