I am replying to Noel and to Luigi (from the "Re: The death John McCarthy - LISP, HIP & GSE" thread - since this discussion does not concern John McCarthy). I argue that LISP does not create a new namespace - so it is not a Loc-ID Separation protocol. Hi Luigi, You wrote: > My only point, may be cynical, certainly arguable, is that I do not > see LISP rename happening. OK - I was discussing arguments for why it should happen. > Now please stop sending around mail with the message "Luigi thinks > that LISP is *the* loc/id separation protocol". I figure you are aware that GSE, HIP, ILNP and others are locator-identifier separation protocols. My point was that by using the full name of the LISP protocol preceded by "the", as you did in: http://www.ietf.org/mail-archive/web/ietf/current/msg70182.html > Like Jari and others I do not see the name as disrespectful and > it is unrealistic to believe that the loc/ID separation protocol > can be renamed. It has been around for more than 5 years it is just > too late. > > On the other hand, the name can be considered an homage by itself. without any qualification, your words could quite reasonably be interpreted as referring to (I wrote "seems that you are both asserting and assuming") the LISP protocol as if it was not only a locator-identifier separation protocol, but the only such protocol. With the LISP protocol's current name, it seems that we have four choices when referring it: 1 - "LISP". This is also a name of the programming language. Some people are confused and/or upset by this usage. (msg70213) 2 - "LISP protocol". I am using this from now on. 3 - "The loc/ID separation protocol" or some variation, such as "The locator-identifier separation protocol", as you did. It is natural to prepend "the" to this - even if you don't mean to imply that the LISP protocol is the only such protocol. Without qualifications, this could reasonably be interpreted as implying that the LISP protocol firstly is a locator-separation protocol and secondly that it is either the only such protocol, or the only one worth mentioning. 4 - Option 2 or 3 with some qualifications such as: (it is not actually a locator-identifier separation protocol) or (it is not the only locator-identifier separation protocol) Options 1 and 3 cause confusion and upset. Option 3 is very common. Google reports ~33,500 pages use the phrase: "The Locator Identifier Separation Protocol" though these numbers are not to be taken too seriously, and some of these instances don't involve "the". Many of these, with "the", are written by LISP protocol developers. Its my impression that very few, if any, of these include a qualification that the LISP protocol is not the only such protocol. Option 2 is brief, but not a proper solution. Even if LISP people assiduously referred to "LISP protocol", many other people would refer to it simply as "LISP". Option 4 is unwieldy. Changing the name to something which can't easily be mistaken for something else in the IT field would eliminate the need to append "protocol", and avoid further upset and confusion for LISP programming language people. Its not just me (who might be discounted as a class of 2007 newbie troublemaker) who argues that the LISP protocol is not a locator-identifier separation protocol. Brian Carpenter (msg70160) and some other people with much longer experience than me argue this too. Hi Noel, You wrote: >>> And no, none of the LISP advocates have ever claimed that LISP was the >>> only Locator Identifier Separation proposal or protocol. > >> I think the claim is also implicit in the title of this draft: >> >> Locator/ID Separation Protocol (LISP) >> >> which has remained unchanged > > Wow. So, according to your reasoning, RFC-1050/1057 ("RPC: Remote Procedure > Call Protocol specification") is (or claims to be) the only remote procedure > call protocol. Who knew? Maybe so. Both these note that they refer to Sun's RPC, so there's no implication in the document as a whole that they concern the only RPC protocol. Unfortunately, as noted above, the current full name for the LISP protocol is often prepended with "the", which does carry this implication. "The RPC protocol" appears in many documents, including RFC-1831/5531, but this is shorthand for the particular RPC protocol which has previously been identified. draft-farinacci-lisp-12 refers to a variety of documents regarding earlier work on Loc-ID Separation protocols, the first of which is your document, from 1999 I think: http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt My understanding of this is that you were proposing genuine a new namespace for identifiers, so this is indeed work on Loc-ID Separation protocols. One option you contemplated was "to reinterpret the IPv4 address as an EID". This does not involve a new namespace. This is how the LISP protocol, Ivip and IRON work - so these protocols do not in fact separate create a separate namespaces for Identifiers. If you created a protocol with a new ID namespace using 32 bit integers, you would be creating a system where a particular value such as 76.54.32.10 means one thing in the IPv4 IP address namespace, and something else in the new ID namespace. This is not what happens when you "to reinterpret the IPv4 address as an EID". This is not how LISP, Ivip or IRON works. Another reference in draft-farinacci-lisp-12 is to: RFC-1498 On the Naming and Binding of Network Destinations (Originally written in 1982) which I think is a foundation document (or the foundation document) in the Loc-ID Separation field, though it doesn't use such terms or propose an actual protocol. SHIM6 and HIP are cited as well, as "host-based solutions" and GSE as a "router based solution", though my understanding is that implementing GSE now would also require alterations to the IPv6 stack and to all applications. SHIM6 doesn't involve a new namespace, so I do not consider it to be a Loc-ID Separation protocol. HIP and GSE do. Also cited is draft-meyer-loc-id-implications-01 but I didn't see any additional references there to other Loc-ID Separation protocols. Hosts using LISP-mapped IP addresses (EIDs) do not treat these IP addresses differently from the current arrangements. Unless a host does a mapping lookup, it can't tell whether the LISP system classifies an IP address as an EID or not. The IP address is within either the IPv4 or the IPv6 namespace, in which certain sub-sections are reserved to be used as independent private network namespaces. LISP's operation doesn't concern those sub-sections. It only concerns the subset of the IPv4 range of 32 bit values which are global unicast addresses, and likewise for the IPv6 range of 128 bit values. (Ivip and IRON are the same in this respect.) LISP involves no new namespace. (Likewise Ivip and IRON.) 76.54.32.10 interpreted as an IPv4 IP address always means the same thing - it refers either to a physical host which responds to this global unicast IP address, or in the case of anycast, to multiple such physical hosts all of which receive packets addressed to this IP address. (This is a simplified explanation, since it assumes there is a host on the IP address - and each such host could respond to other IP addresses as well.) An ITR, ETR or other elements of the LISP system may draw a distinction between whether this 76.54.32.10 IP address is within an EID prefix (meaning it is mapped in LISP, and the packet with 76.54.32.10 in its destination field should be tunnelled to the ETR for the matching EID prefix) or whether it is not in an EID prefix, in which case such a packet should be forwarded normally. But the subset of the global unicast address range which is treated as "EID" is not a new namespace - because the meaning of an IP address which is classified as an EID is still interpreted according to the same algorithm as is used for IP addresses which are not classified as EIDs: the one algorithm which applies to the entire global unicast address namespace. (The IPv4 global unicast address space is a separate namespace from the IPv6 global unicast address space.) The same is true of Ivip and IRON, with different terminology. Can you argue why LISP involves a new namespace, or any other reason why LISP should be regarded as a Locator-Identifier Separation protocol? - Robin More on namespaces: http://www.firstpr.com.au/ip/ivip/namespace/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf