The attestation path detailed at: https://docs.peeringdb.com/committee/admin/approval-guidelines/#approving-facility-fac-objects
is available as an option. Adam, if that turns out to be insufficient, please advise here or to [email protected]. Thank you, Chris On Thu, 1 Feb 2024, Adam Thompson via Pdb-gov wrote: > I’m not 100% sure the -gov list is the right place for this, but we’ll see. > I’m confident at least some of this is governance-related. > > Problem Statement: PeeringDB does not adequately support GREN/NREN[1] > operations, and thereby actively causes problems for my employer and for > carriers. > Proximate Cause: PeeringDB operational policies do not match documented > policy, preventing correct data from being entered into the database. > > Problem Description: Carriers wanting to connect to large academic networks > use PeeringDB to evaluate potential peering sites; the academic-only peering > sites are not listed in PeeringDB, resulting in bad business & technical > decisions. > > Some of you may be thinking “just use a private Facility”, but that seems to > be contra-indicated by the fact that… there’s no such thing, currently! > > Many academic networks interconnect at what would normally be called > “Facilities”, but are not advertised on anyone’s website, because they’re not > quite “public”. These are typically universities cooperating with their > local RAN[2] or NREN who allow other academic operators in the region to > collocate equipment in the hosting institution’s datacenter, and permit > carriers servicing those other operators to bring service into the DC. > > As mentioned in > https://docs.peeringdb.com/gov/misc/2020-04-06_PeeringDB_Data_Ownership_Policy_Document_v1.0.pdf, > the ideal solution would seem to be a “Private Peering Facility” – but this > doesn’t seem to exist in the UI, or the documentation, or the operating > policy today. > > Per Chriztoffer Hansen, this week: > We do accept facility suggestions (top right menu). -> Beware we do a minimum > level of vetting for all Facility submissions. "Website is mandatory and > MUST list colocation as a service." > > The host universities have no appetite for listing themselves as a public > peering facility, as they are not one. They are an academic-only, > by-prior-arrangement-only facility. None of the universities I deal with > would want to list colocation as a service on their website, as it would > simultaneously detract from their communication goals and be fundamentally > misleading. There’s no mention of the website being mandatory, nor being > open to the public, in > https://docs.peeringdb.com/committee/admin/approval-guidelines/ . > > Meanwhile, PeeringDB has succeeded so wildly in its mission that multiple > carriers are relying on it to have substantively complete information about > my peering locations. > > Have I missed something obvious? Carriers rely on PeeringDB to find peering > locations -> I therefore need to have my peering locations in PeeringDB -> My > host facilities aren’t in PeeringDB, because they don’t meet PeeringDB’s > operating criteria. > > I think the addition (or re-addition? Unsure…) of Private Facilities, or at > least some form of Facility that isn’t 100% Public, would solve the problem. > If I go to add a Facility in the UI today, there’s nowhere to describe an > access-restriction policy (e.g. “NREN-only. Prior approval only.”) and the > UI itself even says “To be listed as a Facility in PeeringDB we would expect > that you offer colocation, data center and/or meet-me-room services to the > public.” > > > To recap: PeeringDB’s operational stance doesn’t match its documented > policies, and this is causing both my employer, and some of my carriers, > harm. The harm has been mostly undone now, but at least one of the carriers > I’m describing did suffer some financial harm arising out of this situation. > (I’m not going to name and shame the carrier.) > > > Possible Solution: > > * Align operational stance with documented policy, i.e. drop the “public” > requirement, and allow “private” or at least not-100%-public Facilities > * Allow a way to document the non-publicness of a Facility in the database > > It would be nice if I’m missing something, but it looks to me like PeeringDB > is just ignoring the entire non-commercial side of internet right now. > > I’ll be happy to provide examples if needed. > > > Thoughts? > -Adam Thompson, AS16796 > > > [0] GREN = Global Research and Education Network, a parallel but > interconnected Internet. > [1] NREN = National Research and Education Network, e.g. Internet2, ESnet, > CANARIE, NORDUnet, JANET, etc. > [2] RAN = Regional Access Network, an NREN partner network that aggregates > regional members into a smaller number of connections to the NREN, e.g. > MRnet, RISQ, MERIT, NYSERNet, etc. > > Adam Thompson > Consultant, Infrastructure Services > 100 - 135 Innovation Drive > Winnipeg, MB R3T 6A8 > (204) 977-6824 or 1-800-430-6404 (MB only) > https://www.merlin.mb.ca
