Robin, On Oct 30, 2011, at 10:45 , Robin Whittle wrote: [snip] > "you" applied only to Luigi and anyone else to appears to be happy with > referring to the LISP protocol as something like "the Locator - > Identifier Separation Protocol". > Again, this is just your interpretation and not what I meant to say. Let me clarify. My only point, may be cynical, certainly arguable, is that I do not see LISP rename happening. Now please stop sending around mail with the message "Luigi thinks that LISP is *the* loc/id separation protocol" Thanks Luigi > The "both" was not meant to include you - it applied to the two points > which followed: > > assuming that LISP is not only a Loc/ID Separation protocol, > > but "*the* Loc/ID Separation protocol". > > You wrote: > >> Speaking just for myself, I have not assumed that LISP is the only >> identifier - locator separation protocol. Apologies if something that I >> wrote mistakenly gave that impression. > >> I didn't get this impression. > >> As you know, there are several >> identifier - locator separation architectures, with very different >> designs and characteristics. It would be inappropriate to claim that >> there is just one, or that one particular definition is the only >> possible interpretation. > > OK. In the thread which I think is best titled for this discussion: > "Re: LISP is not a Loc-ID Separation protocol", I suggested that GSE, > HIP and now ILNP and lesser known RRG proposals definitely are Loc-ID > Separation protocols. > > If no-one disputes this, then I think those who support the LISP > protocol retaining its current name should argue persuasively either > that the LISP protocol operates on similar enough principles to GSE, HIP > and ILNP, or that the definition of "Loc-ID Separation" should be > expanded to include the principles by which the LISP protocol works. > > I think the first option is unsupportable and that expanding the > definition so far as to apply to the LISP protocol would render it > largely meaningless. If such a redefinition was generally agreed to, I > would continue to argue against it, since it would also apply to Ivip. > The most fundamental principles of LISP, Ivip and IRON are similar - and > I argue that they are entirely different to, contrary to, and > incompatible with the principles on which GSE, HIP and ILNP operate. > > >> Indeed, the very definition of "identity" could range from something >> that looks very much just like another address (LISP, Mobile IP, >> HBA-based SHIM6) to new identifier concepts (HIP, CGAs) or even to >> DNS names. > > I think DNS could be regarded as a Locator - Identifier Separation > protocol. However, it doesn't seem helpful to group it with GSE, HIP or > ILNP, since these three apply to "every host-to-host communication". > DNS is not required for host-to-host communications, but it can be used > to choose which host IP address(es) to communicate with. > > With the LISP protocol the hosts deal with IP addresses which embody > both the ID and Loc functions, just as IPv4 and IPv6 works today. I > think the same is true at the application level and perhaps the stack > level, depending on which form of Mobile IP is used. > > My initial impression of the IPv6-only Hash Based Addressing RFC-5535 is > that these 128 bit values function identically to today's IP addresses > as far as the host stack and the routing system. They do not embody any > purely ID functionality - so there must be some separate arrangement, > implemented by applications and presumably suitable support in the > stack, to work with a multi-homed host (so with multiple HBA addresses) > on the basis of an Identifier which is presumably not an IP address. > The most obvious way of doing this would be to use the host's DNS name > as its Identifier. However, for this to be used for all communication, > I think the responding host, receiving a packet from some novel IP > address, would need to do some kind of reverse lookup in order to obtain > a DNS name, and then another lookup of that to get > locators, from which to choose from when sending its response. > Otherwise, the recipient host must respond directly to the original > packet's source IP address, without knowing for sure that this can be > used as a locator for the host whose DNS or other form of Identifier is > presumably in the application-level part of the original packet. > > So my initial impression of HBA is that it could be used to support a > Locator - Identifier Separation protocol, with suitable application and > stack changes, if the Identifier namespace was to be other than the DNS > namespace, or if responding hosts were also expected to find all the > Locators of a multi-homed originating host before replying. > > As far as I know, everyone agrees that HIP is a Locator - Identifier > Separation protocol. I understand that HBA is a particular way of using > CGA. As far as I know, CGA and/or HBA are examples of the sorts of > mechanisms you could use in building a complete Locator - Identifier > protocol, but which do not in themselves constitute a complete such > protocol with the aim as GSE, HIP and ILNP: to apply to "every > host-to-host communication". > > I recall a difficulty with ILNP and I guess GSE and HIP not being able > to use their own multihoming protocol for the necessary mapping lookups > - so by "every host-to-host communication" I mean all application and > stack-level communications other than these lookups which are intrinsic > to the Loc-ID Separation protocol itself. > > - Robin > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf