Subject: grow: WGLC for Operation of Anycast Services (draft-ietf-grow-anycast-04.txt)

From: Geoff Huston <[email-masked]>
Date: Wed, 12 Jul 2006 06:21:24 +1000

This note starts the WG Last Call for comments on 
draft-ietf-grow-anycast-04.txt, "Operation of Anycast Services".

It can be found at:
            http://www.ietf.org/internet-drafts/draft-ietf-grow-anycast-04.txt

Please review the document carefully, and send your feedback to the GROW 
list.  Please also indicate whether or not you believe that this document 
is ready to go to the IESG for publication as a BCP.

This Working Group Last Call will end on 26 July 2006 at 0800,  UTC+10

While an previous version of this document (-02) was reviewed in the 
context of a Working Group Last Call in November 2005, the  document has 
been revised following further review comments in the context of the 
overall IESG review. This Working Group Last Call offers Working Group 
members a further opportunity to review this document.

   Thanks,

         Geoff

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jul 2006 01:55:59 +0300 (EEST)

On Wed, 12 Jul 2006, Geoff Huston wrote:
> list.  Please also indicate whether or not you believe that this document is 
> ready to go to the IESG for publication as a BCP.

The document looks good to me.

However, the new section on anycast node identification highlights 
Dean's another concern about NSID uniqueness (and I think 
intentionally duplicated NSID information would be harmful).  This is 
not an issue for this document though.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: Geoff Huston <[email-masked]>
Date: Wed, 12 Jul 2006 20:07:59 +1000

At 08:55 AM 12/07/2006, Pekka Savola wrote:
>However, the new section on anycast node identification highlights Dean's 
>another concern about NSID uniqueness (and I think intentionally 
>duplicated NSID information would be harmful).  This is not an issue for 
>this document though.

Could I please request you to be _absolutely clear_ here. One such way is 
to  provide a simple answer to the following question:

     Are you in favour of passing this document to the IESG for publication 
as a BCP?

regards,

    Geoff

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jul 2006 13:38:34 +0300 (EEST)

On Wed, 12 Jul 2006, Geoff Huston wrote:
> Could I please request you to be _absolutely clear_ here. One such way is to 
> provide a simple answer to the following question:
>
>    Are you in favour of passing this document to the IESG for publication as 
> a BCP?

Yes.

---

From: Geoff Huston <[email-masked]>
Date: Fri, 21 Jul 2006 12:26:35 +1000

This WG last call ends next week

So far I have received 'yes' responses from Pekka Savola and Joao Damas.

Could WG members please read this draft and  indicate on the grow mail list 
whether or not you believe that this document is ready to go to the IESG 
for publication as a BCP.

thanks,

   Geoff

---

From: Vince Fuller <[email-masked]>
Date: Thu, 20 Jul 2006 20:25:44 -0700

> is ready to go to the IESG for publication as a BCP.

I am in favor of publication of this document as a BCP.

	--Vince

---

From: Dean Anderson <[email-masked]>
Date: Mon, 24 Jul 2006 20:09:24 -0400 (EDT)

I am strongly against the publication of this draft, since it is not a
workable technology for stateful anycast.  The document has many
problems relating to its scientific and technical integrity.

Besides the technical analysis and reasons previously given for why it
is unworkable (included by reference);

Besides the discovery of a scientific fraud in testing that purported to
establish its stability (included by reference);

Recently, a June 2006 presentation was given to Nanog by a company that
described itself as providing "TCP Anycast".  The presentation states
that the company uses __custom hardware__ to maintain state: Their
service is not the stateful anycast service described in this document.  
By contrast, this document does not describe any custom hardware to
maintain state.  An examination of the availability data provided by the
company in the presentation showed that it never, ever, reached 100%
availability, even with the custom hardware.

What is described in this document has no technical or rational basis
for stable operation, and demonstrably does not provide stable
operation.

The author (Abley) has even recently stated he (no longer) makes any
claims or assurances for stable operation for anything other than
trivial stateless operations.  This would seem to preclude its use for
root DNS services, or any DNSSEC services, or any stateful service.

