Setting up a peering session is four e-mails of copying IP addresses between two people who both already have the data in PeeringDB. So I put a self-service portal on the peering page: log in with PeeringDB, pick an exchange where we already meet, and the session is configured and waiting for a quick manual check.
Who are you, and is that really your ASN?
Login goes through PeeringDB’s own OAuth. The profile it hands back lists the networks your account is attached to, each with a permission bitmask — I authorise an ASN only when your account actually holds update rights on it. The remote AS on the session is then forced to that ASN server-side; it is never something the browser gets to choose.
What actually gets built
The portal compares your PeeringDB record against mine and offers only the exchanges where we are both present. Where AS215248 has several PoPs on one exchange you pick a location rather than a router name, and one action requests IPv4 and IPv6 together.
The session itself is cloned from an existing neighbour on the same IXP LAN, so it inherits
the filter chains and policy I already trust: prefixes filtered from your AS-SET, RPKI origin
validation, and a max-prefix taken from your PeeringDB info_prefixes plus some headroom.
It is created disabled, tagged as a portal request, and shows up in my dashboard for
approval. You get mail when the request lands and again when it goes live. Asking for a
session to be removed works the same way — it queues for approval rather than tearing
anything down on the spot.
The site is still a static site
The public site remains plain HTML with no backend. Only /peering/api/* is proxied to the
portal, which runs next to the router automation on an internal box, so router credentials
never go near the web server.
If we meet at an exchange and you’d rather not write the e-mail: go ahead.