For those of you who could not attend or listen in to the Peering BOF VIII Monday evening: Here are my notes from the NANOG 33 Peering BOF VIII held late Monday Night...(comments welcome.) We started the Peering BOF VIII at 9:00 PM Monday Night, and we voted on the ranking of the nine issues that peering folks shared with Bill as "Things on the mind of Peering Coordinators in 2005": 1. Peering vs. Transit tradeoff 33 2. Capacity Planning for Peering 10 3. Traffic Analysis Tools Needed 15 4. Comcast still doesn't peer 14 5. De-peering 1 6. Remote Peering 3 7. VOIP Peering 15 8. Peer2Peer Traffic (40%-70%) 6 It was interesting that so many people said that "Peering vs. Transit tradeoff" was highest on the list, and that this was by a factor of 2:1 over the next largest issues. The next three items of interest to the Peering Community were Traffic Analysis Tools (15), VOIP Peering (15) and "Comcast still not Peering" (14). ------------------------------------------------------------- The Great Debate The Great Debate was on the topic of "Remote Peering" – the practice of peering without a collocated router at an IX. This has emerged as a *contentious* issue primarily across the Wide Area – peering from Europe by connecting to a US IX via MPLS-encapsulated Ethernet frames for example. The Pro side (Remote Peering is a good thing) was presented by Patrick Gilmore and the Con side (Remote Peering is a bad thing) was presented by Stephen Wilcox. Key Points from Patrick (why remote peering is a good thing): 1) Peering Costs of router, colo, local loop, etc. can be removed from the cost equation enabling companies to peer 2) The underlying method of getting to the IX should be irrelevant to the peer 3) Many MPLS providers deliver highly robust and stable services, at least as reliable as SONET alternatives. 4)Allows company to meet geographic diversity requirements for peering 5)Remote Peering transport is metered so allows companies to pay for only what they use Key Points from Stephen (why remote peering is a bad thing) 1)Remote Peering is more complex, more network elements to break, leads to BGP instability which hurts everyone 2)Debugging underlying infrastructure is more difficult if not impossible 3)Remote Peering allows peers to circumvent the intent of the geometric distribution requirements in peering policies. For example, one can meet a peer on the East Coast, West Coast and in the middle to meet the three time zones requirement without having the expected underlying infrastructure (multiple routers connected by circuits). A single router failure could bring down all peering sessions with the Remote Peer. 4) Remote Peering instability potential – it implies multiple l2 interconnected nets which may introduce probs ie loops may also allow problems to spill between l2 systems such as IXes 5) Greater Variability in Peering Performance - reroutes may cause ccts to do strange things such as switching to a much longer path. You don't see this with SONET. 6) Detrimental to the Community - the other isp may want equal peers not a network over extending themselves just to save a few $$s and this may lead to peers increasing their peering requirements ie volume/locations which will be detrimental to the genuine networks Both debaters sparred on these points a second round, with a reinforced point from Patrick that a peer should *not* need to care about the others peer's implementation of infrastructure, only that the peering sessions are stable or not. The debaters summed their arguments, and we took a vote: THE VOTE: "Which debater presented the more compelling case." Stephen Wilcox (Con: Remote Peering is a bad idea) 11 Patrick Gilmore (Pro: Remote Peering is a good idea) 50 --------- We invited the audience to chime in and present points that did not come up in the debate. There were many additional good points raised, and the discussion in the community was very lively. Notable among these points: - "Peers" implies similar investment in infrastructure and similar benefits from peering – a similar distribution of customers and content. Remote peering circumvents this perceived notion of fairness." Peering increasingly involves signing NDAs and exchanging network maps and the fake peering would be found out here or during an outage in either case, peering policies would not change and appropriate depeering would result. -Lack of visibility is critical in operations- when things break, a simple infrastructure (layer3 routers, layer 1 circuits with framing) provides visibility essential for debugging. - Route Convergence becomes an issue if a single router is used with tentacles all over the world remotely peering. Price seems to be the main driver – you only do remote peering if you are poor and trying to save capex and colo/IX fees. Maybe you shouldn't be peering then. +The ability to try an IX before you buy without going through a difficult install is a strong benefit of remote peering. +Lack of visbility is lessened when Remote Peering is used for Private Peering +It is a fallacy that "It just feels wrong" - The world is complex – deal with it! +The guys running these MPLS cloud are doing a great job; you may seen some latency/jitter during regrooming but that is about it. Not that instable. +Saves money, both capex and opex - Creating a "Fake" network to meet peering prereqs is not generating an ideal Internet topology. - May save $ but Peering Policies will soon adjust to deal with this, making it difficult for "real" networks to get peering. - General – More Complexity->More Problems->BGP instability for all of us Community VOTE: We took a different vote, given the points raised by the broader audience along with the debater points, asking the question: Is remote peering a good thing? 33 Is remote peering a bad thing? 24 Interesting – I would have thought the peering coordinators would have said uniformly that remote peering was a bad thing, but given all the points shared and discussed, the Peering Community in the room were clearly more accepting of remote peering. Peeringdb.com – Richard Steenbergen Richard shared his community service project to collect and disseminate Peering Contacts in the Peering Coordinator Community. The group felt this was a valuable and noble endeavor and thanks Richard for taking this on. ------------------------------------------ Peering Personals Yahoo! AS#: 10310 US, 15635 in the UK Brokaw Price bprice@yahoo-inc.com Samsung Networks AS#: 6619 Woohyong Choi <woohyong.choi@samsung.com> McLeodUSA Telecommunications AS#: 7228 Thomas Barrera tbarrera@mcleodusa.com VitalStream, Inc. AS#:13980, 30282, 30636, 30637 Kim W. Summers ksummers@vitalstream.com NASA UNITeS / SAIC AS#: 297 Michael Turner Michael.S.Turner@msfc.nasa.gov USC AS#: 226 Walt Prue prue@usc.edu CENIC AS#: 2152 Darrell Newcomb darrell@cenic.org Company: Akamai Technologies AS#: 12222, 20940 • Patrick W. Gilmore patrick@akamai.com Title: Director, Network Strategy & Support Webair Internet Development Inc AS#: 27257 Sagi Brody sagi@webair.com TELUS AS#: 852 Domenica Roda / Geoffrey Holan <Domenica.Roda@telus.com> <Geoffrey.Holan@telus.com> Net Access Corp. AS#: 8001 Steven J. Schecter <sjs@nac.net> Giganews AS#: 30094 Edward Henigin ed@giganews.com University of Washington / Pacific Northwest Gigapop AS#: 73 / 101 Dave McGaugh dmcgaugh@cac.washington.edu Electric Lightwave, LLC AS#: 5650 Steven Raymond <sraymond@eli.net> China Telecom (USA) AS#: 4134 Joe Zhu <ctusa_joe@yahoo.com> ESnet AS#293 Name:Yvonne Hines peering@es.net -------------------------------------- Closing – The Peering BOF closed around 11:00 but people hung around and talked toward midnight. This time slot might be a bit tough for those on Eastern Time who were effectively up until 3AM discussing peering, and rehashing the great debate. -- //------------------------------------------------ // William B. Norton <wbn@equinix.com> // GSM Mobile: 650-315-8635