Subject: W.G. Last Call on "An analysis of IPv6 anycast"

From: Bob Hinden <[email-masked]>
Date: Fri, 24 Aug 2001 14:19:26 -0700

This is a IPng working group last call for comments on advancing the 
following document as an Informational RFC:

	Title		: An analysis of IPv6 anycast
	Author(s)	: J. Hagino et al.
	Filename	: draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt
	Pages		: 10
	Date		: 16-Jul-01

Please send substantive comments to the ipng mailing list, and minor
editorial comments to the author.  This last call period will end two
week from today on September 7, 2001.

Bob Hinden / Steve Deering

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Randy Bush <[email-masked]>
Date: Fri, 24 Aug 2001 14:30:34 -0700

> There are two kind of "anycast" proposed and operated for IPv4 - One is
> RFC1546 [Partridge, 1993] anycast.  Another is what we call "BGP anycast"
> in this document; this is for replicating unicast servers by BGP trick.
> We concentrate into the former in this document.

as it is used for dns etc. *within* a single provider, it can be an igp
which is used, not bgp.

randy

---

From: Pekka Savola <[email-masked]>
Date: Sat, 25 Aug 2001 12:21:42 +0300 (EEST)

> as it is used for dns etc. *within* a single provider, it can be an igp

Yeah.  I think "routing trick" anycast like with IPv4 is a much simpler
approach, and actually _works_ rather well (as there is no constraint the
address must not be used as a source).

6to4 relay, isatap router, shipworm server, ...  All of these use the IPv4
anycast mechanism, and will often be more commonplace in IGP rather than
BGP for non-technical reasons (you often don't want to provide service
outside your domain for free).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 27 Aug 2001 21:41:37 +0900

>as it is used for dns etc. *within* a single provider, it can be an igp

	i see, but are there such practice exist?  how do they cope
	with server failures and IGP flaps?

itojun

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 Aug 2001 05:32:06 +0800

> i see, but are there such practice exist?

only for the large providers and for over five years.

> how do they cope with server failures and IGP flaps?

inject into igp.

randy

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 28 Aug 2001 08:59:13 +0900

>> how do they cope with server failures and IGP flaps?

	what i was asking is, what happens when:
	- IGP route is not stable at this point (*)
	- someone try to establish TCP to the (IGP) anycast address
	- first packet goes to server A, and second goes to server B

	(*) may mean that the provider is in unstable state:-)

	anyway, the technique is just for short-lived transaction, just as
	stated in the draft.

itojun

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 Aug 2001 08:05:14 +0800

> 	- first packet goes to server A, and second goes to server B

much talk and fud about this.  in practice, this does not seem to be
a problem.  e.g. some years back, we did a two hour streaming videocast
to over 100k users, 200mb of traffic, from a dozen anycast servers.
not one noc call.

not that i would advise running nuclear weapons on long-lived tcp to
anycast.  but we don't need to prevent people using what they use today.

randy

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 28 Aug 2001 12:21:48 +0200

> 	with server failures and IGP flaps?

Same problem as for BGP anycast, I guess.

Regards,
	-is

---

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Aug 2001 08:50:52 -0400

> a problem.

It is clear that there is a *potential* for trouble. If one controls
the environment sufficiently, uses protocols that are relatively
robust to network failures, one can make it work. Even work quite well
it would seem. That is fine and we should acknowledge this.

But it is also not helpful to just assert "it works in practice"
without acknowledging that there are real dangers when used
inappropriately. i.e., the "it" needs to be qualified, as not all
"its" will work equally well.

> e.g. some years back, we did a two hour streaming videocast to over
> 100k users, 200mb of traffic, from a dozen anycast servers.  not one
> noc call.

If the metric of "it works" is defined by "how many calls to the NOC",
we're in pretty bad shape. My experience in calling various NOCs is
that it is a waste of time. Only bother when things are totally broken
and they haven't fixed themselves after a prolonged period of
time. I.e., call the NOC only after exhausting all other
alternatives. YMMV.

Thomas

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 Aug 2001 07:46:57 +0800

> It is clear that there is a *potential* for trouble.

yup.  and there is a potential for an earthquake.  as an engineer, i deal
with the pragmatic realities i face, and don't make american-style laws
to prevent my self from being in a tall building in case there is an
earthquake.

> If one controls the environment sufficiently, uses protocols that are
> relatively robust to network failures, one can make it work. Even work
> quite well it would seem. That is fine and we should acknowledge this.

and not prevent it, thank you.

> "its" will work equally well.

sure.  as many weasel words as folk need, within reason.  but don't code
against it in routers, hosts, ...

randy