PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

Sun Aug 22 20:22:01 UTC 2021

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 at 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 at merlin.mb.ca
> www.merlin.mb.ca
>
> ------------------------------
> *From:* NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org> on behalf
> of Eric Kuhnke <eric.kuhnke at gmail.com>
> *Sent:* August 19, 2021 10:32
> *To:* Ben Maddison <benm at workonline.africa>; nanog at nanog.org list <
> nanog at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210822/46d36ca4/attachment.html>