Subject: Re: [RRG] LISP and IP Interworking - Anycast PTRs == Ivip

From: Robin Whittle <[email-masked]>
Date: Sat, 01 Dec 2007 19:23:36 +1100

Hi Darrel,

Thanks for posting this text, which I assume will become an ID soon.

In recent months there have been various on-list references to LISP
"Proxy Tunnel Routers" for ensuring sites without ITRs can send
packets to hosts with LISP-mapped (EID) addresses.  There has also
been discussion of using "NAT" for this purpose.

Now we have a full description of these two approaches:

  http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt

Your LISP "Proxy Tunnel Router" approach is in principle, and in
most details, identical to the "Anycast ITRs in the core" idea I
posted to the RAM list over five months ago (2007-06-15).

  http://www1.ietf.org/mail-archive/web/ram/current/msg01518.html

That was within 24 hours of me thinking of the idea - which has
proven to be useful and novel - at least in terms of what is in IDs,
list messages etc.

The on-list and private responses I received in June from some LISP
folks was  unsympathetic - there was no encouragement or
constructive criticism.  I was urged - by LISP and non-LISP folks
alike - to write an ID.  A month later I produced:

  http://tools.ietf.org/html/draft-whittle-ivip-arch-00

Since then, this ID seems to have been ignored by LISP people.

There is much more to Ivip than "anycast ITRs in the core", but that
was the starting point which prompted me to develop some new ideas.

Eliot developed a similar "anycast ITRs in the core" approach for
LISP-NERD.  It seems, from the language with which he expressed his
ideas, that he developed this independently of whatever he might
have known about Ivip.  He acknowledged that his approach resembles
mine:

  http://psg.com/lists/rrg/2007/msg00260.html
  http://psg.com/lists/rrg/2007/msg00264.html
  http://psg.com/lists/rrg/2007/msg00288.html

Your new lisp-interworking-00.txt doesn't mention Ivip or my
proposal of this approach in mid-June.

There are two reasons why I think your new ID should explicitly
acknowledge the similarity between "Proxy Tunnel Routers" and Ivip -
even if you developed PTRs completely independently of anything I wrote.

Firstly, it seems I was the first to propose this arrangement in a
public document or mailing list message.

Secondly and more importantly, I believe you should assist readers
in understanding the various ITR-ETR proposals by pointing out what
goals, mechanisms and outcomes your proposal shares with other
proposals, and how it differs.

There is a whole section in the Ivip ID - over 5 pages - devoted to
showing how Ivip and LISP differ, and what they have in common.

Incremental deployability has always been a fundamental requirement
of any ITR-ETR scheme.

At the start of December, LISP finally gained a mechanism which
enables it to be incrementally deployable.  The IDs are:

http://tools.ietf.org/html/draft-farinacci-lisp-05            (43pp)
http://tools.ietf.org/html/draft-lear-lisp-nerd-02            (29pp)
http://tools.ietf.org/html/draft-meyer-lisp-cons-03           (21pp)
http://tools.ietf.org/html/draft-fuller-lisp-alt-01           (17pp)
http://tools.ietf.org/html/draft-curran-lisp-emacs-00          (9pp)
http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt(13pp)

These 132 pages are longer than Ivip's 105 - or 116 including IPTM.

Is there some kind of inverse relationship between funding and
output in this field?

ist-RiNG has lots of money.  So far it has produced no technical
documents and no discussion.

Apart from John Curran, who works for servervault.com, and Noel
Chiappa, who is is an independent researcher - as I am - LISP
authors all work for Cisco Systems.  I assume you folks at Cisco are
doing at least some of your LISP work as part of your paid
employment - yet it took you longer to create an incrementally
deployable ITR-ETR scheme than it took me. At the very least, I
assume Cisco sometimes flies you to IETF and other meetings where
you can pursue LISP work.

I don't work on Ivip or RRG correspondence in my employer's time.
I am self employed and it costs me lost income to do this stuff.
Yet my results come sooner - and I think they are easy to read and
understand.

I request anyone who is seriously interested in ITR-ETR schemes to
read the Ivip ID, Fred's sprite-mtu work, my IPTM work:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/

and the recent excellent discussion between Fred and me on this
list.  All ITR-ETR schemes need a solution for the PMTUD and
fragmentation problem.  I have read nothing substantial from the
LISP team on how to solve this.

Then, please provide critiques, alternative ideas, reports of
difficulty in understanding etc. on-list or privately.

I found your new ID generally easier to read than the earlier LISP
IDs.  The examples were particularly helpful.  However, I suggest
you use terminology indicating explicit packet flow direction rather
than "talk to" and "speaking to".

Here is a critique of LISP-NAT, based on my potentially faulty
understanding.

1 - LISP-NAT does not solve the problem which "(typically)
    Anycast ITRs in the Core" (Ivip, LISP PTR) does - the
    problem of how a host in a site with no ITR can send a
    packet to a host with a LISP-mapped address (EID) and
    have that packet delivered properly - that is, via an
    ITR which tunnels it to the correct ETR.  This problem exists
    irrespective of whether the ordinary host or the  host with
    the LISP-mapped (EID) address initiates a two-way
    communication.  The Net needs to work for single, isolated,
    packets.

    LISP-NAT only helps in a two-way communication session - and
    then only when the host with the LISP-mapped (EID) address
    initiates this session.

2 - The LISP-NAT device can only do its work for as many
    concurrently active hosts with LISP-mapped (EID)
    addresses as the device has "publicly routable" IP addresses.

    These "publicly routable" addresses are either ordinary
    addresses, for exclusive use for this LISP-NAT purpose,
    or they are a curious thing - "LISP-R" addresses.

    As I understand it, a "LISP-R" address is a LISP-mapped address
    (an EID - an address such that an ITR handling a packet
    addressed to this address would encapsulate the packet and
    tunnel it to a specific ETR close to the destination host
    which actually has this address) *and* which is also part of
    an advertised BGP prefix and reachable via ordinary BGP
    router forwarding.  This means, I think, that this address
    is not covered by PTRs which advertise the prefix which it
    is within.  This means that there are two ways a packet
    could get to the router which handles this LISP-R address.

       Firstly, it could originate in a site with a LISP ITR, which
       would tunnel the packet to the ETR (presumably the same
       router which is responsible for this address).

       Secondly, if the packet originates in a host in a site with
       no LISP ITR, it arrives by ordinary forwarding through the
       BGP router system.

    As such, the use of LISP-R address space seems to introduce
    complexities and limitations which make it unsuitable for
    robust multihoming, or portability between ISPs.

3 - Therefore, LISP-NAT provides no multihoming, portability etc.
    benefits, for the packets coming from the host in the site with
    no ITR - while "Anycast ITRs in the Core" (Ivip, LISP PTR)
    provides all these the benefits.

4 - It is not clear how long the NAT-ITR should maintain the
    association between the LISP-mapped host's address and the
    LISP-R address in the translation pool.  If there is a pause
    in activity, the communicating hosts reasonably expect to be
    able to send packets to each other in the future.  But unless
    the NAT-ITR has as many LISP-R addresses in its pool as it has
    LISP-mapped host addresses, it will have to recycle the pool
    addresses at some point in time, with the risk that a remote
    host will send a packet to a pool address which has now been
    associated with a different LISP-mapped host than the one
    it was previously communicating with.

If these criticisms are valid, I believe the ID should explicitly
convey these limitations to the reader in some way.

I thought section 2 (LISP Internetworking Models) was systematic and
well written.  However, it left me with the impression that both the
PTR and the LISP-NAT would solve the problem you identified:

     The most challenging case, case 4, occurs when a host at
     a non-LISP source site sends a packet to a host in a LISP
     site.  If the source host chooses a non-routable EID address,
     the packet continue to be forwarded (inside the domain) until
     it reaches a router which cannot forward it, at which point
     the packet is dropped.  So either the EID that the
     destination site is making available for other sites is
     routed outside of LISP or an alternate mechanisms need to be
     in place to solve this.

     This specification describes two alternate interworking
     mechanisms, Proxy Tunnel Router (PTR) (Section 5) and LISP-NAT
     (Section 6).

In fact, LISP-NAT only works in a two-way communication is initiated
by a host with a LISP-mapped address, and then only by using a
separate range of addresses which must be in an ordinary BGP prefix.

Below are some typos which I think would be good to correct.

  - Robin

