DNS pulling BGP routes?

Tom Beecher beecher at beecher.cc
Wed Oct 13 14:56:05 UTC 2021


>
> But, I certainly mean that CDN operators should not request
> peering directly to access/retail ISPs merely because they have
> their own transit, because the transit is not at all neutral.
>

I'm still confused.

Let's say I have a CDN network, with a datacenter somewhere, an edge site
somewhere else. I carry my bits from my datacenter, across my internal
network, to my edge site. This is where I intend to hand the bits over to
someone else to carry them to the end user.

Let's say in this site, I have a paid transit connection , and a peering
session directly with the end user's ISP. Where is anything related to
neutrality being 'violated', regardless of which path I choose to send the
bits out?

On Wed, Oct 13, 2021 at 10:36 AM Masataka Ohta <
mohta at necom830.hpcl.titech.ac.jp> wrote:

> Tom Beecher wrote:
>
> >> For network neutrality, backbone providers *MUST* be neutral
> >> for contents they carry.
> >>
> >> However, CDN providers having their own backbone are using
> >> their backbone for contents they prefer, which is *NOT*
> >> neutral at all.
> >>
> >> As such, access/retail providers may pay for peering with
> >> neutral backbone providers for their customers but should
> >> reject direct peering request from, actively behaving against
> >> neutrality, CDN providers.
>
> > If I am understanding you correctly, are you arguing that anyone with a
> > network MUST be forced to become a transit provider for anyone else, in
> the
> > name of "neutrality"?
>
> No, not at all.
>
> For example, CDN (N stands for a network) operators may rely on
> neutral transit providers to connect their CDN to access/retail
> providers.
>
> But, I certainly mean that CDN operators should not request
> peering directly to access/retail ISPs merely because they have
> their own transit, because the transit is not at all neutral.
>
>                                         Masataka Ohta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211013/47e2086f/attachment.html>


More information about the NANOG mailing list