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

["Darrel Lewis (darlewis)" <darlewis@cisco.com>]

> The LISP-NAT approach doesn't seem useful to me.  See my 4 point
> critique:
> 
>   http://psg.com/lists/rrg/2007/msg00674.html
> 
> I don't recall any response to that critique.
> 
>   - Robin

Robin,

I'm sorry that I didn't respond to your critique of LISP-NAT.  It got
tail dropped from the queue until this reminder.   I'm going to paste
your points below and respond to them in order.  My comments are
prefaced with <DL>.

You wrote:
--------------------
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.
--------------------------------
<DL>
LISP-NAT works when the LISP-NR EID side initiates the connection, true.
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.
</DL>
------------------------------------
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.
---------------------------
<DL>
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).
</DL>


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

-------------------
<DL>
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.
</DL>

-----------------------------
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.
-----------------------------
<DL> 
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.
</DL>


Regards,

-Darrel

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