Re: [lisp] LISP NAT Traversal

[Sharon <[e-mail]>]

Can also add a  carrier use case -

The RTRs are in POPs, racks of equipment or clusters of servers, stable underlay, very responsive low latency mapping. 

The XTRs are across the access, on or off the carrier footprint, (NAT wise) high latency lookup, potentially shaky conditions.

The RTRs anchor the XTRs. The XTR can reach any of the RTRs (any cast) move, recover from a topology change, or access carrier change.


The mapping Service & Resource Schema apropos yesterday discussion regarding easy mapping abstraction (Albert) for orchestrating NSH (Vina, Fabio) is made available to potentially millions of semi loose XTRs aggregating billions of very loose EIDs, using traversal anchoring without creating a global data consistency nightmare. 

--szb

On Nov 3, 2015, at 5:59 AM, Dino Farinacci <[e-mail]> wrote:

>> Hi,
>> 
>> It will be useful if LISP NAT traversal draft (draft-ermagan-lisp-nat-traversal) can elaborate on the following
> 
> See comments inline. Thanks for having a look at the draft.
> 
>> 1) Why LISP NAT traversal cannot be accomplished without RTR (another network entity) which has implications on deployability, complexity and latency. There are other protocols (e.g IKE/IPsec) that achieve NAT-D and NAT-T without the need for additional network entity.
> 
> There are 2 important scalability reasons:
> 
> (1) You want to keep the number of cache entries in the NAT to a minimum. By using an RTR to encapsulate packets to, there is only a single NAT entry.
> 
> (2) When the xTR moves, you want its new locator to be advertised to the fewest number of places in the network. So if the RTR is the only one encapsulating to the xTR then it only has to be updated.
> 
>> 2) Some more details on RTR deployment
>> - location of RTR in the LISP deployment like there are recommendations on PITR/PETR deployments
> 
> The location of the RTR is desiraable to be close to the current location of the xTR so we can minimize packet stretch. Hence when an xTR moves, the Map-Server (which is fixed and doesn’t need to be close to the moving xTR since it is a control-plane function), tells the xTR of a new set of RTRs that is close to it, in the xTRs new location.
> 
> This is mostly policy information in the mapping system.
> 
>> - is RTR shared across LISP sites behind NAT or each site needs a dedicated RTR
> 
> Yes, we envision that millions of xTRs can use the same set of RTRs (i.e. a pair of RTRs that are topologically close to each other and the xTRs that are using them).
> 
>> - what if RTR is behind another NAT (SP-NAT)
> 
> By protocol specification, it should be in public space. But I have an implementation where NAT-traversal works when both the xTR and RTR are behind NATs (different NATs).
> 
>> 3) How is multiple-NAT handled (e.g. enterprise and SP NAT)
> 
> If you have an xTR that is multi-homed to 2 NATs, then Info-Requests are sent each way to both the map-server and to RTRs that map-server has advertised. In the registration, one can decide which RTR is used by remote ITRs encapsulating toward the EIDs behind the xTR. And the xTR can load-split traffic (outgoing traffic) across the RTRs in the list the map-server provided.
> 
> Thanks,
> Dino
> 
>> 
>> Thanks,
>> -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK
>> Senior Technical Leader
>> CSG PI Services Security - India  
>> 
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp