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

From: IAB Chair <[email-masked]>
Date: Wed, 3 Jul 2013 14:13:57 -0400

This is an announcement of an IETF-wide Call for Comment on "Architectural Considerations of IP Anycast" (draft-iab-anycast-arch-implications-09). 

The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection here: 
https://datatracker.ietf.org/doc/draft-iab-anycast-arch-implications/

The Call for Comment will last until August 1, 2013. Please send comments to [email-masked] or submit them via TRAC (see below). 

Russ Housley
IAB Chair

= = = = = = = = = =

Submitting Comments via TRAC

1. To submit an issue in TRAC, you first need to login to the IAB site on the tools server: 
http://tools.ietf.org/wg/iab/trac/login 

2. If you don't already have a login ID, you can obtain one by navigating to this site: 
http://trac.tools.ietf.org/newlogin 

3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: 
http://trac.tools.ietf.org/wg/iab/trac/newticket 

4. When opening an issue: 
a. The Type: field should be set to "defect" for an issue with the current document text, or "enhancement" for a proposed addition of functionality (such as an additional requirement). 
b. The Priority: field is set based on the severity of the Issue. For example, editorial issues are typically "minor" or "trivial". 
c. The Milestone: field should be set to milestone1 (useless, I know). 
d. The Component: field should be set to the document you are filing the issue on. 
e. The Version: field should be set to "1.0". 
f. The Severity: field should be set to based on the status of the document (e.g. "In WG Last Call" for a document in IAB last call) 
g. The Keywords: and CC: fields can be left blank unless inspiration seizes you. 
h. The Assign To: field is generally filled in with the email address of the editor. 

5. Typically it won't be necessary to enclose a file with the ticket, but if you need to, select "I have files to attach to this ticket". 

6. If you want to preview your Issue, click on the "Preview" button. When you're ready to submit the issue, click on the "Create Ticket" button. 

7. If you want to update an issue, go to the "View Tickets" page: 
http://trac.tools.ietf.org/wg/iab/trac/report/1 

Click on the ticket number you want to update, and then modify the ticket fields as required.

---

From: SM <[email-masked]>
Date: Fri, 05 Jul 2013 02:05:28 -0700

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

---

From: Joe Abley <[email-masked]>
Date: Sat, 6 Jul 2013 01:25:44 -0400

Hi there,

I haven't reviewed the draft (but I will). One thing stood out though:

> rssac.org is having DNS issues.

RSSAC.ORG was registered by an individual with an interest in root server operations, but is not (as far as I know) anything to do with RSSAC at this time.

Joe

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 6 Jul 2013 12:27:46 +0200

The informational-draft does not define IP anycast or does not refer
to a document that defines the IP anycast (anycast was defined as
refer to rfc1546). However, I think it is a draft for anycast
services/methods in IP protocols (Internet Anycast), not only IP
anycast.

AB

On 7/3/13, IAB Chair <[email-masked]> 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 document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection here:
> The Call for Comment will last until August 1, 2013. Please send comments to
> [email-masked] or submit them via TRAC (see below).
>
> Russ Housley
> IAB Chair
>
> = = = = = = = = = =
>
> 3. Once you have obtained an account, and have logged in, you can file an
> issue by navigating to the ticket entry form:
> a. The Type: field should be set to "defect" for an issue with the current
> document text, or "enhancement" for a proposed addition of functionality
> (such as an additional requirement).
> b. The Priority: field is set based on the severity of the Issue. For
> example, editorial issues are typically "minor" or "trivial".
> f. The Severity: field should be set to based on the status of the document
> (e.g. "In WG Last Call" for a document in IAB last call)
> 5. Typically it won't be necessary to enclose a file with the ticket, but if
> you need to, select "I have files to attach to this ticket".
>
> 6. If you want to preview your Issue, click on the "Preview" button. When
> you're ready to submit the issue, click on the "Create Ticket" button.
>