Subject: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

From: Brian Haberman <[email-masked]>
Date: Wed, 6 Apr 2005 13:22:58 -0400

All,
      I am soliciting input on a proposal to modify the rules defined
in the current addressing architecture draft with respect to anycast.
There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to change
the following text in the addressing architecture:

       o An anycast address must not be used as the source address of an
          IPv6 packet.

       o An anycast address must not be assigned to an IPv6 host, that
          is, it may be assigned to an IPv6 router only.

to

    o  An anycast address MAY be used as the source address of an IPv6
        packet.
    o  An anycast address MAY be assigned to an IPv6 host.

This change will allow users to operate IPv6 anycast services in the 
same
manner in which they do today with IPv4 anycast.

I would like people to chime in before April 15, 2005 with their 
opinion on
making this change.

It should be noted that the addressing architecture is currently in 
IETF Last
Call.

Regards,
Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Apr 2005 11:50:19 -0700

Define "anycast address" in this question?

An IPv6 anycast address is indistinguishable from an IPv6 unicast  
address. As such, any rule prohibiting the use of an anycast address in  
any location is unenforceable - I have no way to identify an anycast  
address to apply the rule.

I didn't see the draft, but I was talking with Eric Nordmark about a  
notion I have that IP Mobility would be very useful in anycast  
services, and he told me that he had actually described it a year  
earlier. OK, so it's his proposal... Anycast works pretty well with  
DNS, and presumably with similar services that do not set up long tem  
associations. But with anything that routinely opens a TCP session, the  
use of anycast exposes the user to a problem when routing changes  
sufficiently to change servers. All of a sudden he's talking to someone  
who has no idea what he's talking about. The simple solution is to use  
Optimized Routing - connect to the AnyCast address, obtain the fixed  
address of the server as a Care-of Address, and then talk with the  
care-of address. You get the "nearest" server, a benefit of anycast,  
and then get to talk with it reliably even if routing changes. The big  
problem with this is that one has to open an IPSEC association with the  
anycast address, which this rule precludes.

I think that there is a good operational reason to allow for that  
model, which means that one really does need to be able to use the  
anycast address a a source just long enough to obtain the care-of  
address. I think it would be good for the document to describe the  
scenario and impose appropriate limits (you don't talk all day to the  
anycast address, you only use it to find the peer and get a better  
address for him), but it should allow for the scenario.

On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote:

> Brian------------------------------------------------------------------ 
> --

---

From: Joe Abley <[email-masked]>
Date: Wed, 6 Apr 2005 15:12:16 -0400

> Define "anycast address" in this question?

A single unicast address bound to multiple interfaces.

> address. As such, any rule prohibiting the use of an anycast address 
> in any location is unenforceable - I have no way to identify an 
> anycast address to apply the rule.

Correct. However, the v6 addressing spec prohibits the use of an 
anycast address from being used as the source address in a datagram, or 
being bound to an interface on a host. These two restrictions 
effectively prohibit the use of anycast as a service distribution 
mechanism.

I would note that the rule is indeed problematic to enforce, as is 
reflected in the various v6 services that are currently provided in 
violation of these restrictions.

> associations. But with anything that routinely opens a TCP session, 
> the use of anycast exposes the user to a problem when routing changes 
> sufficiently to change servers.

Absolutely. Anycast is not inherently unsuitable for use in 
distributing services over TCP, but there are certainly dangers 
involved in doing so. These are discussed at some length in 
draft-ietf-grow-anycast-00.

> [...]

I believe that use of anycast (as a brief locator service, so that 
subsequent long-held TCP services can be provided using unicast 
addresses) is in draft-ietf-grow-anycast-00. If it's not, it has been 
suggested by others and is in my list of things to incorporate into 
-01.

Joe

---

From: Rob Austein <[email-masked]>
Date: Wed, 06 Apr 2005 16:43:47 -0400

At Wed, 6 Apr 2005 13:22:58 -0400, Brian Haberman wrote:
> same manner in which they do today with IPv4 anycast.

I support making this change.  As far as I can tell, the current
restrictions on IPv6 anycast, while written with the best of
intentions, serve no purpose other than to forbid every real current
use of anycast addresses, and are honored entirely in the breach.
Removing these restrictions is just recognizing that we have learned
something from experience since the restrictions were written.

Use of anycast with TCP (or any protocol in which state crosses packet
boundaries) is a very tricky subject in which black and white answers
are suspect and everything is some shade of grey.  However, I believe
that the GROW WG is already addressing this, in the correct way, by
attempting to detail the considerations for use of such protocols with
anycast.  As far as I can tell, the issues are identical for IPv4 and
IPv6, and informed discussion of them depends heavily on operational
experience with routing protocols, so I think that the GROW WG is the
right place for that work.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 6 Apr 2005 16:51:38 -0400

Fred,

On Apr 6, 2005, at 14:50, Fred Baker wrote:

> earlier. OK,

      This is what Erik and I wrote up on anycast and IP Mobility.
http://anycast.anarg.jp/drafts/draft-haberman-ipv6-anycast-rr-00.txt

> so it's his proposal... Anycast works pretty well with DNS, and  
> presumably with similar services that do not set up long tem  
> sufficiently to change servers. All of a sudden he's talking to  
> someone who has no idea what he's talking about. The simple solution  
> is to use Optimized Routing - connect to the AnyCast address, obtain  
> the fixed address of the server as a Care-of Address, and then talk  
> with the care-of address. You get the "nearest" server, a benefit of  
> anycast, and then get to talk with it reliably even if routing  
> changes. The big problem with this is that one has to open an IPSEC  
> association with the anycast address, which this rule precludes.
>

I agree.

Regards,
Brian

>> Brian----------------------------------------------------------------- 
>> ---

---

From: Brian Haberman <[email-masked]>
Date: Wed, 6 Apr 2005 16:54:01 -0400

On Apr 6, 2005, at 15:12, Joe Abley wrote:

> anycast address from being used as the source address in a datagram, 
> or being bound to an interface on a host. These two restrictions 

The only place where you know it is an anycast address is at the
node where it is configured.  Section 2.6 of the addressing arch says:

    Anycast addresses are allocated from the unicast address space, using
    any of the defined unicast address formats.  Thus, anycast addresses
    are syntactically indistinguishable from unicast addresses.  When a
    unicast address is assigned to more than one interface, thus turning
    it into an anycast address, the nodes to which the address is
    assigned must be explicitly configured to know that it is an anycast
    address.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 6 Apr 2005 15:09:40 -0700

> effectively prohibit the use of anycast as a service distribution 

Why was this prohibition was put into the specification? 

            jak

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Apr 2005 09:50:16 +1000

> Why was this prohibition was put into the specification? 

	The prohibition was put in as we didn't know how to do anycast
	correctly for all cases.  How to do the route injection etc.

	For single packet transactions (one packet each way) as long as
	you don't source the first packet from a anycast address there
	is no problems with sending the reply from the anycast address.
	DNS/UDP falls into this space.

	For sessions bigger than this there are going to be issues that
	need to be examined and maybe addressed.

	e.g.
	* per pack load balancing which causes traffic to go to different
	anycast nodes.
	* routing table changes which change the anycast node.
 
	DNS/TCP w/ anycast assumes the first of these to be almost
	non-exisitant and the second to be a non-issue as the
	sessions have short life times.  Again this is with the
	server on the anycast address and the client on the unicast
	address.

	Note the important thing here is that the session (not
	packet) originated from a unicast address.  Replying with
	unicast source address is reasonable in some/all cirumstances.

	I suspect that the one of the bigger issues will be PPLB
	which may require routing protocols to be able to tag
	prefixes as containing anycast addresses to turn off
	non-parrallel path PPLB. This tag may or may not need to
	be exported across AS boundaries.

	Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Apr 2005 17:10:34 -0700

To be honest, I can't imagine a routing protocol that does anything 
similar to prefix aggregation carrying tags around for individual /32 
or /128 addresses. And while it is conceptually possible to do 
per-packet load balancing, very few routers are actually configured 
that way, because the end station guys complain about the extra packet 
copy load it introduces in TCP. Generally speaking, the source and 
destination addresses in a packet are hashed, the hash reduced using a 
modulus or similar function, and the result used as an index into the 
next hop list in the multipath route. This is done explicitly to limit 
the TCP packet copy issues by reducing the amount of reordering that 
happens in the network. It's legal, but "legal" doesn't make it a good 
thing.

The real issue is temporal. "What is the probability that routing could 
change during the time this address is in use".

Note that none of this about packets going from the anycast server to 
the session originator, which would be the concern that would lead one 
to look hard at packets that had an anycast address as a source. It has 
to do with packets going from the session originator to two different 
nodes offering the anycast service - routing to the anycast address, 
routing changing, choice of server by the network...

