ietf
[Top] [All Lists]

Re: Call for Comment on draft-iab-anycast-arch-implications-09 on "Architectural Considerations of IP Anycast"

2013-07-05 04:41:35
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