Re: [RRG] LISP-EMACS (was: LISPEMACS & LISP-ALT)

[Scott Brim <swb@employees.org>]

This response is about LISP-EMACS.

Excerpts from Robin Whittle on Fri, Nov 16, 2007 11:40:48PM +1100:
> LISP-EMACS ("EID-mappings Multicast Across Cooperating Systems for
> LISP"):
> 
>   http://tools.ietf.org/html/draft-curran-lisp-emacs-00
> 
> does not seem to be tied to LISP-ALT

That's right.

> The idea is that an ITR which has no mapping for a particular EID
> sends the traffic packet to this EMACS multicast system, which
> quickly sends it to the ETR which has the authoritative mapping (and
> I guess which is also the ETR which is supposed to handle the packet
> - though it makes no sense to me to have mapping authority vested in
> such far flung ETRs which are at risk of being unreachable) . . .

Did I answer this "unreachable" question in the last message?  It's
fate-sharing.  If the ETR is unreachable for mapping, then it's
unreachable for forwarding, and vice versa.  If you decouple
administratively-configured mapping servers from real-world
forwarders, you need some other mechanism to couple them.  The nice
thing about LISP-EMACS and LISP-ALT is that no separate mapping server
is required.  Theory matches reality.

> This seems somewhat nifty to me, but there are some scaling problems
> - and I think it is a lot of trouble to set up a whole global
> network like this, with BGP, ASNs etc.

Again, there's no separate network.

> I don't understand how LISP and APT work together, but APT has full
> database default mappers in each ISP network - so I don't think an
> LISP-EMACS-like system is needed with eFIT-APT.

Default mappers are an orthogonal feature.  Whether default mappers
exist or not, there needs to be a mechanism to figure out where to
send the first few packets.  Default mappers take care of this on
behalf of a site or set of sites, but still the default mappers need
the same information -- how to forward the first few packets -- as any
node would if it didn't have a default mapper.  A default mapper just
moves and concentrates the problem.  Also look at CRIO and LISP-EMACS
and destination-side default forwarders (DSDFs).

> LISP-EMACS does not solve the primary problem of LISP: that that
> packets from non-upgraded networks will never find their way to the
> EID addressed destination host, since (in the original conception)
> the EID addresses are not part of any conventional BGP advertised
> prefix.  (See http://psg.com/lists/rrg/2007/msg00529.html for
> possible extensions to CONS and NERD to maintain BGP advertisements
> for prefixes containing EID addresses.)

Transition issues are 80-90% orthogonal to what control plane
mechanism is used.  For example, proxy ITRs can be used with any of
these schemes.

> My main concern is the traffic amplification which this multicast
> system entails.  

Yup.  As we said in the draft, this is one of the issues that requires
further study.  LISP-EMACS was *not* presented as a beautifully
polished work of art.  It is potentially "nifty" as you say, but we
aren't sure of the right way to attack some of the problems, so we put
it out there for everyone else who like the basic premise to think
about those problems and contribute solutions.

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