Peering BOF XI Meeting Minutes ----- D R A F T

Fri Feb 17 18:50:46 UTC 2006

Peering BOF XI Meeting Minutes
Facilitator: William B. Norton <wbn at equinix.com>

Agenda
1. Notes from the Field - wbn
2. ad Hoc Transit Survey – Dave Wodelet
3. Paid Peering as an Adjunct to Settlement Free Interconnect (15 min). -wbn
4. The Great Peering Debate (30 min) ras, ianai
5. Peering Contact Database (peeringdb.com) Update (10 min). - ras
6. AS7018 & AS7132 Discussion (15 min)
7. Peering Personals – all (remainder)

1) Notes from the Field

Trying something new this NANOG Peering BOF: Community Seating

This was a hit!  We had 200 chairs arranged in three concentric ovals
so everyone could see everyone else. The protocol for speaking did not
involve queueing up at a microphone but rather standing up and
speaking your peace. It took a little while to get used to it but it
certainly facilitated very interactive and lively community
discussions.

Peering Ecosystems Update
– Italy Peering Ecosystem Exception
Telecom Italia peers its domestic routes openly in a single (or if
needed two) location in Italy. This is counter to every peering
ecosystem I have studied; Tier 1 ISPs (those with access to the entire
routing table for the country solely via peering relationships)
typically will not peer with anyone else, making Telecom Italia and
Italy an interesting exception. Daniele (from NaMex) pointed out the
recently privatized Telecom Italia peered openly to avoid government
regulation, and I mentioned that they also pointed to increased
revenue from fiber and copper sales to successful competitive ISPs.
Note that this is a different entity from Telecom Italia Sparkle,
which is the sole international transit provider for TI and does not
peer openly.  Job (from AMS-IX) mentioned that KPN is similarly openly
peering.

- Past Peering Debate documented
The last NANOG Peering Ratios debate spilled over into heated
discussions in the hallways and I went ahead and documented the
strongest arguments overheard on both sides of the issue. I have this
white paper available to anyone who wishes to better understand the
Peering Ratios issue. This white paper is now freely available. Send
email to bill.norton at gmail.com with "The Folly of Peering Ratios?" in
the subject line and I'll be glad to send a copy of the "The Folly of
Peering Ratios?" white paper.

2) Ad Hoc Transit Survey – Dave Wodelet (dave.wodelet at sjrb.ca)
Dave was interested in continuing the transit survey we have done in
the past peering bofs with a little more specificity, so he asked
several questions:
a) who are your upstream transit providers?
b) what are the prices per mbps and commits?
c) how old is the contract?
d) are there any special aspects of the deal?

Dave agreed to report back on the results at the next NANOG Peering BOF.

3) Top 8 reasons Paid Peering Has Not Taken Off
The Peering community has discussed paid peering for over a decade.
The question was floated around "Why hasn't paid peering taken off?"
resulting in the following answers:
1. Unpredictability & Budgeting & Gaming the system
2. We are "peers" & we shouldn't pay.
3. If we pay now it will be harder to migrate to settlement free later
4. No Signatory Authority for $$$ - another group handles vendors/paying
5. Transit Price < Paid Peering Price – why bother, use communities to
limit transit, have a backup just in case
6. We don't have that product to offer
7. Low margin product – the margins are already thin on transit, too much effort
8. I don't want to screw up my existing peering relationships. Even if
I get some $$, I piss off a peer I care about.

This was also a lively discussion resulting in a total of eight
reasons when my hallway conversations initially resulted in five
reasons why paid peering hasn't taken off.

4) "The Utility of MEDs" Peering Debate

• Peering Question:
"From a Practical Perspective, are MEDs useful for distributing the
peering traffic load?"
2 minutes each:
1. "MEDs are not a useful tool for Peering" - ras
2. "MEDs are a useful tool for Peering" - patrick
3. Ras attacks "MEDs are a useful tool for Peering" position
4. Patrick attacks "MEDs are not a useful tool for Peering" position
5. Closing Arguments

• Initial vote: How many people believe MEDs are a useful tool for
distributing peering traffic?  Group Answer by Vote: MEDs ARE useful.

Debate begins...
"MEDs are not a useful tool for Peering" - ras
1. MEDs worsen route quality and increase latency
2. Costs go up overall – just shifting costs around
3. Foolhardy to assume you can route to someone else's network better
than they can

"MEDs are a useful tool for Peering" - patrick
1. Judicious use of MEDs can improve performance
2. MEDs can remove the technical objections to peering
3. It's foolhardy to assume other people can route properly inside
their own network.

• Audience votes "Which side made the more compelling case" Group
Answer: Patrick did - "MEDs are useful for Distributing Peering Load"

• Audience added in points that were not made during the debate, or
reinforce positions that you believe needed reinforcement.

• Audience voted "Are MEDs a useful tool for Peering?" Group Answer:
"MEDs are useful for Distributing Peering Load"

5) Peeringdb.com
• Peering Contact Information goes out of date very quickly

7) Peering Personals
• If you are a peering coordinator, stand up
• If you are an IX, sit down
• Look around the room
• Point with two hands the people that you know the least
We had a few folks stand up and introduce themselves, their ASN, their
network, what they are looking for in a peer, and why the group should
want to peer with them.

6) AS7018 & AS7132 Discussion  With the merger of two of the largest
peering companies in the U.S. Peering Ecosystem there are questions in
the Peering Community about the near and medium term impacts. Ren
Provo (AS7132) and Susan Martens (AS7018) stood up and announced the
website for peering: http://www.att.com/peering/ and that things were
pretty much business as usual now.

--
//------------------------------------------------
// William B. Norton <wbn at equinix.com>
// Co-Founder and Chief Technical Liaison, Equinix
// GSM Mobile: 650-315-8635
// Skype, Y!IM: williambnorton