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

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

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

>From owner-dnsop@cafax.se  Mon Aug 23 21:03:19 1999
>Message-Id: <199908231902.MAA15830@kiwi.equinix.com>
>Subject: Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt
>To: lindberg@cdg.chalmers.se (Gunnar Lindberg)
>Date: Mon, 23 Aug 1999 12:02:54 -0700 (PDT)
>Cc: hardie@equinix.com, dnsop@cafax.se
>In-Reply-To: <199908231340.PAA15361@wilfer1.cdg.chalmers.se> from "Gunnar Lindberg" at Aug 23, 1999 03:40:23 PM
>From: hardie@equinix.com

>Hi Gunnar,
>	I think the term "single organization" has tripped me up here;
>sorry for any lack of clarity.  I am not proposing that there be one
>single Root Server organization.  I actually believe that the
>individual roots being run by different organizations helps preserve
>the overall system, because it means that different eyes, box types,
>and architectures are being used to deliver the data.  One Root Server
>organization could mean a single point of failure; it doesn't have to,
>of course, but it might.  What I have proposed is allowing
>organizations running root servers to do so in a way that distributes
>the service to multiple places in the network topology.  A nutshell
>might be: one organization runs one root in many places.

>There are some further comments in line below.

>> 
>> Ted,
>> 
>> Let me make a half-technical/non-technical remark first and then do
>> some more comments in-line:
>> 
>> I agree that one single Root Server organization would be a good
>> thing. However, I see no reasonable way to get that in place, to get
>> funding for it (from users or from ISPs), etc, etc, and to make it
>> scale to "enough" number of Root Servers.
>> 
>> As I've written in my draft I think the need is one or more Root
>> Servers per ISP - maybe not all for pure technical reasons, but no
>> ISP in their right mind would ever admit (or allow) that their users
>> totally depend on Root Servers located at, and controlled by, their
>> main competitor. I know there are several ISP people on this list -
>> please correct me if I'm wrong...

>Given the current architecture, they won't ever totally depend on their
>competitor; at most, they lowest-latency response could be retrieved
>from a server at a competitor.  I would also like to hear how much
>that would influence ISPs choices about what to implement in this
>space.

>> 
>> Therefore, we're into several organizations operating instances of
>> Root Server(s) (instances with - hopefully - identical content).
>> 
>> >From owner-dnsop@cafax.se  Fri Aug 20 00:50:26 1999
>> >Message-Id: <199908192248.PAA01033@kiwi.equinix.com>
>> >Subject: Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt
>> >To: lindberg@cdg.chalmers.se (Gunnar Lindberg)
>> >Date: Thu, 19 Aug 1999 15:48:31 -0700 (PDT)
>> >Cc: dnsop@cafax.se
>> >From: hardie@equinix.com
>> 
>> >Hi Gunnar,
>> 
>> >> Hm. Did any of you expect Free Lunch? Of course not!
>> >> 
>> >> Increasing the number of Root Servers from "13" to "enough" will not
>> >> come free, like it or not. Complexity will increase and question is
>> >> "how much" and "where". The latter is important since it tells
>> >> whether
>> >> complexity in controlled by DNS people or it shows up elsewhere, far
>> >> from DNS control.
>> 
>> >I find your comment about controlling complexity interesting,
>> >particularly in that it indicates a split between "DNS people" and
>> >some other group (presumably "network people" or "routing people").  I
>> >think many folks have seen this problem in terms of network
>> >topology-related performance issues and so have focused the solutions
>> >in those arenas.  Latency from the current root servers to some places
>> >in the network is certainly a problem; redundant paths to some set of
>> >root servers can also also a problem.
>> 
>> If I was to provide a vital service for a large community I would be
>> careful to base it on things closely under my control and for every-
>> thing else have that be as simple as possible. That way it's less
>> likely that things fail, or change under my feet. Then, at times it
>> pays off to violate this "layered approach"; fine, but then one should
>> document what behavior is expected from other layers and not try to
>> hide that under the carpet.
>> 
>> My split between "DNS people" and "routing people" comes from this
>> observation and a concern that the <idr> WG people might not always
>> know what undocumented behavior other people expect and depend on
>> (e.g. at unintended events like "inconsistent AS path"). I put my
>> draft together in an effort to minimize that dependency and a hope
>> that existing dependencies/expectations be documented.
>> 
>> I know "anycast" has been discussed for use with Multicast RPs and
>> I am attracted by the idea, but I also think most of us agree it's
>> some difference between Multicast RPs and the DNS Root Servers...

>I absolutely agree that good documentation and careful examination of
>the dependencies is required here.  I also agree that deploying any of
>these schemes to the roots would depend on successful experiments
>being conducted and reviewed extensively prior to full deployment.


>> 
>> >> 
>> >> Saying that clearly is not good/bad, it simply means being honest.
>> >> 
>> >> If you look at most of the other proposals they say "anycast"
>> >> and hope
>> >> it's a done deal. I'm concerned:
>> >> 
>> >>     1) It expects a routing behavior that is not well documented.
>> >> 
>> >> 	What happens if someone (errounously) injects a Root Server's
>> >> 	IP prefix originating from the wrong AS ("inconsistant AS
>> >> 	path")? Today, i.e. cisco implementation, it still works,
>> >> 	although there is a warning message on the console. What will
>> >> 	happen tomorrow? Maybe that prefix gets dropped? To the best
>> >> 	of my abilities I've not found that documented.
>> >> 
>> >> 	If we're going to base the DNS, the very heart of the Internet,
>> >> 	on "anycast", that default behavior at least needs to be
>> >> 	documented in an RFC (carved in stone, rather). Btw, the BGP4
>> >> 	draft has just expired.
>> 
>> >In the draft I put forward (and will soon revise), the idea is that
>> >some organizations running root servers would make multiple boxes
>> >available in multiple locations.  One of the reasons I prefer to have
>> >a single organization responsible for the AS announcing the route to a
>> >specific root server is that one group remains on the hook for
>> >noticing/responding to/fixing problems like this.  
>> 
>> >In that context, the problem you describe is not a lot different from
>> >a bad route being injected now.  The organization serving the route
>> >has to notice it, respond, and fix the problem.  Note that the
>> >injected route being fixed affects how traffic gets to the
>> >organization, where the "shared unicast" portion of the delivery takes
>> >place internal to the organization.
>> 
>> >In a context where multiple organizations manage a special AS, fixing
>> >problems like that might have other characteristics.  Masataka may
>> >want to respond to that idea.
>