Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared

>   http://tools.ietf.org/html/draft-farinacci-lisp

I would suggest http://www.dinof.net/~dino/ietf/draft-farinacci- 
lisp-02.txt.

>   http://tools.ietf.org/html/draft-meyer-lisp-cons-00 (July 3)

I would suggest http://www.dinof.net/~dino/ietf/draft-meyer-cons-01.txt.

> While NERD is "push", in comparison to CONS - which is purely a
> query and cache system - the mapping updates are not actually sent
> to the ITRs.  Each ITR has to poll a server and retrieve the

What you state above is not clear if you are talking about NERD or  
CONS. But in both cases the ITR can get mappings. That is if the ITR  
has enough storage capacity it can take the entire NERD database. In  
CONS, the ITRs make requests over TCP connections to their peering  
CARs that return mapping replies back to them.

> LISP-CONS is a "pull" system.  ITRs query and cache the mapping
> data, via local CARs which also cache.  Requests and replies
> traverse a mesh of CARs and (non-caching) CDR servers, all linked
> via authenticated TCP sessions.

So maybe you were talking about about NERD. Just wanted to clarify  
though.

>     This will lead to much faster and more reliable query
>     responses than LISP-CONS - but as with Ivip, raises the
>     challenging problem of distributing the database updates in
>     real-time to all these Default Mappers.  However, eFIT-APT
>     has very slow goals regarding the speed of distributing
>     these updates.

I was told by a credible source that most DNS servers cannot handle a  
DNS query packet with multiple query types in it. So you will need  
numerous changes to DNS servers to get QSDs to work. In my book, that  
is a non-starter.

> Here are some questions about each scheme, with "LISP" implying
> LISP 3.x.  There is no concrete information about LISP 3.x other
> than that implied by NERD and CONS that I won't consider how LISP
> might work with APT.

LISP 3.X is not a protocol. It refers to doing encapsulation with an  
external mapping database service such as NERD, CONS, or APT.

The variants are models where LISP 1 and LISP 1.5 use a data- 
triggered mapping model. LISP 2 uses the directory already deployed  
on the network which is DNS, and LISP 3 are new models which you see  
there is a lot of activity on.

> Encapsulation of data
> ---------------------
>
> LISP-NERD/CONS: Not documented yet, but presumably using UDP, with
> the outer source address being that of the ITR which encapsulated
> the packet. (Outer SA = ITR's address.)  See the recent messages
> "ETRs checking src & dest addresses" about how I think this makes
> it harder for the ETR's filtering system to protect against
> spoofing of local source addresses.

Encapsulation is defined in draft LISP-02. NERD and CONS are control- 
plane mapping database services only.

> LISP-NERD/CONS:  As noted above, ITRs have complex functions,
> including making decisions on a packet-by-packet basis for MH
> service restoration, TE and I think load balancing functions.  The
> ITR may or may not communicate with the ETR, but I think the ITR
> is always ready to accept ICMP messages as sign it is tunneling
> the data packets to the wrong address.

I beg to differ. The ITR simply does a cache lookup on the DA when  
the DA has a routing table miss or a default route match. When the  
cache lookup returns an RLOC it slaps a header on. It's as simple as  
that.

> Since LISP-mapped addresses are not in any prefix which is
> advertised in BGP, ITRs must be inside or at the border of
> provider or end-user networks.

This is not true. If you wanted to put an ITR at a PE edge and the  
EID-prefixes for each site connected to the PE advertised them via  
BGP, the ITR could act as an ETR for packets it receives from the  
provider network. For encapsulating, you still need a mapping database.

> LISP-NERD/CONS: ETRs are located in the provider network or at its
> border router, or in the end-user's network or at its border (CE)
> with the provider network - as long as the address is BGP
> reachable.  I think ETRs have complex communication functions.

NERD and CONS say nothing about where ETRs are placed in the network.  
And they don't need to either.

> Incremental deployability
> -------------------------
>
> LISP-NERD/CONS: According to current definitions and all my
> off-list attempts to understand LISP, LISP-mapped addresses are
> not part of BGP advertised prefixes.  So in order for a host to
> send packets to a host on any LISP-mapped address, the sending
> host must be in a network with an ITR.  I think this makes LISP

Or the EIDs are from PA space or the EIDs are from PI space that  
continues to get advertised into the network. There will be these PIs  
that will never be withdrawn. And this is a good thing. We just don't  
want all sites to do this.

> not at all incrementally deployable.  Why would an early adopter
> want to use LISP-mapped addresses when it will make their hosts
> unreachable for any communication initiated by a host on a
> non-LISP-upgraded network?

This is not true. Remember what else you need for an incrementally  
deployed design. That is no changes to hosts, no changes to DNS, no  
changes to core routers. LISP requires *only changes* to CE routers.  
Or P-routers in the core if you need LISP for ISP-based TE.

There are many respects to incrementally deployable not just an non- 
LISP site talking to a LISP-site.

> As with all proposals, there are major challenges in setting up
> the infrastructure.  Ivip's Replicator and ITR system is
> adventurous, but the ITRs are doing a simpler job and the overall
> design is simpler than the designs of other proposals.  The ETRs
> are free-wheeling, low-cost devices and require no coordination.
> With sufficient provider networks with ETRs, one or more
> independent Ivip or Ivip-like systems could be set up, and work
> fine alongside each other (each with their own set of core ITRs,
> or perhaps all driving data to a common set).  These could
> probably run at a profit, because they provide portability,
> multihoming (with basic TE) and mobility with full reachability
> (and generally pretty good path lengths, if the core-ITRs are well
> distributed) from all hosts.

I haven't heard how any of the non-LISP proposals deal with ISP-based  
traffic engineering and multicast.

Dino

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram