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

Fri Feb 2 03:24:23 PST 2024

Adam,

makes all sense to me. Would you mind creating an issue on Github [0]? 
IMO, it's best discussed there.

Greetings
Arnold
[0] 
https://github.com/peeringdb/peeringdb/issues/new?assignees=&labels=&projects=&template=feature_request.md&title=

On 01.02.2024 18:46, 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 <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/ 
> <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 <https://www.merlin.mb.ca/>
> 
> Chat with me on Teams 
> <https://teams.microsoft.com/l/chat/0/0?users=athompson@merlin.mb.ca>
> 
> <https://outlook.office.com/bookwithme/user/a3e87142ccc14503bf5ec7ea59afd6e3@merlin.mb.ca?anonymous&ep=bwmEmailSignature>
> 
> 		
> 
> Book time to meet with me 
> <https://outlook.office.com/bookwithme/user/a3e87142ccc14503bf5ec7ea59afd6e3@merlin.mb.ca?anonymous&ep=bwmEmailSignature>
> 
> 	
> 

-- 
Keep calm, keep distance, keep connected!

Arnold Nipper
email: arnold at nipper.de
mobile: +49 172 2650958

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.peeringdb.com/pipermail/pdb-gov/attachments/20240202/66bbdbcf/attachment.sig>