Dean,

These points have all been covered before. Once more, then, for the
road.

On 28-Jun-2006, at 16:57, Dean Anderson wrote:

> On Wed, 28 Jun 2006, Sam Hartman wrote:
>
>> Dean> The -02 draft did not complete WGLC. A new draft was
>> Dean> issued.
>>
>> It's often the case that a WG will decide that the result of a WG LC
>> is that minor changes are required and that a new draft will be
>> issued
>> but that no new LC is required.
>
> I agree this can happen. This was the case with the NSID draft, which
> also contained errors resulting from confusion and moving too fast.
> But that wasn't the case for the draft-ietf-grow-anycast-02 document.

In fact, it was. Your statement is incorrect. There are more details
below.

> In that case, the Last Call issued in November by Geoff Huston also
> indicated that there were no comments requiring a new draft. This was
> wrong.

The last time you voiced this opinion, the grow chair replied:

http://darkwing.uoregon.edu/~llynch/grow/msg00461.html

After the WGLC had been concluded, Geoff forwarded the document to
David Kessens as AD requesting that the document be published. David
Kessens contacted the authors of the drafts with a list of
typographic, spelling and wordsmithing complaints. We fixed those and
resubmitted it as -03, as requested by David.

A unified diff between -02 and -03 is included below.

> A new draft was then issued.

-03 was forwarded to the IESG for publication as BCP, and was
subsequently subject to Secdir and Gen-ART review. Those reviews
resulted in changes which were greater in extent than the simple typo/
spelling/wordsmithing corrections from -02 to -03. Those changes were
incorporated into what will one day hopefully be called -04, the
current text of which has been sent to the grow list as -pre04.

The IESG issued a last call on -03 and as far as I know they received
no comments on the draft apart from yours.

> The November last-call failed to
> achieve consensus on the -02 document. Therefore, the
> draft-ietf-grow-anycast-02 document did not "complete the last
> call", as
> Abley asserts.

That's not correct. See, for example:

http://darkwing.uoregon.edu/~llynch/grow/msg00451.html

>> Another common reason for a post-wg-LC draft is comments received
>> from
>> the AD between the time when the AD accepts the draft and an IETF
>> last
>> call is issued.
>
> I understand that is possible, too. But it is not the case for the
> draft-ietf-grow-anycast-02 document.

Again, that's factually incorrect.

As I mentioned in my recent message to the grow list, once we are
able to submit -04 we will ask the grow wg chair to carry out a new
grow wglc specifically on the changes made to the document between
-02 and -04. If the chair agrees to this, then there will have been
no revisions (minor, typographical, or otherwise) which have not been
subject to a working group last-call.

To the best of my knowledge, there is not a single person who has
read this draft, apart from you, who objects to its publication. The
following may provide useful background:

http://dictionary.reference.com/browse/consensus

Joe

--- draft-ietf-grow-anycast-02.unpg 2006-06-27 18:10:06.000000000
-0400
+++ draft-ietf-grow-anycast-03.unpg 2006-06-28 17:54:37.000000000
-0400
@@ -3,13 +3,13 @@
Network Working Group J. Abley
Internet-Draft ISC
-Expires: April 4, 2006 K.
Lindqvist
+Expires: July 5, 2006 K.
Lindqvist
Netnod Internet
Exchange
- October
2005
+ January
2006
Operation of Anycast Services
- draft-ietf-grow-anycast-02
+ draft-ietf-grow-anycast-03
Status of this Memo
@@ -34,11 +34,11 @@
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on April 4, 2006.
+ This Internet-Draft will expire on July 5, 2006.
Copyright Notice
- Copyright (C) The Internet Society (2005).
+ Copyright (C) The Internet Society (2006).
Abstract
@@ -90,7 +90,7 @@
6.3. Service Hijacking
7. Protocol Considerations
8. IANA Considerations
- 9. Acknowlegements
+ 9. Acknowledgements
10. References
10.1. Normative References
10.2. Informative References
@@ -108,6 +108,9 @@
of services are discussed in [RFC1546], [ISC-TN-2003-1] and [ISC-
TN-
2004-1].
+ The techniques and considerations described in this document
apply to
+ services reachable over both IPv4 and IPv6.
+
Anycast has in recent years become increasingly popular for adding
redundancy to DNS servers to complement the redundancy which the
DNS
architecture itself already provides. Several root DNS server
@@ -148,13 +151,18 @@
Anycast Node: an internally-connected collection of hosts and
routers
which together provide service for an anycast Service
Address. An
Anycast Node might be as simple as a single host
participating in
- a routing protocol with adjacent routers, or it might include a
+ a routing system with adjacent routers, or it might include a
number of hosts connected in some more elaborate fashion; in
either case, to the routing system across which the service is
being anycast, each Anycast Node presents a unique path to the
Service Address. The entire anycast system for the service
consists of two or more separate Anycast Nodes.
+ Catchment: in physical geography, an area drained by a river, also
+ known as a drainage basin. By analogy, as used in this document,
+ the topological region of a network within which packets directed
+ at an anycast address are routed to one particular node.
+
Local-Scope Anycast: reachability information for the anycast
Service
Address is propagated through a routing system in such a way
that
a particular anycast node is only visible to a subset of the
whole
@@ -178,9 +186,12 @@
Anycast is the name given to the practice of making a Service
Address
available to a routing system at Anycast Nodes in two or more
- discrete locations. The service provided by each node is consistent
- regardless of the particular node chosen by the routing system to
- handle a particular request.
+ discrete locations. The service provided by each node is generally
+ consistent regardless of the particular node chosen by the routing
+ system to handle a particular request (although some services may
+ benefit from deliberate differences in the behaviours of individual
+ nodes, in order to facilitate locality-specific behaviour; see
+ Section 4.6).
For services distributed using anycast, there is no inherent
requirement for referrals to other servers or name-based service
@@ -230,9 +241,8 @@
traffic sources in the case of attack (or query) traffic which
incorporates spoofed source addresses. This information is
derived from the property of anycast service distribution that
- the the selection of the Anycast Node used to service a
- particular query may be related to the topological source of the
- request.
+ the selection of the Anycast Node used to service a particular
+ query may be related to the topological source of the request.
5. Improvement of query response time, by reducing the network
distance between client and server with the provision of a
local
@@ -266,13 +276,13 @@
Some services have very short transaction times, and may even be
carried out using a single packet request and a single packet reply
- in some cases (e.g. DNS transactions over UDP transport). Other
- services involve far longer-lived transactions (e.g. bulk file
- downloads and audio-visual media streaming).
-
- Some anycast deployments have very predictable routing systems,
which
- can remain stable for long periods of time (e.g. anycast within an
- well-managed and topologically-simple IGP, where node selection
+ (e.g. DNS transactions over UDP transport). Other services involve
+ far longer-lived transactions (e.g. bulk file downloads and audio-
+ visual media streaming).
+
+ Services may be anycast within very predictable routing systems,
+ which can remain stable for long periods of time (e.g. anycast
within
+ a well-managed and topologically-simple IGP, where node selection
changes only occur as a response to node failures). Other
deployments have far less predictable characteristics (see
Section 4.4.7).
@@ -298,9 +308,9 @@
ISP's network, one Anycast Node per site.
o A root DNS server service might be distributed throughout the
- Internet with nodes located in regions with poor external
- connectivity, to ensure that the DNS functions adequately within
- the region during times of external network failure.
+ Internet; Anycast Nodes could be located in regions with poor
+ external connectivity to ensure that the DNS functions adequately
+ within the region during times of external network failure.
o An FTP mirror service might include local nodes located at
exchange points, so that ISPs connected to that exchange point
@@ -345,18 +355,18 @@
distribution (see Section 4.1).
An IGP will generally have no inherent restriction on the length of
- prefix that can be introduced to it. There may well therefore be no
- need to construct a covering prefix for particular Service
Addresses;
- host routes corresponding to the Service Address can instead be
- introduced to the routing system. See Section 4.4.2 for more
- discussion of the requirement for a covering prefix.
+ prefix that can be introduced to it. In this case there is no need
+ to construct a covering prefix for particular Service Addresses;
host
+ routes corresponding to the Service Address can instead be
introduced
+ to the routing system. See Section 4.4.2 for more discussion of the
+ requirement for a covering prefix.
IGPs often feature little or no aggregation of routes, partly
due to
algorithmic complexities in supporting aggregation. There is
little
- motivation for aggregation in many networks' IGPs in any case, since
- the amount of routing information carried in the IGP is small enough
- that scaling concerns in routers do not arise. For discussion of
- aggregation risks in other routing systems, see Section 4.4.8.
+ motivation for aggregation in many networks' IGPs in many cases,
+ since the amount of routing information carried in the IGP is small
+ enough that scaling concerns in routers do not arise. For
discussion
+ of aggregation risks in other routing systems, see Section 4.4.8.
By reducing the scope of the IGP to just the hosts providing
service
(together with one or more gateway routers) this technique can be
@@ -401,9 +411,9 @@
Where a routing advertisement from a node corresponds to two or
more
Service Addresses, it may not be appropriate to trigger a route
withdrawal due to the non-availability of a single service.
Another
- approach is to route requests for the service which is down at one
- Anycast Node to a different Anycast Node at which the service is up.
- This approach is discussed in Section 4.8.
+ approach in the case where the service is down at one Anycast
Node is
+ to route requests to a different Anycast Node where the service is
+ working normally. This approach is discussed in Section 4.8.
Rapid advertisement/withdrawal oscillations can cause operational
problems, and nodes should be configured such that rapid
oscillations
@@ -435,7 +445,7 @@
Where multiple Service Addresses are covered by the same covering
route, there is no longer a tight coupling between the
advertisement
of that route and the individual services associated with the
covered
- host routes. The resulting impact on signaling availability of
+ host routes. The resulting impact on signalling availability of
individual services is discussed in Section 4.4.1 and Section 4.8.
4.4.3. Equal-Cost Paths
@@ -484,9 +494,9 @@
where the paths converge to a single exit as they leave the AS,
should cause no node selection problems;
- 3. PPLB across links to different neighbour ASes where where the
- neighbour ASes have selected different nodes for a particular
- anycast destination will, in general, cause request packets
to be
+ 3. PPLB across links to different neighbour ASes where the
neighbour
+ ASes have selected different nodes for a particular anycast
+ destination will, in general, cause request packets to be
distributed across multiple anycast nodes. This will have the
effect that the anycast service is unavailable to clients
downstream of the router performing PPLB.
@@ -527,7 +537,7 @@
arrange that the AS_PATH attributes on routes from different nodes
are as diverse as possible. For example, Anycast Nodes should use
the same origin AS for their advertisements, but might have
different
- upstream ASs.
+ upstream ASes.
Where different implementations of flap dampening are prevalent,
individual nodes' instability may result in stable nodes becoming
@@ -539,7 +549,7 @@
problems to the Local Nodes' limited regions of influence;
2. Aggressive flap-dampening of the service prefix close to the
- origin (e.g. within an Anycast Node, or in adjcacent ASes of
each
+ origin (e.g. within an Anycast Node, or in adjacent ASes of each
Anycast Node) may also help reduce the opportunity of remote
ASes
to see oscillations at all.
@@ -596,8 +606,8 @@
Advertising reachability to Service Addresses from Local Nodes
should
ideally be made using a routing policy that require presence of
- explicit attributes for propagation, rather than reling on implicit
- (default) policy. Inadvertant propagation of a route beyond its
+ explicit attributes for propagation, rather than relying on implicit
+ (default) policy. Inadvertent propagation of a route beyond its
intended horizon can result in capacity problems for Local Nodes
which might degrade service performance network-wide.
@@ -644,7 +654,7 @@
Both of these issues can be mitigated to some extent by the use
of a
single covering prefix to accommodate multiple Service
Addresses, as
- described in Section 4.8. This implies a decoupling of the route
+ described in Section 4.8. This implies a de-coupling of the route
advertisement from individual service availability (see
Section 4.4.1), however, with attendant risks to the stability
of the
service as a whole (see Section 4.7).
@@ -669,7 +679,7 @@
might be provided by originating the covering 24-bit prefix.
For an IPv4-numbered service deployed within a private network, a
- locally-unused [RFC1918] address might be chosen, and rechability to
+ locally-unused [RFC1918] address might be chosen, and
reachability to
that address might be signalled using a (32-bit) host route.
For IPv6-numbered services, Anycast Addresses are not scoped
@@ -727,6 +737,14 @@
software, routing protocol software, etc, such that a defect which
appears in a single component does not affect the whole system.
+ It should be noted that these approaches to increase node autonomy
+ are, to varying degrees, contrary to the practical goals of making a
+ deployed service straightforward to operate. A service which is
+ over-complex is more likely to suffer from operator error than a
+ service which is more straightforward to run. Careful consideration
+ should be given to all of these aspects so that an appropriate
+ balance may be found.
+
4.8. Multi-Service Nodes
For a service distributed across a routing system where covering
@@ -756,7 +774,7 @@
4.8.2. Pessimistic Withdrawal
Multiple Service Addresses are chosen such that they are covered
by a
- single prefix. Advertisement and withdrawl of the single covering
+ single prefix. Advertisement and withdrawal of the single covering
prefix is coupled to the availability of all associated
services; if
any individual service becomes unavailable, the covering prefix is
withdrawn.
@@ -864,7 +882,7 @@
might be difficult to detect by clients or by the operator of the
service.
- The risk of service hijacking by manipulation of the routing sytem
+ The risk of service hijacking by manipulation of the routing system
exists regardless of whether a service is distributed using
anycast.
However, the fact that legitimate Anycast Nodes are observable
in the
routing system may make it more difficult to detect rogue nodes.
@@ -880,7 +898,7 @@
This document requests no action from IANA.
-9. Acknowlegements
+9. Acknowledgements
The authors gratefully acknowledge the contributions from various
participants of the grow working group, and in particular Geoff
@@ -993,6 +1011,9 @@
writing; reference should be updated to an RFC number when
available). Added commentary on per-packet load balancing.
+ draft-ietf-grow-anycast-03: Editorial changes and language clean-up
+ at the request of the IESG.
+
Authors' Addresses
@@ -1055,7 +1076,7 @@
Copyright Statement
- Copyright (C) The Internet Society (2005). This document is subject
+ Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.