At 11:13 03-07-2013, IAB Chair wrote:
This is an announcement of an IETF-wide Call for Comment on
"Architectural Considerations of IP Anycast"
(draft-iab-anycast-arch-implications-09).
The first version of this draft was submitted in February 2010. The
IETF-wide Call is a little more than three years after that.
The title of the draft is "Architectural Considerations of IP
Anycast". The Abstract mentions "architectural implications of IP
anycast". After reading the draft it seems to me that it is more
about considerations of using IP Anycast.
In Section 1:
"As of early 2009, at least 10 of the 13 root name servers were
using IP anycast [RSSAC29]"
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62449
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;rssac.org. IN A
rssac.org is having DNS issues.
The above cites a report published in 2007 about root name servers
using IP anycast in 2009. That seems incorrect.
In Section 2.1:
"One of the first documented uses of anycast was in 1994 for a "Video
Registry" experiment [IMR9401]."
I suggest using
ftp://ftp.rfc-editor.org/in-notes/museum/imr/imr9401.txt as the
stable reference for IMR9401.
"At the same time, site-local-scoped well-known addresses began
being used for recursive resolvers [I-D.ietf-ipv6-dns-discovery],
but this use was never standardized (see below in Section 3.4 for
more discussion)."
That I-D from 2002 is cited as work in progress. :-)
'"Requirements for a Mechanism Identifying a Name Server Instance"
[RFC4892] cites the use of anycast with DNS as a motivation to
identify individual name server instances, and the Name Server ID
(NSID) option was defined for this purpose [RFC5001].'
From an architectural point of view I would look at it in terms of
locator and identifier separation.
In Section 3.4:
'Section 3.3 of [RFC4339] proposes a "Well-known Anycast Address" for
recursive DNS service configuration in clients to ease configuration
and allow those systems to ship with these well-known addresses
configured "from the beginning, as, say, factory default". During
publication the IESG requested that the following "IESG Note" be
contained in the document:'
Section 3 is about principles. RFC 4339 was published in 2006. I
didn't look into what seems to be the preferred approach since
then. The IESG Note quoted in the draft does not convey much
information from an anycast perspective. I guess that Section 3.3.2
of RFC 4339 is more appropriate as it discusses about the
disadvantages of using the well-known anycast address.
It seems to me that the idea here was more about well-known address
instead of anycast. As a comment about history it seems that this
goes back to the idea of logical addressing mentioned in 1981. To
keep matters easy I would go with the idea of locator of ubiquitous
service which offers flexibility to the host.
Would it be appropriate to say that one of the assumptions for
anycasting an application is that it has a fail-over mode in addition
to using a stateless transport? Otherwise the route has to be
withdrawn to avoid service outage (see Section 4.5).
The draft was an interesting read. I didn't catch the potential for
a cascaded failure at first (see Section 4.4). On a second read I
realized that I was confusing a specific case with a general
approach. The "many pitfalls and subtleties" mentioned in Section
1 sums up IP anycast.
Regards,
-sm