Page 7

  ... on behalf LISP sites to non-LISP sites can reach ...

  ... on behalf of LISP sites so non-LISP sites can reach ...

  Rather than deploying PTRs close the LISP sites, they get
  deployed close to the non-LISP sites.

  Rather than deploying PTRs close to the LISP sites, they are
  deployed close to the non-LISP sites.

  I didn't understand the term "scoping".

Page 8

  Two instances of "140.1.1.1" should be "140.0.0.1".

  4. The PE has route to ....

  4. The PE has a route to ....

Page 9

  in order to have a course way to control ...

  in order to have a coarse way to control ...

     There are several that a network using PTRs would place the
     PTR as close as possible to non-LISP sites.

  Perhaps:

     There are several (burdens/impacts) that a network using PTRs
     would place on the PTR ....

  but then the rest of it doesn't make sense to me.

  traffic will be routed towards ... (extra newlines)

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Eliot Lear <[email-masked]>
Date: Sat, 01 Dec 2007 09:00:42 -0800

Hi Robin,

I'd just like to clarify one thing and add a general statement.

Robin Whittle wrote:
> LISP-NERD.  

This has been ascribed to me before, and either I misspoke or was
misunderstood.  I believe Dino early on recognized that anycast could be
a useful scaling mechanism for LISP.  I myself have not explored anycast
in any substantial way.  I have, however, pondered transitions, but I
have not devoted as much "ink" to transition as perhaps you and others
have.  Our early exchange you quote below refers to multiple
announcements and not anycast.
> It seems, from the language with which [Eliot] expressed his

As I said, I was told there were similarities, probably by you.  Also, I
have not been focusing on transition but longer term matters.  Although
it may appear the case by company name, we are not all at Cisco of one
mind, and sometimes our best coordination occurs at IETF, IRTF, and
similar places.  And to be fair, I do not have a full understanding of
iVIP.  Finally, please understand that with such a fast moving field,
and a -00 draft out, I think figuring out who did what first has not
been foremost on people's minds.  I personally try not to be original
about anything ;-)

All the best,

Eliot

---

From: Robin Whittle <[email-masked]>
Date: Sun, 02 Dec 2007 15:33:35 +1100

Hi Eliot,

Thanks for your reply, in which you wrote:

>> Eliot developed a similar "anycast ITRs in the core" approach 
>> for LISP-NERD.
> 
> misunderstood.  

You didn't use the term "anycast", but you wrote an alternative
approach to two proposals I made, both of which have problems, and
which I think were the only alternatives to "anycast ITRs in the
core".

   > I think I would handle this differently. Prior to withdrawing
   > 20.0.0.0/20 there should be a reasonable number of ITRs in SP
   > environments.

So far I think this is the standard LISP approach of relying on
there being enough networks with ITRs that the unreachability of
20.0.0.0/20 from networks without ITRs would somehow not be a
problem when this prefix is no longer advertised in BGP.  The
trouble is that even a few hosts in networks without ITRs is
probably a completely unacceptable problem for anyone contemplating
using this address space.

   > At that point it makes sense for those to at least locally
   > propagate a NOEXPORT route along the lines of 20.0.0.0/8.

This is not exactly anycast, but I understand it involves multiple
border routers of multiple ISPs acting as multiple ITRs and
advertising the same prefix to neighbouring ISPs - with NOEXPORT
preventing those ASes (or is it those routers?) from propagating the
route to this prefix any further.  So the neighbouring ASes which do
not yet have ITRs would have their hosts able to reach hosts in the
LISP-mapped prefix 20.0.0.0/20.  NOEXPORT ensures that those
neighbouring ISPs would not transit traffic from their neighbours to
this prefix.

Depending on AS topology and how many ASes didn't yet have ITRs,
this would marginally reduce the number of ASes in which hosts could
not send packets to 20.0.0.0/20.  So it is not a complete solution.

  > One could go further and say that it should be a 0.0.0.0/1 and
  > 128.0.0.0/1.

That would make each border router in a LISP-upgraded AS (each one
is implicitly an ITR as well) attract packets for all otherwise
unadvertised address space from its neighbouring ASes.  This would
collect all the packets from neighbouring ISPs which need to go to
an ITR, when the neighbouring ISP has no ITRs.

 > At that point you can have multiple ITRs doing this for
 > redundancy's sake, and you're doing it with very few routes.
 > Maybe 200-300 at most.

The key points you make include having multiple ITRs advertising the
same prefix.  To me, this is anycast.  However, as long as they all
advertise with NOEXPORT, maybe this isn't quite the same as
"anycast".  I don't see the purpose in limiting the range of packet
collection with NOEXPORT.

Still, it was close enough for me to regard it as "similar" to
"anycast ITRs in the core".  I wrote about this to the list because
it was at a time when no-one else involved in LISP had said anything
positive about my "anycast ITRs in the core" proposal.

> I believe Dino early on recognized that anycast 
> could be a useful scaling mechanism for LISP.  I myself have not 
> explored anycast in any substantial way.  I have, however, 
> pondered transitions, but I have not devoted as much "ink" to 
> transition as perhaps you and others have.  Our early exchange 
> you quote below refers to multiple announcements and not anycast.

I don't see how "multiple announcements" - multiple ITRs in the DFZ
advertising the same prefix is different from "anycast", as I use
the term or as it is used in the new ID:

unless your use of NOEXPORT is regarded as such as difference.

Normal BGP practice is to have one router advertising a particular
prefix.  If two or more do, I think it is reasonably described as
"anycast".  The principles are the same whether it is 2 or 20,000
routers advertising the same prefix.

>> ideas, that he developed this independently of whatever he 
>> might have known about Ivip.  He acknowledged that his approach
>>  resembles mine:
>> 
> As I said, I was told there were similarities, probably by you.

Yes - as much as I understand what you wrote, it seems to be
very similar in principle to "anycast ITRs in the core/DFZ", which
is in Ivip and draft-lewis-lisp-interworking-00.

I recognise that what you wrote was in a mailing list message rather
than an ID, but you were providing information on the possible
future direction of LISP-NERD and helping to show how it could be
incrementally deployed.

> Also, I have not been focusing on transition but longer term 
> matters.  Although it may appear the case by company name, we are
> not all at Cisco of one mind, and sometimes our best
> coordination occurs at IETF, IRTF, and similar places.  

LISP IDs are written by quite a number of people and I don't assume
you all think alike or work closely together.  The basic LISP
architecture can be used with various mapping systems.  NERD takes
the middle road in terms of speed for a push system - faster than
eFIT-APT and slower than Ivip's ambitious "few seconds" goal.  I
think push to the ITRs (and/or push to local query servers, as is
possible with Ivip and as is the basic architecture of eFIT-APT) is
better than relying on a global query system as does LISP-CONS and
TRRP.  That global query system is bound to be slow and unreliable -
and also costly and potentially complex, as is LISP-CONS or LISP-ALT.

> And to be fair, I do not have a full understanding of iVIP.

I didn't suggest you understood Ivip, or what I wrote to the RAM
list starting on 2007-06-15.  I guess you developed it independently
- though I was arguing the inevitability of "anycast ITRs in the
core" in list discussions at the time.

> Finally, please understand that with such a fast moving field,
> and a -00 draft out, I think figuring out who did what first has
> not been foremost on people's minds.  I personally try not to be
> original about anything ;-)
> 
> All the best,
> 
> Eliot

Who thought if this first and who wrote in public about it first are
minor matters compared to the importance of acknowledging that a
mechanism Y in scheme X is similar or identical to mechanism B in
scheme A.  We owe that to the readers of our IDs.

This field is difficult enough without people writing up the same
thing, as if it was a new and different approach to what has already
been publicly proposed in another scheme.

There is a strong tradition in science, engineering and the IETF of
correctly attributing the source of ideas - or at least any prior
publication of similar or identical ideas.

I do try to be original.  I come into this field with less
experience of networking than most people on this list.  That is an
obvious disadvantage - but one advantage is I see may things in a
fresh light.  There is an adage about never asking an expert to do
something which is "impossible", because they know it can't be done.

If I propose 10 things and only one of them turns out to have
long-term value, I figure this is worthwhile.

Few people seem to think it is practical to do what I intend with
Ivip - fan relatively simple mapping data out around the world to a
few hundred thousand (later millions?) ITRs in a few seconds.  I
reckon it can be done.  If not, there are plenty of other ideas in
Ivip and IPTM which I think might have long-term value.

If it can be done, then the ITR-ETR scheme can be simpler and
support mobility in efficient ways not previously dreamed of by
mobile IP people - because they never considered that something like
a global ITR scheme could be justified just for mobility.

Since we have to build a global ITR scheme, I say lets make it fast
and simple from the start.  If LISP was built, in any form, people
would soon be trying to soup it up to get the mapping data to the
ITRs faster.

  Cheers

    - Robin

---

From: Robin Whittle <[email-masked]>
Date: Sun, 02 Dec 2007 18:34:54 +1100

Hi Darrel,

Quoting my earlier message, you wrote:

>> Normal BGP practice is to have one router advertising a
>> particular prefix.  If two or more do, I think it is
>> reasonably described as "anycast".  The principles are the
>> same whether it is 2 or 20,000 routers advertising the same
>> prefix.
>
> One short point here.  You are incorrect above.  In the Internet,
> almost every prefex/aggregate is originated from more than one
> router - you'd not want an entire aggregate disappearing if a
> single router died.

Can anyone else comment on this this?  I can imagine it is done for
some prefixes, but "almost every" prefix?

> If multiple routers originate the same prefix, then the next hop
> ip address (usually the routerID/loopback of the originating
> router) is different.  This causes the BGP path selection to
> prefer/propagate one over the other.  This is normal.

Yes.

> In anycast, multiple devices are configured with the same ip
> address, nothing more.  Its quite different than having the same
> prefix announced from different sources.

I disagree with your second sentence.  AFAIK, in the context of BGP
"anycast" involves multiple routers (perhaps "many" rather than just
2 or a few) advertising the same prefix.

> Selective route announcements and anycasting are two very
> different ways to control traffic.

Google finds only 3 pages for "selective route announcements" and
none for the singular. Googling:

   "selective announcement(s)" BGP

finds about 34 pages.  I assume you mean this term to encompass
NOEXPORT though none of these pages mentions NOEXPORT.

Yes, but NOEXPORT and anycasting could be combined - as I think
Eliot did.

Eliot proposed multiple announcements, all over the Net, which I
interpreted as "anycast" - but with NOEXPORT (a selective route
announcement), which is arguably just anycast with limited
propagation.  I don't know what purpose NOEXPORT has, since it
limits the capacity of the system to provide connectivity from hosts
in non-upgraded networks.

In the ivip-arch-00 ID, I stated that Ivip's approach may be an
unusual form of anycasting:

   1.5 Anycast ITRs

   Multiple routers, usually each with an associated server,
   advertising the same prefix is known as "anycasting" [RFC1546]
   [ISC-Anycast http://www.isc.org/pubs/tn/isc-tn-2003-1.html].
   Ivip's use of multiple anycast routers may be novel: tunneling
   packets to a single tunnel endpoint, which forwards the packets
   to a single host.

With this proviso, I still think "anycast" is an appropriate term,
given that this new arrangement is reasonably similar to other
scenarios to which the term is applied.

In http://en.wikipedia.org/wiki/Anycast I find:

   On the Internet, anycast is usually implemented by using BGP to
   simultaneously announce the same destination IP address range
   from many different places on the Internet. This results in
   packets addressed to destination addresses in this range being
   routed to the "nearest" point on the net announcing the given
   destination IP address.

This uses "many", which is different from my statement about "2 or
more" - but I believe the technical principles are the same whether
2, 3 or "many" BGP routers advertise the same prefix.

RFC 1546 (1993) doesn't mention BGP.  It discusses the problems of
using a stateful protocol such as TCP with anycast, when there are
multiple destination hosts, with the packet arriving at any one of
them, according to the current state of the routing system.  This is
on the reasonable assumption that the separate destination hosts
can't coordinate their activities in order to allow TCP
communications to continue when the packets in one session are
forwarded to different destination hosts.

RFC 1546 then goes on to state:

   Stateful protocols will have to employ some additional
   mechanism to ensure that later datagrams are sent to
   the same host.  Suggestions for how to accomplish this
   for TCP are discussed below.

   After considering the two examples, it seems clear that
   the correct definition of IP anycasting is a service
   which provides a stateless best effort delivery of an
   anycast datagram to at least one host, and preferably
   only one host, which serves the anycast address.  This
   definition makes clear that anycast datagrams receive
   the same basic type of service as IP datagrams.  And
   while the definition permits delivery to multiple hosts,
   it makes clear that the goal is delivery to just one host.

I believe that in all important principles, LISP's Proxy Tunnel
Router scheme is identical to Ivip's "anycast ITRs in the core" scheme.

For instance, both schemes honour RFC 1546s preferred goal of
delivery to just one host - the destination host whose address is
mapped by Ivip or LISP.

The example in RFC 1546 involves just two hosts, X and Y,
advertising the one address.  I see no mention that the number of
advertising routers (or hosts) needs to be "many" - that is, more
than two.  RFC 3258 references RFC 1546 for its definition of anycast.

Can you point to any definition or widespread use of "anycast" which
precludes having only two, or some similarly small number, of
simultaneously advertising routers?

The semantics of anycast is a side issue to the question of how
similar or identical LISP Proxy Tunnel Routers are to Ivip's
"anycast ITRs in the core", or perhaps "anycast ITRs in the DFZ".

By the way, I don't see the "Proxy Tunnel Router" as a proxy for
anything.

> P.s. I'll make a reply to the list re: your comments on the draft
> next week when I have some more time.

OK!

  - Robin

---

From: Tony Li <[email-masked]>
Date: Sat, 1 Dec 2007 23:48:20 -0800

> some prefixes, but "almost every" prefix?

That's a tough call.  Many ISPs have a singly homed customer injected  
into IBGP from the router that terminates their circuit.  However,  
these are customer specific prefixes that generally aren't leaked  
into the DFZ.

Certainly aggregates are originated from all domain borders.

My recollection is that aggregates are still in the majority, altho  
the number of leaks for TE purposes is significant.  I think "almost  
every" is overstating things slightly.

> 2 or a few) advertising the same prefix.

That's correct.  In anycast, you can have a prefix originated from  
different routers, with different origin ASes, and different AS paths.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Sun, 02 Dec 2007 22:17:34 +1100

Hi Tony,

I intended this to be a brief response, but I found a recent BCP RFC
which is devoted to anycast service distribution.  In summary:

   I think what we are doing in Ivip and LISP-PTRs is close
   enough to "anycast" as it is generally understood, and distinct
   enough from everything else, that it is best to adapt the
   currently rather loose and informal definition of "anycast" to
   include what we are doing.

DL> In anycast, multiple devices are configured with the same ip
DL> address, nothing more.  Its quite different than having the same
DL> prefix announced from different sources.

RW> I disagree with your second sentence.  AFAIK, in the context of BGP
RW> "anycast" involves multiple routers (perhaps "many" rather than just
RW> 2 or a few) advertising the same prefix.

> different routers, with different origin ASes, and different AS paths.

In this view, which I think is helpful, the practice of multiple
ASes advertising the same prefix (necessarily from multiple routers)
distinguishes anycasting from the common practice - not normally
called "anycasting" - of one AS advertising the same prefix from
multiple routers.

So in the context of BGP in the DFZ, "anycasting" is defined as the
same prefix being advertised by routers belonging to two or more ASes.

This removes any fuss about 2, 3 or "many".

If so, then Ivip and LISP Proxy Tunnel Routers are both clearly
"anycast", since they allow (but do not mandate) that the various
ITRs (PTRs for LISP) can be run by different organisations.

I think Eliot's suggestions are the same - "anycast" - but with
NOEXPORT.  Assuming that there are one or more ASes without ITRs who
are also without immediate peering neighbours with ITRs, NOEXPORT
means that packets to LISP-mapped addresses originating from such
ASes would still be dropped at their border routers.

Googling anycast and NOEXPORT turns up our list discussions, various
low-key things and a few documents - but I didn't find anything of
interest regarding NOEXPORT together with anycast.  I found a few
things of general interest which I list after my signature.

I discovered an RFC I hadn't encountered before, previously
draft-ietf-grow-anycast from the Global Routing Operations WG:

  http://tools.ietf.org/html/rfc4786
  Operation of Anycast Services
  Best Current Practice BCP126
  December 2006

It seems to be pretty obscure, with Google only finding 72 mentions
of "RFC4786" .

  This document is addressed to network operators who are
  considering whether to deploy or operate a distributed service
  using anycast.

  ...

  To distribute a service using anycast, the service is first
  associated with a stable set of IP addresses, and
  reachability to those addresses is advertised in a routing
  system from multiple, independent service nodes.

This is not a definition of "anycast", but of how to distribute a
service using anycast - which is what RFC 4786 is purely concerned with.

Anycasting in the global Internet may currently have no other role
than distributing a service such as DNS.  Ivip and LISP-PTR give
Internet anycasting a new purpose in life, since the "service" is
packet tunneling and forwarding, according to mapping information -
quite different from the current use of generating a response to a
query.

Here are some definitions:

   Service Address:  an IP address associated with a particular
      service (e.g., the destination address used by DNS resolvers
      to reach a particular authority server).

   Anycast:  the practice of making a particular Service Address
      available in multiple, discrete, autonomous locations, such
      that datagrams sent are routed to one of several available
      locations.

Does "multiple ... autonomous locations" imply multiple ASes?

   Anycast Node:  an internally-connected collection of hosts and
      routers that together provide service for an anycast Service
      Address.  An Anycast Node might be as simple as a single host
      participating in a routing system with adjacent routers, or it
      might include a number of hosts connected in some more
      elaborate fashion; in either case, to the routing system
      across which the service is being anycast, each Anycast Node
      presents a unique path to the Service Address.  The entire
      anycast system for the service consists of two or more
      separate Anycast Nodes.

2 or more.

   ...

   Global-Scope Anycast:  reachability information for the anycast
      Service Address is propagated through a routing system in such
      a way that a particular anycast node is potentially visible to
      the whole routing system.

   Global Node:  an Anycast Node providing service using a
      Global-Scope Anycast Address.

There is no specific mention of separate ASes, but "one of several
available locations" and "two or more" seems to agree with "2 or
more", rather than requiring a larger number such as "many".

2 or more is specified in section 3.1:

   Anycast is the name given to the practice of making a Service
   Address available to a routing system at Anycast Nodes in two
   or more discrete locations.

   The service provided by each node is generally consistent
   regardless of the particular node chosen by the routing system
   to handle a particular request (although some services may
   benefit from deliberate differences in the behaviours of
   individual nodes, in order to facilitate locality-specific
   behaviour; see Section 4.6).

So if I define the "service" to be that of an ITR - tunneling
packets to the appropriate ETR, according to the mapping data for
the micronet within which the destination address of the packet
falls - then Ivip and LISP Proxy Tunnel Routers fit this definition
of "anycast".

The trouble is, so does multiple border routers in one AS, if the
service is defined as "forwarding packets to their proper
destination hosts"!

   The scale of the routing system through which a service is
   anycast can vary from a small Interior Gateway Protocol (IGP)
   connecting a small handful of components, to the Border Gateway
   Protocol (BGP) [RFC4271] connecting the global Internet,
   depending on the nature of the service distribution that is
   required.

I think what we are doing in Ivip and LISP-PTRs is close enough to
"anycast" as it is generally understood, and distinct enough from
everything else, that it is best to adapt the currently rather loose
and informal definition of "anycast" to include what we are doing.

  - Robin

  http://www.net.cmu.edu/pres/anycast/Deploying%20IP%20Anycast.ppt
  Anycast DNS for .JP.

  http://www.nanog.org/mtg-0310/pdf/miller.pdf  (2003)
  http://www.net.cmu.edu/pres/anycast/

    Anycast
      Multiple nodes configured to accept traffic on
      single IP address

      Usually, one node receives each packet

        Packet could be dropped like any other
        Preferably only one node receives packet, but no
        absolute guarantee

      The node that receives a specific packet is determined
      by routing.

   http://tools.ietf.org/html/rfc2101
   IPv4 Address Behaviour Today
   February 1997

      The concept of an anycast address is of an address that
      semantically locates any of a group of systems
      performing equivalent functions. There is no way such an
      address can be anything but a locator; it can never serve
      as an identifier as defined in this document, since it
      does not uniquely identify host.  In this case, the
      effective temporal uniqueness, or useful lifetime, of an
      IP address can be less than the time taken to establish a
      TCP connection.