<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Chiming in, top-posting because work MUA and to keep the trend going<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">This year we automated a good amount of our peering maintenance: checking for missing sessions with existing peers in IXPs we have in common, checking session
status across all peers, configuring new peers across any/all locations in common (or adding the missing sessions) (with a bit of human review), and digging through netflow top talkers on transit to look for peering opportunities…
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">However, the piece that is more difficult to find a good approach to is also the most time-consuming remaining piece: contacting prospective peers, figuring out
whether they’re interested, whether we have contacted them before, and also removing the human bit from the incoming requests/communication. “Pinder” helps not only the matchmaking aspect, but if run by a well-known central database of peering information
whose API we already use… it is inherently a deterministic mechanism to help solve this programmatic challenge.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If this state was centralized by PeeringDB, with an API and Python module – that would provide a robust enough solution to these gooey meatspace problems described
in the above paragraph. For smaller networks, they would likely just want to interact with it through the PeeringDB web UI … and yeah, I suspect there are some out there that would like to use a Pinder app (but hey, that’s just another consumer/client of
the API so who cares at that point).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">+1 for turning this into something running on/inside of PDB, since it is already the hub of peering matchmaking today… just without the actual matchmaking (well,
Peering Coordinator Communication State Machine).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The only downside is if those networks don’t want to trust PeeringDB (or any 3<sup>rd</sup> party) with a potential list of all of their peers, since this Pinder-esque
mechanism would benefit from maintaining state on who a given network already peers with. There are options that can probably help solve this, if it is a real concern – but could diminish the value for others. So this may not be an issue worth solving until
it is an actual problem/blocker for participants<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Ryan
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">--<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Ryan Rawdon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Network Engineer , Principal<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">+1-312-477-5410<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">101 N Wacker Dr Fl 23, Chicago, IL 60606 conversantmedia.com<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Pdb-tech [mailto:pdb-tech-bounces@lists.peeringdb.com]
<b>On Behalf Of </b>Matthew Walster<br>
<b>Sent:</b> Wednesday, November 02, 2016 22:13<br>
<b>To:</b> Matt Griswold <grizz@20c.com><br>
<b>Cc:</b> pdb-tech@lists.peeringdb.com<br>
<b>Subject:</b> Re: [PDB Tech] RIPE NCC IXP Tools Hackathon: Pinder<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Excellent, most appreciated!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<p style="mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:0in;margin-left:0in;margin-bottom:.0001pt;line-height:15.0pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333;border:solid windowtext 1.0pt;padding:0in"><img width="100" height="100" id="_x0000_i1025" src="cid:~WRD259.jpg" alt="Image removed by sender."></span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333"><o:p></o:p></span></p>
<div>
<div>
<div>
<p class="MsoNormal" style="line-height:15.0pt"><b><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333">Matthew Walster </span></b><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333">| Network Engineer<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="line-height:15.0pt"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333"><a href="http://fastly.com/" target="_blank"><span style="color:#3B73AF;text-decoration:none">fastly.com</span></a> | <a href="https://twitter.com/fastly" target="_blank"><span style="color:#3B73AF;text-decoration:none">@fastly</span></a> | <a href="http://www.linkedin.com/company/fastly" target="_blank"><span style="color:#3B73AF;text-decoration:none">LinkedIn</span></a><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 3 November 2016 at 03:08, Matt Griswold <<a href="mailto:grizz@20c.com" target="_blank">grizz@20c.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Top posting since I just skimmed it (but had already looked at your<br>
slide deck from the RIPE emails) and am not addressing specific<br>
points... yet :)<br>
<br>
Nice work - I think it's a good idea and would belong in PeeringDB.<br>
I've brought it up internally for board discussion and we will update<br>
the list after further discussion.<br>
<br>
* Matthew Walster <<a href="mailto:matthew@walster.org">matthew@walster.org</a>> [161101 16:39 +0000]:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">> Hey all,<br>
><br>
> The weekend before RIPE73, RIPE NCC held an IXP Tools Hackathon, and<br>
> an idea we came up with was a system to facilitate peering.<br>
><br>
> It's not a matchmaking service -- you don't get suggested possible<br>
> peers, you don't submit any sensitive data -- it just facilitates<br>
> peering.<br>
><br>
> I'm sure you've all received emails from other networks... Perhaps it<br>
> came from a @<a href="http://gmail.com" target="_blank">gmail.com</a> address, perhaps it just had their IP<br>
> address at an exchange without telling you which exchange it came<br>
> from, perhaps this peer is only responsible for a couple of<br>
> Megabits per second of traffic and the effort required to setup<br>
> this peer is disproportional to the benefit your network would gain<br>
> from it.<br>
><br>
> That's why Pinder came around -- Tinder for Peering.<br>
><br>
> The idea is that if there is a desired peering relationship between<br>
> two networks, and you're happy to just configure some sessions<br>
> rather than enter into a commercial agreement, Pinder would be the<br>
> middle man. You would submit the request via either a basic Web UI<br>
> or an API, the other network would either be notified or<br>
> periodically check their outstanding requests, and if they are<br>
> willing to peer, both sides are told to configure a session. Once<br>
> both sides indicates sessions are configured and established, the<br>
> request is then deleted (rather than persisting in a database) so<br>
> as to prevent any data security issues in the future.<br>
><br>
> We knocked up a brief slide deck to explain a little better:<br>
> <a href="http://accel.waffle.sexy/pinder.pdf" target="_blank">http://accel.waffle.sexy/pinder.pdf</a><br>
><br>
> Our example code is at: <a href="http://github.com/dotwaffle/pinder" target="_blank">
http://github.com/dotwaffle/pinder</a><br>
><br>
> A brief description of the project is at: <a href="http://peer.sexy" target="_blank">
http://peer.sexy</a><br>
><br>
> I would love it if this could be integrated (probably with entirely<br>
> new code) into PeeringDB, taking advantage of almost all networks<br>
> having valid accounts and fairly accurate data on which exchanges<br>
> they are at.<br>
><br>
> Is this something the PeeringDB board would consider? Is this<br>
> something networks are interested in seeing from PeeringDB?<br>
> Certainly on the of the other Hackathon teams (the peerme team,<br>
> partly from Facebook, who I know have just subscribed to this list<br>
> to hear this discussion) are interested in integrating with it as<br>
> soon as possible, rather than providing yet another one-sided crazy<br>
> web form that prospective peers have to fill out.<br>
><br>
> Here's some discussion points I thought of:<br>
><br>
> 1. Does PeeringDB want to be that facilitator? Does it want to be a<br>
> third party service?<br>
><br>
> 2. If so, how is authentication/authorisation performed?<br>
><br>
> 3. Also, if it isn't a function provided by PeeringDB, do we want a<br>
> new field in the ASN record that has an endpoint for a particular<br>
> protocol (preferably via https rather than on raw TCP) so people<br>
> can design their own tools against it and the communication becomes<br>
> decentralised?<br>
><br>
> 4. If it is taken on by PeeringDB, how much metadata wants attaching<br>
> to the communication? Should it just be "accepted", "rejected",<br>
> "contact me" as we have suggested, or would a messaging field be<br>
> appropriate? If that was the case, does that put PeeringDB in an<br>
> awkward position?<br>
><br>
> 5. If the primary consumable was an API, with a basic Web UI on top<br>
> for those unwilling to build on top of it, how do we make sure the<br>
> private data stays private?<br>
><br>
> 6. Assuming PeeringDB was chosen as the "right place" to store this<br>
> project, is this likely to gain any traction anytime soon? Do we need<br>
> volunteers to help implement it? Is this even something that can be<br>
> considered a separate module that perhaps we want to have Open Source<br>
> from Day One?<br>
><br>
> Anyway, enough waffle from me... I'd be interested in hearing people's<br>
> thoughts.<br>
><br>
> Matthew Walster<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">_______________________________________________<br>
Pdb-tech mailing list<br>
<a href="mailto:Pdb-tech@lists.peeringdb.com">Pdb-tech@lists.peeringdb.com</a><br>
<a href="http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech" target="_blank">http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>