[as112-ops] LOA Request for AS112 Prefixes

[Frank Habicht]

Hi,

I practically agree with all Todd has said here.
Yes, we should *not* stand in their way.
And the traffic to AS112 is really not that urgent. true.
I was thinking a bit about the state that the resolvers have to keep 
open... (over unnecessarily long time)
But then it's a case where the pain of bad configuration hurts exactly 
at the place of root cause - so i like it ;-)

just the "10-20ms" i feel is on the low side.
In the previous example to a root, it was over 400ms for the scenic route.
 From a looking glass about 1-2ms away from me now, I can see a 
traceroute to 192.175.48.1 with 130ms (to a peering).
[While AS112 could also be 1 ms away from the LG over another potential 
peering, but that's absolutely a different issue.]

Or let's take the 330ms in https://pastebin.com/SXA69EhJ

So I'm in favour of letting them do it.
I just want providers to see that an AS112 instance is not completely 
the same as any other (unicast) client.
[which i'm afraid might drive some to advertise to upstream]

Frank


On 04/11/2018 06:43, Todd Crane wrote:
> When did latency become a priority for AS112? My understanding is
> that AS112 was designed to help lift the burden of improperly
> ran/configured dns resolvers by answering certain queries it
> shouldn’t be asking. Furthermore, by implementing anycast, that
> burden is spread across a bunch of volunteers instead of overloading
> a single one. If that is in fact the problem we’re trying to solve,
> how does potentially adding 10-20ms to travel across the country or
> even continent, become “not good enough” to solve the problem?
> 
> I understand that speed/latency is a key metric in many instances,
> but if that is the case here, we need to be more intentional about
> the types of servers, the load on those servers, the network
> topography of the nodes, etc. Each one of those factors introduces
> significantly more latency than transporting bits an extra 1000 miles
> over a fiber network.
> 
> I feel like we shouldn’t stand in the way if someone wants to take on
> a bigger portion of the load, provided they can handle it. In fact,
> we should thank them.
> 
> </2¢>
> 
> —Todd
> 
> 
> 
>> On Nov 3, 2018, at 5:43 PM, Frank Habicht <geier at geier.ne.tz 
>> <mailto:geier at geier.ne.tz>> wrote:
>> 
>> Hi Joe,
>> 
>> On 03/11/2018 21:52, Joe Abley wrote:
>>> Hi Jonathan, On Nov 3, 2018, at 04:09, Jonathan Stewart 
>>> <jonathan.stewart at gmail.com <mailto:jonathan.stewart at gmail.com>>
>>> 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?
>> 
>> My thinking is that a transit provider covering large geographies 
>> learning AS112 these prefixes from customers SHOULD (not MUST) give
>>  them same local-pref as from peerings, so that traffic doesn't
>> travel around the globe. (better would be their own instances,
>> ideally sprinkled $everywhere)
>> 
>> Thinking the other way, every provider could have them as their 
>> self-operated "customers" in many POPs.
>> 
>> The questions really is about what's more important: do we want to
>>  give fast answers to a customer resolver [by running our own AS112
>> or peering it off everywhere, by preferring peerings as much as 
>> customers], or do we want to transport bits over distances[from the
>>  resolver to a paying customer's AS112] and charge for it [by 
>> preferring a customer more].
>> 
>> And the answer to this question might be different for different 
>> network operators.
>> 
>> So I think of the LOA as a weapon, which the provider can use to
>> shoot themselves into the foot. If they don't think twice.
>> 
>> 
>> Frank _______________________________________________ as112-ops
>> mailing list as112-ops at lists.dns-oarc.net
>> <mailto:as112-ops at lists.dns-oarc.net> 
>> https://lists.dns-oarc.net/mailman/listinfo/as112-ops
>