Short version: Ran objects to some things I wrote about his ILNP protocol - which was chosen in preference to the LISP protocol, IRON, Ivip and many others by the IRTF Routing Research Group co-chairs as their recommended scalable routing protocol for further IETF development (RFC-6115). However, he does not mention what statements he disagrees with. He simply refers readers to a bunch of papers and some Internet Drafts at his site. Below is a list of things I wrote about ILNP and why I wrote them. Hi Ran, In the thread "Re: The death John McCarthy - LISP, HIP & GSE" you wrote: > Gentle Folks, > > Robin Whittle either hasn't read the ILNP documents > and published papers or he hasn't understood them. > His characterisation of ILNP on this list is > not correct in a wide range of dimensions. Folks > who want to learn more about ILNP might consider > starting at this web site: > <http://ilnp.cs.st-andrews.ac.uk> > > I'm not a LISP or HIP expert or spokesperson, > but I also doubt that his characterisations > of LISP or HIP are correct. > > Yours, > > Ran This is all very broad-brush, as if you are too busy to help IETF list people understand exactly which statements about ILNP you dispute. Likewise you don't help the readers by directing them to any particular documents at your site. I recall that many of your messages to the IRTF Routing Research Group list were of a similar form. In recent IETF list messages I have characterised ILNP as: 0 - A member of the Locator-Identifier Separation class of scalable routing protocols. and the following I wrote about all Loc-ID Separation protocols: 1 - They are IPv6-only. 2 - They require rewritten stacks and applications. 3 - They require hosts to send and receive more packets and do more work (than the current arrangements) in order to respond to a communication, when (as is often the case) it is important that the reply packet must go to no other host than the one which has the Identity specified as the source in the initiating packet. 4 - They can't support mobility with MNs behind NAT or handle Loc changes fast enough for VoIP. If there is something else I wrote which you object to, please write about it to the list. Likewise regarding any specific disagreements you have with what I wrote about the LISP protocol and HIP. Point 3 above is a critique of ILNP, HIP and GSE - or any other protocol which I regard as being of the "Locator-Identifier Separation" class (this does not include the LISP protocol). I argue that such protocols impose extra burdens of work, delays and extra packets going in and out of a host which responds to an incoming communication initiation in a way which requires its response not to be delivered to any host which does not have the Identity specified in the sender field of the initiating packet. That's a rather long sentence, but it means that the simple process we have with today's "Loc-ID overloaded IP address" arrangement - of responding to the initiating packet's source IP address - is something which sometimes, probably frequently, can't be done with Loc-ID Separation. If a host ABC receives a communication request with the IP address XYZ in the source field (which in today's "overloaded" arrangement acts as both a host/endpoint Identifier and routing Locator) then ABC can send a reply packet straight back to the XYZ IP address without doing any lookups, knowing that the routing system will either deliver it to the host which has this IP address (or to one of multiple hosts, in the case of anycast) - or the packet will be dropped. So ABC can craft its reply with whatever information it wants host XYZ to have, but would not want any other host to have - and send it to IP address XYZ. This is still true if, as is possible, the source address of the initiating packet is spoofed. So in the current "overloaded" arrangement, a host can respond immediately and without any lookups. With Loc-ID Separation, to achieve the same assurance, ABC would need to do a mapping lookup of the Identifier which came in the initiating packet, and send the reply to one of the resulting Locators (assuming the Identifier was for a multi-homed host, meaning there would be at least two Locators). This requires sending at least one packet to the global mapping system, which after some delay (due to its global geographic size, and due to the need for real-time non-cached responses forcing it to get a response from the one or one of a few authoritative query servers) would return a single packet of mapping information to ABC, with the Locators and some other stuff regarding which one to choose in preference to the others. (Maybe the mapping would be too long for the and would need to go in two packets - or maybe it would be sent as a long packet in IPv6, which was too long for some part of the path near ABC, and so it would be dropped with a packet-to-big response, causing the query server to send the same information again in shorter packets - assuming the query server cached its response for this purpose.) Assuming the map reply packet arrives, then ABC can proceed to send a reply to XYZ, knowing it will get to XYZ or be dropped (and therefore will not to to any host other than XYZ), by sending the packet to one of the specified Locators. If the mapping query or response packet gets lost, ABC will need to wait two or so seconds to send a second query. This is bad enough for a host in a data centre. It is much worse for a host ABC hanging off a possibly low data-rate, expensive, high-latency high packet loss mobile radio link such as 3G or whatever. So my critique of Locator-Identifier Protocols is also of one of the longest cherished wishes of quite a few IETF people, from the early 80s to this day. An early write-up of this wish is in RFC-1498, which was originally written in 1982. I wrote about this on the RRG list (2010-06-22): "Overloading" of Loc & ID functions is good for hosts and should be maintained http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html in response to something you wrote in an earlier message: RA> If we ignore the lack of 40 years since the initial definition > of IP itself, I believe there is actually pretty broad consensus, > both within this RG, and also within the routing/addressing parts > of the IETF, that the current overloaded semantics are indeed > the root of multiple problems. but you never responded. Toni Stoev replied and in messages 07022, 25, 27, 29 and 30 we discussed his proposal - but I couldn't envisage a fast, lightweight, secure way of doing it. RW> Toni hasn't yet described a secure method by which > one node can tell another it has a new Locator. > > I can't imagine how this proposal, or any other CEE > (Loc/ID Separation) architecture, such as ILNP, > could handle mobility with sufficiently short > delays and sufficiently light-weight protocols > to make it practical or attractive for VoIP. > > If a scalable routing proposal can't do mobility > with delays short enough to not disrupt conversations > with VoIP, then I think it is a non-starter. So far > I think TTR Mobility is the only approach to mobility > which can do this - and it is only for CES > architectures such as LISP, Ivip and perhaps IRON. Here are the reasons why I wrote these things about ILNP. 0 - Quoting from http://tools.ietf.org/html/draft-rja-ilnp-intro-11 "The crux of this proposal is to have different names for the identity of a node and the location of its subnet, with crisp semantics for each. This enhances the Internet Architecture by adding crisp and clear semantics for the Identifier and for the Locator, removing the semantically-muddled concept of the IP address, and updating end system protocols slightly, without requiring router changes." Throughout the document, the term "the Identifier/Locator split mode (of operation)" is used to refer to the use of ILNP. So I assume you agree with me that ILNP is a Locator-Identifier Separation (AKA "Split") protocol. 1 - ILNPv6 has a 64 bit Identifier - the lower order bits of the field currently known as the 128 bit IP address - so there's no need for a new packet format. In ILNPv4 the 32 bit IP addresses become Locators and a new packet format is required to carry 64 bit Identifiers: "The obvious two ways to carry the ILNP Identifier with ILNPv4 are either as an IPv4 Option or as an IPv6-style Extension Header placed after the IPv4 header and before the upper-layer protocol (e.g. OSPF, TCP, UDP, SCTP)." "At least some currently available IPv4 forwarding silicon is able to parse past IPv4 options to examine the upper- layer protocol header at wire-speed on reasonably fast (e.g. 1 Gbps or better) network interfaces. By contrast, no existing silicon is able to parse past a new Extension Header at all. So, for engineering reasons, ILNPv4 uses a new IPv4 Option to carry the Identifier values." HIP and GSE are applicable to IPv6 only. I argue that ILNPv4 is so impractical as not to be considered realistic, because some, most or all routers in the DFZ handle packets with IPv4 options via their "slow path" - with the CPU rather than the fast forwarding hardware. I have no knowledge of this directly but it was discussed on the RRG and people who I assume do have direct knowledge of this agreed. See RRG msg06001 and: End-to-end measurements on performance penalties of IPv4 options Fransson, P.; Jonsson, A. Global Telecommunications Conference, 2004. GLOBECOM apos;04. IEEE Volume 3, Issue , 29 Nov.-3 Dec. 2004 Page(s): 1441 - 1447 Vol.3 10.1109/GLOCOM.2004.1378221 http://www.sm.luth.se/csee/csn/publications/end_to_end_measurements.pdf The abstract concludes: "From the analysis it can be concluded that there is a slight increase in delay and jitter and a severe increase in loss rate." If you have any evidence that most or all routers in the DFZ and in edge networks can handle IPv4 packets with novel options at full line rate, without excessive losses or delays, please present it. If this was so, then it would greatly expand the possibilities of what can be done with the IPv4 Internet. 2 - GSE and HIP require existing IPv6 applications to be rewritten. Section 9.1 of draft-rja-ilnp-intro-11 claims (to my understanding) that a host with an ILNP stack will perform ILNP communications with today's IPv6 applications: The existing BSD Sockets API can continue to be used with ILNP underneath the API. That API can be implemented in a manner that hides the underlying protocol changes from the applications. For a long while, I and I think other RRG folks - co-chair and ILNP supporter Tony Li included - accepted this notion that ILNP could work without the need to rewrite IPv6 applications. I think this was regarded as a major feature of ILNP over any other Loc-ID Separation protocol. When I tried to figure out how this would work, I couldn't find a way. You didn't respond to my requests for guidance. Tony had a go at it, gave up (it was late) and never tried again: http://www.ietf.org/mail-archive/web/rrg/current/msg07113.html Before giving up, he wrote (msg07111): And having a name oriented stack would be the best solution. ILNP is not a name oriented stack protocol - and any such protocol would require rewritten applications. 3 - As mentioned above with the host ABC and XYZ discussion. 4 - Loc-ID Separation protocols (Core-Edge Elimination protocols) implement mobility by the Mobile Node (MN) getting a new IP address (Locator) and securely updating the global mapping system with this new Locator. Either the MN or the global mapping system then needs to update the mapping stored by any hosts they are currently communicating with. To do this securely will take more time than is acceptable for VoIP. Since a MN may gain new Locators frequently - for instance just for a few seconds when coming into range of a WiFi system which is preferable to a 3G connection, the flurry of mapping updates to the potentially numerous correspondent hosts becomes unreasonably expensive. The LISP protocol's approach to mobility has the same problem, though it is not a Loc-ID Separation protocol. As far as I know, the only way of doing mobility without needing to instantly update the mapping of all the correspondent hosts is my TTR Mobility system, which can be applied to Ivip or LISP, and which I understand is used, in principle, for all communications (mobile and non-mobile networks) in Fred Templin's IRON. http://www.firstpr.com.au/ip/ivip/#mobile The correspondent hosts have mapping to a (typically close to the MN) ITR-like router I call a Translating Tunnel Router. The MN establishes 2-way tunnels to one or more TTRs from each of its potentially multiple IP addresses, which can be behind any number of layers of NAT. As these change, and as the best one to use changes, this is just a matter between the MN and the TTR which is currently receiving all the incoming packets from the correspondent hosts. Loc-ID Separation protocols can't work with the host behind NAT. That's fine when the protocol is used for the IPv6 Internet, but not for IPv4. - Robin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf