I have an example locally: BellMTS (ASNs 684, 7122, 4398), the local ILEC. To the best of my knowledge, they only peer with downstream customers (including myself) and their sole upstream, Bell Canada (AS577). Meanwhile that's a ~700k eyeball network (with some hosting, sure), roughly ~400Gbps upstream connectivity, and no public peering whatsoever. In fact, one might describe their peering model as "feudal", where they're subjugate to their corporate overlord (Bell Canada). It's unfortunate, I know there are some smart people working there, but either they don't understand the value of sub-1ms access to root nameservers (*cough* MBIX *cough*), or they're prevented from doing anything about it.
[Disclaimer: I'm on the MBIX board. But I also used to work for MTS, and tried to setup the first peering relationship but got shot down for "marketing" reasons, something about "legitimizing the competition". Very monopolistic thinking, IMO.] Meanwhile, MTS still has a PeeringDB record, even though it documents quite nicely the fact that perhaps that record shouldn't exist, or at least doesn't need to. FWIW, their upstream, Bell Canada, is a very different story. And also mostly ~8msec away. -Adam Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb...@nanog.org> on behalf of Eric Kuhnke <eric.kuh...@gmail.com> Sent: August 19, 2021 10:32 To: Ben Maddison <benm@workonline.africa>; nanog@nanog.org list <nanog@nanog.org> Subject: Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits] I agree with you in the utility of that, but sort of as a side topic... I wonder how many ASes are out there that have any significant volume of traffic/multi-site presences, but are exclusively 100% transit customers, do not have any PNIs at major carrier hotels, and are not members of any IX. What would be a good example of such an AS and how big of a network would it be? Undoubtedly there are some enterprise end user type customers set up like that, but I can't imagine they receive a very large volume of unsolicited peering requests. On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote: Hi Patrick, On 08/18, Patrick W. Gilmore wrote: > > Of course! Including headers to show authenticity. I was very amused by the > > explanation of the "chicken and egg" problem. Who's creating that? The > > networks > > who refuse to peer with non-peeringdb registered ASNs, or peeringdb who > > won't > > recognize ASNs that are not peering with anyone because nobody wants to peer > > with them because they are not registered in peeringdb because nobody wants > > to > > peer with them? You get the idea. > > First, most networks do not require a PDB record to peer. (Silly of > them, I know, but still true.) > > Second, you do not need to have a PDB record to get a link to an IXP. > Even membership in a free IXP is sufficient for an account in PDB, as > Grizz points out below. > > Third, if you have an agreement, even just an email, saying a network > will peer with you once you have a record, that may well suffice. Have > you asked any network to peer? Private peering (because you are not on > an IXP) is usually reserved for networks with more than a modicum of > traffic. If your network is large enough to qualify for private > peering, I have trouble believing you cannot get another network to > agree to peer so you can get a record. > > I guess you are right, the _Peering_DB does not register “certain” > networks. Those networks would be ones that do not peer. Which seems > pretty obvious to me - it is literally in the name. > A PDB record for an Internet-connected ASN, listing no IXPs or facilities, but with a note saying approximately "We only use transit, and don't peer" has some utility: it saves prospective peers from finding contacts to ask and sending emails, etc. I'd argue this is in scope for PDB. But perhaps there was additional context to the original decision that I'm missing? Cheers, Ben