What you're cautioning against is the use of an anycast service by an 
originator, not the use of an anycast address as a source.

Do you have any concerns that relate to using an anycast address as the 
*source*?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Apr 2005 11:36:28 +1000

> or /128 addresses.

	It wouldn't have to be for a /32.  Take the root servers for
	example.  Tagging the /24 they each live in would be sufficient.
	Similarly for IPv6.

> And while it is conceptually possible to do 

	We've pointed this out everytime someone complains about F being
	anycast.  The problem is that they still argue that this is a
	issue.  It would be nice to have a come back other that "no one
	does this in practice except to demonstrate that it can be done."
 
> originator, not the use of an anycast address as a source.

	Yes.

> Do you have any concerns that relate to using an anycast address as the 

	The classic session problem is when you have a DNS server
	cluster (behind a single router) and it is a slave and the
	masters are only configured to accept transfer requests
	from the anycast address.  Lets say that it gets interesting
	to say the least especially when the router adds the transport
	and / or ports into the mix.

	The UDP refresh query will only work for one instance.  The
	AXFR (over TCP) may only work for another instance (depends
	upon how the router identifies a flow).	The the NOTIFY message
	goes to a instance for which the refresh and/AXFR fails.

	Wide area anycast makes this even more interesting.

	No, I am not talking about F here.  F uses a unicast address
	and TSIG for zone transfers / refresh queries.

	Getting back to unicast initiated sessions I would still
	like to see some mechanism (as low in the stack as possible)
	which would allow long running session to survive routing
	changes.  But if we can't just removing the restrictions
	and documenting the problems would be sufficient.  Lots of
	protocols can cope or can be made to cope as long as short
	term sessions work.

	e.g.
	* HTTP can redirect.
	* DNS could return a unicast address as a EDNS option to queries
	  to the anycast address.
	
	Mark

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Apr 2005 19:37:34 -0700

On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote:

> 	changes.

You're speaking in this thread. Did you take a look at the proposal 
that Eric Nordmark, I, and the grow folks have discussed about a 
care-of-address that would give a long term fixed address to the server 
in question? Answering that question is where we started out.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Apr 2005 13:19:51 +1000

> in question? Answering that question is where we started out.

	care-of-address would be overkill for somethings and
	quite a reasonable solution for others.  If it could be
	made selectable on a per/socket basis (I havn't looked
	at how implemetation do this at present) I suspect this
	will meet most of what would be required.

	In other words we would not want to do this for DNS/UDP but
	for DNS/TCP it would be acceptable even though it would only
	be really required for long running AXFR's (multi-megabyte).

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Apr 2005 21:33:12 -0700

OK, so then lets go back to the question posed in the thread. The 
current spec says that one should never use an anycast address as a 
source address under any circumstances. That clearly flies in the face 
of present practice, isn't responsiv to the set of concerns you raised 
about anycast in general, and can be mitigated if anycast is use for 
rendesvous. The suggestion was made that under a defined set of 
circumstances (single message each way exchange, rendezvous, perhaps 
some others) and with a defined set of procedures it would be OK to use 
it as a source address. Those procedures need to spell out the whys and 
wherefores.

Would you be willing to see the 100% ban removed from the draft 
standard and substitute text to the effect of that above included, with 
follow-up work in grow-or-wherever to spell out those procedures?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Apr 2005 14:50:05 +1000

> follow-up work in grow-or-wherever to spell out those procedures?

	Definitely yes.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Apr 2005 09:00:59 -0700

I agree.

            jak

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "Fred Baker" <[email-masked]>
Cc: "Brian Haberman" <[email-masked]>; "James Kempf"
<[email-masked]>; "Margaret Wasserman" <[email-masked]>;
"Bob Hinden" <[email-masked]>; "IPv6 WG" <[email-masked]>; "Joe Abley"
<[email-masked]>
Sent: Wednesday, April 06, 2005 9:50 PM
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 08 Apr 2005 16:41:26 -0700

Brian Haberman wrote:

> This change will allow users to operate IPv6 anycast services in the same

If we do this, shouldn't we also list the issues one needs to cope with?

For instance, when anycast is used as a source address, ICMP errors 
might no longer be delivered to the sender (they might be delivered to 
some other host that uses the same anycast address). This means that 
ICMP path mtu discovery might not work. As a result, I think it would 
make sense to say that when an anycast address is used as source 
address, the sender SHOULD limit the IPv6 packets to 1280 bytes.

