Short version:  In what ways do the LISP team think that the current
                Mobile LISP approach is superior to the TTR approach?

                I am certain that Mobile LISP's principle of
                locating the ETR in the MN cannot be made to work
                well enough to be acceptable to most users.

                An alternative has existed since June 2007 and was
                fully documented in August 2008 - the "TTR Mobility
                Extensions for Core-Edge Separation Solutions to the
                Internet's Routing Scaling Problem".

                The TTR approach is well suited to LISP.  It will
                work fine with the MN's CoA behind NAT.  It provides
                continual connectivity as long as the MN has at least
                one functional CoA.  It does not require a mapping
                change every time the MN changes its CoA.

                For most users, if the current TTR is within 1000km
                or so of the MN, then there's no need to use another
                TTR, so there is no need to change the mapping.

                Even if the MN does acquire and rely upon a CoA on
                the other side of the Earth from the current TTR,
                a mapping change is not required.  A mapping change
                is only needed to use a different TTR, and generally
                it is best to use one close to the MN, to reduce
                latency and the risk of packet loss.  The MN can use
                both the old and the new TTRs at the same time, so
                there is no loss of connectivity as the mapping
                change propagates over seconds, minutes or even hours
                to the various ITRs which are handling packets
                addressed to the MN.


Further to my critique:

  http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html


Mobile LISP follows the persistent assumption many people seem to
have when thinking about mobility and a core-edge separation scheme
such as LISP:  that the Mobile Node (MN) should act as its own ETR.

This lead most people to think that extending a core-edge separation
scheme to mobility would be impractical, since this means the mapping
would have to change every time the MN got a new Care-of Address
(CoA) - the address it acquires on some access network, and it may
acquire multiple such CoA addresses on multiple access networks.

Mobile LISP follows this most obvious approach and it is indeed
impractical for both of these two major reasons.  Just one would be
sufficient to make it completely impractical.

  1 - When the MN needs to use a different CoA, connectivity can
      only continue after the mapping has been updated and all
      ITRs which are currently sending packets to the MN's ETR
      function at the old CoA begin using the new mapping.

      This makes the whole proposal a complete non-starter.

      Even with Ivip, which should be able to get mapping updates
      to all ITRs in a few seconds (for a small fee - a few cents
      I guess) this would be a non-starter because even a few seconds
      of lost connectivity is unacceptable.  Furthermore, the cost
      of the updates becomes a significant impediment, considering
      the MN may acquire and use new CoAs frequently and
      automatically - perhaps every few seconds as various radio
      links become available.

      It is even worse with LISP, where there is no way of getting
      mapping to some or all ITRs in a few seconds.  Reducing
      the time delay for all ITRs updating their mapping can
      in some - I guess many - cases only be achieved by shortening
      the caching time, and therefore burdening ITRs and the global
      mapping lookup system with more frequent lookups.

      A MN might have a WiFi CoA and a 3G CoA.  The WiFi link is
      faster, cheaper and generally more reliable, so the WiFi
      CoA is the one to use as long as it is available.  However,
      when the WiFi system becomes unreachable, the MN needs to
      switch to the 3G system within a fraction of a second, with
      no loss of connectivity.  There's no way the current Mobile
      LISP approach can do this.


  2 - The inability of the system to work when the MN's CoA is
      behind NAT.

      ITRs need to be able to tunnel packets to the ETR function
      without any delay, handshaking etc.   This precludes the
      use of complex and time-consuming NAT traversal techniques
      (which, by the way, would be a great way of DOSing the
      MN and whatever servers were involved in the NAT traversal
      stuff).

      In IPv4 (the Internet which everyone relies upon - and the
      only one with a routing scaling problem) most mobile devices
      would be connected to the Net via NAT.  For instance any
      device on cabled or WiFi Ethernet in a home or SOHO setting.

The TTR approach has neither of these problems.  I first described it
on the RAM list in June 2007 (section: "ViP-Mobile"):

  http://www.ietf.org/mail-archive/web/ram/current/msg01518.html

The TTR approach has been available to LISP or any other core-edge
separation scheme since then - 2 years before the release of
draft-meyer-lisp-mn-00.

The TTR approach was fully documented, with diagrams etc. in August 2008:

  http://www.firstpr.com.au/ip/ivip/#mobile
  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

  TTR Mobility Extensions for Core-Edge Separation Solutions to the
  Internet's Routing Scaling Problem
  Robin Whittle, Steven Russert 2008-08-25


  - Robin