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 [EMAIL PROTECTED] 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
