[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 at iab.org
https://www1.ietf.org/mailman/listinfo/ram