Re: [RRG] Comments on draft-lewis-lisp-interworking

[Robin Whittle <rw@firstpr.com.au>]

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 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