Operation of Anycast Services
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
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. Minor ----- > 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
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
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
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
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 problems." 3) The security review by Hilarie Orman claims that 6.1 should be deleted because it is inadequately supported. I concur.