Thank you, Robin, for provoking the presentation of my proposal. It follows inline.
On Wednesday 23 June 2010 at 16:51:33 Robin Whittle sent: > Hi Toni, > > In "Re: [rrg] "Overloading" of Loc & ID functions – Another world is > possible." you wrote: > > > 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. > > but this makes no concrete sense to me. I used "hosts" meaning "nodes". I will hereafter use "node(s)" with a preference for the new proposal. > Locator / Identifier Separation means packets have separate fields > for these, all the way from sending host to receiving host. Or have different options in the header. > Therefore, the hosts are doing different protocols from what they do > today. Sure. But the basic ideas that are known to be sustaining will be inherited. > Can you give a detailed account of how you propose to have hosts send > and receive packets which have separate Identifiers and Locators for > source and destination, without the delays inherent in looking up > Locators? A look-up needs to be done once per stateful session. Thereafter nodes inform each other of any locator changes. Node ID system: Imagine a DNS-like system with numbers instead of names. The IDs are FQD Number sequences. Numbers are quite less subjected to human competition than names. A domain number server knows locators of its tended nodes. A server authoritative for a (number) subdomain is also a tended node in its parent domain. The add-on with regard to the renown DNS is that not only servers know locators of tended nodes, but also nodes know locators of their tending servers. Upon (initial) configuration a node gets an identifier from an ID server and thereafter informs the server about changes of its locators. So here's how the initial resolution/outreach is done: A node knows the ID of a remote node (from the DNS). The node dispatches an initial packet for the remote node with destination ID and source ID & locator. The packet is sent to the source node's ID server using a known locator. The server performs longest match of the destination ID, first with its own ID. If the matching part is shorter (than the server's ID) then the packet is relayed to the parent ID domain server. When the destination ID covers the ID of the server and there is a remaining part, the destination ID is compared to the IDs of the server's tended nodes/subdomains. And then the packet is relayed to the matched tended node or subdomain server. Generally, this longest-ID-match & relay approach leads to finding & reaching the destination node initially. I call this inicast. > Then, for your concrete example, why do you argue that hosts should > do this extra work, rather than new elements in the routing system > such as ITRs, as in LISP, Ivip or (by some other name) IRON? No extra work. Nodes will use locators for packet outreach and IDs for session maintenance. The routing system will consist of path selection facilities that make use of locators. The node ID system will consist of ID distribution/matching servers. > Does your concrete proposal involve new application protocols, or can > existing protocols work with IP addresses, with the stack somehow > implementing whatever is required so the application can assume that > an IP address is both an Identifier and Locator? For this separate uses of IDs and locators new application protocols or amendments of exiting ones are needed. > This involves > ensuring that a packet is never received by a host which does not > have the Identity implied by the application's destination IP address. Yes, an important feature. Destination identifier. > Does your proposal provide a facility similar to today's anycast and > to round-robin DNS, where one DNS name resolves to multiple IP > addresses, meaning multiple hosts or sets of anycast hosts? Anycasting is a matter of naming and recognition of service types. It is not about naming nodes or their location. Service type naming is a different aspect of the architecture. A node identifier may resolve to multiple locators, which would be used in a round-robin fashion or with some preference. But those locators would be each of the same node. > How would your proposal handle multihoming and mobility? Every "home" of a node may supply it with a locator. Locators may come and go. Sessions are maintained with identifiers. > Is there any RRG proposed architecture which matches or resembles > your plan? Matching – no. Resembling – I guess no. Others are welcome to match. > If your plan doesn't alter host protocols, then I guess you must be > advocating an entirely network based solution, such as LISP, Ivip or > IRON. In these, the hosts have no separate notion of Locator and > Identity in their communications - just as is the case today - so it > is wrong to refer to this as Loc/ID Separation. > > Also, how would your analysis of the goals and proposed architectures > differ from mine?: > > http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html I have not read all the writings there. Maybe in the course of this discussion I could answer. Or you could help me do so. > > - Robin > Toni _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