It might also make sense to note that the lack of ICMP errors means that 
debugging tools like ping and traceroute might not work when an anycast 
address is used as source address.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 08 Apr 2005 16:52:50 -0700

> Why was this prohibition was put into the specification? 

My recollection was that it was a combination of issues.
1. ICMP and pmtu discovery not working, means you can't use it as a
    source
2. We don't have a protocol that allow hosts to tell the routers which
    anycast addresses they want to receive
3. TCP and higher level protocols might be confused when things change
    due to routing changes

The "rebuttals" to those could be
1. Add text to say "SHOULD limit packets with an anycast source to 1280
    bytes". Add note that ICMP-based tools don't work with an anycast
    source address.
2. Any IGP (RIPng, OSPF, etc) can be used for this. (There was also some
    work to extend MLD to do this). But this really isn't a need to
    architecturally prohibit hosts from being anycast receivers; if/when
    there is a protocol by which they can advertise things, they should
    be able to use anycasts.
3. From the IPv6 WG we can point out that this is an issue, but leave it
    to some other WG to solve (whether it is solved by a protocol
    mechanisms, or operational constraints such as not using TCP with
    anycast, or ensuring that routing stays stable enough)

   Erik

---

From: Rob Austein <[email-masked]>
Date: Fri, 08 Apr 2005 22:01:43 -0400

>     bytes". Add note that ICMP-based tools don't work with an anycast

Unless, of course, the application protocol in question happens to be
one of those for which, after all these years of trying to relegate IP
fragmentation to the dustbin of history, we still have no better
transport protocol than UDP without path MTU discovery, and if that
means that we have to send fragments, so be it, we send fragments.

Yes, there are such protocols, and yes, at least one of them is being
used today with anycast source addresses.

It's not that fragmented UDP without path MTU discovery is good.  It's
just that sometimes all the other alternatives are even worse.

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 10 Apr 2005 23:10:57 -0700

> means that we have to send fragments, so be it, we send fragments.

That's ok, as long as no packet is larger than 1280 bytes i.e. that the 
sender fragments to 1280 bytes instead of, say, 1500.

> just that sometimes all the other alternatives are even worse.

Sounds like my suggestion above needs to be clarified in that it doesn't 
prohibit fragmentation. Sending at 1280 bytes is the IPv6 way to run 
without path MTU discovery i.e. the logical counterpart of not setting 
DF in IPv4.

    Erik

---

From: Rob Austein <[email-masked]>
Date: Mon, 11 Apr 2005 03:05:02 -0400

At Sun, 10 Apr 2005 23:10:57 -0700, Erik Nordmark wrote:
> prohibit fragmentation.

Yep.

Probably best just to say that we don't know how to do Path MTU
discovery with anycast source address and point to the text in other
specs that explain how to handle that (eg, RFC 2460 section 5).

---

From: Brian Haberman <[email-masked]>
Date: Mon, 11 Apr 2005 10:02:57 -0400

Hi Erik,

On Apr 8, 2005, at 19:41, Erik Nordmark wrote:

> It might also make sense to note that the lack of ICMP errors means 
> that debugging tools like ping and traceroute might not work when an 
> anycast address is used as source address.
>

I tend to think that it is worthwhile to list some of these issues in 
the spec.  These
are not intuitive problems that people will recognize without some 
guidance.

Regards,
Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Apr 2005 14:13:34 -0700

Hi,

[Document author hat on]

Interesting discussion.  Sorry for not responding to this thread, but I 
have been dealing with a family matter and wasn't staying current with email.

I think there is general agreement that we can relax the anycast rules 
specified the address architecture.  The relevant text from Section 2.6 is 
currently:

    There is little experience with widespread, arbitrary use of Internet
    anycast addresses, and some known complications and hazards when
    using them in their full generality [ANYCST].  Until more experience
    has been gained and solutions are specified, the following
    restrictions are imposed on IPv6 anycast addresses:

The intent of this text was to not prohibit their usage for all time, but 
to wait until there was more experience and the usage was specified.  This 
may well be now.

I agree with the discussion that we shouldn't relax the rules without some 
additional text that summarizes the issues.  The cases where we think it is 
good to use anycast are specific and we still want to limit general usage.

Here is a proposal (rough) based loosely on Fred Baker's proposal and 
subsequent discussion on the list:

    Arbitrary use of Internet anycast addresses is not recommended.  There
    are known complications and hazards when using them in their full
    generality [ANYCST].  Specific usage guidelines are:

       1) Anycast may be used for simple query response applications
          (for example DNS) where all nodes serving the anycast
          address will respond with the same information and the packets
          are limited in size so path mtu discovery is not needed.

       2) Anycast may be used for applications where anycast is used to
          rendezvous with a server and subsequently learn a stable unicast
          address for further communication.

       3) Except as described in 1) and 2) above an anycast address must
          not be used as the source address of an IPv6 packet.

       4) Except as described in 1) and 2) an anycast address must not be
          assigned to an IPv6 host, that is, it may be assigned to an IPv6
          router only.

Comments and suggestions welcome.

Another approach is to write a separate document that relaxes the rules and 
describes the issues in more depth than we might want to add here.  This 
would keep the current limits in the address architecture (going forward to 
Draft standard) and have the new document start at Proposed standard.

Comments?

Bob

---

From: Rob Austein <[email-masked]>
Date: Wed, 13 Apr 2005 21:06:29 -0400

>     generality [ANYCST].  Specific usage guidelines are:

Ok so far, although "arbitrary" is in the eye of the beholder....

>           are limited in size so path mtu discovery is not needed.

Not quite right.  DNS packets might be big enough to need
fragmentation.  But there isn't any useful way to do path MTU
discovery in DNS/UDP anyway (very high client/server ratio, idempotent
lookup protocal, and the big packets are the responses going from the
server to the client, so the overhead of performing PMTU discovery and
keeping the necessary state on the server almost certainly outweighs
cost of just performing the query again when fragments get dropped).

So the criteria here are:

a) Short-lived session (typically two packet UDP exchange, but some
   argue that even a fast 7 packet TCP exchange is ok, so long as it's
   fast);

b) Path MTU either not needed or not useful for reasons having nothing
   to do with use of anycast.

>           address for further communication.

Ok.

>           not be used as the source address of an IPv6 packet.

Too strong.  I'd be ok with "should not".

>           assigned to an IPv6 host, that is, it may be assigned to an IPv6

I realize that this is just continuation of a fine old IPv6 tradition,
but it has never made any sense to me.  What's so special about
routers in this context?  Why is it ok when a router does it but not
when a host does it?  As near as I can tell, the real historical
answer to this is that, once upon a time, somebody thought that router
discovery might use anycast, back before the current RA protocol.

If there's a strong technical justification for treating routers and
hosts differently here, please make it (here and in the text), but
absent such a justification I'd urge dropping point (4) entirely.

> Draft standard) and have the new document start at Proposed standard.

I'd rather just fix the current doc and let the ongoing work happen in
GROW.  If the GROW work results in enough IPv6-specific stuff that
there's a need for a new IPv6 WG document, fine, but so far I am not
seeing it.  Anycast is mostly an IP issue, not an IPv6 or IPv4 issue.

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Apr 2005 23:19:32 -0400

Hi Bob,

> Comments and suggestions welcome.

I think the issue of when it is appropriate to use anycast addresses is 
not going to be reasonably summarised in five paragraphs, and I caution 
against attempting to do so. By way of illustration, the document 
draft-ietf-grow-anycast-00 runs to 20 pages. (That draft could use 
improvements, but it doesn't contain 19 pages of filler :-)

Might it be better to simply note that anycast is not a 
universally-appropriate technique for service distribution, and that 
caution is required? From some vantage points the text you proposed 
doesn't actually say much more than that (since most services can be 
described as "simple query response applications" when deconstructed). 
If details are required, a reference to the grow document would provide 
better guidance to the reader.

Specific points raised by the text above include:

1. There are services distributed using anycast in IPv4 which 
deliberately provide different information from different nodes, in 
order to provide topologically-sensitive service. It is not clear that 
this is unreasonable, or should be prohibited in IPv6, as your 
suggested item (1) above does.

2. There are examples of "simple query response applications" that 
perform very badly when distributed using anycast, including the DNS. 
The suitability of anycast lies both in the nature of the protocols 
concerned and also the nature of the network across which the service 
is being distributed.

Joe

---

From: Rob Austein <[email-masked]>
Date: Wed, 13 Apr 2005 23:32:35 -0400

Upon further analysis....I agree with Joe.  I was trying to meet Bob
halfway, but upon reflection have concluded that I was wrong to do so.

