[PDB Gov] Lack of NREN support - causing problems, how to fix?

[Chris Caputo]

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 
stewards at lists.peeringdb.com.

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