Excellent, most appreciated! *Matthew Walster *| Network Engineer fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
On 3 November 2016 at 03:08, Matt Griswold <gr...@20c.com> wrote: > Top posting since I just skimmed it (but had already looked at your > slide deck from the RIPE emails) and am not addressing specific > points... yet :) > > Nice work - I think it's a good idea and would belong in PeeringDB. > I've brought it up internally for board discussion and we will update > the list after further discussion. > > * Matthew Walster <matt...@walster.org> [161101 16:39 +0000]: > > Hey all, > > > > The weekend before RIPE73, RIPE NCC held an IXP Tools Hackathon, and > > an idea we came up with was a system to facilitate peering. > > > > It's not a matchmaking service -- you don't get suggested possible > > peers, you don't submit any sensitive data -- it just facilitates > > peering. > > > > I'm sure you've all received emails from other networks... Perhaps it > > came from a @gmail.com address, perhaps it just had their IP > > address at an exchange without telling you which exchange it came > > from, perhaps this peer is only responsible for a couple of > > Megabits per second of traffic and the effort required to setup > > this peer is disproportional to the benefit your network would gain > > from it. > > > > That's why Pinder came around -- Tinder for Peering. > > > > The idea is that if there is a desired peering relationship between > > two networks, and you're happy to just configure some sessions > > rather than enter into a commercial agreement, Pinder would be the > > middle man. You would submit the request via either a basic Web UI > > or an API, the other network would either be notified or > > periodically check their outstanding requests, and if they are > > willing to peer, both sides are told to configure a session. Once > > both sides indicates sessions are configured and established, the > > request is then deleted (rather than persisting in a database) so > > as to prevent any data security issues in the future. > > > > We knocked up a brief slide deck to explain a little better: > > http://accel.waffle.sexy/pinder.pdf > > > > Our example code is at: http://github.com/dotwaffle/pinder > > > > A brief description of the project is at: http://peer.sexy > > > > I would love it if this could be integrated (probably with entirely > > new code) into PeeringDB, taking advantage of almost all networks > > having valid accounts and fairly accurate data on which exchanges > > they are at. > > > > Is this something the PeeringDB board would consider? Is this > > something networks are interested in seeing from PeeringDB? > > Certainly on the of the other Hackathon teams (the peerme team, > > partly from Facebook, who I know have just subscribed to this list > > to hear this discussion) are interested in integrating with it as > > soon as possible, rather than providing yet another one-sided crazy > > web form that prospective peers have to fill out. > > > > Here's some discussion points I thought of: > > > > 1. Does PeeringDB want to be that facilitator? Does it want to be a > > third party service? > > > > 2. If so, how is authentication/authorisation performed? > > > > 3. Also, if it isn't a function provided by PeeringDB, do we want a > > new field in the ASN record that has an endpoint for a particular > > protocol (preferably via https rather than on raw TCP) so people > > can design their own tools against it and the communication becomes > > decentralised? > > > > 4. If it is taken on by PeeringDB, how much metadata wants attaching > > to the communication? Should it just be "accepted", "rejected", > > "contact me" as we have suggested, or would a messaging field be > > appropriate? If that was the case, does that put PeeringDB in an > > awkward position? > > > > 5. If the primary consumable was an API, with a basic Web UI on top > > for those unwilling to build on top of it, how do we make sure the > > private data stays private? > > > > 6. Assuming PeeringDB was chosen as the "right place" to store this > > project, is this likely to gain any traction anytime soon? Do we need > > volunteers to help implement it? Is this even something that can be > > considered a separate module that perhaps we want to have Open Source > > from Day One? > > > > Anyway, enough waffle from me... I'd be interested in hearing people's > > thoughts. > > > > Matthew Walster > > _______________________________________________ > Pdb-tech mailing list > Pdb-tech@lists.peeringdb.com > http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech >
_______________________________________________ Pdb-tech mailing list Pdb-tech@lists.peeringdb.com http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech