[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dns op wg <dnsop@cafax.se>
From: Randy Bush <randy@psg.com>
Date: Wed, 19 Dec 2001 13:47:55 -0800
Sender: owner-dnsop@cafax.se
Subject: Re: draft-ietf-dnsop-hardie-shared-root-server-06.txt

iesg reviewer said the appended.  i may have been at fault, but my records
do show i passed it on.

randy

----



wdiff shows only changes to the author contact info between -05 and
-06.  I had comments a while back that I fear got lost.

---

I've had a todo to send you comments on this one for way too long.
Here they are.  Do these seem reasonable requests? 

Thomas

	<draft-ietf-dnsop-hardie-shared-root-server-05.txt>

>   name servers.  The shared unicast system described here is specific
>   to IPv4; IPv6 uses anycast differently from IPv4 and those
>   differences prevent this system from being used in IPv6
>   environments.  It should also be noted that the system described

This technique could work equally well in IPv6 as in IPv4. I
understand the wording relates to what IPv6 documents say, but they
may change. How about rewording as:

   The shared unicast system described here is specific to IPv4;
   applicability to IPv6 is an area for further study.

>  in the mesh make their zones available for zone transer, the administrative

s/transer/transfer

>  here is related to that describe in [ANYCAST], but it does not

described

>   One potential problem with using shared unicast addresses is that
>   routers forwarding traffic to them may have more than one available
>   route, and those routes may, in fact, reach different instances of
>   the shared unicast address.  Because UDP is self-contained, UDP
>   traffic from a single source reaching different instances presents
>   no problem.  TCP traffic, in contrast, may fail or present
>   unworkable performance characteristics in a limited set of
>   circumstances.  For split-destination failures to occur, the router 
>   forwarding the traffic must both have equal cost routes to the two 
>   different instances and use a load sharing algorithm which does 
>   per-packet rather than per-destination load sharing.  

The wording around UDP is not completely accurate. Indeed, the issue
really is an application issue; even UDP protocols (NFS?) can have
problems. Also, the last sentence seems too narrow. A link failure can
cause routes to switch.

Suggested alternate text:

  One potential problem with using shared unicast addresses is that
  routers forwarding traffic to them may have more than one available
  route, and those routes may, in fact, reach different instances of
  the shared unicast address.  Some applications, whose communication
  consists of independent request-response messages each fitting in a
  single UDP packet presents no problem.  Other applications, in which
  multiple packets must reach the same endpoint (e.g., TCP) may fail
  or present unworkable performance characteristics in some
  circumstances.  Split-destination failures may occur when a router
  does per-packet (or round-robin) load sharing, a topology  change
  occurs that changes the relative metrics of two paths to the same
  anycast destination, etc.


    
>   Lastly, in the case where the traffic is TCP, per packet load
>   sharing is used, and equal cost routes to different instances of a
>   name server are available, any implementation which measures the
>   performance of servers to select a preferred server will quickly
>   prefer a server for which this problem does not occur.  For

I'm not sure this is true. I.e., if some packets actually go to server
A and some go to server B, and TCP is in use, what will happen is that
only one of the servers will have a TCP connection block (i.e, the one
to which the SYN was sent). WHen a TCP packet gets delivered to the
other server, it will return a TCP RST and the connection will be
terminated. How does one recover from that? When opening a connection
again, presumably the same thing happens again.

Or am I misunderstanding the point here?

>   Appendix A. contains an ASCII diagram of a simple implementation of
>   this system.  In it, the odd numbered routers deliver traffic to the
>   shared-unicast interface network and filter traffic from the
>   administrative network; the even numbered routers deliver traffic to
>   the administrative network and filter traffic from the shared-unicast
>   network.  These are depicted as separate routers for the ease this

I don't understand this diagram at all. Am I just being dense?

Home | Date list | Subject list