The document describes a myth, a scientific fraud, (and perhaps a
financial fraud to the tune of perhaps $24 million per year in root DNS
Anycast server sales--depending on the claims made to customers); a myth
that has no truthful technical or factual basis.

Therefore this document should not be published by a professional
society.

Dean Anderson
Av8 Internet, Inc

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 25 Jul 2006 11:13:34 +0200

On Thu, Jul 20, 2006 at 10:39:45PM -0400,
 Joe Abley <[email-masked]> wrote 
 a message of 89 lines which said:

> Any review and comments would be gratefully received (either to the  
> grow list, or direct to geoff at the address below if you're not  
> subscribed).

I've reviewed draft-ietf-grow-anycast-04 and I think that:

* it is OK (I do no find gross errors or omissions),
* it is useful, and, because of the practical importance of anycast in
  today's Internet, it should be published as a RFC.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 26 Jul 2006 08:40:28 +1000

At 06:21 AM 12/07/2006, Geoff Huston wrote:
>This note starts the WG Last Call for comments 
>on draft-ietf-grow-anycast-04.txt, "Operation of Anycast Services".
>
>It can be found at:
>Please review the document carefully, and send 
>your feedback to the GROW list.  Please also 
>indicate whether or not you believe that this 
>document is ready to go to the IESG for publication as a BCP.
>

The Working Group Last Call period for this document has concluded.

I observe consensus within the Working Group to 
request publication of this document as a BCP.

thanks to all those who responded

regards,

    Geoff Huston
     GROW WG Chair

=========================================

26 July 2006

Document: draft-ietf-grow-anycast-04.txt

Proposed Publication track: BCP

While the working group has not been unanimous in its support of proceeding
to a recommendation to publish this document, I am comfortable in making a
call that the Working Group has shown a rough consensus to indicate that it
has completed its work on this document and is ready to proceed with
publication as a BCP.

The following advice is being passed to the ADs as the Protocol Note
associated with this request for publication.

1.a) Have the chairs personally reviewed this version of the Internet
      Draft (ID), and in particular, do they believe this ID is ready
      to forward to the IESG for publication?  Which chair is the WG
      Chair Shepherd for this document?

         Yes, the document has been reviewed by the GROW WG Chair.

         The document is, I believe, ready to forward to the IESG for
         publication.

         Geoff Huston is the WG Chair Shepherd for this document

1.b) Has the document had adequate review from both key WG members and key
      non-WG members?  Do you have any concerns about the depth or breadth
      of the reviews that have been performed?

         The document has had extensive review by the GROW WG across 2005
         and 2006, and has generated a considerable volume of discussion. I
         have no residual concerns about the depth or breadth of the Working
         Group's review process for this document.

         The document has been further reviewed in July 2006 in the context
         of a Working Group Last Call, and I received positive responses
         from the following Working Group members to proceed with
         publication in response to a Working Group Last Call on this
         version of the document:

           Pekka Savola, Joao Damas, William Maton, Vince Fuller, Matt
           Pounsett, McTim (Tim McGinnis), Bill Woodcock, MÃ¥ns Nilsson,
           Anton Ivanov and Stephane Bortzmeyer.

           http://darkwing.uoregon.edu/~llynch/grow/msg00556.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00557.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00561.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00568.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00569.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00570.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00573.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00575.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00577.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00579.html

         A number of WG members submitted review comments to the Grow WG
         mail list during the WG Last Call. These comments are archived at
           http://darkwing.uoregon.edu/~llynch/grow/msg00571.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00577.html
           http://darkwing.uoregon.edu/~llynch/grow/msg00578.html

         In this WG Last Call period Dean Anderson has indicated his
         opposition to publication of this document "since it is not a
         workable technology for stateful anycast", citing "technical
         analysis and reasons previously given" as the basis for his
         position:
           http://darkwing.uoregon.edu/~llynch/grow/msg00576.html

         This has been the only WG contribution 
to the Last Call against proceeding with publication of this document.

1.c) Do you have concerns that the document needs more review from a
      particular (broader) perspective (e.g., security, operational
      complexity, someone familiar with AAA, internationalization, XML,
      etc.)?

         The document has been reviewed from an applications design
         perspective, and, in particular, from the perspective of deployment
         of DNS services. I have no concerns that that additional review of
         the document from an applications perspective is necessary.

