I don't think that's a valid example at all since clearly the entity to peer with for access to the BellMTS ASes and their customers is AS577. Which definitely does peer and is present at IX points. I am familiar with another entity which has an entire regional ILEC's AS behind it, but where the newly created AS (part of the people who bought the big chunk of ILEC) is present at many IX points and peers quite widely. Was referring more to a theoretical example if somebody were to attempt to build a medium to large sized ISP exclusively as a transit customer of some top-50 CAIDA ASrank size transit providers, and do no peering whatsoever. On Thu, Aug 19, 2021 at 3:05 PM Adam Thompson <athompson@merlin.mb.ca> wrote:
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 [image: 1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca www.merlin.mb.ca
------------------------------ *From:* NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Eric Kuhnke <eric.kuhnke@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> 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