LOAs for Cross Connects - Something like PeeringDB for XC

Christopher Morrow morrowc.lists at gmail.com
Mon Feb 22 15:26:31 UTC 2021


On Mon, Feb 22, 2021 at 9:19 AM Douglas Fischer
<fischerdouglas at gmail.com> wrote:
>
> I believe that almost everyone in here knows that LOAs for Cross Connects in Datacenters and Telecom Rooms can be a pain...
>
> I don't know if I'm suggesting something that already exists.
> Or even if I'm suggesting something that could be unpopular for some reason.
>
> But every time I need to deal with some Cross-Connect LOA, and mostly when we face some rework on data mistakes, I dream with a "PeeringDB for Cross Connects".
>

are you asking about something like this:
  https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/

Which COULD be used to, as an AS holder:
  "sign something to be sent between you and the colo and your intended peer"

that you could sign (with your rpki stuffs) and your peer could also
sign with their 'rpki stuffs', and which the colo provider could
automatically validate and action upon final signature(s) received.

> So, this mail is a question and also a suggestion.
>
>
> There is something like an "online notary's office" exclusive for Cross-Connect LOAs?
>  - Somewhere Organizations can register information authorizing connections of Port on their Places (Cages, Racks, etc)...
>

The RPKI data today doesn't contain information about
cages/ports/patch-panels, so possibly the spaghetti draft isn't a
terrific fit?

> If it doesn't exist. What would be necessary for that?
> Mostly considering the PeeringDB work model.
>  - OpenSource.
>  - Free access to the tool, and sponsors to keep the project alive.
>  - API driven, with some Web-gui.
> And considering some data-modeling.
>  - Most of the data being Open/Public (Organizations, Facilities(Datacenters and/or Telecom-Rooms), Presence on Facilities, etc).
>  - Access control to Information that can not be public (A-side organization, Z-Side Organization, PathPanel/Port).
> And some workflow
>  - Cross Connect Requiremento/Authorization from A-Side
>  - Acceptance/Authorization from Z-side.
>  - Acceptance/Authorization from Facilities involved (could be more than one)
>  - Execution/Activation notice from Facilities.
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação


More information about the NANOG mailing list