- NANOG - lists.nanog.org

RE: East Coast Outages?
by John Kloian III 28 Jun '01

28 Jun '01

Thanks for all the responses. I should have first prefaced my original post with: "I cannot verify that anythting is actually down because I can get to everything I mentioned." I thought it weird getting a call from a reporter in Maryland stating that he and several ISPs are seeing a "major" outage that I nor my engineers can verify. ~ - John On Thu, 28 Jun 2001, Susan L. Collicott wrote: > >internettrafficreport.com shows everything in the world as 'down', as far >as I can see ... :) > >Susan > >On Thu, 28 Jun 2001, Daniel Golding wrote: > >> >> John, >> >> Needless to say, MAE-EAST ATM and MAE-WEST ATM are both up. If this is news >> that MAE-East FDDI is down, than it is, unfortunately, a bit late. :) >> >> Besides, I thought Opnix didn't need to worry about those terrible public >> peering points... >> >> - Dan >> >> > -----Original Message----- >> > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of >> > John Kloian III >> > Sent: Thursday, June 28, 2001 4:53 PM >> > To: nanog(a)merit.edu >> > Subject: East Coast Outages? >> > >> > >> > >> > I've just had several calls, even one from a reporter back east in >> > Maryland. Apparently mae-east and west are down. Can anyone veryify an >> > outage, ANYWHERE? internettrafficreport.com shows mae-west down and >> > serverbank.net shows mae-east down (both with 100% packet-loss). >> > Anything? >> > >> > >> > ~ >> > - John >> > >> >> > > >

1 0

Re: Peering Breakeven Analysis White Paper
by PETER JANSEN 28 Jun '01

28 Jun '01

Bill: I would be very interested reading and commenting on your peering paper. Best regards Peter Jansen Senior Manager, Global Peering Cable & Wireless Global e-mail: peter.jansen(a)cw.net Date: Thu, 28 Jun 2001 14:46 -0400 (EDT) From: "William B. Norton" <wbn(a)equinix.com> To: nanog(a)merit.edu CC: wbn(a)equinix.com Sender: owner-nanog(a)merit.edu Delivered-to: nanog-outgoing(a)trapdoor.merit.edu Delivered-to: nanog(a)trapdoor.merit.edu Delivered-to: nanog(a)merit.edu Subject: Peering Breakeven Analysis White Paper Hi all - After about 6 months, I've finally finished a presentable draft of a community white paper I'd like to share with a handful of interested folks. The draft is titled "The Peering Breakeven Analysis Graph: An ISP Peering Cost Savings Analysis" and finishes up the research I've done with the Peering Coordinator Community. It complements the "Internet Service Providers and Peering" white paper that I know many of you have read and focuses on its business case for peering that Bill St. Arnaud cited at a NANOG. Here is the Abstract: -------------------------------- During the recent economic turmoil, Internet Service Providers are looking for ways to reduce their costs of providing Internet services. Chief among their costs are telecommunications costs, the cost of getting traffic to the other networks of the Internet. Discussions with ISP Peering Coordinators identified Internet Service Provider (ISP) "Peering" as one of the most effective methods of reducing telecommunications costs for ISPs. The ISP Peering Coordinator's job is to establish and effectively manage this interconnection between ISPs. Goals include maximizing efficiency and minimizing costs of interconnect costs. As demonstrated in the "Internet Service Providers and Peering " earlier work, the job requires a rare combination of technical and business acumen with good people and negotiating skills. This paper introduces the ISP Peering Coordinators terminology and the tools and analysis typically used. We demonstrate these with a specific implementation and generalize them in the form "Peering Break Even Analysis Graph". This is the business case for Internet Service Provider peering based on current practices and market prices. ------------------------------------- If you can help and have the inclination to read it (it is only six pages) and comment, please send me e-mail: wbn(a)equinix.com Thanks - Bill ---------------------------------------------------------------------------- ------------------------------------------------- William B. Norton Co-Founder and Chief Technical Liaison Equinix wbn(a)equinix.com 650.315.8635

1 0

RE: New NAP Opening in Miami this week
by Mark Borchers 28 Jun '01

28 Jun '01

Two, actually. Refer to http://www.nanog.org/mtg-0102/florida.html <http://www.nanog.org/mtg-0102/florida.html> -----Original Message----- From: Larry Diffey [mailto:ldiffey@technologyforward.com] Sent: Thursday, June 28, 2001 2:41 PM To: nanog(a)merit.edu Subject: New NAP Opening in Miami this week According to this story <http://www.zdnet.com/intweek/stories/news/0,4164,2779717,00.html> on zdnet, there is a large NAP opening this week in Miami. This NAP will primarily be used to pipe traffic to and from Latin and South America. The facility is a whopping 32 feet above sea level!

3 2

Peering Breakeven Analysis White Paper
by William B. Norton 28 Jun '01

28 Jun '01

