I suspect that our disagreement may relate to the definition of Anycast.
For example, IPv6 anycast, which as I understand it is a prefix followed
by all zero bits, and routes to any place that handles the prefix. Is
sensible, routable, scalable, and ought to be aggregateable. I have no
problem with it.
I also have no problem with the fact taht DNS names often resolve to
multiple IP addresses, any of which can be used by the client aplicaiton
to reach the entity of interest.
Where I have trouble is treating as a name for a topological location in
the net, a quantity as long as the full address (32 IPv4 bits or 128
IPv6 bits) and having that thing reachable in multiple distinct
topological locations, with no aggregation possible. While that can be
used for special purposes, it appears to me that it is a special purpose
hack, placing application / service information in the routing system,
rather than a first class service component usable at whatever scale
anyone wants to use it.
Having read the text below, given that you refer to multiple routes to a
prefix as a form of anycast, I am left confused as to what you are
arguing should be treated as a full part of the architecture.
Yours,
Joel
William Herrin wrote:
Put differently, anycast addresses are no different than, and arguably
worses than, PI addresses. A whole lot of our work is to get PI addresses
out of the core table. Getting PI out, but allowing unlimited anycast in
would not be progress.
Several of you have made comments like the above. In my head I can
almost see the rest of you behind your screens, sagely nodding your
heads in agreement that anycast shouldn't be a first-class citizen in
the architecture.
Before anyone nods his way into a mistake, I'd ask you to consider a
simple question: What might anycast look like in the various
approaches we've discussed to solving the routing problem?
Let's look at a map-encap strategy A system first. What can't it do
adequately without anycast? And how can it provide routeless anycast?
First off your non-local packets need to find an ingress router. The
more specific local routes will keep local packets away. The rest will
follow a default route to the ingress router. Or is there some other
way you'll find the ITR? Somehow force it inline with all packets
routed?
You'll no more run your network on just one ingress encoder than you'd
run it on a single DNS server or a single T1. Okay, well, some of you
will but those of you who are serious about reliability won't. No,
you'll have two or several ingress routers. And each one will ANYCAST
the default route so that if one of them fails the packets seamlessly
reroute to the other.
What about the transition period? For a while there'll be both legacy
routing and the ITR/ETR routing. How will you bridge the legacy
systems in? Well, every one of us who has come up with a strategy-A
solution has posited some sort of ITR in the core that advertises
short prefixes out to the legacy system and encodes the packets it
gets for delivery in the new system. Will we have one for all the ETRs
serving 192.0.0.0/8 and one for all the ETRs serving 193.0.0.0/8? Yeah
right. We'll have 20 geographically distributed ITRs for 192.0.0.0/4,
each of which will announce 192.0.0.0/4 via ANYCAST.
And if you plan to go out and query a distributed map database (as
more of you do now than did two years ago when I proposed it) then
you'll announce your map roots via ANYCAST too.
But that's only half the equation. Strategy A systems don't just
consume anycast routes, they provide them. And unless you do something
really bone-headed in your design, they do it in the map without
consuming slots in the routing table.
You do a map lookup on the destination. You get a prioritized list of
of egress routers. Though presumably multiple entry points into the
same system, this is no more a rule than with routes in the BGP table.
Make each egress an entrance to a different, geographically and
topologically diverse, host. The akamai-like map server dynamically
reorders the list based on its heuristic guess as to which of the
hosts are closer or further from you. Presto! You connect to the
nearest server through minor magic in the map.
Give the ingress router a mild resistance to change during relookups
and you even get anycast with a very high probability of packets
reaching the same respondent over time -- rather handy for anycast TCP
which isn't really practical in the current routing system.
Stable TCP over anycast would, by the way, be fantastic news for the
CDNs and their customers which include, oh, just about every major
content provider on the web.
Of course, you might implement strategy A badly. You can build a rigid
design where the map is static and the ingress router has no
discretion whatsoever for which egress it sends to. But none of you
made that mistake in your designs, right?
Strategy B systems alter or replace TCP with a protocol that doesn't
use the layer-3 address for its transport identity. They use a map to
find the current set of "locators." Routeless anycast here works in
much the same way as strategy A. The map is like an enhanced DNS SRV
record. Better really: not only do the endpoints know which set of
locators to try first, they know which locators match each of the
multiple hosts returned by the lookup. You're actually guaranteed to
get the same respondent for the duration of the layer-4 connection.
It's SO easy.
And, of course, anycast and unicast routes are identical in every
respect in strategy D, E and F systems since the routes on those RIBs
function identically to what we have today.
With this in mind, I propose a statement which is, on its face,
absurd. Yet each time you consider it in the coming months and years,
you'll find it makes more and more sense:
Unicast is a special case of anycast in which there is only one
destination endpoint.
Food for thought.
Regards,
Bill Herrin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
