Operation of Anycast Services
RFC 4786

Note: This ballot was opened for revision 04 and is now closed.

(Bill Fenner) Yes

(Ted Hardie) Yes

(David Kessens) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) (was Discuss) No Objection

Comment (2006-10-06)
I would really like to see a separate more architectural document,
in the transport area or from the IAB. It would describe the impact of 
route changes on sessions using anycast for various types of sessions,
such as command/response (e.g. DNS/UDP, SNMP/UDP), TCP, TLS, SCTP, 
RTP and DCCP. 

> 4.4.7.  Other Peoples' Networks
>    By way of mitigation, routing policies used by Anycast Nodes across
>    such routing systems should be conservative,

I don't understand what 'conservative' means.

> 4.4.8.  Aggregation Risks
>    In general, the scaling problems described here prevent anycast from
>    being a useful, general approach for service distribution on the
>    global Internet.  It remains, however, a useful technique for
>    distributing a limited number of Internet-critical services, as well
>    as in smaller networks where the aggregation concerns discussed here
>    do not apply.

This should be more prominent in the Introduction or in a Conclusion.


> 6.1.  Denial-of-Service Attack Mitigation

This section gives two pro arguments, but not the obvious con:
if a DoS attack is distributed across multiple anycast servers,
much more coordination will be needed between those
servers to fight the attack.

> 6.3.  Service Hijacking
>    Many protocols which incorporate authentication or integrity
>    protection provide those features in a robust fashion, e.g. using
>    periodic re-authentication within a single session, or integrity
>    protection at either the channel (e.g.  [RFC2845], [RFC2487]) or
>    message (e.g.  [RFC4033], [RFC2311]) levels.  Protocols which are
>    less robust may be more vulnerable to session hijacking.

These are countermeasures against session hijacking, but the
section is only named 'service hijacking.' 

> 7.  Protocol Considerations
>    This document does not impose any protocol considerations.

This section isn't needed.

(Lars Eggert) No Objection

Comment (2006-09-26)
Section 4.1., paragraph 0:
>   4.1.  Protocol Suitability

  It may be worth pointing out that protocols where transactions create
  state on the server may more problematic to deploy with anycast than
  query-only protocols. A series of transactions that creates and acts
  on server state will fail if anycast routing changes during its
  processing (and the replication mechanism between anycast servers
  hasn't propagated the state yet). Or maybe that's too fine a point?
  (Is also related to Section 4.6.)

(Russ Housley) No Objection

(Cullen Jennings) (was Discuss) No Objection

(Jon Peterson) No Objection

Comment (2006-09-28)
The presence of a Protocol Considerations sections, aside from being a bit anachronistic, seems odd when there are apparently no protocol considerations - I'm not sure what message the existence of this section is intended to convey. This is not a required section like IANA or Security Considerations in the I-D Checklist, as far as I can see.

(Dan Romascanu) No Objection

Comment (2006-09-27)
I find the information in Section 5 Service Management quite insufficient. It is hard to talk about service management and monitoring without being clear what are the characteristics of the service that are important and the associated metrics. There is some text in other sections about availability and response time, but this is not enough. I would have also liked to have more exact references to IPPM metrics that are relevant for anycast service measurements listed here, rather than just examples of tools that may have not persist or may change during the life cycle of this BCP.

(Mark Townsley) No Objection

(Magnus Westerlund) No Objection

(Lisa Dusseault) Abstain

(Sam Hartman) (was Discuss) Abstain

Comment (2006-10-15)
I believe that the IESG did not follow a process consistent with how
we handle other documents and that the divergences from our normal
process created an unacceptably closed process.  As such, I am
abstaining on this document as I cannot support its publication under
the process that was used.

The area director described the process used as "hard ball."  He said
that because of the history of the document he was pushing back
against changes both from the IESG and late last call comments more so
than usual.  By history, I suspect that he meant both the fact that
this document has already been subject to an appeal and the fact that
the document has been under development for a long time.  I think that
the area director chose to play hard enough ball that the process can
no longer be considered open and that the IESG erred in supporting
this process and approving the document.

In particular, I believe that last call comments from Dean Anderson,
Sam Hartman, Lars Eggert, Eric Rescorla and David Oran were not given
due consideration.  IESG members received overly strong pushback
against discuss comments and the working group chair and area director
engaged in tactics that I found both intimidating and inimical to an
open discussion of the issues.  I have withdrawn my discuss not
because I believe that my discuss comments are in appropriate or have
been fixed but because absent an appeal, it would be undesirable to
spend more energy on this document.  The content isn't bad--my concern
is with the process.

The last call comments I'm complaining about were submitted after the
formal IETF last call had ended.  However it is very common for the
IESG to consider last call comments received after an IETF last call.
It is particularly common to consider comments received from IESG
members as last call comments even if they are not discuss ballots.
In this instance, the working group chair has created a high bar (new
WG last call and new IETF last call) for any changes that there is a
strong disincentive for any of these comments to be seriously
considered.  Even when several of the comments tended to focus on the
same sections of the document and to describe clarity problems,
authors said that they did not consider the change because they did
not see a problem.  The authors of a document are perhaps the worst
people to judge clarity of that document.  There was enough
commonality in comments that these comments should have at least been
referred to the WG if not the ietf list.

The handling of Dean Anderson's comments is particularly concerning.
These comments were delivered to the IESG in the form of an appeal.
The IESG chose to consider Dean's technical arguments as last call
comments and dismissed his appeal.  The IESG made no response to these
comments nor is it clear how much effort was spent considering these
technical comments.  Particularly considering that one of Dean's
reasons for choosing an appeal rather than a last call comment was
that he did not have faith that he could engage in a discussion and
actually get a response to his issues, it is concerning that he did
not in fact get such a response.  The fairness of the handling of
Dean's appeal depends critically on handling his technical comments
fairly and openly as last call comments.

Attached please find the discuss comments that I have withdrawn in the
interest of expedience and under protest.

Three discuss items:

1) It's not clear to me as a reader of this document whether it
intends to make a recommendation on whether DNS is an appropriate
application of anycast or simply to use operational experience with
DNS as a basis for research and other recommendations.  Based on the
history of this document and of discussions within the IETF, I think
ambiguity is harmful on this point.  I see three reasonable
resolutions.  First,  add a statement clearly indicating that this
document takes no position on the suitability of DNS as an anycast
application.  Second, refer to an existing IETF recommendation  on the
topic if there is one.  Finally, make an explicit statement that DNS
either does or does not  meet the recommendations of this document.  I
think the third solution is least preferred because I am not convinced
that making recommendations about specific applications is in scope
for this document.

2) Because of the history of this document, I think it likely that the
claims made in this document will be subjected to a higher level of
scrutiny than usual.  As such, I think we should hold ourselves to a
high standard of quality and only make claims for which we can cite
supporting research.  To that end, I'm not sure the following sentence
in 4.4.3 is sufficiently supported: " Consequently, in many cases it
is reasonable to consider networks making such use of PPLB to be
pathological."  (I suspect it is true, but question whether the
references in the two previous sentences are sufficient.)  In
particular, the document only claims that uses of PPLB *can cause*
*persistent packet reordering*.  That's not quite the same as claiming
that they *do cause* *persistent segment reordering*, which is the
condition that [Allman2000] requires.  In particular, consider under
what circumstances TCP flows where data is not sent in two directions
at the same time and PPLB is applied in the direction of ACKs will
actually meet the conditions of [Allman2000]?  I'm not just trying to
highlight this case, but any potential case in which the conclusion of
one sentence is not sufficient to support the pre-conditions of the
conclusion.  Does the analysis of [McCreary2000], [Fomenkov2004]
actually show that the TCP traffic on the Internet meets the
conditions necessary for re-ordering to be a problem?  If so, modify
the text to say this is the case.  If not, consider language like
"Consequently, making such use of PPLB may cause operational

3) The security review by Hilarie Orman claims that 6.1 should be
deleted because it is inadequately supported.  I concur.