Hi all - After about 6 months, I've finally finished a presentable draft of a community white paper I'd like to share with a handful of interested folks. The draft is titled "The Peering Breakeven Analysis Graph: An ISP Peering Cost Savings Analysis" and finishes up the research I've done with the Peering Coordinator Community. It complements the "Internet Service Providers and Peering" white paper that I know many of you have read and focuses on its business case for peering that Bill St. Arnaud cited at a NANOG. Here is the Abstract: -------------------------------- During the recent economic turmoil, Internet Service Providers are looking for ways to reduce their costs of providing Internet services. Chief among their costs are telecommunications costs, the cost of getting traffic to the other networks of the Internet. Discussions with ISP Peering Coordinators identified Internet Service Provider (ISP) "Peering" as one of the most effective methods of reducing telecommunications costs for ISPs. The ISP Peering Coordinator's job is to establish and effectively manage this interconnection between ISPs. Goals include maximizing efficiency and minimizing costs of interconnect costs. As demonstrated in the "Internet Service Providers and Peering " earlier work, the job requires a rare combination of technical and business acumen with good people and negotiating skills. This paper introduces the ISP Peering Coordinators terminology and the tools and analysis typically used. We demonstrate these with a specific implementation and generalize them in the form "Peering Break Even Analysis Graph". This is the business case for Internet Service Provider peering based on current practices and market prices. ------------------------------------- If you can help and have the inclination to read it (it is only six pages) and comment, please send me e-mail: wbn(a)equinix.com Thanks - Bill ---------------------------------------------------------------------------- ------------------------------------------------- William B. Norton Co-Founder and Chief Technical Liaison Equinix wbn(a)equinix.com 650.315.8635

3 2

New NAP Opening in Miami this week
by Larry Diffey 28 Jun '01

28 Jun '01

According to this story on zdnet, there is a large NAP opening this week in Miami. This NAP will primarily be used to pipe traffic to and from Latin and South America. The facility is a whopping 32 feet above sea level!

2 1

Re: Cable Modem [really responsible engineering]
by Fletcher E Kittredge 28 Jun '01

28 Jun '01

On Thu, 28 Jun 2001 10:54:14 -0700 Ted Lemon wrote: > You're missing a piece, actually - sorry about that. You need to > read RFC3046 as well. I thought DOCSIS referred to it, but maybe > not. Hey! That is a *very* cool spec. Do you know if any cable equipment implements it yet (Motorola I assume?) From my packet sniffing, I don't think the DOCSIS 1.0 and 1.1 gear we use implements RFC3046 yet. >From a casual skim RFC3046, "DHCP Relay Agent Information Option", looks like a great idea that would solve many of the problems mentioned in this thread. Rather than ask the customer for their MACs, it would be possible to monitor DHCP packets and populate a database from the Relay information. I am not involved in the DOCSIS standards process, but future DOCSIS specs should require RFC3046. Since Motorola is a major player in cable modems, I bet RFC3046 will make it into future standards. Thanks Ted, I appreciate the pointers. I will lobby to try to make the above happen. This is the Internet at its best. regards, fletcher

1 0

Open Peers at PAIX
by Pete Ashdown 28 Jun '01

28 Jun '01