Anycast is complicated, and the complications are not specific to
IPv6.  It really would be doing the world a favor if the IPv6 WG were
to get rid of the language in the IPv6 address architecture doc that
places IPv6-specific restrictions on anycast, then let the GROW WG
handle the general anycast problem.

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Apr 2005 23:38:33 -0400

>    argue that even a fast 7 packet TCP exchange is ok, so long as it's

For the record, I know of people who have distributed video streaming 
services and ftp servers using anycast, with attendant long-held, 
million-packet TCP sessions, and who have done so very successfully. 
POP3 and SMTP services have been anycast in real, live ISPs' production 
networks for a long time (I know of an example that dates back at least 
10 years).

As I noted in my reply to Bob, the nature of the protocol is not the 
final discriminator here -- it's the protocol *and* the network *and* 
the distribution of nodes, and a comprehensive treatment (such as might 
be expected if MUST NOTs are showing up in the text) is not going to 
fit in this draft.

>> Draft standard) and have the new document start at Proposed standard.

Such a draft already exists in the form of 
draft-jabley-v6-anycast-clarify, which tersely defers most commentary 
to the grow draft. If there is a use for that draft, then perhaps it 
lies in being able to include a normative reference to the grow draft 
without holding the v6 architecture document too long in the RFC 
editor's queue (waiting for the grow document to be WGLCd and 
published).

> [...] Anycast is mostly an IP issue, not an IPv6 or IPv4 issue.

That is my view, too, which is why I keep trying to illustrate this v6 
discussion with examples of v4 anycast deployment.

Joe

---

From: Brian Haberman <[email-masked]>
Date: Thu, 14 Apr 2005 09:32:47 -0400

Hi Rob,

> handle the general anycast problem.

If I read this correctly, you would like to see the two rules on anycast
in the addressing architecture completely removed rather than relaxed.

I can see the benefit of having the anycast functionality defined in
one common place.

Regards,
Brian

---

From: Rob Austein <[email-masked]>
Date: Thu, 14 Apr 2005 11:50:06 -0400

> in the addressing architecture completely removed rather than relaxed.

Correct.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 14 Apr 2005 10:33:45 -0700

Rob,

>handle the general anycast problem.

OK, I think this makes sense.

The proposal is then to remove the following text from the end of Section 
2.6 the document:

This would mean we would not try to describe the general issues with 
anycast usage in the document.  I agree this makes sense because the issues 
are not specific to IPv6, there is now a body of experience with anycast 
usage, and the GROW working group is working in this area.

Is everyone else OK with this proposed change?

Bob

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Apr 2005 17:47:59 -0400

On 14 Apr 2005, at 13:33, Bob Hinden wrote:

> The proposal is then to remove the following text from the end of 
> Section 2.6 the document:
>
> anycast usage in the document.  I agree this makes sense because the 
> issues are not specific to IPv6, there is now a body of experience 
> with anycast usage, and the GROW working group is working in this 
> area.
>

For the record, I am OK with this change (it's what I proposed to the 
IESG when we kicked off this thread, so I presume that's obvious, but 
just to be clear).

Joe

---

From: Rob Austein <[email-masked]>
Date: Sun, 17 Apr 2005 16:31:57 -0400

At Thu, 14 Apr 2005 10:33:45 -0700, Bob Hinden wrote:
> ...

For the record, I agree with this change.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Apr 2005 23:28:37 +0900

(Sorry for the long delay for this thread.  I've been off-list for a
vacation.)

>>>>> On Thu, 14 Apr 2005 10:33:45 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

      [...]

> Is everyone else OK with this proposed change?

I generally agree with the change, but I'm afraid a fresh reader of
this RFC-to-be will wonder about the removal, comparing to RFC3315.
So it would be nice to provide at least a pointer to relevant
discussion/drafts.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Fri, 22 Apr 2005 00:24:19 -0700

Jinmei,

>So it would be nice to provide at least a pointer to relevant

Good point.

I will add an entry will be added to "APPENDIX B: Changes from RFC-3513" 
that the restrictions on anycast usage were removed because there is now 
sufficient usage experience, the issues are not specific to IPv6, and that 
the GROW working group is working in this area.

Thanks,
Bob

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 24 Apr 2005 10:48:18 +0900

>>>>> On Fri, 22 Apr 2005 00:24:19 -0700, 

> the GROW working group is working in this area.

This looks reasonable to me.

					JINMEI, Tatuya