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

[Robin Whittle <rw@firstpr.com.au>]

Hi Scott,

You wrote:

>> LISP-EMACS ... does not seem to be tied to LISP-ALT
> 
> That's right.

OK - but I understand that the multicast system is on an overlay
system of special routers, which use GRE tunnels - and presumably
their own instance of BGP - much like that of the LISP-ALT system.


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

OK.  In LISP you are not relying on an ETR to give short-term new
information about which ETR to tunnel packets to, because the
options have already been spelt out in the mapping data which the
ITR has previously received and cached.

But still it seems like:

   Here are my friend's phone number and mine.  Whenever you want
   to call one of us, call my number first, then hers if mine is
   disconnected.  Anyone who wants to know our current numbers can
   phone us as just described.

Whereas I would have thought it better to say, for the second sentence:

   Anyone who wants to know our numbers can call directory
   assistance.

To me, an ETR is for decapsulating packets and getting them to the
destination host - so they may be deep within ISP networks.  Being a
reliable, redundant, secure, source of mapping information is a
totally different task, best suited to a more centralised - but
still distributed - system designed for this purpose.


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

I guess it is a philosophical difference.  I prefer to make an
optimised system for mapping information, which does not necessarily
have anything to do with the ETRs.  Ivip end-users can choose to
make their ETRs the authoritative source of mapping information -
but they are not forced to.

The ETR would be generally owned and operated by the ISP.  With
Ivip, the end-user controls their own mapping via some secured
access directly or indirectly to a RUAS (Root Update Authorisation
Server).  This is more complex and flexible than the fixed
arrangement you have in LISP.  For example, it enables an end-user
to contract another company, unrelated to any of their ISPs, to run
an automated system to monitor their connectivity and ETRs, and
change the mapping information to restore connectivity and spread
load etc. however they desire - without involving their own servers
which are typically dependent on the very connectivity which is
threatened by the outages the system is supposed to cope with.


>> 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 think it is a new network in a logical sense, even though its data
links are carried in tunnels over existing data links.  You run
routers, each with their own LISP-ALT/EMACS-specific BPG instance
and ASN system.


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

The LISP-EMACS ID's Problem Statement mentions APT as one of the
proposed mapping mechanisms for LISP.  The APT ID:

  http://tools.ietf.org/html/draft-jen-apt-00

is cited, but I think APT is supposed to work with eFIT, not LISP.
Perhaps someone can correct me.

eFIT-APT involves Default Mappers receiving the full set of mapping
updates (slowly) via BPG (or maybe some other mechanism?) - so I
think there is no need for approaches such as LISP-EMACS or LISP-ALT
with eFIT-APT.


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

When I proposed "anycast ITRs in the core" in June, I was criticised
by some LISP people and urged to write it up in an ID.  A month
later I produced a comprehensive ID.

Now, it seems, LISP may adopt something which looks the same to me -
but you may be calling "proxy ITRs".  I am keen to see a well
documented example of this.  I think it is the only way forward and
that if it turns out to be in principle the same as what I proposed,
you should at least mention that your proposal bears some
resemblance to Ivip's approach, and probably to what Eliot
contemplates for LISP-NERD.  This is needed so that newcomers to
this field do not see the two approaches as being fundamentally
different, just because they use different terminology, come from
different teams and apply to different ITR-ETR 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.

Sure.  This is an ambitious exercise with far-reaching consequences.
 If a whole ID, or even a whole proposal, does nothing more than
provoke someone into thinking of something better which is actually
used, then I figure it was a worthwhile exercise.

  - Robin


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