Hi Christian, I agree that with the strictly aggregated model of ALT (as best I understand it) the end-user would need to connect their ETRs (actually, the ETRs probably belong to the one, two or more ISPs the end-user connects to the Net through) via a GRE tunnel to a particular ALT router which is at the lowest level of the hierarchy. That ALT router is is presumably operated by whoever is responsible for the address space of which the end-user's EID is a subset.
That router would be located somewhere, probably not anywhere near the ISPs currently chosen by the end-user, since end-users are able to use any ISP in the world. This does imply a direct "provider-dependence", in terms of physical LISP-ALT communications via the GRE tunnels, which are essential to the system operating correctly. Alternatively, invoking ALT's potential for meshiness, the first ALT router might be a local one, not owned by whoever provides the address space. That ALT router would be more likely to be operated by the ISP which the end-user chose for Net connectivity. End-users are not bound to any particular ISP. Every administrative arrangement I can think of for managing the new type of address space of a map-encap scheme (EID for LISP) involves some kind of dependence on the organisation who somehow provides the larger block of address space from which the end-user's space is a subset. This assumes that the end-user gets their EID or micronet addresses from some other organisation, implicitly a "provider", who also provides such address space to many other end-users. I use the term "Mapped Address Block" (MAB) to denote each range of addresses, advertised in BGP as a prefix, which is devoted to Ivip mapping. A "provider" is the organisation who has been assigned this address space by an RIR (unless of course the provider is an RIR). If an end-user already had their own PI space today, with its own BGP advertised prefix, made that a part of LISP or Ivip, and then mapped the whole thing as a single EID/micronet, then the end user is acting as their own "provider". There is no direct reduction in the number of BGP advertised prefixes - so this is not how I think LISP or Ivip should generally be used. I wrote about provider dependencies for Ivip on 2007-11-14: Ivip end-users' dependencies http://psg.com/lists/rrg/2007/msg00536.html The end-user does depend on the organisation which provides the address space. The most obvious dependency is that the organisation accept the end-user's commands about changing the mapping of their micronets and makes sure this is sent to all the ITRDs and QSDs in the Net. The end-user can't select some other organisation to be responsible for this, since ultimately, one organisation has to cryptographically sign the packets which are sent out to the ITRDs and QSDs. Theoretically, that "organisation" could be a consortium, somehow operating a genuinely distributed system or contracting the work to a separate organisation which handled the mapping changes. Then, the end-user could change from having a commercial relationship with one member of this consortium to having it with any other member. But as long as the end-user wants to retain this address, it is dependent on the "organisation" which physically administers the mapping information for the larger address block of which the end-user's micronet is a part. Number portability has been enforced on many cell-phone and wireline POTS services around the world - despite their protests. I am not sure exactly how this is implemented, but I think it involves the call first going to the telco which originally had the number, and then to the telco which the end-user currently selects for their service. This is messy, but is feasible on the national scale of these phone networks. (The alternative is a database lookup - perhaps locally cached - of a national numbering database for every single call which is made.) The end-user is still dependent on the telco which originally had that block of numbers assigned to it, although they don't have a business relationship with them. I think we don't want such "triangle routing" in the new map-encap architecture. My idea with Ivip is that a bunch of mapping updates for a particular MAB would be contained in one or more packets, as part of a larger stream of such updates for other MABs. I intend that each such packet be signed or be in some other way verifiable as having been authorised by the organisation which is responsible for it. It would probably be prohibitively messy to redesign the system so that all the ITRs in the world could somehow get updates for each individual micronet from some other organisation. With the current plan, the packet says what MAB it applies to, and contains one or more mapping updates - with the whole thing verified in some way as having come from the one organisation which is publicly known as being responsible for this MAB. Individual signatures for each update, and the verification and security problems this would entail, sounds like more trouble than it is worth. Absolute, true, independence from any one "provider" whilst retaining a given IP address is probably too much to ask from a map-encap scheme. End-users need to choose their IP address provider with care. But the scheme enables them to use any ISP, to split their address space into as many micronets as they like, and to have each micronet use any ETR at any ISP in the world - so its a pretty good deal. - 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
