Hi Darrel, In responding to Christian Vogt, you wrote, in part:
> So are you claiming incremental deployment is not possible with > LISP? > > What if a 3rd party provides a proxy between the two systems, > then incremental deployment is possible. Then networks who > are not LISP capable can reach EIDs that are not in the global > Routing table. > > Alternatively, what if an xTR performs NAT between PA space > and EID space? > > There are some other possibilities here, but I think you are > being too harsh in your analysis. I don't understand your NAT or the "3rd party proxy" proposals in sufficient detail to evaluate them. In on-list discussions regarding LISP incremental deployability, two solutions have emerged - both of which I think are in principle the same as the "anycast ITRs in the core" idea I proposed in mid June and which became part of Ivip. There are no doubt other aspects to incremental deployability, but one problem which certainly needs to be solved is reachability from non-upgraded networks. A sending host in a network with no ITR needs to be able to successfully send a packet to a destination host with an address which is managed by the LISP/eFIT-APT/Ivip/TRRP system. The only way this is going to happen, as far as I can see, is for the destination host's address to be part of a BGP advertised prefix. Otherwise, the border router of the sending host's network will drop the packet. The addresses which Ivip manages are all part of BGP advertised prefixes. The idea is that there are one or more ITRs outside the non-upgraded networks which advertise this prefix, and the packet is forwarded to one of these, where it is tunnelled to the ETR of the destination host. Bill Herrin uses the term "micronet" to refer to the range of addresses which belongs to each end-user network. For Ivip or any other ITR-ETR scheme to provide a beneficial reduction in the number of advertised prefixes, there generally needs to be two (or ideally many more) "micronets" per advertised prefix which is managed by the scheme. In these messages: http://psg.com/lists/rrg/2007/msg00260.html http://psg.com/lists/rrg/2007/msg00264.html http://psg.com/lists/rrg/2007/msg00288.html I think it can be seen that Eliot arrived at an arrangement for LISP-NERD in August which is much the same as Ivip's "anycast ITRs in the core". In this message a few weeks ago: http://psg.com/lists/rrg/2007/msg00487.html I think Dino accepted that a similar approach would be needed for LISP-CONS to achieve reachability from sending hosts in networks without ITRs: DF >>> . . . so the only way to get packets to a LISP site from a DF >>> non-LISP site is to have the packets hit an ITR some where DF >>> on the path to the LISP site. That could be a proxy ITR that DF >>> does this. RW >> As far as I can see, the only way a "proxy ITR" could RW >> receive packets from non-upgraded networks is for the prefix RW >> these addresses are part of to be advertised in BGP. Without RW >> a BGP advertisement for the prefix in which LISP maps address RW >> space, the packets will never leave the border routers of the RW >> non-upgraded networks. DF > Right. Either we make them a very small number of prefixes (I DF > say < 100) or we don't do it. And the only alternative is then DF > to do a NAT in the ITR. I think that every end-user network with a LISP-mapped address would require continued reachability from non-upgraded networks, so the idea of limiting the number of prefixes to 100 or so makes no sense to me. I imagine that any successful ITR-ETR scheme would have hundreds to tens of thousands of address blocks, each block, on average, containing many "micronets". Dino seems to have a very firm goal with advertised prefixes - to radically reduce their number. My aims are more modest - to be happy with a similar or higher number of BGP advertised prefixes than there are at present, as long as the ITR-ETR scheme is used in a way that many more end-user networks get multihomable and portable address space than would be possible with the same number of BGP advertised prefixes without the scheme. Can you explain your "3rd party proxy" or "NAT" approaches in greater detail? The current eFIT-APT proposal does not seem to provide reachability from non-upgraded networks. Michael Meisel acknowledged this as a difficulty on 12 October: http://psg.com/lists/rrg/2007/msg00446.html RW > With eFIT-APT, there would be no benefit for early RW > adopters (no portability without grave loss of reachability RW > and TE only for packets from upgraded networks) and no RW > benefit for the whole network (removal of prefixes from the RW > BGP routing table) until virtually all networks had RW > upgraded. MM > This is one issue we will certainly be putting a lot of thought MM > into over the next couple months. Stay tuned. Bill Herrin discussed TRRP reachability from non-upgraded networks: http://psg.com/lists/rrg/2007/msg00488.html This too involves "anycast ITRs in the core" and I think address space for each end-user network (a "micronet") being part of larger blocks of address space, each of which remains advertised in BGP, for as long as there needs to be reachability from non-upgraded networks. For Ivip, this is forever. For TRRP and perhaps other systems, this may not be forever. BH > For these micronets to be reachable by networks without an BH > ITR, someone has to deploy an ITR and announce a covering BH > "route of last resort" which leads to an ITR. So, we put it BH > out for bid and one company wins. BH > BH > Why would any company bid? Because its almost free money. BH > Until ITRs are ubiquitously deployed, that company will BH > essentially have a monopoly on PI micronets. If you want BH > any real inbound bandwidth for your micronet then until TRRP BH > is ubiquitous, you'll have to pay them. BH > BH > So, they deploy the first ITR. Global scope limited to the BH > covering prefix for the micronets. BH > BH > Who's next? Who deploys the second ITR where the process BH > becomes anycast? The IPv6-only proposals Six-One and SHIM6 have no problem with "reachability from non-upgraded networks". http://psg.com/lists/rrg/2007/msg00524.html These schemes are quite different from the schemes discussed above - there are no ITRs or ETRs. They are IPv6-only, they require changes to operating systems in participating hosts, and I think that for Six-One to provide its benefits over SHIM6 (router centric multihoming management, not just host-centric), routers of participating networks need to be upgraded too. I think the major incremental deployment challenge challenge for Six-One and SHIM6 is that when an end-user deploys Six-One or SHIM6 in one host, or in multiple hosts and in their network's routers (Six-One) that they only gain benefits when the other host in the communication has also upgraded. So initially there are very modest benefits, since very few other hosts will be upgraded. This is a classic problem of incremental deployment in that there is little benefit in being an early adopter, which must be weighed against the probably significant cost and effort of upgrading. This means that while a Six-One or SHIM6 upgraded host gains multihoming benefits (not portability or support for mobility, as I think are possible and desirable with an ITR-ETR scheme such as Ivip) when communicating with upgraded hosts, those benefits do not apply to communications from other hosts. So the whole system still has to cope with lack of multihoming for some proportion (initially close to 100%) of its communications. But that is not as severe a barrier to incremental deployment as upgrading and being unable to communicate with any host in a non-upgraded network. I think a properly implemented ITR-ETR scheme such as Ivip will be able to provide these benefits absolutely 100% of the time, for communications with all hosts: Multihoming. Portable address space (apologies to those who wince at this phrase) - retain the address range and use any ISP who has an ETR. Finer divisions and so more efficient use of IPv4 space without each end-user network requiring its own BGP advertised prefix. Support for mobility (so far, only Ivip aspires to this). No changes to host operating systems, applications or most internal and BGP routers. This means multihoming and portability etc. is managed centrally - not on a host-by-host basis, as with SHIM6 and Six-One. - 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
