Short version: I support a relatively specific, narrow, use
of the term "anycast" - where one of two or more
destination hosts may receive the packet.
I recognise "anycast" is used rather loosely -
one of those words which needs to be preceded by
someone waving a red flag and carrying a definition
for the purposes of the discussion.
Also correcting what I think are some
misunderstandings about Ivip.
Hi Bill,
I won't comment on all you wrote - just on a few points.
I grappled with the meaning of "anycast" in 2007 and 2008:
http://www.google.com/search?q=Robin+anycast+RRG+-%22rrg+Discussion+Archive%22
Initially I called the ITRs in the core "anycast ITRs in the
core/DFZ". I was convinced by one of the LISP team that this was an
incorrect use of "anycast". So I renamed them to OITRDs - "Open ITRs
in the DFZ".
I decided that the best meaning to assume for "anycast" is an address
or prefix which is advertised as in a local routing system and/or the
DFZ from multiple routers and where the packets are actually handled
by separate hosts.
So if an ISP has two border routers both advertising 12.34.56.0/24
and within that, the address 12.34.56.78 is handled by a single host,
then this is not "anycast" - it is just advertising the same route
from two or more border routers.
If there are two or more hosts responding to the same address -
12.34.56.78 - and each one has its own router advertising the
encompassing prefix, then this is a true use of "anycast". The
address 12.34.45.67 is not the name for any particular device - it is
just an address which is used by multiple destination hosts, all of
which presumably use the received packets in some consistent and
useful manner. They don't have to respond in exactly the same
manner, but they presumably exist for a common purpose and can
collectively be relied upon to perform one or more tasks.
In the case of OITRDs there are typically more than one OITRD which
advertises a given MAB (Mapped Address Block). They all tunnel
packets addressed to any given micronet (such as 12.34.56.77 to
12.34.56.80) to one ETR address. Generally, with Ivip, that will
mean one (non-anycast) ETR which will forward the packets to one
end-user network where the packets will go to one host. So I think
that OITRDs, LISP Proxy Tunnel Routers (PTRs) etc. are not inherently
a form of anycast.
I could imagine anycast being used with with Ivip - and probably in
principle with LISP, APT or TRRP:
1 - Anycast ETRs. There could be multiple physical ETRs with the
same address. So the packets are tunneled from ITRs to
whichever (typically "closer") ETR the DFZ and internal routing
system forwards the tunneled packet to.
It is a separate issue whether those multiple ETRs forward the
packets to a single destination host or to a separate host for
each ETR.
2 - Anycast hosts. There may be one ETR or there might be anycast
ETRs as above. There are two or more destination hosts with
the same address, and depending on how the one or more ETRs
link to these destination hosts, the packets may go to one
or another of them.
I am not sure what use these arrangements might be - but they may
well have uses for non-TCP, simple request and response protocols.
There may well be a role for anycast query servers in local networks
- however I think it is more likely to involve anycast or some other
zero configuration default arrangement so that ITRs can discover
their nearest Query Servers' addresses and so use one or more of
them. I may use TCP between the ITR and the Query Server, so we
can't have the Query Servers on anycast addresses.
You wrote, in part:
> 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.
Likewise, I don't think that the word "anycast" should be used to
describe multiple ITRs (internal to a network or OITRDs in the DFZ)
advertising the same MAB - since this doesn't necessarily and won't
typically result in the packets being handled by multiple destination
hosts.
> 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.
This is a description of Ivip OITRDs or LISP PTRs. However, I don't
think of it as a "transition period". I expect there will always be
some networks which don't have ITRs, and so there will always be a
need for OITRDs.
> 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.
There are various ways it could be done.
You could have a single set of widely distributed OITRDs each
advertising every MAB.
You could have one set of OITRDs advertising one or more MABs and
another set advertising others.
See: Ivip business models: fast push & OITRDs 2008-04-18
http://www.ietf.org/mail-archive/web/rrg/current/msg02100.html
> 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.
I think LISP-ALT is the only other currently developed proposal (AKA
candidate architecture) which uses a global query server system, as
does your TRRP system. TRRP is a DNS-like query server system and
LISP-ALT's is totally different - there are no servers advertised in
the Internet in any way. Each ITR is either a part of the ALT
network or it connects to a Map Resolver which is.
So AFAIK, TRRP is the only one which might use anycast as part of the
mapping system, in the form of anycast servers in the global DNS-like
query server system.
Anycast may well have a role in LISP Map Resolvers, but this is not
the same as anycast DNS-like servers as you would use in TRRP.
> 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.
I can't imagine any robust approach to TCP using anycast. The
routing system could change at any time and direct the packets to
another destination host. Unless all those hosts were in some way
linked to behave as a single system, TCP or any other protocol in
which the host stores state, would not be reliable.
> You do a map lookup on the destination. You get a prioritized list
> of of egress routers.
Ivip's mapping has no list. The mapping specifies the matching
micronet and has a single ETR address. If that ETR goes down, it is
up to the end-user network - or more likely a multihoming monitoring
company they appoint to do the work - to decide on an alternative ETR
address and to send this as a real-time mapping update, which all the
ITRs which need it will get in a few seconds.
See the new section "The actual source of mapping changes" in the
recently updated Summary and Analysis:
http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
> 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?
This is not a mistake in Ivip. It is a core part of the architecture.
It is GOOD that the end-user network can and must control the mapping
in real time. Then there is no need for multiple ETR addresses, ITRs
having to decide between them etc. Also, it modularly separates the
decision making process about where to tunnel packets (for instance
due to an outage being detected) right out of the core-edge
separation system.
LISP, APT and TRRP monolithically integrate this, because in none of
these systems do you have essentially real-time mapping distribution
- so you must provide multiple ETR addresses and add a lot of
complexity to ITRs so they can decide which ETR address to use.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
