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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Darrel,

Thanks for the clarification... see below.

On 2008-03-12 17:14, Darrel Lewis (darlewis) wrote:
>  
> 
>>> You can consider PTRs optional, but NAT is a core 
>> requirement for any 
>>> sensible interworking between LISP and non LISP-NR sites.
>> Can you expand on that a bit please? I have a little trouble 
>> parsing "non LISP Non-Routable". And by "NAT" do you mean "LISP-NAT"
>> specifically?
>>
> 
> Brian,
> 
> Sorry about the jargon above.  I was using terms defined in the draft
> that aren't very easy to parse.  Also, I think I have a Boolean problem
> in the above statement, so let me take it over again from the top.
> 
> To be more clear, LISP-NAT and PTR are two ways (they have some nice
> synergies, but are independent) for LISP sites whose EIDs are not found
> in the DFZ to communicate with non-LISP sites. 
> 
>  LISP-NR is a short for LISP-Non Routable, that is a site whose EIDs are
> found only in the LISP Mapping database, and _not_ in the Internet DFZ.
> 
>  LISP-R is short for  LISP Routable, that is a site whose EIDs are found
> both in the LISP Mapping database, and the Internet DFZ. 
> 
> LISP-NAT is a form of NAT that allows for LISP-NR addressed hosts to
> send packets who's sources get translated to LISP-R addresses.  LISP-NAT
> confines the Interworking problem to be site specific, which some sites
> may consider a benefit.  It has the classic limitations of NAT,
> including the 'global directory' problem:  Which of the two EIDs are in
> DNS, the LISP-NR EID, or the LISP-R EID?
> 
> PTRs are network elements that advertise (highly) aggregated LISP-NR
> space into the DMZ (essentially making it routable).  These devices act
> _only_ as ITRs and encapsulate traffic destined to LISP-NR sites.   Note
> that return traffic does not back go through the PTR, but is returned
> natively (not lisp encapsulated) by the LISP-NR site's xTR to the
> originating host.
> 
> LISP-NAT can work along side PTRs nicely, I can describe how this works
> in more detail if there is interest.  But the trade off in this space is
> that PTRs allow for sites not to have to deal with Interworking, at the
> cost of connections inbound to the site potentially having stretch.
> LISP-NAT allows site independent Interworking, with the (pretty well
> understood) limitations of NAT.

I was afraid you'd say that ;-). I think there will be a lot of resistance
to a solution that require v6-v6 NAT; we pretty much know NAT is
inevitable to deal with IPv4 address space, but it would be very
distressing to have non-reversible mappings in the IPv6 address
space. LISP has the nice property of reversing the mapping in
general, and I don't like any solution that loses it.

     Brian

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