Re: Evaluation: draft-ietf-ipngwg-ipv6-anycast-analysis

[Alex Zinin <zinin@psg.com>]

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.

-- 
Alex
http://www.psg.com/~zinin/