As noted in a recent message ("Agenda") there is an item "Mapping
Model Discussion" for discussion on Tuesday:http://www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaPhily I am not sure what this discussion will entail. Perhaps it will be theoretical discussion of different ways of getting the mapping data where it is needed, without pushing it everywhere - whilst avoiding discussion of current proposals. In case it is a discussion about push, pull, hybrids etc. here is some stuff which might be of interest - my analysis of the mapping distribution aspects of the major proposals. - Robin LISP-NERD Pure push. The entire mapping database is pushed, relatively slowly, to every ITR. ITRs do this by initiating downloads of files from some servers, such as by using HTTP. (NERD also contemplates a hybrid of push and pull, where some likely to be frequently used parts of the mapping database are downloaded - pushed - and others are not. This means that for some EIDs the ITR is a full database ITR and for others it is a caching ITR, relying on some query server system, such as ALT or CONS. But if at least some ITRs can get the full database, why not make them, or servers near them into query servers, so nearby partly caching ITRs can query them? See: http://psg.com/lists/rrg/2008/msg00176.html.) Major strengths: No delay of packets. Major critique: Lots of mapping data to push and store at every ITR. Also NERD's "push" system is not very fast or efficient. For instance unless there is some other elaboration, a hundred ITRs in one are of the Net will each be doing independent downloads, rather than using some nearby staging point where the data is fanned out, or getting the data one from another. LISP-ALT Pure pull. All ITRs are caching ITRs and use a global network to send queries (typically in the form of traffic packets which will be delivered to the correct ETR) to the authoritative query servers, which are typically ETRs. Major strengths: Can scale to any number of EIDs without any extra burden on ITRs. Major critiques: Initial packets will frequently be delayed due to the time it takes to look up the mapping or to deliver the packet (much the same thing) over the global ALT network. Furthermore, unless there is some elaboration, the path through the ALT network's routers will not be optimised for geography, and could involve many long trips back and forth around the world. TRRP Pure pull - but with two incomplete "notify" techniques All ITRs are caching ITRs and use DNS to look up mapping. So this is another global query server system. The two approaches to pushing an alert about updated mapping are incomplete. One involves sending messages to the querier, but the querier may not be reachable, especially if the query went via a caching DNS server. The other involves the ITR signalling unreachability of the destination, which may prompt the ITR to do a fresh mapping request. Also, there is an initial packet delivery system (waypoint routers) which may not scale well. See: messages 450, 475 etc. Major strengths: Like ALT, can cope with arbitrary numbers of EIDs/micronets without any extra burden on ITRs. Major critiques: Slowness of query server network due to global nature and need for two lookups, at least. Resolvable by converting the whole DNS server system into locally replicated server farms which answer the query directly. This somewhat resembles the hybrid push-pull nature of APT or Ivip. See message 497. APT Hybrid push-pull (slow push) with local notify Full mapping database (for the APT island) pushed to all Default Mappers (DMs) which are full database ITRs and full database query servers. Push is relatively slow, via BGP flooding. The rest of the ITRs are caching ITRs and get their mapping quickly from a DM, by sending a traffic packet to the DM, which also tunnels it to the correct ETR. DM can notify ITRs of changed mapping. Major strengths: Most ITRs can be cheaper caching ITRs, but the get mapping quickly and reliably, without delaying packet delivery, thanks to the local nature of the query servers they rely on. Greatly reduces the number of places the full mapping database needs to be pushed to, compared to NERD's full push. Major critiques: Since there is no unified global mapping system the APT system starts off as individual islands, which can't support end-user networks properly if those networks use longer prefixes than the /24 which is the practical limit in today's IPv4 network. See messages 472, 485-87 etc. (To be continued.) Slow rate of push compared to NERD or Ivip. Ivip Hybrid push-pull (fast push) with local notify. Fast push to full database ITRs and query servers, located wherever operators want them. Unified but decentralised global push system enables charging per mapping change, which is difficult or impossible to achieve with BGP, and could be tricky to implement with APT. Beyond the full database ITRs and query servers, ITRs are caching - including caching ITRs in sending hosts. ITRs query the local full database query servers directly, or via one or more levels of caching query server. Query servers notify recent queriers of mapping changes, using UDP packets, and expect acknowledgement. Notify message carries the new mapping information - it is not just cache invalidation. Notify is secured by using the nonce from the initial query. Major benefits: Like APT, but with greater flexibility, enables operators to choose how far to push the full database into their networks. Good support for micronets down to /32. The fast (~5 second) nature of the push system means the mapping can be simple, only a single ETR address. End-users do their own multihoming monitoring and make their own decisions about service restoration, so the system is modular rather than monolithic. Also, as a result of the single ETR mapping data, less mapping to store and simpler functionality for ITRs and ETRs, which don't need to do reachability stuff. Fast push also enables the system to be used for IPv4 and IPv6 mobility with generally optimal path lengths, no upgrades for correspondent hosts and few for the mobile hosts. See Ivip-summary.pdf for full list of benefits of fast push. Major critiques: No explicit TE function in the ITR, so user has to do it by splitting traffic over multiple micronets, and mapping each micronet to different ETRs. Most folks seem to think fast push is difficult or impossible, and are wary of any system which pushes the full database anywhere. But it looks feasible to me - and there have been no detailed critiques of the db-fast-push ID at: http://www.firstpr.com.au/ip/ivip/ -- 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
