November 2016 - Pdb-tech

Help with peeringdb app
by Regivaldo Gomes Costa 27 Dec '16

27 Dec '16

Hello All, I need help regarding peeringdb application. I'm using Ubuntu 14.04, and after have been installed the peeringdb application using pip, I made the configuration in according my database. However, when I used the sync command, the application created the tables, but in "migration" phase, occurs an error. In the attached file is the execution trail until the error occur. In the last lines I ran some command to debug as can be seen. I'll grateful for any help. Thanks a lot. Best regards, Regivaldo Costa Doe Sangue. Doe Vida.

2 2

Accounts with a + in the email address
by Marty Strong 25 Nov '16

25 Nov '16

I created an account with a + in, registration worked fine and password reset emails are received, but upon trying to login I get "Invalid username/password.” Anybody else experienced this? Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty(a)cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335

2 5

RIPE NCC IXP Tools Hackathon: Pinder
by Matthew Walster 05 Nov '16

05 Nov '16

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

7 11

MySQL table description
by Regivaldo Gomes Costa 03 Nov '16

03 Nov '16

Hello Guys, I have a newbie doubt about table/columns in MySQL structure. Please, somebody can help me in an specific information. My doubts are: 1. In table "peerParticipantsPublics", the column "public_id" matches with column "id" in table "mgmtPublics"? Recordds in table "mgmtPublics" are IXPs? 2. Regarding table "peerParticipantsPublics" and the column "participant_id", i.e., are peers with the "public_id" objects (in this case IXPs... I think). Thanks in advance. Best regards, Regivaldo Costa Doe Sangue. Doe Vida.

2 3