Subject: Under IESG review: draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt

From: Alex Zinin <[email-masked]>
Date: Tue, 5 Aug 2003 16:00:20 -0700

Please sanity check this one.

Token holders: dmm, chopps

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

---

From: Christian Hopps <[email-masked]>
Date: Wed, 6 Aug 2003 19:58:05 -0700

> Token holders: 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.

Inline comments follow.

> DRAFT                   Analysis of IPv6 anycast               June 
> 2003
>
> o A provider-independent IPv4 address prefix is allocated from an RIR.

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

> 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?

> 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).

Token returned,
Chris.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 7 Aug 2003 16:40:14 -0700

Thanks Chris!

Wednesday, August 6, 2003, 7:58:05 PM, Christian Hopps wrote:
...