Re: grow: draft-ietf-grow-anycast

[Joe Abley]

On 11-Aug-2005, at 19:10, Dean Anderson wrote:

I have some concerns about this draft.


DNSOP WG, and is a very controversial notion.

First, the issue of Anycast DNS has been extensively discussed on the IETF

I do not believe this is an accurate assessment. Rather, the use of anycast to distribute DNS authority servers has been widely implemented, and has been studied, and I think it is reasonable to conclude that it is now an established technique.

  Your draft should at least

2) require state, or 3) uses packets large enough to be fragmented.
Abley participated in the DNSOP discussion.

acknowledge that Anycast is inappropriate for protocols that 1) use TCP,

The draft includes extensive discussion about the use of anycast in protocols carried over TCP, or otherwise requiring state. See sections 4.1 and 4.4.3, for example. If you have specific suggestions as to improvements, please send text.

Second, the draft fails to consider Per-Packet-Load-Balancing (PPLB) or other fine grained load balancing behaviors which may be introduced at any level in the network, including by the end-user. PPLB and Anycast will cause insurmountable problems for any protocol that (as before) either

  1)  uses TCP,
  2) requires state, or
  3) uses packets large enough to be fragmented.

The draft includes discussion about the impact of equal-cost paths in section 4.4.3. Again, please send text if you have changes to suggest.

Third, there seems to be little discussion of what protocols (besides
DNS--presumably why ISC is interested), might be suitable for Anycast.

See section 4.1 for discussion about protocol suitability.

The draft is not at all specific to the DNS; it is a general discussion of the use of anycast for distributing services. Where DNS is mentioned, it is used as an example of a service for which anycast distribution is a tried and tested technique. I asked the room in the grow meeting at IETF 62 whether anybody there considered the draft to be DNS-centric, and the consensus was that it was not. You are the first person apart from me to bring this up, in fact.

Fourth, there is little or no discussion or warning against the rather

perniciously difficult if not impossible to identify hazards of Anycast.

The draft discusses service monitoring in section 5, and security considerations in section 6. If you have suggestions as to how these sections could be made more clear, please send text.

In summary, there seems to be little acknowlegement of RFC1546 admonitions

for Anycasting;

Since RFC 1546 was written there has been much operational experience gained in the use of anycast to distribute services. It is partly because of this additional experience (and the extent to which some of the advice in RFC 1546 has been proven to be over-cautious or pessimistic) that draft-ietf-grow-anycast has been written.

The BGP gyrations described by the draft seem to be an attempt to assume that two successive packets will be sent to the same anycast address on

the same host.  However, neither BGP configuration, nor any routing
protocol can make such a network-wide guarantee.

In fact, most of section 4 is concerned with describing exactly these hazards, together with many more.

**[I am working on text of a draft to be submitted to DNSOP WG to
recommend against using anycast for DNS, and to advise that Root DNS

Anycast violates the requirements RFC 2870 section 2.6, 3.3.1, and 3.3.2]

Good luck with that.


Joe

PGP.sig
Description: This is a digitally signed message part