Re: The death John McCarthy - LISP, HIP & GSE

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(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf