Re: [RRG] LISP and IP Interworking - Anycast PTRs == Ivip
Robin Whittle <rw@firstpr.com.au> Sat, 01 December 2007 08:23 UTC
Envelope-to: rrg-data@psg.com
Delivery-date: Sat, 01 Dec 2007 08:26:09 +0000
Message-ID: <47511A08.9070306@firstpr.com.au>
Date: Sat, 01 Dec 2007 19:23:36 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Routing Research Group list <rrg@psg.com>
Cc: "Darrel Lewis (darlewis)" <darlewis@cisco.com>
Subject: Re: [RRG] LISP and IP Interworking - Anycast PTRs == Ivip
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Hi Darrel, Thanks for posting this text, which I assume will become an ID soon. In recent months there have been various on-list references to LISP "Proxy Tunnel Routers" for ensuring sites without ITRs can send packets to hosts with LISP-mapped (EID) addresses. There has also been discussion of using "NAT" for this purpose. Now we have a full description of these two approaches: http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt Your LISP "Proxy Tunnel Router" approach is in principle, and in most details, identical to the "Anycast ITRs in the core" idea I posted to the RAM list over five months ago (2007-06-15). http://www1.ietf.org/mail-archive/web/ram/current/msg01518.html That was within 24 hours of me thinking of the idea - which has proven to be useful and novel - at least in terms of what is in IDs, list messages etc. The on-list and private responses I received in June from some LISP folks was unsympathetic - there was no encouragement or constructive criticism. I was urged - by LISP and non-LISP folks alike - to write an ID. A month later I produced: http://tools.ietf.org/html/draft-whittle-ivip-arch-00 Since then, this ID seems to have been ignored by LISP people. There is much more to Ivip than "anycast ITRs in the core", but that was the starting point which prompted me to develop some new ideas. Eliot developed a similar "anycast ITRs in the core" approach for LISP-NERD. It seems, from the language with which he expressed his ideas, that he developed this independently of whatever he might have known about Ivip. He acknowledged that his approach resembles mine: http://psg.com/lists/rrg/2007/msg00260.html http://psg.com/lists/rrg/2007/msg00264.html http://psg.com/lists/rrg/2007/msg00288.html Your new lisp-interworking-00.txt doesn't mention Ivip or my proposal of this approach in mid-June. There are two reasons why I think your new ID should explicitly acknowledge the similarity between "Proxy Tunnel Routers" and Ivip - even if you developed PTRs completely independently of anything I wrote. Firstly, it seems I was the first to propose this arrangement in a public document or mailing list message. Secondly and more importantly, I believe you should assist readers in understanding the various ITR-ETR proposals by pointing out what goals, mechanisms and outcomes your proposal shares with other proposals, and how it differs. There is a whole section in the Ivip ID - over 5 pages - devoted to showing how Ivip and LISP differ, and what they have in common. Incremental deployability has always been a fundamental requirement of any ITR-ETR scheme. At the start of December, LISP finally gained a mechanism which enables it to be incrementally deployable. The IDs are: http://tools.ietf.org/html/draft-farinacci-lisp-05 (43pp) http://tools.ietf.org/html/draft-lear-lisp-nerd-02 (29pp) http://tools.ietf.org/html/draft-meyer-lisp-cons-03 (21pp) http://tools.ietf.org/html/draft-fuller-lisp-alt-01 (17pp) http://tools.ietf.org/html/draft-curran-lisp-emacs-00 (9pp) http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt(13pp) These 132 pages are longer than Ivip's 105 - or 116 including IPTM. Is there some kind of inverse relationship between funding and output in this field? ist-RiNG has lots of money. So far it has produced no technical documents and no discussion. Apart from John Curran, who works for servervault.com, and Noel Chiappa, who is is an independent researcher - as I am - LISP authors all work for Cisco Systems. I assume you folks at Cisco are doing at least some of your LISP work as part of your paid employment - yet it took you longer to create an incrementally deployable ITR-ETR scheme than it took me. At the very least, I assume Cisco sometimes flies you to IETF and other meetings where you can pursue LISP work. I don't work on Ivip or RRG correspondence in my employer's time. I am self employed and it costs me lost income to do this stuff. Yet my results come sooner - and I think they are easy to read and understand. I request anyone who is seriously interested in ITR-ETR schemes to read the Ivip ID, Fred's sprite-mtu work, my IPTM work: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ and the recent excellent discussion between Fred and me on this list. All ITR-ETR schemes need a solution for the PMTUD and fragmentation problem. I have read nothing substantial from the LISP team on how to solve this. Then, please provide critiques, alternative ideas, reports of difficulty in understanding etc. on-list or privately. I found your new ID generally easier to read than the earlier LISP IDs. The examples were particularly helpful. However, I suggest you use terminology indicating explicit packet flow direction rather than "talk to" and "speaking to". Here is a critique of LISP-NAT, based on my potentially faulty understanding. 1 - LISP-NAT does not solve the problem which "(typically) Anycast ITRs in the Core" (Ivip, LISP PTR) does - the problem of how a host in a site with no ITR can send a packet to a host with a LISP-mapped address (EID) and have that packet delivered properly - that is, via an ITR which tunnels it to the correct ETR. This problem exists irrespective of whether the ordinary host or the host with the LISP-mapped (EID) address initiates a two-way communication. The Net needs to work for single, isolated, packets. LISP-NAT only helps in a two-way communication session - and then only when the host with the LISP-mapped (EID) address initiates this session. 2 - The LISP-NAT device can only do its work for as many concurrently active hosts with LISP-mapped (EID) addresses as the device has "publicly routable" IP addresses. These "publicly routable" addresses are either ordinary addresses, for exclusive use for this LISP-NAT purpose, or they are a curious thing - "LISP-R" addresses. As I understand it, a "LISP-R" address is a LISP-mapped address (an EID - an address such that an ITR handling a packet addressed to this address would encapsulate the packet and tunnel it to a specific ETR close to the destination host which actually has this address) *and* which is also part of an advertised BGP prefix and reachable via ordinary BGP router forwarding. This means, I think, that this address is not covered by PTRs which advertise the prefix which it is within. This means that there are two ways a packet could get to the router which handles this LISP-R address. Firstly, it could originate in a site with a LISP ITR, which would tunnel the packet to the ETR (presumably the same router which is responsible for this address). Secondly, if the packet originates in a host in a site with no LISP ITR, it arrives by ordinary forwarding through the BGP router system. As such, the use of LISP-R address space seems to introduce complexities and limitations which make it unsuitable for robust multihoming, or portability between ISPs. 3 - Therefore, LISP-NAT provides no multihoming, portability etc. benefits, for the packets coming from the host in the site with no ITR - while "Anycast ITRs in the Core" (Ivip, LISP PTR) provides all these the benefits. 4 - It is not clear how long the NAT-ITR should maintain the association between the LISP-mapped host's address and the LISP-R address in the translation pool. If there is a pause in activity, the communicating hosts reasonably expect to be able to send packets to each other in the future. But unless the NAT-ITR has as many LISP-R addresses in its pool as it has LISP-mapped host addresses, it will have to recycle the pool addresses at some point in time, with the risk that a remote host will send a packet to a pool address which has now been associated with a different LISP-mapped host than the one it was previously communicating with. If these criticisms are valid, I believe the ID should explicitly convey these limitations to the reader in some way. I thought section 2 (LISP Internetworking Models) was systematic and well written. However, it left me with the impression that both the PTR and the LISP-NAT would solve the problem you identified: The most challenging case, case 4, occurs when a host at a non-LISP source site sends a packet to a host in a LISP site. If the source host chooses a non-routable EID address, the packet continue to be forwarded (inside the domain) until it reaches a router which cannot forward it, at which point the packet is dropped. So either the EID that the destination site is making available for other sites is routed outside of LISP or an alternate mechanisms need to be in place to solve this. This specification describes two alternate interworking mechanisms, Proxy Tunnel Router (PTR) (Section 5) and LISP-NAT (Section 6). In fact, LISP-NAT only works in a two-way communication is initiated by a host with a LISP-mapped address, and then only by using a separate range of addresses which must be in an ordinary BGP prefix. Below are some typos which I think would be good to correct. - Robin Page 7 ... on behalf LISP sites to non-LISP sites can reach ... ... on behalf of LISP sites so non-LISP sites can reach ... Rather than deploying PTRs close the LISP sites, they get deployed close to the non-LISP sites. Rather than deploying PTRs close to the LISP sites, they are deployed close to the non-LISP sites. I didn't understand the term "scoping". Page 8 Two instances of "140.1.1.1" should be "140.0.0.1". 4. The PE has route to .... 4. The PE has a route to .... Page 9 in order to have a course way to control ... in order to have a coarse way to control ... There are several that a network using PTRs would place the PTR as close as possible to non-LISP sites. Perhaps: There are several (burdens/impacts) that a network using PTRs would place on the PTR .... but then the rest of it doesn't make sense to me. traffic will be routed towards ... (extra newlines) -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
- Re: [RRG] LISP and IP Interworking - Anycast PTRs… Robin Whittle
- Re: [RRG] LISP and IP Interworking - Anycast PTRs… Eliot Lear
- Re: [RRG] LISP and IP Interworking - Anycast PTRs… Robin Whittle
- Re: [RRG] LISP and IP Interworking - Anycast PTRs… Robin Whittle
- Re: [RRG] LISP and IP Interworking - Anycast PTRs… Tony Li
- Re: [RRG] LISP and IP Interworking - Anycast PTRs… Robin Whittle