An analysis of IPv6 anycast
draft-ietf-ipngwg-ipv6-anycast-analysis-02

First, the spelling is entertainingly variable.  In addition to be
treated to questions of existance, we got authorization, authorisation, and their relatives in a single paragraph.

More striking, though, is this:

  2) Admission Control

      The requirements of section 3 discuss labels and security.  In
      going beyond this, the ability to distinguish emergency flows
      implies the need for admission control if resources become
      scarce.  Solutions must recognize this when trying to satisfy
      the above requirements such that the simple presence of a
      label does not imply admission control always exists along
      the end-to-end path.

It is not clear to me whether this means "the requirements here
imply that admission control must be added to the Internet architecture"or "there is a requirement to find solutions which do not rely on admission control, since it is not part of the Internet architecture." Clearing that up seems like a good idea.  I suggest:

The requirements of section 3 discuss labels and security.
Those developing solutions should understand that the
ability labels provide to distinguish emergency flows does
not create an ability to selectively admit flows.  Admission
control as it is commonly understood in circuit-switched
networks is not present in IP-based networks, and schemes
which presume the ability to selectively admit flows when
resources are scarce will fail outside of very controlled
environments.  Given the nature of emergencies to occur
outside controlled environments, the development of
technologies based on admission control is not
        recommended as the foundation of emergency services.

IESG comments from Alex:

Meta issues:

In section 4.1, the draft talks about the possibility of assigning
anycast addresses to hosts, and links this tightly to how such
addresses would be injected into the routing infrastructure.

First of all, I don't believe the two issues should be considered
as tightly coupled. I.e., assigning anycast addresses to hosts
does NOT prescribe the actual method of route injection.

Second, the two proposed solutions (hosts participating in the RP, and
a separate protocol used to inject routes from hosts) have
considerable problems.

    1. Running routing protocols on hosts

          This method affects two critical aspects of routing protocols:
          their scaling and security.

          From the scaling perspective, running RPs on hosts has the
          potential of substantially increasing the number of nodes in the
          domain in case a killer-app is developed that encourages hosts
          to participate in anycast.
 
          From the security perspective, adding hosts to the routing domain
          changes the whole security model of the routing
          protocols--assumption of implied authorization of authenticated
          announcements will not hold true anymore, i.e., participation
          in the routing domain will not be limited to routers administered
          by a few people.

    2. Injecting routes from hosts through a new protocol

          This approach does not stretch the scalability assumptions in
          routing, but still has the same drawbacks as far as security
          is concerned.

Again, I don't think the doc should consider assignment and
advertisement together. Static route configuration and subsequent
redistribution in a RP on a router seems like the right approach given
the scale of deployment

Minor:

3. Section 4.3. Anycast address in source address

> Under RFC2373 rule, anycast address cannot be put into source address.
> Here is a possible workaround, however, it did not win a consensus in
> the past ipngwg meetings:

Why is this section here? If it does not represent a consensus within
ipv6, then the only reason I would see in documenting this option is
to say "and, BTW, we do NOT want to do this", which I don't think is
the case.

4. Section "2.3. Route scaling issues"

> The use of anycast addresses has route scalaing issues. If anycast
> addresses are drawn from the unicast address space (as is the case in
> RFC2373 anycast and the shared-unicast address used for anycast DNS
> servers) the routing scaling impact can potentially be limited by
> aggregating the anycast addresses as part of the regular unicast routing
> prefixes. But this aggregation can only be applied when all members in
> the anycast group remaing within the piece of toplogy whose routes get
> aggregated. For instance having an anycast address where all the
> members belong to one ISP means it the anycast address can be drawn from
> the ISPs address space and be aggregated at the ISP boundary with no
> effect on route scaling outside that domain. But having e.g. anycast
> groups with members across the whole Internet will have effect on the
> size of the routing tables globally.

It may be worth adding that if topological localization of anycast
members is not 100% guaranteed, aggregation will break anycast, as
unaggregated prefixes will be preferred over the aggregates because
of the longest match forwarding behavior.

State Changes to New Version Needed (WG/Author)                    from Request Rejected                                  by nordmark

State Changes to Request Rejected                                  from AD Evaluation                                    by scoya