Call for Comment on draft-iab-anycast-arch-implications-09 on "Architectural Considerations of IP Anycast"
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 i...@iab.org 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.
Re: Call for Comment on draft-iab-anycast-arch-implications-09 on "Architectural Considerations of IP Anycast"
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
Re: Call for Comment on draft-iab-anycast-arch-implications-09 on "Architectural Considerations of IP Anycast"
Hi there, I haven't reviewed the draft (but I will). One thing stood out though: On 2013-07-05, at 05:05, SM wrote: > ;; ->>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. 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
Re: Call for Comment on draft-iab-anycast-arch-implications-09 on "Architectural Considerations of IP Anycast"
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 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: > https://datatracker.ietf.org/doc/draft-iab-anycast-arch-implications/ > > The Call for Comment will last until August 1, 2013. Please send comments to > i...@iab.org 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. > >
