LOAs for Cross Connects - Something like PeeringDB for XC
fischerdouglas at gmail.com
Mon Feb 22 17:03:11 UTC 2021
Well... I must confess that I had some difficulty on the first
understanding of what is proposed.
But after the 4 reads, I saw that this "spaghetti" thing is more
powerful than I could imagine!
Please correct me if I'm no right:
But it looks like a "crypto sign and publishes" anything related to an
Yes, I think that with some effort CrossConnect LOAs can be fitted inside
I'm not sure if it is the better solution for the scope of LOAs, but
certainly is a valid discussion.
What is bubbling in my mind is the standard data model for each type of
different attribute that can exist...
Who will define that?
Em seg., 22 de fev. de 2021 às 12:26, Christopher Morrow <
morrowc.lists at gmail.com> escreveu:
> 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
> > 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:
> Which COULD be used to, as an AS holder:
> "sign something to be sent between you and the colo and your intended
> 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
> > - Execution/Activation notice from Facilities.
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NANOG