<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<p>Definitions of <b>Single point of failure</b> on the Web:</p>
<ul class="std" type="disc">
<li>A Single Point of Failure, (SPOF), is a part of a system
which, if it fails, will stop the entire system from working .
They are undesirable in any system whose goal is high
availability, be it a network, software application or other
industrial system.<br>
<a
href="http://www.google.com/url?q=http://en.wikipedia.org/wiki/Single_point_of_failure&sa=X&ei=OWqGTfOuNZS8sAPSzuDrAQ&ved=0CAoQpAMoAA&usg=AFQjCNEABaeh-qWQHTC-ZySQnvMr6BPCNg"><font
color="#008000">en.wikipedia.org/wiki/Single_point_of_failure</font></a></li>
<li>a component in a device, or a point in a network, that, if it
were to fail would cause the entire device or network to fail;
normally eliminated by adding redundancy<br>
<a
href="http://www.google.com/url?q=http://en.wiktionary.org/wiki/single_point_of_failure&sa=X&ei=OWqGTfOuNZS8sAPSzuDrAQ&ved=0CAsQpAMoAQ&usg=AFQjCNHajRjFjzDRivFwMLoCXHkwG_d4BQ"><font
color="#008000">en.wiktionary.org/wiki/single_point_of_failure</font></a></li>
<li>An element of a system for which no redundancy exists. A
failure of such a component may disable the entire system.<br>
<a
href="http://www.google.com/url?q=http://www.businessrecords.com/resources-21/glossary-112/&sa=X&ei=OWqGTfOuNZS8sAPSzuDrAQ&ved=0CAwQpAMoAg&usg=AFQjCNE9F4iQJ_AtGiauTx_4M4_zFIpHxQ"><font
color="#008000">www.businessrecords.com/resources-21/glossary-112/</font></a></li>
</ul>
<br>
<br>
On 3/20/2011 4:03 PM, Bill Woodcock wrote:
<blockquote cite="mid:544F9D95-5F48-48D7-9E76-E2A30153D03E@pch.net"
type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mar 20, 2011, at 12:21 PM, Jim Reid wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Extra complexity in server configuration
</pre>
</blockquote>
</blockquote>
<br>
This depends on particular implementation choices and is not
inherent to anycast itself.<br>
<br>
For example, I can set up a network segment at a location (Location
A) addressed as 192.0.2.0/24 and place a server on this segment with
an address of 192.0.2.10 (Server A). Server A has a single IP
address and is configured with the exact same complexity as a
unicast server.<br>
<br>
I can also set up a network segment at another location (Location B)
addressed as 192.0.2.0/24 and place a server on this segment with an
address of 192.0.2.10 (Server B). Server B has a single IP address
and is configured with the exact same complexity as a unicast
server.<br>
<br>
Now, Server A and Server B service the anycast address 192.0.2.10
from Location A and Location B with no extra complexity in server
configuration.<br>
<br>
In any case, complexity isn't a SPoF per se.<br>
<br>
If the claim is that some admin could accidentally misconfigure a
server, then unicast is much more susceptible to this. If an
anycast server is 'broken' then that anycast address is only 'down'
for a particular region. If a unicast server is 'broken' then that
unicast address is 'down' for the entire internet. <br>
<br>
Unicast, as opposed to anycast, has a designed in SPoF - i.e. one
server on one address. This SPoF can be mitigated, to some degree,
by having additional servers that can service the unicast address
with a failover mechanism to make that happen, but this requires
adding in the complexity to the unicast configuration that you refer
to above.<br>
<br>
<blockquote cite="mid:544F9D95-5F48-48D7-9E76-E2A30153D03E@pch.net"
type="cite">
<blockquote type="cite">
<pre wrap="">More complicated systems & network management (procedures)
More complicated monitoring arrangements
More elaborate network operations and support (procedures)
</pre>
</blockquote>
<pre wrap="">Aren't all of these differences dependent on the number of servers, rather than whether they're anycast or unicast? I'd argue, actually, that these are all valid arguments against large unicast server networks, that hold _less_ true of similarly-sized anycast networks. After all, unicast servers each have to be uniquely configured and have unique routing and be managed, to some degree, individually. None of that is true of anycast server clouds.
I think you're just arguing against having multiple servers, not against anycast.
</pre>
</blockquote>
<br>
Agreed, these are merely arguments against complexity (i.e. multiple
servers). <br>
<br>
Also, none of these are SPoFs inherent to anycast.<br>
<br>
<blockquote cite="mid:544F9D95-5F48-48D7-9E76-E2A30153D03E@pch.net"
type="cite">
<blockquote type="cite">
<pre wrap="">Extra complexity in router setups
"Special" filtering/peering treatment for anycast ASNs and prefixes
</pre>
</blockquote>
<pre wrap="">I disagree with these two. Routers don't need special configuration to deal with anycast, because they don't know the difference between anycast and unicast. Therefore, no additional complexity on that front, nor any special treatment.
</pre>
</blockquote>
<br>
Agreed, the routers of the world don't know the difference between
anycast and unicast routes. There is nothing on a route as it
exists in the DFZ that signals that a prefix is anycast or unicast.<br>
<br>
The routers under the control of an anycast service provider could
have knowledge of and provide different treatment to anycast
prefixes, but this is a particular implementation decision and is
not inherent to anycast itself. Anycast requires nothing more than
the exact same routing that is used to guide traffic to a unicast
address.<br>
<br>
<br>
<blockquote cite="mid:544F9D95-5F48-48D7-9E76-E2A30153D03E@pch.net"
type="cite">
<pre wrap=""> -Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
iEYEARECAAYFAk2GXYEACgkQGvQy4xTRsBHI3QCgmQRXZoi+A5f+wsEU7QfrTzXr
DzYAnA7bLM/T2ss9mbOlpJ9qxswzAeRB
=eTmI
-----END PGP SIGNATURE-----
_______________________________________________
dns-operations mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a>
<a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
-___________________________________
David Miller
Tiggee LLC
<a class="moz-txt-link-abbreviated" href="mailto:dmiller@tiggee.com">dmiller@tiggee.com</a></pre>
</body>
</html>