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

[Alex Zinin <zinin@psg.com>]

More comments from rtg-dir (dmm + chopps):

High level comment.

Anycast is supplying the ability to address a topologically close
instantiation of a service in a transparent (to the host) way. It
makes no guarantees that any packet sent to the given anycast
address will arrive at the same node.

Many of the problems seem to arise from stateful protocol uses of
anycast. In my opinion the reason they don't work is because they
are misusing the service supplied by anycast.

This draft doesn't seem to be stating that directly.

A solution to almost all the problems seems to be to send a
packet to the anycast server, acquire it's unicast address and use
that from then on (i.e., resolve the anycast address using the
routing infrastructure). This strikes me as a proper use of the
anycast service.

> o A provider-independent IPv4 address prefix is allocated from an RIR.

I think this acronym might should be expanded to regional internet
registry.

no need for it to be provider-independent. Can even be
RFC1918 w/in a domain

> o The address prefix is configured at multiple distant locations on the
>   Internet.

s/distant//

> Shared-anycast address technique must not be confused with the one we
> discuss in the document (RFC2373 anycast), as the problem domain is
> different.

That should be "The shared-unicast" right?

> o A host route, or a route that covers the address prefix is advertised
>   from all of the locations.

maybe. A /32 is injected into the IGP by the router(s)
adjacent to the host with the anycast address

In section 3.2 (Nondeterministc packet delivery):
Cu, Sa, Su, and Ca are used in the example and not
defined (although you can figure it out).

> One possible workaround is to use IPv6 routing header.  By specifying a
> unicast address of Si as an intermediate hop, C can deliver the packet
> to Si, not to other Sn.

Why not just switch to using the unicast IP as the destination after it
has been learned?

> o Define an additional connection setup protocol that resolves IPv6
>   unicast address from IPv6 anycast address.  We first resolve IPv6
>   unicast address using the new protocol, and then, make a TCP
>   connection using the IPv6 unicast address.  IPv6 node information
>   query/reply [Crawford, 2002] could be used for this.
>

This seems like a solution that could be used for more than just TCP
(e.g., the UDP examples).