Re: draft-ietf-dnsop-hardie-shared-root-server-06.txt

[Ted Hardie <Ted.Hardie@nominum.com>]

Randy, Thomas,

I've never seen the comments before, so they may have been lost in
transit.  I've made comments inline; I expect to issue as -07.txt as a
result.


On Wed, Dec 19, 2001 at 01:47:55PM -0800, Randy Bush wrote:
> 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.

This wording was in response to comments by Bernard Aboba about the
design of anycast in IPv6, and obviously came before the IPv6 anycast
analysis draft came out.  According to Bernard's comments, the current
specs disallow this use.  I've cc'ed him on this so he can comment on
any further discussion.  Pending further comment, I will plan to
incorporate the change.


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

Noted.

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

Noted.

> 
> >   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.

Thomas is right that this is an application issue; the text is talking
about the UDP request-response in the DNS, not UDP in general. I'm
fine with the text below.  I believe we could make it even more
specific by saying "the DNS request-response", rather than his more
general "communication consists of independent request-response
messages each fitting in a single UDP packet".  I'm happy either
way, and I'll incorporate the suggested text unless I get a
feedback preferring the DNS-specific language.

> 
> 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?

Again, this is DNS-specific.  The DNS failover mechanisms mentioned in
1.3 mean that in common implementations a failure of this type will
cause the DNS to attempt to reach other authoritative servers.  That,
combined with the advice in 1.5:

   To guard even against the case where multiple meshes have a
  set of users affected by per packet load sharing along equal cost
  routes, organizations implementing these practices should always
  provide at least one authoritative server which is not a participant
  in any shared unicast mesh.

means that even in the worst case the DNS failover mechanism will
eventually work to allow resolution.



> 
> >   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?


ASCII art is always a bit tough to parse.  Can you be more specific in
describing the problem, or can you indicate whether the text is clear
enough without the Appendix?  I don't consider the Appendix normative.

			regards,
				Ted Hardie