1.d) Do you have any specific concerns/issues with this document that you
      believe the ADs and/or IESG should be aware of?  For example, perhaps
      you are uncomfortable with certain parts of the document, or have
      concerns whether there really is a need for it.  In any event, if your
      issues have been discussed in the WG and the WG has indicated it that
      it still wishes to advance the document, detail those concerns in the
      write-up.

         In an earlier WG Last Call there was a single dissenting view from
         Dean Anderson noting a difference in semantic interpretation of
         'node selection', differences in capabilities of 'Per-Packet Load
         Balancing', and differences of view in the potential for TCP
         failure over parallel diverse paths with Per-Packet Load Balancing.
         Dean Anderson noted that the chairs had judged WG consensus for
         publication of this document and that he did not dispute that
         judgment.

         This initial consensus call in November 2005 has been the subject
         of an appeal by Dean Anderson. The Working Group chair rejected
         this appeal on the 6th June 2006.
           http://darkwing.uoregon.edu/~llynch/grow/msg00540.html

         The document has been revised since, and a revision (-04) was
         published in July 2006. A 2 week Working Group Last Call on this
         revised version (-04) of the document was issued on the 12th July,
         and has been completed on the 26th July 2006. The WG response to
         this Last Call is summarized in the response to question 1.b).

1.e) How solid is the WG consensus behind this document?  Does it
      represent the strong concurrence of a few individuals, with others
      being silent, or does the WG as a whole understand and agree with it?

         The document has been reviewed by a number of WG members and there
         appears to be a very considerable level of support for  this
         document to proceed with publication as a BCP. I am confident in
         making the judgement of a rough consensus within the Working Group
         to proceed with publication of this document.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarize the areas of conflict in separate
      email to the Responsible Area Director.

1.g) Have the chairs verified that the document checks out against
      all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
      Boilerplate checks are not enough; this check needs to be
      thorough.

         Yes - the only nit in the document is that it was published as a
         draft on the 10th July 2006, yet the data header on the draft
         indicates January 2006 with an expiration of 5 July 2006.

         No other nits have been found and the document checks against the
         online nits checked.

1.h) Has the document split its references into normative and
      informative?  Are there normative references to IDs, where the IDs are
      not also ready for advancement or are otherwise in an unclear state?
      The RFC Editor will not publish an RFC with normative references to
      IDs (will delay the publication until all such IDs are also ready for
      RFC publication).  If the normative references are behind, what is the
      strategy for their completion?  On a related matter, are there
      normative references that are downward references, as described in BCP
      97, RFC 3967 RFC 3967 [RFC3967]?  Listing these supports the Area
      Director in the Last Call downref procedure specified in RFC 3967.

         References are split into normative and informative references.
         Normative references reference published RFCs. Informative
         references include a reference to a current internet draft.

         As this is a proposed BCP there is no downward normative
         references.

1.i) For Standards Track and BCP documents, the IESG approval
      announcement includes a write-up section with the following
      sections:

      *    Technical Summary

              This document describes the use of anycast for both local
              scope distribution of services using an Interior Gateway
              Protocol and global distribution using BGP.  Many of the
              issues for monitoring and data synchronization are common to
              both, but deployment issues differ substantially.

              The document considers the design of anycast services,
              including considerations of protocol suitability, routing
              considerations, addressing considerations and multi-service
              configurations, as well as service management issues.

      *    Working Group Summary

              The document was adopted as a GROW WG document in February
              2005, and further revised in accordance with WG comments. The
              Working Group Last Call was conducted in November 2005, and a
              further revision of the document was published in January
              2006. The revision that has been last-called in July 2006 is
              the -04 version of the internet draft.

              The WG position was a general consensus, with some further
              review comments that do not appear to alter the overall WG
              consensus that the document is ready for publication as a BCP.

      *    Protocol Quality

              The document describes the advantages and limitations of a
              commonly used service deployment technique.

              Anycast has been widely deployed in a number of scenarios,
              particularly relating to the deployment of DNS servers.

              Anycast does not require specific support from equipment
              vendors.