Hi David, Responding to Yakov in the "Long term clean-slate only for the RRG?" thread, you wrote, in part:
>> (c) could one benefit with only a partial deployment, > > I suppose it depends on what you mean by partial deployment. One can > imagine scenarios where you have incremental deployment amongst > cooperating ISPs, but one of the hardest problems to solve is how you > have asymmetrical deployment (that is, where an end/user site has > migrated to the new system and wants to communicate with an end/user > site that hasn't yet migrated). In principle, this problem was solved a year ago. "Partial deployment" is going to be the case pretty much forever. We may never reach the stage where every single network has its own ITRs. In order for a map-encap system to be attractive enough to be widely deployed, it needs to be highly attractive to the very first adopter, and the second etc. - without depending at all on how many networks have ITRs. I used to think this independence of benefits from the level of adoption was called "incrementally deployable", but I found that this term is generally recognised to mean something much less stringent. I tried to define my thoughts about a proposal needing to provide solid benefits, no matter how few networks have so far adopted it: http://psg.com/lists/rrg/2008/msg00957.html LISP with Proxy Tunnel Routers (PTRs) and Ivip with its OITRDs (Open ITRs in the DFZ) both solve the problem. APT can do it too, although if there are multiple APT islands, there are some tricky restrictions about end-user networks having to stick to the one Island for their ETRs if their space is within the one BGP-advertised prefix: http://psg.com/lists/rrg/2008/msg00734.html I should add this question how to handle packets sent by hosts in networks without ITRs to the list of distinctions between the map-encap schemes at: http://www.firstpr.com.au/ip/ivip/comp/ PTRs (according to my potentially faulty understanding of LISP) and OITRDs both do the same job - they are both ITRs in the DFZ. There are typically many of them, all over the Net, and each advertises one or more prefixes in the DFZ. Within that prefix, all the addresses are EID addresses (LISP) or micronet addresses (Ivip). The PTR or OITRD is an ITR and encapsulates those packets, tunneling them to the correct ETR. There are several things which need to be achieved before this can be done scalably. Firstly, these PTRs or OITRDs need to scattered around the Net, close enough to the non-upgraded networks that the total path from the non-upgraded network, to the PTR/OITRD, and then to the ETR of the destination host is not excessively long. Secondly, these PTRs and OITRDs need to be able to cope with whatever traffic levels they encounter - otherwise packets will be lost. Thirdly, PTRs and OITRDs will not be a scalable approach to "partial deployment" unless each prefix they advertise serves the needs of many end-user networks. If each end-user network had, for instance, one EID (micronet) prefix, and each of these required a single BGP-advertised prefix (Mapped Address Block - MAB - in Ivip) so PTRs (OITRDs) would get the packets, then there would be no scalability advantage (no reduction in the total number of BGP advertised prefixes) compared to the end-user networks not using map-encap, but using ordinary BGP-managed PI prefixes as they do today. Ivip includes as part of its design the intention that MABs generally be quite large, and contain the micronets of many (potentially tens or hundreds of thousands) of end-user networks. So by each MAB burdening the BGP system with a single advertised prefix, each MAB can provide the space for tens to hundreds of thousands of micronets to serve the needs of similarly large numbers of end-user networks. There also needs to be a business case for building and running these PTRs or OITRDs. This depends a lot on how the address space is managed, the commercial arrangements of obtaining an EID prefix or micronet etc. This in turn depends on many factors I won't list fully here, but which include the extent that end-user networks obtain their EID (micronet) space from someone else, or whether they convert their current PI space into LISP (Ivip) managed space. Also, consider four end-user networks with separate PI space in a contiguous block of address space, which could all be advertised as a single prefix in BGP. With LISP and Ivip (and I guess APT), the four currently advertised prefixes could be replaced by a single BGP-advertised prefix for the purpose of getting the packets to the nearest PTR (OITRD). This reduction in the number of BGP-advertised prefixes makes it scalable - but involves the four networks having a joint arrangement for running the PTRs or OITRDs. (This could easily be sub-contracted out, and in Ivip, would naturally be done as part of a paid-for service by the organisation which manages the mapping for the micronets in this MAB.) In principle, every PTR or OITRD could advertise every MAB, so there would effectively be one unified system of PTRs or OITRDs for the whole Net. However, this is not necessary - there could be multiple such systems, each system handling one or more advertised prefixes. I wrote about the business case for Ivip's OITRDs in April: http://psg.com/lists/rrg/2008/msg01158.html Around that time there was some discussion (I wasn't involved) about the business case for deploying LISP PTRs. I recall that no such business case had yet been developed. - 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
