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

From: Randy Bush <[email-masked]>
Date: Wed, 19 Dec 2001 13:47:55 -0800

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?

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Dec 2001 15:07:38 -0800

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

many people are working on un-breaking v6 anycast

>>   single UDP packet presents no problem.  Other applications, in which
                              /
>>   does per-packet (or round-robin) load sharing, a topology  change
                                                   ^ and/or when

---

From: Lars-Johan Liman <[email-masked]>
Date: Thu, 20 Dec 2001 14:13:17 +0100 (MET)

[email-masked]:
> iesg reviewer said the appended.  i may have been at fault, but my
> records do show i passed it on.

Um, yeah you did ...

The fault is mine. I didn't check the addresses in that message, and
thought it obvious that you had sent it to Ted (the author) as well
(so I was kind of waiting for his comments), but you didn't. It was
sent only to Ray and me.

It has now obviously reached the entire WG ... ;-)

				  /Liman

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Dec 2001 06:38:24 -0800

> It has now obviously reached the entire WG ... ;-)

i am an american.  when whispering does not work, we go nuclear.  :-)

randy

---

From: Ted Hardie <[email-masked]>
Date: Wed, 19 Dec 2001 14:57:25 -0800

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.

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

Noted.

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

Noted.

> problems. Also, the last sentence seems too narrow. A link failure can

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.

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

> 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