Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt

[Gunnar Lindberg <lindberg@cdg.chalmers.se>]

>From owner-dnsop@cafax.se  Wed Sep  8 19:16:16 1999
>Date: Wed, 8 Sep 1999 10:15:31 -0700 (PDT)
>From: Jerry Scharf <scharf@vix.com>
>To: Gunnar Lindberg <lindberg@cdg.chalmers.se>
>cc: dnsop@cafax.se
>Subject: Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt
>Message-ID: <Pine.BSI.4.05L.9909081008210.1551-100000@sh.lh.vix.com>

>On Wed, 8 Sep 1999, Gunnar Lindberg wrote:

>> Ted,
>> 
>> Sorry for the long delay, but I had hoped someone else would step in.
>> 
>> Anyway, it seems to me we agree on what can be agreed on, given rather
>> different proposals. Sometime in the future the WG will make some
>> decision, I guess.
>> 
>> Finally, a comment on "anycast" that I haven't seen yet (but which
>> may have been beaten to death before I joined the list). What about:
>> 
>>     "anycast"
>>     "TCP lookup" (lookup - not AXFR)
>>     "equal-cost multi-path, per-packet, load sharing"
>> 
>> E.g: at some site they have two equal-cost routes to [198.41.0.4]. We
>> know it's anycast - routes to *different instances* of [198.41.0.4]
>> and not two routes to the same host - but the routers don't. Instead
>> the routers send 50% of the packets one direction and 50% the other.
>> 
>> No big deal for UDP queries that are self contained, but TCP has a
>> connection and keeps state and 50% TCP packets to each [198.41.0.4]
>> instance is not likely to work. And, at least for UNIX the choice of
>> UDP or TCP is set per application, "_res.options |= RES_USEVC", which
>> is hard enough to handle - what BillGatesWare does is unknown to me.
>> 
>> Am I the only person worried?
>> 
>> 	Gunnar

>There are ways of doing load sharing that do not screw up TCP
>(Cisco CEF
>being one example.) If someone is using routing tricks, we have
>to require
>them to not be stupid about how to do that. I think you could add
>language
>that points out to the person implementing anycast routing that
>this kind
>of situation must be avoided.

The sad news is that it's not the person implementing anycast routing
who gets hit, but the persons that already have unicast routing up
running (most of us :-), and happened to end up with multiple paths.
I'm not sure it's convinient that the IETF comes up with a "use Cisco
CEF" recommendation to them.

>I don't see it as a specific reason to toss the concept out of hand.
>It is
>a risk and needs to be evaluated against benefits.

Agree 100% on the latter.

	Gunnar