[as112-ops] LOA Request for AS112 Prefixes

Boian Bonev bbonev at ipacct.com
Tue Nov 6 21:10:00 UTC 2018


Hi Aleksi,

On Tue, Nov 6, 2018 at 9:26 PM Aleksi Suhonen <as112-ops at trex.fi> wrote:

> On 03/11/2018 20:52, Joe Abley wrote:
> >> If this ISP cannot understand what AS112 is from the RFC, there's a
> >> good chance they won't handle the AS112 prefixes correctly.
> >
> > What special handling do AS112 prefixes need compared to any other
> > prefix from the perspective of a transit provider?
>
> IMO, the transit should prefer IGP metric over AS Path length and
> customer relationship. This may be impossible with current existing
> technology, but this is still what I think. /: - )
>

I believe that the transit ISP should not treat AS112 prefixes in a special
way. It should be the hosting operator responsibility to assign the
appropriate communities (as proposed below).

And in case an operator somehow attracts all AS112 traffic to his node, it
should be all up to him, because as far as I understand how stuff works,
the main goal of AS112 is to shift senseless load away from the roots...
If latency to AS112 is an issue for an ISP, then this means they have lots
of mis-configured/outdated DNS servers on their network and they can most
appropriately handle the case by deploying a local AS112 node. If they are
not big enough to be able to afford that, then it means it is much easier
to fix their DNS servers instead.

It is quite a different story for root servers, where latency is important,
requires attention and affects services...

I wonder if we should recommend that all AS112 announcements were tagged
> with "tier 1 local preference communities" for setting the local
> preference to be the same as that of peered routes. So even if they are
> accidentally leaked to transits, they would keep routing reasonable.
>
> I fished a few such communities from: https://onestep.net/communities/
>
> 1299:150 2914:470 1273:80 7018:80
>
> While I was fishing, I noticed that some of them don't seem to have a
> community for matching peers exactly. I suppose in those cases the
> community that is just below peer local preference should be picked...
>

As we happen to host a couple of anycast root DNS servers as well and got
involved into solving the before mentioned problem (traffic from another
continent hitting our node as best path), it seems to be appropriate to
create a recommendation for AS112 based on what root operators do for the
anycast nodes - decrease the local preference by tier1 specific communities
on prefixes announced. Here are couple of additions for this purpose:

3356:80 6453:70

That would not work in case their upstreams are not tier1 and do not pass
communities received.


> On 02/11/2018 19:32, Grant Taylor wrote:
>  > Would it be worth while to originate the AS112 prefixes to all peers
>  > willing to accept it with the don't (re)export attribute?  That way
>  > directly connected peers (that accept the advertisement) will benefit.
>  > But people further away won't be drawn towards your AS112 instance?
>
> I consider using no-export for AS112 harmful:
>
> When the receiving AS has transit customers, they won't receive the
> prefix. If those transit customers operate a default-free network, they
> will blackhole the traffic.
>

True. Also in the extreme case where every single AS112 node sets
no-export, it will become unreachable in some parts of the world.

With best regards,
b.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/mailman/private/as112-ops/attachments/20181107/1115ed5e/attachment.html>


More information about the as112-ops mailing list