What follows is a list I compiled of organizations at PAIX who peer without restrictions. Restrictions are "requirements" like nationwide or international OC-48 backbone, 45Mbit minimum traffic, four geographically disparate peering locations, bicoastal peering, and a standing seat on the Trilateral Commission. These restrictions are impossible for a small network like my own to fill. Usually by the time I am financially able to meet these restrictions, new ones have been crafted in their place. This list was compiled after an exaustive attempt to contact and peer with everyone participating at PAIX. The PAIX organization is unable to compile such a list, as it would violate their neutrality. I, however, am interested in peering with anyone and anything at PAIX, and I would presume that most networks who have made an investment to get there, would actually want to utilize their equipment. Without rehashing the endless debate on open peering, I believe it is more productive to promote the networks who are open peers, so time is not wasted filling out NDA's and applications only to be told, "No." I have only listed participants who are actively peering with me now. Several are still awaiting equipment and transit and have reacted positively to my requests. Also, I have not listed a particular network whom with I have peered for over two years. They have decided to place a "bicoastal restriction" on peering, and they are actually going through and depeering with former peers. This hasn't happened to me yet, but I'd imagine after this email, they'll accelerate their isolation. If anyone has any corrections or additions to this list, please email them to me directly. I will send this list to NANOG periodically unless there are major objections. Organization IP address AS# Email contact Vixie Enterprises 198.32.176.3 3557 noc(a)unnwo.net AboveNet 198.32.176.11 6461 noc(a)above.net DSL.net Santa Cruz 198.32.176.13 4436 admin(a)tycho.net Exodus 198.32.176.15 3967 peering(a)exodus.net Hurricane Electric 198.32.176.20 6939 mleber(a)he.net U-Net 198.32.176.22 5669 aid(a)u-net.net ValuServe 198.32.176.28 6123 noc(a)valuserve.com Global Crossing 198.32.176.29 3549 peering(a)gblx.net I.Net Technologies 198.32.176.30 3976 noc(a)nuri.net Lightning Internet 198.32.176.34 6427 noc(a)cp.net Critical Path 198.32.176.37 10627 wayne(a)criticalpath.net WebTV 198.32.176.39 6469 soc(a)corp.webtv.net XMission 198.32.176.42 6315 peering(a)xmission.com DACOM Corporation 198.32.176.43 3786 peering(a)bora.net Maxim Computer Systems 198.32.176.45 11388 peering(a)maxim.net PFM Communications 198.32.176.48 4513 help(a)pfmc.net SingTel 198.32.176.50 7473 peering(a)ix.singtel.com Zocalo 198.32.176.53 715 peering(a)zocalo.net KDDNet 198.32.176.65 2516 peering(a)kddnet.ad.jp WinterLAN 198.32.176.73 5081 noc(a)winterlink.net Hanaro Telecom 198.32.176.75 9318 peering(a)hanaro.com Hotmail 198.32.176.77 12076 dmcgilli(a)microsoft.com ViaNetWorks 198.32.176.80 7091 noc(a)via-net-works.com Open Data Network 198.32.176.86 4725 as-admin(a)gw.odn.ad.jp Digital Island 198.32.176.99 6553 mrose(a)digisle.net StarNet 198.32.176.100 6316 peering(a)starnetusa.net Electronic Arts 198.32.176.107 14891 rcortez(a)ea.com Sunrise Communications 198.32.176.110 6730 helpdesk(a)sunrise.ch Open Data Network 198.32.176.115 4725 as-admin(a)gw.odn.ad.jp Advanced Telcom Group 198.32.176.116 6971 peering(a)atgi.net DirecTV Broadband 198.32.176.119 12050 peering(a)telocity.net Nominum 198.32.176.120 17204 peering(a)nominum.com Thrunet 198.32.176.122 9277 noc(a)eng.thrunet.com Akamai 198.32.176.127 12222 peering(a)akamai.com One Call Communications 198.32.176.133 6402 rirving(a)onecall.net SITA Equant 198.32.176.140 2647 Juan.Vadillo(a)sita.int Compaq 198.32.176.241 33 noc(a)compaq.net Compaq 198.32.176.242 33 noc(a)compaq.net Internet Mainstreet 198.32.176.249 3856 woody(a)pch.net RSNG 198.32.176.251 178 rsngpeer(a)rsng.net RSNG 198.32.176.252 178 rsngpeer(a)rsng.net

1 0

Qwest fiber cut near Boulder?
by Sean Donelan 28 Jun '01

28 Jun '01

Anyone else experiencing problems with a Qwest fiber cut near Boulder Colorado?

4 3

Problems between CW and Global Crossing
by Jason Lewis 28 Jun '01

28 Jun '01

Anyone seeing any problems between CW and GC? I am seeing dropped packets and expired TTLs. jas

1 1

RE: Global BGP - 2001-06-23 - Vendor X's statement...
by Matt Levine 28 Jun '01

28 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim, Agreed, so throw the bad route to the bit bucket and leave the bgp session open, or at the very least (as others have suggested) give me an OPTION to do that. Bad enough we were only operating at 33% capacity, however, if we only had transit from the 4 that were giving us the bad route, we would have lost connectivity totally. While it would've been really cool to post an outage notification bragging about our RFC compliance, and how it's everybody elses fault, I (personally) would have preferred to stay connected to the internet and not be losing revenue. Perhaps I just have my priorities wrong. Matt - -- Matt Levine @Home: matt(a)deliver3.com @Work: matt(a)eldosales.com ICQ : 17080004 PGP : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF - -----Original Message----- From: Jim Segrave [mailto:jes@nl.demon.net] Sent: Wednesday, June 27, 2001 5:36 AM To: Matt Levine Cc: 'Chance Whaley'; nanog(a)merit.edu Subject: Re: Global BGP - 2001-06-23 - Vendor X's statement... On Tue 26 Jun 2001 (15:09 -0400), Matt Levine wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > What I would like is for my routers to not drop 4 of our 6 transit > providers, RFC, standard, not standard, whatever. We've suggested > to our vendor that there atleast be some option to control this, > we are not at the core, we are an end user. When following the > RFC dictates that our routing equipment loses connectivity to the > internet, then I say that there is a problem. It's really nice > that they can say "it's not a bug, it's a feature", but this is a > feature I'd at the very least have the ability to turn off. > > > Matt So you'd prefer to propogate the error to all of your peers, who, in the interests of interoperability, are standards compliant? A bad announcement should be stopped as soon as it's discovered, not propagated because it's inconvenient to drop the session on someone's network. - -- Jim Segrave jes(a)nl.demon.net -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOzoVx8p0j1NsDQTPEQKGLQCfd9wIWwhyDYgD/5ObtpOMl4IZWZAAn3R2 HsLf2EeNXCn0R6ZChnKdBPpk =9Sc3 -----END PGP SIGNATURE-----

5 4