NANOG 33 Peering BOF VIII Notes

Wed Feb 2 23:01:25 UTC 2005

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 at yahoo-inc.com

Samsung Networks
AS#: 6619
Woohyong Choi
<woohyong.choi at samsung.com> 

McLeodUSA Telecommunications 
AS#: 7228 
Thomas Barrera
tbarrera at mcleodusa.com

VitalStream, Inc.
AS#:13980, 30282, 30636, 30637
      Kim W. Summers    
     ksummers at vitalstream.com

NASA UNITeS / SAIC
AS#: 297
 Michael Turner
Michael.S.Turner at msfc.nasa.gov 

USC
AS#: 226
 Walt Prue
prue at usc.edu

CENIC
AS#: 2152
Darrell Newcomb
darrell at cenic.org

Company: Akamai Technologies
AS#:     12222, 20940
•	   Patrick W. Gilmore
  patrick at akamai.com
Title:   Director, Network Strategy & Support

Webair Internet Development Inc
AS#:    27257
  Sagi Brody
 sagi at webair.com

TELUS 
AS#: 852 
Domenica Roda / Geoffrey Holan
<Domenica.Roda at telus.com> 
<Geoffrey.Holan at telus.com> 

Net Access Corp.
AS#: 8001
Steven J. Schecter
 <sjs at nac.net> 

Giganews
AS#: 30094
Edward Henigin
ed at giganews.com 

University of Washington / Pacific Northwest Gigapop
AS#: 73 / 101
Dave McGaugh
dmcgaugh at cac.washington.edu 

Electric Lightwave, LLC
AS#: 5650
Steven Raymond
<sraymond at eli.net> 

China Telecom (USA) AS#: 4134
Joe Zhu <ctusa_joe at yahoo.com> 

ESnet AS#293
Name:Yvonne Hines
peering at 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 at equinix.com> 
// GSM Mobile: 650-315-8635