Hi Darrel, Thanks very much for your response to my points 1 to 4 in:
> http://psg.com/lists/rrg/2007/msg00674.html 1 > LISP-NAT works when the LISP-NR EID side initiates the connection, true. OK - that is my main critique. A further critique is that the nature of the communication session must be recognised by the NAT box in order to associate packets coming from the outside world. This would often be the case, but if the application involved a response coming back on a different UDP or TCP port, or involved some other protocol such as SCTP which the NAT box wasn't aware of, then it wouldn't work. > However, it works when non-LISP site initiates the connection as well > assuming the DNS address for the host resolves to the LISP-R (the > outside nat) address. This is a well understood NAT problem. I can't imagine how this would be useful. The NAT box would need to know a particular address and perhaps port, and forward packets received there to a particular host on a LISP-mapped address, with address translation. Then the application code at both ends needs to be able to cope with the translations. However my main concern is that this approach would involve manual configuration, fixed uses for addresses, a host having one address in the global DNS and another on its LISP-mapped actual address etc. I can't imagine how this could be useful enough to deploy, when Proxy Tunnel Routers do everything needed already. 2 > LISP-R addresses are found both in the LISP Mapping system and in the > DFZ. There are several possible reasons for their existance. One being > PA addresses assigned by a provider to a site for use as a NAT pool. A > second example would be an existing site with PI addressing that does > not choose to remove their existing addresses from the DMZ, but wants to > implement LISP (note that this doesn't require the site to use NAT). Since I can see LISP-NAT only being useful for outgoing sessions from LISP-R hosts (assuming the protocol is supported by NAT) I don't see how your statement alters my critique: 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. For instance, how do you multihome and maintain connectivity when using PA NAT pool addresses from ISP-A, and that ISP goes down and you need to use ISP-B instead? Portability isn't so bad in this respect, but I think that for NAT to be in any way usable, you would need something like what (I think) you suggested in your response to point 1, which I think involves careful configuration of the NAT system to accept incoming packets on particular addresses and translate them to particular LISP-R hosts. Perhaps I don't have a clear enough understanding of what you are suggesting, but if I do, then the system looks unwieldy and requires a great deal of careful manual configuration when changing from one ISP to another - and it can't provide session continuity in a multihoming service restoration situation. 3 > Sorry but I don't think this aguement has merit based on my explanation > of 1. and 2., above. I do agree with your second statement that > LISP-PTRs are a viable alternative, however. I haven't changed my mind about LISP-NAT being only partially useful - not enough to be deployed. 4 (NAT association time-outs) > How exactly the LISP-NAT pool is maintained an implementaiton detail > that I think at this point is out of scope of the Interworking draft. > The draft keeps this deliberately simple in order to foster an > implementation that can be used to gain more experience on how this will > work in the real world. I don't think you need experience in the field to establish that there is no clear way your NAT system can know when to time-out an association. So you have to trade off robustness for existing sessions with how many sessions you can support on a given sized NAT pool. Proxy Tunnel Routers (the same as Ivip's "anycast ITRs in the core/DFZ") have no such problem. Since Proxy Tunnel Routers do the trick, I can't imagine what help it would be to have LISP-NAT, which seems more complex, hard to configure and prone to failure. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] 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
