[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] LISP and IP Interworking - Anycast PTRs == Ivip
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.
> That's correct. In anycast, you can have a prefix originated from
> 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.
--
to unsubscribe send a message to rrg-request@psg.com 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