Robin, There is a way to separate identity from location and still have hosts not care much about mapping and resolving. It is by integrating resolution and session initiation. The first packet to resolve an ID to locator has characteristics relevant to those of the first one for session start. So the two can become one and of course be handled by the routing system.
Regards Toni On Tuesday 22 June 2010 at 14:57:19 Robin Whittle sent: > Hi Ran, > > You wrote (msg06884), in part: > > > If we ignore the lack of 40 years since the initial definition > > of IP itself, I believe there is actually pretty broad consensus, > > both within this RG, and also within the routing/addressing parts > > of the IETF, that the current overloaded semantics are indeed > > the root of multiple problems. > > These are problems for today's interdomain routing system, in that it > causes scaling problems with the growth in the number of PI prefixes, > and the rate of change in how they are advertised in the DFZ. > > However, "overloading" - having the IP address perform the roles of > Identifier and Locator - is good for hosts. > > As long as hosts can rely on the routing system (local systems plus > interdomain routing system) behaving as they do today, then hosts are > saved a great deal of effort. > > In today's "overloaded" system, when a host emits a packet with > destination address NNNN, the routing system will: > > 1 - Generally deliver the packet to the one host whose IP address > is NNNN, or to one of the hosts with this address if there > are multiple such hosts (anycasting). Otherwise, the packet > will be dropped somewhere. > > 2 - Will not deliver the packet to any host which does not have > the IP address NNNN and therefore is not a host which > is the intended destination of the packet. > > So the sending host doesn't concern itself with where the destination > host is (or where the closest one of multiple anycasts hosts is). > Nor does it need to concern itself with the possibility that the > packet will be delivered to some host whose identity does not match > the destination address. > > Compared to a Core Edge Elimination = Locator / Identifier Separation > architecture such as ILNP, the current "overloaded" system puts a lot > of responsibility on the routing system and takes it off the hosts. > > Loc/ID Separation architectures (LISP is not such an architecture) > solve the scaling problem by forcing all hosts to manage separate > Identifiers and Locators, and for packets to contain these two > separate things, for both destination and source addresses. This > makes things quite easy for the routing system, so solving the > routing scaling problem. > > I believe the existing division of responsibilities is good and > should be maintained. If Loc/ID Separation was adopted, hosts would > need to do mapping lookups and other complex, delay-prone, operations > before they can send packets to a new destination. This will > generally delay the establishment of communications, since these > lookups must be done by the hosts. > > LISP, Ivip and IRON are Core Edge Separation architectures which > preserve the current "overloaded" nature of the the IP address. > > I think this is a good thing: make the routing system somewhat more > complex so it can support hosts in their current, relatively simple, > form. This will be faster (in terms of establishing initial > communications, at least with Ivip and perhaps IRON) and more > efficient (hosts not having to send and receive longer packets, or > more packets) than with any Loc/ID Separation architecture such as ILNP. > > It will also more efficient in terms of hosts not needing to maintain > any extra state or fuss around with things which the routing system > currently handles: how to get a packet to a host whose identity is NNNN. > > Since more and more hosts are going to be battery operated devices > running from potentially slow, high latency, wireless connections, it > is all the more important that we not try to change the architecture > to something like Loc/ID Separation, which further burdens these > links and hosts. > > > For my overview of what I think should happen: > > http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html > > but IRON-RANGER has changed a lot since then. I plan to write about > it soon. > > - Robin http://www.firstpr.com.au/ip/ivip/ > > > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
