I will discuss my limited understanding of these two new facets of LISP with respect to IPv4. I also criticise LISP for being over-complex - and contrast it with Ivip's simpler approach, which is predicated on the idea that it will be practical and desirable to rapidly distribute mapping data on a global scale.
I understand that LISP-ALT (AKA LAT = LISP Alternate Topology): http://tools.ietf.org/html/draft-fuller-lisp-alt-01 is a short-term (for deployment, or just for research) alternative to LISP-CONS and LISP-NERD. A new set of "LISP-ALT routers" is created, forming an overlay network using GRE. These LISP-ALT routers form a network using the same IPv4 address space, but this is a different, separate network from the global Internet. This network runs its own BGP system with a separate ASN number space, completely unrelated to the current BGP and ASN numbering systems. The connectivity patterns of these LISP-ALT routers is somehow determined by address structure, rather than physical proximity as it is in the current Internet. ETRs are the authoritative source of mapping information. (I don't understand how this would work, especially with respect to redundancy and the fact that ETRs may be cut off from the rest of the Net.) I understand that the purpose of the LISP-ALT network is to: 1 - Enable an ITR to send a packet it has no mapping for into the LAT network, which will tunnel it to the correct ETR - with the ETR returning mapping information which the ITR will cache. 2 - Enable the ITR to request mapping information. 3 - Something else in the 3 paragraphs after the "5" heading - to do with pushing mapping data to ITRs which want it. There is also something in 5.2 (3.) about LISP-ALT routers acting as a "proxy-ITR to "support non-LISP sites". I understand this is to handle packets sent from networks without any LISP upgrades - specifically, without an ITR. As I have written recently (mssg 529), I don't see how any such scheme can work unless the prefixes in which EIDs are found are advertised in ordinary BGP - which is at odds with the original conception of LISP. There are so many options within this proposal, and so few examples, I can't clearly understand it. However, I see there is no mention of how to cope with MTU, PMTUD etc. problems and that there is no discussion of why anyone would want to build this network. As with the other LISP proposals (unless they adopt an "anycast ITRs in the core" approach, as perhaps they might - see message 529) it is not obvious how packets from non-upgraded networks can get to a "proxy-ITR" so they can be tunneled to the correct ETR. Since the number of separate micronets (see mssgs 533 & 535) and therefore ETRs is likely to grow to vastly higher than the ~240k prefixes of the current BGP system, it is not clear to me why BGP is a good choice to cope with this larger number in the LISP-ALT overlay network. (I understand this new network has some simplifications which might help.) If the final desired result is LISP-CONS or LISP-NERD, I don't see the point of creating some other architecture in the meantime. It is not clear how research with a temporary architecture can help much with designing the final one, which is fundamentally different. Overall, I think the LISP proposals (not so much NERD) are hard to understand, with terse, conceptual descriptions with many options and not enough examples. While Ivip has quite a few elements, the description is fulsome and the architecture can be used flexibly. This is different from having a variety of principles which can be combined in various combinations, as in LISP, to create fundamentally different architectures. I am surprised that Ivip remains the only proposal which aims for fast distribution of mapping data to query servers and ITRDs all over the world. Bandwidth, RAM and CPU power are cheap and getting cheaper. So I don't think the future architecture of the Net should be constrained by over-complex architectures which have only modest aims regarding mobility and rapid delivery of packets - as if the designers are scared by the apparent impossibility of doing what Ivip aims to achieve. I think part of the reason people are overly wary of data rates for mapping updates is that the current BGP system is so awful at propagating it. This is a distributed system in which intentionally dumb routers compare notes with their immediate neighbours - and in time, often with fits and starts, the proper information eventually propagates to all corners of the Net. ("Proper information" is whatever messages each router needs to make a good-enough decision on where to forward packets addressed to each prefix.) I think it will be practical to create a fresh architecture and a fancy, fast, mapping data distribution system for what we all seem to agree will soon be needed: a global network of ITRs and ETRs which enables the main BGP system to keep on working without massive bloat in the number of advertised prefixes. LISP-EMACS ("EID-mappings Multicast Across Cooperating Systems for LISP"): http://tools.ietf.org/html/draft-curran-lisp-emacs-00 does not seem to be tied to LISP-ALT, but shares with it the concept of a global overlay network of routers, using GRE, with its own BGP system. In this case, the overlay network supports multicast, using Bidirectional Protocol Independent Multicast (BIDIR-PIM): http://tools.ietf.org/html/rfc5015 which is an extension of Protocol Independent Multicast - Sparse Mode (PIM-SM): http://tools.ietf.org/html/rfc4601 The idea is that an ITR which has no mapping for a particular EID sends the traffic packet to this EMACS multicast system, which quickly sends it to the ETR which has the authoritative mapping (and I guess which is also the ETR which is supposed to handle the packet - though it makes no sense to me to have mapping authority vested in such far flung ETRs which are at risk of being unreachable) . . . and that ETR sends back a message to the ITR with the mapping information. Therefore, the LISP-EMACS system is intended only to handle a low volume of packets, such as the first one or few packets which an ITR handles, before it gets the mapping information. This seems somewhat nifty to me, but there are some scaling problems - and I think it is a lot of trouble to set up a whole global network like this, with BGP, ASNs etc. The problem LISP-EMACS attempts to solve - dropped packets when an ITR has no mapping information - does not exist for Ivip, because a caching ITR (ITRC) can always let a packet go if it has no mapping for its destination address, knowing the packet will naturally flow to an ITRD, including one outside the current network. LISP-NERD has all its ITRs being full database ITRDs, so I think LISP-EMACS is not applicable to LISP-NERD. I don't understand how LISP and APT work together, but APT has full database default mappers in each ISP network - so I don't think an LISP-EMACS-like system is needed with eFIT-APT. LISP-EMACS does not solve the primary problem of LISP: that that packets from non-upgraded networks will never find their way to the EID addressed destination host, since (in the original conception) the EID addresses are not part of any conventional BGP advertised prefix. (See http://psg.com/lists/rrg/2007/msg00529.html for possible extensions to CONS and NERD to maintain BGP advertisements for prefixes containing EID addresses.) While I don't feel motivated to fully understand LISP-EMACS (or LISP-ALT - what is the long-term value of it?) I do want to raise a fundamental scaling / DoS problem. The ITR gets the 32 bits of destination address and chops off the least significant 16 bits. This results in 16 bits 0.0 to 223.255 = 57,344 possibilities. These 16 bits form the multicast address to which the packet will be sent. For instance, the packet is addressed to 44.55.66.77 and the ITR multicasts it (to use the ID's example) to 238.1.44.55. Every ITR which is expecting to be the tunnel endpoint for packets to any EID in 44.55/16 is expected to join the multicast group for 238.1.44.55. It is my impression that the LISP designers tend to think of end-user networks similar to those today - which I guess typically have 256, 512, 1024 etc. addresses. However, I am convinced that everyone will need IPv4 space for a long time to come, and that more and more multihomed, portable address, end-user networks will be using much smaller blocks of addresses, including 8, 4 and sometimes 1 IP addresses. Let's say that in the hypothetical LISP future, the 44.16.0.0/16 prefix is all EID space, and that there are a mixture of micronet sizes, from /20 to /30. For instance: /20 4 (1/4 of the /16) /21 8 (1/4 of the /16) /22 8 (1/8 of the /16) /23 16 (1/8 of the /16) /24 32 (1/8 of the /16) /30 2048 (1/8 of the /16) There could easily be more /30s or /32s - say: /23 32 (1/4 of the /16) /24 64 (1/4 of the /16) /28 512 (1/8 of the /16) /29 1024 (1/8 of the /16) /30 2048 (1/8 of the /16) /32 8192 (1/8 of the /16) Each multicast group could easily have to handle the ETRs of thousands of micronets - up to 10k or more. Each micronet is likely to have a different ETR. (Actually, each micronet typically has 2 or more ETRs in LISP - it is only Ivip which has a single ETR at any one time for each micronet.) There is the problem of churn in which ETRs these are - each ETR has to leave or join the appropriate multicast group as end-user networks change their set of ETRs. My main concern is the traffic amplification which this multicast system entails. This is a burden for the multicast system itself (resulting in massive amplification of a small proportion of legitimate traffic packets), but also would be a powerful amplifier for someone wishing to launch a DoS attack: Simply have a modest botnet emit single, short, packets to random or sequential addresses, and LISP-CONS ITRs (all of them caching) all over the world would dutifully forward each packet to the multicast overlay network, which would fan each packet out to a few thousand or 10k+ ETRs. By the way, it is not clear to my why nonces are unsuitable (4.9) for securing mapping replies. I think a lot of the options and complications of LISP are attempts to fix problems which are inherent in its conception, including: 1 - An overly ambitious goal of removing BPG advertisements, when I think it would be fine to keep a lid on the current number, or accept a somewhat higher number, provided we can serve the needs of many more end-user networks. 2 - An overly cautious approach to the problem of distributing mapping information around the world - either with CONS, which does not attempt it, or NERD which does it very slowly. (TRRP generally does not attempt it and eFIT-APT intends to do it very slowly indeed, over the current BPG network - which is not necessarily a consenting partner . . . ) 3 - Therefore, LISP mapping distribution is too slow to allow mapping database changes to be the means of implementing multihoming service restoration. This leads to the requirement for more complex mapping information, ITRs having to make their own decisions about which of various ETRs is the best one to tunnel packets to etc. My answer to these problems is a simpler architecture, with a simpler database, simpler mapping information (just one ETR address, nothing else) simpler ITRs and ETRs, almost no communication between ITRs and ETRs (only for PMTUD) - as long as we can devise a system for getting mapping data out to the ITRDs and QSDs in a few seconds. This will probably be less data than a single IPTV stream. I am still thinking of the best way to do this, but it doesn't seem impossible. The data rate of the updates will be dwarfed by the volume of traffic handled by routers in modest or large networks. ITRs in smaller networks would be caching ITRCs or ITFHs, and use an upstream network's QSD query servers. - Robin 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
