>From the "Re: [IETF] The death John McCarthy - LISP, HIP & GSE" thread: Hi Luigi (and other LISP people), I wasn't directly discussing your opinion that the LISP protocol shouldn't have its name changed. My objection was to referring to the LISP protocol by its formal title "Locator/ID separation protocol" without any qualification, especially since you preceded it with "the" - as if LISP was the only Loc/ID Separation protocol. Do you and other LISP folks agree that GSE, HIP and ILNP are Loc-ID Separation protocols? GSE was the earliest and ILNP is based on GSE. The term was used in the title of a 1997-07-30 draft: Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 http://tools.ietf.org/html/draft-ietf-ipngwg-esd-analysis-01 Four months earlier, Version 00 included a formal definition of the Loc/ID Separation concept - with a note that the idea had been "conventional wisdom for some time": Consequently, conventional wisdom for some time has been that having separate values for location and identification could be of significant benefit. The GSE proposal attempts to make such a separation. Assuming you agree that GSE, HIP and ILNP are Locator - Identifier Separation protocols, how do you argue that LISP is as well? LISP operates on completely different principles. In this debate about whether the LISP protocol should be renamed, a vital question is whether LISP really is a Locator-Identifier Separation protocol. GSE, HIP and ILNP are. They involve new host protocols and a new namespace. All hosts use numbers (which some people do not regard as "addresses") from a new ID namespace to identify themselves for the purposes of communicating with other hosts. The routing system, including any routing functions in hosts with more than one interface, uses conventional IP addresses (Loc) to get packets to their destination. This requires a fast, secure, global mapping system so a router or host can look up an ID's one or more current Locs. According to some perspectives - which have apparently been well regarded in the IETF for 14 years or more - Loc-ID separation is desirable, elegant and supports mobility. However, I think it would be a really bad idea, even if it could be easily introduced: http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html There's no prospect of transitioning to any Loc/ID Separation system because no substantial benefits accrue until all hosts and their application programs are upgraded to the new system. As far as I can tell (and apart from unsupported assertions, no-one argued otherwise) ILNP cannot support existing applications. GSE and HIP can't. So all applications would need to be completely rewritten and all operating systems of all hosts changed to the new system before we can realise the benefits and turn off the old system. I argue that there are few, if any, benefits in the transitional period where hosts and applications have to cope with other hosts being Loc/ID capable or not (or perhaps not being able to determine this) and therefore having to support both communication systems at the same time, without getting the benefits (multihoming, mobility) of using Loc/ID Separation for all traffic. Even if Loc/ID Separation was adopted in place of the current system ("overloading" ID and Loc functions onto IP addresses, in both IPv4 and IPv6), it would be impossible to support seamless mobility suitable for VoIP, due to the time delays inherent in securely updating mapping systems and in getting all sending hosts to recognise the change, whenever the Mobile Node (MN) changes its IP (Loc) address. The most serious critique of Locator ID Separation concerns the extra work, including extra packets and delays, which hosts must engage in for any communication where that the packet to be sent must not be allowed to arrive at any host other than the one with the specified ID. Due to the security problems of information leakage, I think this probably includes most Internet communication. More on this below. LISP, Ivip and IRON operate on completely different principles to GSE, HIP and ILNP. LISP, Ivip and IRON do not involve a new host protocols (so there's no need to rewrite applications or host stacks), or a new namespace. http://www.firstpr.com.au/ip/ivip/namespace/ LISP, Ivip and IRON are changes to the routing and addressing system, which can be introduced incrementally, with full benefits of multihoming and perhaps mobility accruing to the networks which adopt it, no matter how few or how many other networks adopt the new system. I believe that the current system of "overloading" the ID and Loc functions onto a single IP addresses is a very good idea, since it reduces the workload of host operating systems and applications and reduces the delay times in establishing communications, compared to the Loc-ID Separation approach. The primary reason for this is that in the current system (or with LISP, Ivip or IRON partially or fully adopted) the routing system can be relied upon to either deliver a packet to its intended destination IP address (which operates in part as the destination host Identifier) or to drop the packet. That is to say, the current system can be relied upon not to deliver packet to any host other than the one with the packet's destination IP address. (With anycast, this can be multiple physical hosts, but that is fine.) A Loc-ID Separation architecture can't do this, so hosts need to go to a lot more trouble, looking up mapping etc. before they can send a packet to the desired host - assuming, as is commonly the case, it is important that the packet is never delivered to a host other than the desired one. This is argued in the above-mentioned message and in: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html So I am arguing against Loc-ID Separation (also known as "Core-Edge Elimination") architectures and for "Core-Edge Separation"* architectures, which includes LISP, Ivip and IRON. LISP and Ivip can use the TTR Mobility system to do glitch-free mobility of the MN's IP address(es) - as is required for VoIP. http://www.firstpr.com.au/ip/ivip/#mobile However, the LISP folks have never been interested in this. LISP's current mobility system can't support MNs behind NAT, while TTR Mobility can work with hosts behind any depth of NATs. IRON uses the principles of TTR Mobility - including for non-mobile networks. So I argue that its a good thing that LISP is not a Locator-Identity Protocol. I have many criticisms of LISP, such as the mobility arrangements, the impossibility of scaling well when each ITR is required to figure out reachability on its own, and the impossibility of building the ALT network so it is both robust against single points of failure and provides a path with minimal number of hops and minimal geographic distance. However LISP is the right kind of architecture - a Core-Edge Separation architecture - not a Locator-Identifier Split (Core-Edge Elimination) architecture. - Robin * History of scalable routing taxonomies 2010-09-07: http://www.ietf.org/mail-archive/web/rrg/current/msg07307.html http://www.ietf.org/mail-archive/web/ietf/current/msg70190.html On 29/10/2011 12:41 AM, Luigi Iannone wrote: > Hi Robin, > > Thanks, but no thanks. I do not want to be dragged in such kind of > discussion. > > I expressed my opinion, please do not attribute to me things that I > did not say or meant to say. > > Thanks > > ciao > > Luigi _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf