Hi Yakov, In "Re: [RRG] Long term clean-slate only for the RRG?" you wrote some critical things about LISP.
I am defending the map-encap schemes - LISP, APT, my own Ivip and probably Bill Herrin's TRRP - against the negative judgements you seem to have made about LISP and perhaps about map-encap schemes in general. You wrote, quoting Dino: (Some text omitted.) >> The routing table size problem is not the only problem. > > Good. So, at least we seems to agree that we do not need LISP > to deal with the routing table size. That is not what Dino meant, I am sure. Since the map-encap schemes can be used to serve a large number of end-user networks (generally those requiring smaller amounts of space) from a single BGP advertised prefix, they certainly can reduce the DFZ routing table size for any given number of multihomed end-user networks. This remains true for many more end-user networks using the map-encap approach compared to the limited number who have so far been able to gain conventional BGP-managed PI space. I believe a map-encap scheme *should* be used to achieve this, since the bloat in the DFZ global routing table is a major cost burden on the entire Internet, shouldered initially via the providers who run the DFZ routers. There is a need to reduce this bloat, and so far, the map-encap schemes are the only potentially practical proposals for IPv4. Likewise for IPv6, except that Six/One Router (a router-based translation scheme) may be practical for IPv6. >> There are many >> enterprise sites that want to do low-cost multihoming, they want to be >> good citizens to the Internet and don't want to inject more specifics, >> and they want to control their ingress traffic flows. > > LISP is *not* going to reduce the cost of multi-homing. To the > contrary, LISP is going to make the cost of multihoming higher than > it is today. This is because deploying and operating additional > infrastructure/mechanisms to support LISP has its own (non-zero) > cost. LISP and Ivip have clearly defined methods of supporting multihoming without requiring any ITRs in the networks of the sending hosts. For Ivip, this is OITRDs (Open ITRs in the DFZ). For LISP it is Proxy Tunnel Routers (PTRs). APT and I think TRRP have their own approaches to support of packets from non-upgraded networks. However, I think APT has some problems, unless there is a single APT "island". More information on this and other distinctions between the map-encap schemes is at: http://www.firstpr.com.au/ip/ivip/comp/ Very large numbers of end-user networks - including large ones but also many who only need small amounts of space (one IPv4 address, two, four or whatever) - can be served by the one map-encap infrastructure. OITRDs and PTRs need to be placed around the world, in order that packet paths are generally short no matter where the sending host (in an unmodified network) is and where the ETR is of the end-user network. BGP, in practice, is only able to slice IPv4 space as fine as 256 address subnets. (I know this administrative, but it is unlikely to be changed in the foreseeable future.) Map-encap schemes can slice down to 1 IPv4 address. This means the cost of multihoming can be much less, since there is no need for the end-user network to obtain space from an RIR, since they only need small amounts of space in general, since they don't need to field a BGP router, or use BGP resources of their ISPs' routers and since they don't need BGP expertise. > Moreover, LISP would would place this cost not only on the enterprises > that want to do multihoming, but on other parties as well (which > would result in mis-alignment of cost relative to benefits). If you read about LISP PTRs and Ivip's OITRDs: http://www.firstpr.com.au/ip/ivip/ http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf you will see that hosts in non-upgraded networks have their packets caught in the DFZ by the nearest PTR or OITRD, and tunnelled to the correct ETR. This involves no cost or involvement at all in the sending host's network. The end-user networks therefore find all incoming packets subject to the map-encap systems multihoming, portability and TE arrangements: packets sent from networks with and without ITRs. There is no LISP home page, but there is a list of the LISP Internet Drafts at: http://www.firstpr.com.au/ip/ivip/lisp-links/ PTRs are described in: http://tools.ietf.org/html/draft-lewis-lisp-interworking-00 - Robin -- 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
